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

[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.

[jaenicke]

Zitat von AuronTLG:

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

Hast du alle Threads durchgeschaut?

[AuronTLG]

Zitat:

Hast du alle Threads durchgeschaut?

Jo. Zum Zeitpunkt der Exception gibt es abgesehen vom Hauptthread nur Systemthreads (Kernel32, ntdll, win32...), von denen die meisten auf irgendeiner Form von WaitFor stehen.
Die erste Exception tritt leider nicht immer genau gleich an der selben Stelle auf, sondern immer bei irgendeiner Art von Finalization.
Recht häufig war das z.B. die Finalization vom WPViewPDF, aber nicht nur, weswegen ich das eher als Folgefehler ansehen würde, genau wie vorher Styles, die ich momentan deaktiviert habe.
Der einzige größere Zusammenhang ist, dass unten im Stack immer System.FinalizeUnits zu laufen scheint.