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:

Zitat von AuronTLG (Beitrag 1543834)

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.

[jaenicke]

Zitat:

Zitat von AuronTLG (Beitrag 1543840)

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.

[jaenicke]

Zitat:

Zitat von AuronTLG (Beitrag 1543864)

Der einzige größere Zusammenhang ist, dass unten im Stack immer System.FinalizeUnits zu laufen scheint.

Dann musst du ja nur noch herausfinden, bei welcher Unit das passiert. Das geht relativ einfach. Schau dir die Finalisierung mal an. Da setzt du einen Haltepunkt mit Bedingung, dass ein bestimmter Durchlauf erreicht ist (ich glaube da gab es eine Variable i, also als Bedingung z.B. i > 100). Das setzt du dann hoch (sprich Bedingung ändern, F9, ändern, F9, ...), bis du den Durchlauf kennst, bei dem es passiert. Und dann gehst du mit F7 in diese Initialisierung rein.

[Delphi.Narium]

Wo steht der Aufruf des Anmeldeformulares, was steht zwischen diesem Aufruf und dem Application.Run?

Das von Dir beschriebene Szenario "Anmeldemaske mit Abbruchmöglichkeit" löse ich für gewöhnlich in der Art:

Delphi-Quellcode:

begin
  Application.Initialize;
  // hier der Aufruf der Anmeldemaske:
  // Anmeldemaske erstellen oder passende Methode aufrufen ...
  if Anmeldemaske.ShowModal = mrOk then begin
    // Von den Initialisierungen der Formulare ... wird beim Abbruch nix benötigt.
    // also werden sie vor der Entscheidung, ob Anmeldung oder Abbruch, nicht erstellt.
    Application.CreateForm(TfmMain, fmMain);
    // ... und alle anderen Formulare ...
    Application.Run;
  end else begin
    // nix oder Meldung des Programmabbruches ...
    // Hier ist Application.Terminate eine schlechte Idee.
    // Wenn schon CreateForms vor der Entscheidung, dann wird hier das Hauptformular des Programmes geschlossen, 
    // damit alle anderen auch die Chance bekommen, ordentlich aufzuräumen.
    // Application.MainForm.Close;
    // Wobei: Die Erfahrung zeigt, dass auch das nicht immer zwingend ohne negative Nebenwirkungen "durchläuft".  
    // Z. B. Irgendwo in 'nem FormCreate oder einer DFM wird/ist ein Timer auf True gesetzt, Thread erstellt, ...
  end;
end.

[AuronTLG]

Zitat:

Dann musst du ja nur noch herausfinden, bei welcher Unit das passiert. Das geht relativ einfach. Schau dir die Finalisierung mal an. Da setzt du einen Haltepunkt mit Bedingung, dass ein bestimmter Durchlauf erreicht ist (ich glaube da gab es eine Variable i, also als Bedingung z.B. i > 100). Das setzt du dann hoch (sprich Bedingung ändern, F9, ändern, F9, ...), bis du den Durchlauf kennst, bei dem es passiert. Und dann gehst du mit F7 in diese Initialisierung rein.

Das ist ja gerade das Problem: Es wechselt. Ich habe da schon alle möglichen Units im Aufruf-Stack drin gehabt. Z.B. irgendwelches Imageen-Zeugs, WPTools-Zeugs, Indy-Zeugs oder was auch immer. Ich habs sicherheitshalber mal oft genug ausprobiert, um auszuschließen, dass das nur Drittanbieter-Units betrifft, und siehe da, momentan hängt die Exception in der Finalization von Xml.xmlutil, die ja delphi-eigen ist.
Das scheint völlig zufällig zu sein.

Ich wills nur sicherheitshalber nochmal zusammenfassen, einfach weil ich mit diesem Kram bisher noch nie herumschlagen musste und dementsprechend vielleicht etwas falsch verstehe:

Ich starte das Programm im Debugger, schließe es direkt in der Anmeldung wieder und halte bei der Exception, die dann kommt, an.
Daraufhin schaue ich mir den Aufrufstack des Hauptthreads an: Relativ konsistent ist, dass das Programm im System.FinalizeUnits steckt, doch die Details weiter oben im Stack wechseln. Ist halt immer irgendeine Finalization von verschiedenen Units, bei der dann etwas ziemlich mundänesknallt. Momentan z.B. ist es ein FinalizeRecord in XML.xmlutil.Finalization.
Wenn ich das Programm das nächste mal starte und bei der Exception halte, ist es was ganz anderes.

