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

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

[jaenicke]

Zitat von AuronTLG:

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.