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

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

[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 von AuronTLG:

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.