Das wirkt für mich so, als hätte ich allgemeineres Problem, was wechselnde Folgefehler verursacht oder interpretiere ich das Problem irgendwie falsch dahingehend, dass doch eine einzelne Unit der Schuldige sein müsste? Ich habe halt keine Ahnung, wie das FinalizeUnits bzw der gesamte Ablauf nach dem Terminate arbeitet.

[AuronTLG]

Zitat:

Wo steht der Aufruf des Anmeldeformulares, was steht zwischen diesem Aufruf und dem Application.Run?

Das von Dir beschriebene Szenario "Anmeldemaske mit Abbruchmöglichkeit" löse ich für gewöhnlich in der Art:

Ich habe heute keine Zeit mehr und gucke morgen nochmal genauer. Daher nur die kurze Info, dass ich Application.MainForm.Close anstatt Terminate auch schonmal probiert habe und es keinen Unterschied macht.
Vor Anzeige der Anmeldemaske werden diverse Sachen gemacht, dabei auch mit einigen wenigen ausgewählten Forms. Der grundsätzliche Aufbau ist ähnlich wie bei dir, d.h. Application.Run wird nur ausgeführt, wenn man durch die Anmeldung durchgeht; in meinen Fall hier wird es also nicht ausgeführt.

Und nur nochmal kurz allgemein: Meine Projekt-DPR hat sich zur funktionierenden Vorversion quasi nicht verändert und schon gar nicht das grundsätzliche Startverhalten. Liege ich richtig damit, dass das Problem, was auch immer es sein mag, dementsprechend in Units/Formen liegen muss, die vor der Anmeldung bereits verwendet werden und von mir zur Vorversion hin verändert/hinzugefügt worden sind?

[jaenicke]

Wenn da etwas im Speicher kaputt geht, wäre FastMM mit FullDebugMode einen Versuch wert...
Und dann kann das Problem ganz woanders liegen als die Änderung, die das Auftreten ausgelöst hat.

Dennoch könntest du, da es ja reproduzierbar ist, in der Versionsverwaltung versuchen, die Änderungen der Reihe nach durchzugehen und zu schauen, ab wann das auftritt.

[Delphi.Narium]

Wo der Fehler auftritt ist abhängig davon, wie schnell auf Abbruch geklickt wird. Derweil von dem Zeitraum ist abhängig, wie weit der Verarbeitungsfortschritt ist und wann das Terminate dann dem Prozess und/oder den inzwischen gestarteten Threads, ... die Daseinsberechtigung unter dem Hintern wegzieht.

Application.Terminate ist da einfach eine schlechte Idee.

Initialisierung zu Ende durchlaufen lassen und dann erst den Anmeldedialog anzeigen und dann beim Abbruch das Hauptformular des Programmes schließen, damit ein geordnetes Programmende möglich wird oder den Anmeldedialog zuerst anzeigen und nur dann die übrige Initialisierung laufen lassen, wenn kein Abbruch gewünscht ist. Andernfalls suchst Du die 'nen Wolf und wirst höchstwahrscheinlich keinen dauerhaften Erfolg haben.

Sinspin schriebe nicht umsonst:

Zitat:

Zitat von Sinspin

Application.Terminate ist generell keine Lösung zum geregelten Beenden eines Programms.

Für mich heißt das: Bei Verwendung von Application.Terminate wirst Du Dein Problem (in mehr oder weniger abgemilderter Form) behalten, aber nicht verlässlich lösen.

Zitat:

Zitat von AuronTLG

Liege ich richtig damit, dass das Problem, was auch immer es sein mag, dementsprechend in Units/Formen liegen muss, die vor der Anmeldung bereits verwendet werden und von mir zur Vorversion hin verändert/hinzugefügt worden sind?

Ja (mit der Einschränkung, sie müssen sich nicht verändert haben und/oder es muss nichts hinzugefügt worden sein, lediglich eine Veränderung in der Zeitabfolge reicht für die Entstehung derartiger Probleme, bei der Nutzung von Application.Terminate, aus). Die werden durch ein Application.Terminate immer "abgeschossen" und zwar genau da, wo sie zum Zeitpunkt des "Abschusses" gerade dran sind. Und das kann bei jedem Programmstart mit Abbruch woanders sein. Du wirst hier kaum eine Chance haben, ein reproduzierbares Verhalten zu erlangen (Außer, dass Du reproduzierbar in "irgendeinen Fehler" läufst).

Bevor Du "ewig und drei Tage" weitersuchst, versuche es bitte einmal in der Form:

Delphi-Quellcode:

