Seltsamer Fehler beim schließen

[Satyr]

Huhu,

ich wußte nicht wohin mit dem Thema, ich hoffe hier ist es richtig.

Mein Problem: Ich habe ein simples Programm das ich per Form1.close; schließe. Macht das Programm auch. NACH dem Schließen kommt von Windows die Meldung "Ein Problem hat die richtige ausführung dieses Programmes verhindert". Es wurde aber alles richtig ausgeführt.
Das merkwürdige ist, diese Meldung kommt nur auf PC's auf denen keine Delphiumgebung installiert ist. Von WinXP über Vista, Win7 und Win8.1.
Ist kein Delphi installiert, bekomme ich diese Meldung. Ist es installiert (aber nicht ausgeführt), bekomme ich sie nicht. Und wenn ich sie bekomme, dann nur NACH dem schließen des Programms.

Was ist das?

Bin für jede Hilfe dankbar...

Gruß,
Andreas

[himitsu]

Irgendwo ein Problem beim Freigeben einer Form/Componente?
> OnDestroy, Finalize usw.

Vermuten würde ich eine Endlosschleife oder ein Deadlock (z.B. eine CriticalSection, bzw. Synchronize), welche hängen bleiben.



Nja, Debuggen wird hier etwas schwer, aber du kannst mal probieren, ob du das über den Remote-Debugger hinbekommst.
Dabei kann das Delphi auf einem anderem Rechner installiert sein und man debuggt dann über das Netzwerk (z.B. LAN, Internet oder VPN)

Und dann gibt es noch so Dinge wie Eurekalog und MadExcept,
bzw. selber manuell ein paar Logeinträge in eine Datei schteiben, bzw. über ein paar MessageBoxen prüfen, bis wo hin das Programm beim Beenden kommt.

[Perlsau]

Führst du in deinem Formular Form1 den Close-Befehl mit vorangestelltem Form1-Namespace aus?

Delphi-Quellcode:

Procedure TForm1.CloseExecute(Sender: TObject);
begin
  Form1.Close;
end;

oder

Delphi-Quellcode:

Procedure TForm1.CloseExecute(Sender: TObject);
begin
  Close;
end;

[Satyr]

@Perlsau

Ersteres, damit hatte ich bisher auch nie Probleme.

@himitsu

Mid MadExcept hatte ich es auf einem anderen Rechner mal getestet. Keine Probleme.
Wie schon geschrieben arbeitet und schließt das Programm ganz normal. Erst DANACH kommt von Windows diese Meldung.
Der Zeitpunkt irritiert mich, sonst hätte ich auf ein MemoryLeak getippt. Oder zumindest eine Fehlermeldung mit mehr Aussagekraft *grml*.

[Perlsau]

Vielleicht hast du ja jetzt doch ein Problem damit? Nimm diesen unnötigen und vor allem fehleranfälligen vorangestellten Namespace heraus. Den brauchst du nicht, denn du befindest dich ja bereits im Namespace "Form1".

[Satyr]

Hat leider nichts geändert...

[himitsu]

Zitat:

Zitat von Satyr (Beitrag 1266229)

Wie schon geschrieben arbeitet und schließt das Programm ganz normal. Erst DANACH kommt von Windows diese Meldung.
Der Zeitpunkt irritiert mich, sonst hätte ich auf ein MemoryLeak getippt. Oder zumindest eine Fehlermeldung mit mehr Aussagekraft *grml*.

Falsch, nicht dein Programm ist da bereits geschlossen beendet, sondern nur die MainForm (deine Form1) ist "ausgeblendet" oder vielleicht schon freigeben.

Das Programm läuft dennoch weiter, bis alle Aufräumaktionen beendet wurden und in einer dieser Aufräumaktionen wird es bei dir vermutlich ein Problem geben.

In der DPR mal nach dem

Delphi-Quellcode:

Application.Run;

eine MessageBox anzeigen. Kommt dein Programm denn wenigstens bis dort hin? (Dialog wird angezeigt)


Nie Probleme?
Kleines Beispiel:

Delphi-Quellcode:

FreeAndNil(Form1);

und jetzt versuche mal im OnDestroy auf Form1 zuzugreifen, denn das ist dann bereits NIL, da die Funktion eigentlich NilAndFree heißen müsste, da sie zuerst die Variable auf NIL setzt und danach dann das Free aufruft.
Wenn du unbedingt einen NameSpace nutzten willst, dann benutzte auch den Richtigen, also

