Die Anweisung in [...] verwies auf Arbeitsspeicher bei [...]

[AuronTLG]

Moin,
ich hätte hier mal ein Problem wo ich Tipps gebrauchen könnte.
Ich habe ein Programm, an dem ich zur Vorversion einige Änderungen durchgeführt habe. Dieses Programm hat weiterhin eine Anmeldemaske, bei der man auch direkt wieder abbrechen und es damit schließen kann.

Mir ist beim Kompilieren nun zufällig aufgefallen, dass, wenn ich das Programm direkt in der Anmeldemaske schließe, das Programmsymbol in der Taskleiste unten verschwindet, dann aber direkt nochmal das Programm wieder in der Taskleiste aufploppt, nur ohne Icon, und nach paar Sekunden entweder wieder verschwindet, oder aber auch häufig folgenden Fehler schmeißt:

Zitat:

Die Anweisung in 0x000000000A695DF4 verwies auf
Arbeitsspeicher bei 0x000000000A695DF4. Der Vorgang
written konnte im Arbeitsspeicher nicht durchgeführt
werden.

Klicken sie auf "OK", um das Programm zu beenden.

Wenn ich mich anmelde, das Programm dementsprechend vollständig startet und ich es dann schließe, ist alles wunderbar.
Geschlossen wird das Programm über Application.Terminate, was auch problemlos ausgeführt wird. Das Problem manifestiert sich also irgendwo in den abschließenden Operationen der Windows-API, die ja vom Terminate ausgelöst werden.
Das Problem ist unabhängig vom PC nachvollziehbar und tritt mit der Programmvorversion (selbe Delphi-Version) nicht auf, also habe ich es in irgendeiner Form hineingebaut.

Eine genauere Beschreibung kann ich leider nicht geben, da ich in der Version einiges, aber nichts technisch außergewöhnliches, gemacht habe und momentan keinen Anhaltspunkt dafür habe, was das ausgelöst haben könnte.

Hat jemand Ahnung bzw Erfahrung damit, was solch einen Fehler für gewöhnlich auslösen kann? Ich sehe diesen nämlich zum ersten Mal und das Internet liefert mir viel zu viele Möglichkeiten, die aber nicht hierzu passen.

[jaenicke]

Bekommst du den Fehler im Debugger nicht? Dort solltest du ja mehr sehen können, insbesondere den Stacktrace.

[AuronTLG]

Damit habe ich eben mal etwas herumprobiert.
Im Debugger bekomme ich nicht immer dasselbe, aber beim am häufigsten auftretenden Fehler hält er tief in der CPU.
Der Stacktrace sieht in diesem Fall von oben nach unten mehr oder weniger folgendermaßen aus:

Zitat:

C:\WINDOWS\SysWOW64\user32.dll
user32.SendMessageW + 0x46
Vcl.Controls.DestroyChildWindow(???,???)
user32.EnumChildWindows + 0x8c
Vcl.Controls.TWinControl.DestroyHandle
Vcl.Controls.TWinControl.CMRecreateWnd(???)
Vcl.Controls.TControl.WndProc(???)
Vcl.Controls.TWinControl.WndProc((45107, 0, 0, 0, 0, 0, (), 0, 0, (), 0, 0, ()))
Vcl.Controls.TControl.Perform(???,???,0)
Vcl.Forms.TCustomForm.WndProc((45145, 0, 0, 0, 0, 0, (), 0, 0, (), 0, 0, ()))
Vcl.Controls.TWinControl.MainWndProc(???)
System.Classes.StdWndProc(2820586,45145,0,0)
C:\WINDOWS\SysWOW64\user32.dll
user32.SendMessageW + 0x46
Vcl.Themes.TStyleManager.SetStyle(???)
Vcl.Styles.Finalization
System.FinalizeUnits
System._Halt0

Ich bin mir dabei nicht sicher, wie sehr ich mich auf diesen Fehlerstack versteifen sollte. Ich verwende VCL-Styles, habe an diesen aber im Vergleich zu vorigen Version eigentlich nichts geändert. Wenn diese Exception mein Problem sein sollte, kann das vielleicht auch ein Folgefehler sein?