begin
  Application.Initialize;

  // Anmeldemaske erstellen und anzeigen
  with TLoginForm.Create(nil) do
  try
    if ShowModal = mrOk then
    begin
      // Initialisierungen der Formulare nur bei erfolgreicher Anmeldung
      Application.CreateForm(TfmMain, fmMain);
      // Weitere Formulare initialisieren ...
      Application.Run;
    end
    else
    begin
      // Bei Abbruch oder fehlgeschlagener Anmeldung wird das Programm beendet
      // Application.Terminate wird vermieden, um unerwünschte Nebenwirkungen zu verhindern
    end;
  finally
    Free;
  end;
end.

[jaenicke]

Grundsätzlich stimme ich zu, dass es sinnvoll ist, die Projektdatei gut zu strukturieren. Ich persönlich sorge auch dafür, dass initialization und finalization nach Möglichkeit keinen Code enthalten, der dann direkt ausgeführt wird. Sprich ich verwende ein eigenes Framework, das diese Schritte zentral im Rahmen von Aufrufen aus der Projektdatei erledigt. Dadurch sind diese beim "end." der Projektdatei bereits abgearbeitet.

Deshalb ist der Vorschlag, Application.Run ggf. gar nicht erst auszuführen, schon gut.

Allerdings dürfte korrekter Code durch Application.Terminate nicht zu einem Fehler führen.

[himitsu]

Per se kann Application.Terminate nicht zu einem Fehler führen, da es erstmal nur eine Message an Application sendet, wo dann eine Variable (Terminated) auf True gesetzt wird,
worauf z.b. auch Threads reagieren können, um beim Ende sich ordentlich zu beenden.

Eigentlich würde ein Programm so lange laufen, bis ALLE Threads (der MainThread ist nur Einer von Vielen) beendet wurden.
OK, die RTL (Delphi) sorgt bei ordnungsgemäßem Ende des MainTreads dafür, dass der "Prozess terminiert" wird, womit dann noch laufende Threads gekillt werden.

ABER, es ist inzwischen möglich, auch ein paar OnTerminate-Events zu registrieren, um darüber das Beenden zu beenden (abzubrechen, also das ordnungsgemäße Beenden des Programms zu verbieten)
ACHTUNG: So lange keine TerminateProcs registriert sind, ist Application.Terminate per se thread-save, mit aber nicht, da die TerminateProcs vor dem Senden der Message abgehandelt werden. :wall:

[AuronTLG]

So, ich habe das Problem mehr oder weniger gefunden und behoben.
Im Prinzip haben alle hier im Thread mit ihren Anmerkungen Recht:
Das fragliche Programm ist ziemlich groß, hat Altlasten und der gerade der DPR-Code Recht ist teilweise sehr alt und, wie ich nun feststelle, voller kleiner Unsauberkeiten, die jetzt wohl übergeschwappt sind.
Der große und entscheidende Übeltäter war eine Form, die schon vor der Anmeldung aus technischen Gründen kreiert und dann nicht mehr manuell entsorgt wurde, womit ihre Entsorgung beim Programmende automatisch stattfand. Das war anscheinend schon lange so drin, hatte aber bisher keine Probleme verursacht, weswegen es nicht auffiel.
Ich werde es nochmal im Detail untersuchen, aber gehe momentan stark davon aus, dass meine Änderungen zur Vorversion prinzipiell nichts direkt damit zu tun hatten, sondern beim zugrundeliegenden Problem einfach irgendein technischer Schwellenwert überschritten wurde und es rein theoretisch auch schon viel früher hätte knallen können.

Vielen Dank für Hilfe, ich gehe dann wohl erstmal paar DPRs säubern, nicht dass es noch mehr solcher lustigen Überraschungen gibt.

[jaenicke]

Zitat:

Zitat von AuronTLG (Beitrag 1543906)

Der große und entscheidende Übeltäter war eine Form, die schon vor der Anmeldung aus technischen Gründen kreiert und dann nicht mehr manuell entsorgt wurde, womit ihre Entsorgung beim Programmende automatisch stattfand.

Gib einfach alle Formulare, die mit Application als Owner erzeugt wurden, vor dem end des Projektquelltextes mit Application.DestroyComponents frei.

Aber dann muss das Formular etwas machen, das nicht mit der GUI zu tun hat, worauf auch "aus technischen Gründen" hindeutet. Da wäre dann ggf. eine Restrukturierung sinnvoll. Zumindest sollten z.B. keine DLLs oder Netzwerk- oder Datenbankverbindungen oder ähnliches erst bei der Freigabe entladen werden.