Delphi-Quellcode:

Self.Close;

(innerhalb einer TForm1-Methode aufgerufen).

[Satyr]

Ein Dialog nach Run ist kein Problem. Wie gesagt, das Programm läuft ansonsten völlig normal.
Wenn ich Dich richtig verstehe, versucht das Programm nach dem Close noch auf Form1 zuzugreifen, oder?
Ich wüsste zwar nicht wo ich danach noch explizit code habe aber ich gehe morgen mal die Komponenten durch. Vielleicht versuchen die AlphaSkins noch irgendwo ein skinning nach dem Close oder sowas.

[Sir Rufo]

Wie lautet denn der Dateiname von dem Programm?

[Satyr]

"concepter.exe", warum? Kann man da etwas falsch machen?

[Sir Rufo]

Zitat:

Zitat von Satyr (Beitrag 1266236)

"concepter.exe", warum? Kann man da etwas falsch machen?

Ja, wenn so Schlagworte wie "install", "setup" oder "update" enthalten sind/wären

[himitsu]

Wenn sich Programme nicht via Manifest beim Windows als Kompatibel zu dieser Version outen, dann geht Windows davon auß, daß es sich eventuell um alte schrottige Programme handelt.

Da z.B. viele Programmierer großen mist bauten und ständig versuchen ins Programmverzeichnis "C:\Programme" zu schreiben.
Bzw. die genannten "Schlagworte", betreffend noch schorottiger Setupprogramme, welche vergessen die Adminrechte anzufordern.

Dann schaltet Windows gewisse Heuristiken an und schaltet dann automatisch die Adminanforderung ein, oder schaltet in die Dateizugriffe verschiedene Umleitungen (z.B. VirtualStore) dazwischen.

[Satyr]

Wow, das die Sicherheitsrechtlinien mittlerweile so weit greifen wusste ich nicht. Gut zu wissen für die Zukunft.
Mein Programm liegt allerdings recht einsam in einem Ordner auf dem Desktop.
Was könnte eigentlich der Grund dafür sein, das es in Delphi problemlos beendet werden kann?

[Perlsau]

Zitat:

Zitat von Satyr (Beitrag 1266231)

Hat leider nichts geändert...

Hast du denn auch überall innerhalb von Form1 das vorangestellte Form1 entfernt?

[himitsu]

Warumn?
Der Debugger schaltet sich dazwischen und da Laufen einige Dinge ein bissl anders.


Mittlerweile?
Das ist schon seit NT (2000) so strikt, nur war es Keinem aufgefallen, da alle ständig mit vollen Adminrechten rumrannten.
Und als Microsoft das bei Vista endlich und zurecht mal abgestellt hat (Standardbenutzter sind nur noch Benutzer), heulten alle rum, weil fast nix mehr lief, was aber nicht die Schuld von MS war.

[Satyr]

Ich habs nur für den close benutzt. Im Grunde nur zur reinen Übersichtlichkeit, für mich war der Code so strukturierter zu lesen.

Kurz dachte ich das Problem könnte der Wechsel der Systemcursor sein. Ausbauen davon hat aber leider nichts gebracht *grummel*.
Schlicht unterdrücken kann man das nicht, oder? Ich weiß, ist dirty. Ich meine auch nur zum testen. Mit TApplicationEvents habe ich ein Abfangen versucht, ohne Erfolg. Wohl weil es ein Fehler ohne konkrete Fehlernummer ist.

@humitsu
Die NT Schiene habe ich zum programmieren ausgelassen, Vista auch. Ins Programmverzeichnis habe ich aber schon vorher nur sehr ungern geschrieben. Ich hab da einiges verpennt, ja.

[Perlsau]

Durch deine Verwendung von Form1 innerhalb der Klasse TForm1 entstand – zumindest bei mir – die Vermutung, daß dir noch weitere ähnliche Fehler unterlaufen sein könnten. Da es den durchaus hilfsbereiten Usern dieses Forums jedoch bislang verwehrt bleibt, deinen streng geheimen Code auf gewisse Verdächtige zu untersuchen, ist das Problem leider kaum lösbar. Anders ausgedrückt: Der einzige, der den Code durchforsten kann, um zu schauen, ob ihm was auffällt oder wo der Hase im Pfeffer liegen könnte, bist du. Wir können hier eigentlich nur dumm rumraten :twisted:

[jaenicke]

Du könntest im Projektquelltext nach dem Run einmal eine MessageBox einbauen, dann alle Formulare freigeben und dann wieder eine MessageBox einbauen.
So findest du heraus, ob das Problem bei der Freigabe der Formulare entsteht.

[Satyr]

@Perlsau
Ihr ratet sicherlich nicht "dumm" herum, sondern wesentlich schlauer als ich es könnte :).
Mein Quellcode ist im Grunde nicht geheim. Nur weiß ich nicht welcher Teil für Euch interessant wäre und ob mein Cheff das mag, wenn ich Code herumreiche...

@jaenicke
Danke für den Tipp, ich versuchs mal!

[himitsu]

NT ist alles seit NT, also auch bis Windows 8. (man könnte ja denken, daß die Entwickler sich in den letzen 20 Jahren hätten daran gewöhnen können)

Der Metro-Teil ist die neue RT-Schiene (Architektur/API), welchen es auch einzeln gibt (für ARM-CPUs).


Davor gab es vorallem die 3.1-Schiene (16 Bit > 1.x bis 3.x) und dann die 9x-Schiene (32 Bit DOS). Mit ME den 9x/NT-Mischmasch und nebenbei gab es noch CE und Mobile/Phone.

[Sir Rufo]

Zitat:

Zitat von Satyr (Beitrag 1266258)

Ich habs nur für den close benutzt. Im Grunde nur zur reinen Übersichtlichkeit, für mich war der Code so strukturierter zu lesen.

Dann solltest du korrekterweise

Delphi-Quellcode:

Self.Close

nehmen, denn

Delphi-Quellcode:

Self

(in einer Methode) ist immer der Verweis auf die aktuelle Instanz.

Im Gegensatz dazu ist

Delphi-Quellcode:

Form1

der Verweis auf eine Instanz, die dort irgendwann mal von wem auch immer reingeschrieben wurde. Du kannst dir aber niemals sicher sein, dass das auch der Verweis auf die aktuelle Instanz ist, bei

Delphi-Quellcode:

Self

ist das per Definition immer so.

[Satyr]

Danke für die Hinweise und Tipps :).

Also eine MessageBox nach Run wird beim Beenden von dem Programm angezeigt. Nun weiß ich aber nicht genau wo ich die Formulare per Hand freigeben soll.

Es könnte trotzdem sein das ich hier irgendwo etwas falsch mache. Ich habe das für eine SplashScreen ein wenig umgebaut, die Anleitung fand ich damals per Google. Hier der Code:

Delphi-Quellcode:

program Conceptor;

uses
  madExcept,
  madLinkDisAsm,
  madListHardware,
  madListProcesses,
  madListModules,
  Forms,
  sysUtils,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas' {SplashScreen},
  Unit3 in 'Unit3.pas' {notepad},
  func in 'func.pas';

{$R *.res}

begin


Application.Initialize;
Application.Title := 'Conepter';

SplashScreen := TSplashScreen.Create(nil);
SplashScreen.Show;

application.ProcessMessages;
Sleep(1000);


  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(Tnotepad, notepad);


  Application.Run;
end.

[himitsu]

Delphi-Quellcode:

Application.Title := 'Conepter';

:stupid: C?

Du könntest nach dem Application.Run mal ein FreeAndNil(Application) reinmachen und danach noch eine MessageBox.
Oder erstmal nur

Delphi-Quellcode:

FreeAndNil(Form1); FreeAndNil(notepad);

nach dem Run.

Bzw. über Screen.CustomForms alle Fenster auflisten und Diese freigeben.


Als allererste Unit in der DPR eine Unit aufnehmen, die nur Windows einbindet (im Interface) und in Finalization eine MessageBox anzeigt.


Wer gibt eigentlich den SplashScreen wieder frei?

[Satyr]

Hm! Also das hier:

Delphi-Quellcode:

  Application.Run;

  FreeAndNil(Form1); FreeAndNil(notepad);
  Application.MessageBox('test', 'Test');

zeigt die Message an wenn ich das in Delphi rennen lasse, nicht aber auf dem Rechner mit Fehler. Da kommt nur wieder der Fehler und das wars.