Ergänzung: Wegen Optimierung kann ich im Debugger leider keine genaueren Information dazu sehen, was da genau passiert, wie z.B. welche WinControl etc das ist.

[Bbommel]

Hast du die Debug-DCUs eingeschaltet? Falls nicht, mach das mal, dann landest du ggf. an einer aussagekräftigeren Stelle und kannst dich besser an die Stelle in deinem Code hangeln, wo das Problem auftritt.

[AuronTLG]

Debug-DCUs sind angeschaltet.

[jaenicke]

Deaktiviere am besten mal testweise die Styles.

[AuronTLG]

Mit deaktivierten Styles tritt das Problem immer noch auf, war also ein Folgefehler; die Exception, bei der er im Debugger anhält, ist jedoch anders.
Anhalten tut er natürlich in der CPU, der Stack sieht aber dann folgendermaßen aus:

Zitat:

:09703206
:0970232c
:0964a82e
:76807ba9 KERNEL32.BaseThreadInitThunk + 0x19
:779ec0cb ntdll.RtlInitializeExceptionChain + 0x6b
:779ec04f ntdll.RtlClearBits + 0xbf

Da das alles in der CPU hängt, kann ich da leider nicht viel mehr rauslesen.

[Sinspin]

Hey, nach dem was du beschreibst würde ich darauf tippen das ein anderer Thread nicht mitbekommen hat dass der Main Thread nicht mehr existiert und noch fröhlich Daten sendet.
Das kann immer passieren. Deshalb sollte jeder Thread ein ordentliches Fehlerhandling haben damit das nicht bis ins System durchrauscht.
Application.Terminate ist generell keine Lösung zum geregelten Beenden eines Programms.

[peterbelow]

Zitat von AuronTLG:

Moin,
ich hätte hier mal ein Problem wo ich Tipps gebrauchen könnte.
Ich habe ein Programm, an dem ich zur Vorversion einige Änderungen durchgeführt habe. Dieses Programm hat weiterhin eine Anmeldemaske, bei der man auch direkt wieder abbrechen und es damit schließen kann.

Mir ist beim Kompilieren nun zufällig aufgefallen, dass, wenn ich das Programm direkt in der Anmeldemaske schließe, das Programmsymbol in der Taskleiste unten verschwindet, dann aber direkt nochmal das Programm wieder in der Taskleiste aufploppt, nur ohne Icon, und nach paar Sekunden entweder wieder verschwindet, oder aber auch häufig folgenden Fehler schmeißt:

Wo wird das Anmeldeform erzeugt und angezeigt? Aus einem Event des Mainforms oder per Kode im DPR-File? Das ist vermutlich relevant da das von Application.Terminate gesetzte Flag erst greift, wenn Application.Run ausgeführt wird. Da kann dann noch so einiges ausgeführt werden nachdem das Anmeldeform geschlossen wurde.

[AuronTLG]

Zitat:

Wo wird das Anmeldeform erzeugt und angezeigt? Aus einem Event des Mainforms oder per Kode im DPR-File? Das ist vermutlich relevant da das von Application.Terminate gesetzte Flag erst greift, wenn Application.Run ausgeführt wird. Da kann dann noch so einiges ausgeführt werden nachdem das Anmeldeform geschlossen wurde.

Per Code im DPR File vor dem Application.Run. War in der vorigen Version aber genauso. Im ganzen DPR-File hat sich nichts Relevantes geändert.

Zitat:

Hey, nach dem was du beschreibst würde ich darauf tippen das ein anderer Thread nicht mitbekommen hat dass der Main Thread nicht mehr existiert und noch fröhlich Daten sendet.
Das kann immer passieren. Deshalb sollte jeder Thread ein ordentliches Fehlerhandling haben damit das nicht bis ins System durchrauscht.
Application.Terminate ist generell keine Lösung zum geregelten Beenden eines Programms.

Ich werde sicherheitshalber mal etwaige Threads überprüfen. Update: Zu diesem Zeitpunkt sind keine eigenen Threads am laufen.
Abgesehen davon, Terminate wird nur zum Schließen bei der Anmeldung verwendet, ansonsten läuft es über die Hauptform. Was wäre denn in diesem Fall die bessere Option? Terminate ist doch eine sehr sanfte Option zum codeseitigen Schließen des Programmes.