Wenn ich dann die Formulare einzeln durchgehe, liegt der Fehler dann im Formular?

Edit: Den SplashScreen gebe ich in Form1 frei.

[himitsu]

Eine MessageBox noch zwischen die beiden Fenster und auch mal die Reihenfolge (der Free) tauschen
und schon weißt du bei welchem Form es hängt.

Das kann nun ein Code im OnDestroy sein oder eine der Komponenten.


PS: hier muß man aufpassen, denn wenn die Fenster schon vorher freigegeben wurden, dann steht in der Variable eine falsche Referenz, da normalerweise keiner diese Variablen freigibt, da sie keiner mehr kennt ... drum hatte ich auch das FreeAndNil verwendet, damit danach die Variable auch nil ist, denn dann knallt es "schöner", falls nochmal wer auf diese Variable zugreift.

[Satyr]

Dann wird mein Fehler irgendwo in Form1 sein. Im Destroy steht nichts drin. Dann gehe ich morgen jede Komponente einzeln durch.

Vielen Dank Euch für die Hilfe. Ich wusste nicht wo ansetzen und wie schon garnicht. Danke :).

[pelzig]

Ein ähnliches Problem hatte ich - schon länger her - auch mal und habe dann ewig rumgesucht und bei den potentiell Verdächtigen eine MessageBox-Meldung reingedengelt.

Gefunden habe ich dadurch den Fehler nicht, sondern eher durch Zufall: Im Hauptformular die Reihenfolge der eingebundenen Komponenten-Units ändern schuf Abhilfe :evil:

Testen musste ich die Echse aber (quasi nach jeder Buchstabenänderung im Quelltext) in einer VirtualBox (mit XP darin), in der kein Delphi installiert war (da mein Entwicklungsrechner-OS natürlich Delphi kannte).

MfG

[himitsu]

Zitat:

Zitat von pelzig (Beitrag 1266279)

Ein ähnliches Problem hatte ich auch mal ...

Dein Problem klingt zuerst mal nach einer falschen Initialisierungs-/Finalisierungsreihenfolge, welche vorallem dadurch entsteht, wenn man unnötige/ungünstige Units in Implementation, anstatt im Interface einbindet, wobei die Initialisierungs-/Finalisierungsreihenfolge sich zufällig ändern kann.

Bzw. nicht oder falsch deregistrierte Komponenten/Funktionen welche vorher registriert wurden.

[pelzig]

Ja und nun was denn? Vielleicht haz der TE genau dieses Problem? :?

MfG

[himitsu]

Dann ist aber das wahllose Rumpfuschen an der Unitliste der "falsche" Weg, denn so werden nur die Symptome behoben, aber nicht die Ursache,
womit das Problem also irgendwann unverhofft wieder auftauchen könnte.

Das Einzige, wo diese Art der Lösung nötig ist, wären Compilerfehler (die berühmten "internal error"), wenn schnell eine Lösung benötigt wird, oder wenn man mit einem Bugfix nicht mehr zu rechnen braucht.


Da kann man auch gleich die Hardcorelösung benutzen.
- ich kann mein Programm nicht beenden, ohne daß es zu Exceptions kommt
- na dann schieße ich das Programm einfach hart ab und weg ist das Problem

[Perlsau]

Da wir ja weiterhin nur vermuten können: Ich tippe auf den Splash-Screen, der mit Nil als Parameter erzeugt wurde ...

Zitat:

Zitat von Satyr (Beitrag 1266267)

Es könnte trotzdem sein das ich hier irgendwo etwas falsch mache. Ich habe das für eine SplashScreen ein wenig umgebaut, die Anleitung fand ich damals per Google. Hier der Code:

Delphi-Quellcode:

program Conceptor;

uses
  madExcept,
  madLinkDisAsm,
  madListHardware,
  madListProcesses,
  madListModules,
  Forms,
  sysUtils,
  ...
{$R *.res}

begin
Application.Initialize;
Application.Title := 'Conepter';
SplashScreen := TSplashScreen.Create(nil);
SplashScreen.Show;
application.ProcessMessages;
Sleep(1000);
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(Tnotepad, notepad);
  Application.Run;
end.

Also bei mir sieht das mit dem Splash-Screen (Form-Info) ein wenig anders aus:

Delphi-Quellcode:

program ...;
{$R *.dres}

uses
  Forms,
  UnitInfo in 'UnitInfo.pas' {FormInfo},
  UnitMain in 'UnitMain.pas' {FormMain},
  UnitData in 'UnitData.pas' {DatMod: TDataModule},
  GlobalVars in 'GlobalVars.pas',
  DatBankEdit in 'DatBankEdit.pas',
  UnitPrint in 'UnitPrint.pas' {FormPrint},
  ...
{$R *.res}

begin
  ReportMemoryLeaksOnShutdown := True;
  Application.MainFormOnTaskbar := True;
  FormInfo := TFormInfo.Create(Application);
  FormInfo.Show;
  FormInfo.Update;
  Application.Initialize;
  Application.Title := 'PC-Heil Blutzucker-Verwaltung v0.0.1.171';
  Application.CreateForm(TFormMain, FormMain);
  Application.CreateForm(TDatMod, DatMod);
  Application.CreateForm(TFormPrint, FormPrint);
  ...
  Application.Run;
end.

Ich benutze FormInfo auch noch als Info-Form während des Programmablaufs.

[Satyr]

Ich habe die letzten 3 Stunden die Komponenten auf Form1 durchsucht (ausgebaut, getestet, eingebaut, nächste Komponente...), nichts gefunden :evil:.

Den SplashScreen habe ich wie gesagt nach einem kleinen Tut eingebaut das ich bei Google fand. Was ist genau der Unterschied ob ich es mit nil oder etwas anderem erzeuge?

[himitsu]

Wenn du es definitif selber freigibts, dann ist es egal.

Dieser Parameter ist der "Owner", also der Besitzer der Komponente.
Und der Owner kümmert sich um das Aufräumen.

Wenn du also mal nicht diese Form freigibst, dann würde schich Application darum kümmern, wenn man Diesen als Owner verwendet. Und zwar dann, wenn Application freigegeben wird (beim Entladen der Unit Form), dann würde spätestens diese Form mit freigegeben.

z.B. deiner Form1 wird, in dem Application.CreateForm, das Application als Owner übergeben, damit sich Application um dessen Freigabe (Free) kümmert.

[Satyr]

Verstehe. Ich habe jetzt noch mal nachgeguckt, ich verstecke die Splash Form nur (hide). Also habe ich im create nil durch Application getauscht. Leider ändert das nichts *sfz*.

[Satyr]

Interessant, ExitProcess(0) geht, Halt(0) nicht. Es knallt also dazwischen (war Euch sicher schon klar :) ). Gibt es noch eine andere Möglichkeit das finalisieren durchzusteppen, als wie gestern Abend? Zum Beispiel nur das was in Form1 passiert?

[baumina]

Warum hast du ein HALT in deinem Programm drin?

[jaenicke]

Zitat:

Zitat von Satyr (Beitrag 1266275)

Dann wird mein Fehler irgendwo in Form1 sein. Im Destroy steht nichts drin.

Das deutet eher darauf hin, dass du die Variable Form1 irgendwo veränderst oder selbst irgendwo freigibst.

Zitat:

Zitat von Satyr (Beitrag 1266325)

Interessant, ExitProcess(0) geht, Halt(0) nicht.

Halt bedeutet:
Mit voller Fahrt gegen den Baum fahren um anzuhalten.
Bist du sicher, dass du das möchtest? Dass es dabei auch knallen kann, dürfte klar sein.

Zitat:

Zitat von Satyr (Beitrag 1266325)

Gibt es noch eine andere Möglichkeit das finalisieren durchzusteppen, als wie gestern Abend? Zum Beispiel nur das was in Form1 passiert?

Debug-DCUs in den Projektoptionen aktivieren.

[Satyr]

Also wenn ich per grep search nach Form1 suche, kommt nichts wo ich das sonst beende oder freigebe.

Ich möchte Halt() nicht dauerhaft verwenden. Ich wollte nur mal testen was die Stelle mit dem Fehler nicht durchgeht, Halt() oder ExitProcess(). Ich habe (wieder Google) gelesen das Halt() trotzdem finalized und ExitProcess() nicht. Da bei Halt() der Fehler bleibt, ist mir so recht klar wo er ist. Nur wie ich weitersuche noch nicht so ganz. Was Debug-DCU's sind muss ich mir noch ergooglen *g*.