Ausgabedatei kann nach Debugging nicht erstellt werden

[Aviator]

Hallo Community,

der Titel sagt eigentlich schon alles. Sobald ich mein Programm einmal (manchmal auch mehrmals) mit dem Debugger gestartet habe, kann die Ausgabedatei nicht mehr erzeugt werden. Das Löschen der Datei per Windows Explorer funktioniert weiterhin. Danach kann die Datei wieder erstellt werden, bis ich das Programm wieder mit dem Debugger ausführe. Dann das gleiche Spiel von vorne.

Ich habe auch schon im Netz etwas recherchiert und bin auch auf einige hilfreiche Tipps gestoßen, wie z.B. das Ausschalten des Windows Indexer Dienstes in diesem Verzeichnis. Ich meine auch, dass es danach eine Zeit lang funktioniert hat. Auf meinem privaten Rechner sowie auf meinem Rechner in der Firma und auch auf meinem Notebook habe ich dieses Problem, was mich langsam etwas rasend macht. Daraus resultierend würde ich vermuten, dass es an den Einstellungen oder an Windows liegt. Es ist also nicht direkt rechnerabhängig. Vielleicht wäre noch wichtig zu wissen, dass in allen Rechnern bzw. Notebook eine SSD verwendet wird, sofern das auch Probleme bereiten kann (wegen mir aus irgendwelchen SSD internen Dingen wie Trim oder sonst was).

Die Projekteinstellungen habe ich so belassen, wie Delphi diese voreinstellt. Habe auch nicht besonders viel Ahnung, was die meisten Schalter genau bedeuten. Das heißt also, dass auch die Debug und Release Dateien in den entsprechenden Unterordnern erzeugt werden. (Also <Projekt>\Win32\Debug oder <Projekt>\Win32\Release).


Ich hoffe, dass jemand von euch eine Idee hat, wie ich dieses Problem lösen kann, da ich nicht ständig die Datei löschen will, bevor ich meine Datei erzeugen kann.

Ein weiteres Problem, was wahrscheinlich darauf basiert, ist auch, dass meine komplette IDE beim Start mit Debugger (in 95% der Fällen) abschmiert (RAD Studio for Windows funktioniet nicht mehr ...), sobald einmal die Datei nicht erstellt werden konnte und ich diese gelöscht habe. Ohne Debugger ausführen funktioniert meistens noch nach dem Löschen.

[Der schöne Günther]

So etwas ähnliches hatte ich neulich plötzlich auch- Auf Dauer wird man wirklich wahnsinnig.

Der Grund war nicht der Indexdienst, sondern der abgeschaltete "Windows Anwendungserfahrungsdienst". Nimm doch mal ein Tool wie LockHunter und schaue, ob jemand die Datei noch offen hat- Bei mir war es immer SYSTEM (PID: 4).

Selten vergeigt es auch das RAD Studio selbst, seine eigenen Handles auf die Exe wieder freizugeben. Das wirst du ja dann damit sehen können. Bei mir war es immer Windows selbst der den Finger drauf hatte. Deswegen ließ es sich kurioserweise über den Explorer löschen.

Ich hatte erst immer den Virenscanner im Verdacht (der könnte da übrigens auch mit reinspielen).

[Aviator]

Danke für den Tipp. Werde ich natürlich direkt mal ausprobieren. Du hattest den Fehler eliminiert, indem du den Dienst standardmäßig gestartet hast? Dieser Dienst ("Anwendungserfahrung") ist bei mir zur Zeit gestartet, steht jedoch auf Starttyp "manuell".


Edit:

Schon getestet. Es ist das RAD-Studio selbst, das die Datei blockiert. Nachdem ich diese mit dem Tool freigegeben hatte, lies es sich auch direkt wieder starten. Ideen, woran das liegen könnte? Das Projekt wurde von mir ganz neu eröffnet (vor 2 Tagen).

[Der schöne Günther]

Bei mir ebenso. So ist es glaube ich auch normal.

Vorher war er bei mir deaktiviert. Das führte dazu, dass SYSTEM immer gerne die Datei offen hielt. Wer ist es denn bei dir? Das RAD Studio selber?

Edit: Ich glaube nicht, dass es am Projekt selbst liegt. Hast du das auch mit neuen und bestehenden Projekten? Auch: Wie beendest du das üblicherweise? Wenn ich den Prozess aus dem Debugger kille habe ich das ganz selten auch mal...

[Dalai]

Ist denn sichergestellt, dass im Code wirklich alle Handles auf die Datei geschlossen werden?

MfG Dalai

[Aviator]

Zitat von Der schöne Günther:

Edit: Ich glaube nicht, dass es am Projekt selbst liegt. Hast du das auch mit neuen und bestehenden Projekten?

Das aktuelle Projekt habe ich vor 2 Tagen begonnen. Es passiert aber auch bei einem etwas älteren Projekt, an dem ich intensiv in der Firma arbeite. Das Projekt hat ca. 20.000 Zeilen Quellcode. Das aktuelle vielleicht 300, da ich code technisch noch nicht sehr viel gemacht habe.

Zitat:

Auch: Wie beendest du das üblicherweise? Wenn ich den Prozess aus dem Debugger kille habe ich das ganz selten auch mal...

Normalerweise beende ich über das Schließen-X der Form oder über einen speziell dafür vorgesehenen Button auf der Form mit dem Code Self.Close; . Per Debugger killen mache ich nur, wenn ich mein Programm so abgeschossen habe, das ich es gar nicht mehr beendet bekomme wie z.B. eine AV oder so.

Zitat von Dalai:

Ist denn sichergestellt, dass im Code wirklich alle Handles auf die Datei geschlossen werden?

Ich erzeuge zwar die ein oder anderen Objekte oder ähnliches, gebe diese aber auch immer wieder frei. ReportMemoryLeaksOnShutdown gibt auch keine Fehlermeldungen mehr aus. Ich würde also behaupten, dass alles geschlossen ist. Kann ich das noch irgendwie überprüfen?

[Aviator]

Hi Leute,
gibt es bzgl. meines Problems noch irgendwelche Ideen, Hinweise oder sonstige Vorschläge, wie ich es in den Griff bekommen kann?

Hier noch einmal die Dinge die ich schon probiert habe:

• Windows Indexer im Projektordner deaktiviert
• Per LockHunter geprüft, wer den Zugriff auf die Datei blockt (Das RAD-Studio selbst ist der Verursacher) (Danke an Günther)
• Zugriff per LockHunter freigegeben --> Datei konnte wieder erstellt werden
• Überprüft, ob der Dienst "Windows Anwendungserfahrung" läuft. Dienst war allerdings gestartet (Trotzdem auch hier danke Günther)

Ich wäre euch sehr dankbar, wenn ihr mit diesbezüglich noch weitere Hinweise/Tipps oder sonstiges geben könntet, da ich dieses Problem auf mehreren Rechnern habe. Ich benutze auf 2 Rechnern RAD-Studio XE3 und auf einem Rechner XE4. Auf allen 3 Rechnern tritt der Fehler auf. Jedoch auch nicht immer. In meiner früheren IDE (RAD-Studio 2010) hatte ich dieses Problem nie.

Zitat von Aviator:

Zitat von Dalai:

Ist denn sichergestellt, dass im Code wirklich alle Handles auf die Datei geschlossen werden?

Ich erzeuge zwar die ein oder anderen Objekte oder ähnliches, gebe diese aber auch immer wieder frei. ReportMemoryLeaksOnShutdown gibt auch keine Fehlermeldungen mehr aus. Ich würde also behaupten, dass alles geschlossen ist. Kann ich das noch irgendwie überprüfen?

Gibt es hierzu noch Hinweise? Möglicherweise ist dies der Fehler. Klingt für mich zumindest logisch. Nur wie kann ich es überprüfen?

[Dalai]

Zitat von Aviator:

Zitat von Aviator:

Zitat von Dalai:

Ist denn sichergestellt, dass im Code wirklich alle Handles auf die Datei geschlossen werden?

Ich erzeuge zwar die ein oder anderen Objekte oder ähnliches, gebe diese aber auch immer wieder frei. ReportMemoryLeaksOnShutdown gibt auch keine Fehlermeldungen mehr aus. Ich würde also behaupten, dass alles geschlossen ist. Kann ich das noch irgendwie überprüfen?

Gibt es hierzu noch Hinweise? Möglicherweise ist dies der Fehler. Klingt für mich zumindest logisch. Nur wie kann ich es überprüfen?

Mir fällt nur ein, den Code durchzusteppen und zu prüfen, ob alle Handles wirklich geschlossen werden (CloseHandle erfolgreich). Man kann ja vor die CloseHandle-Aufrufe jeweils einen Breakpoint setzen, damit man sich nicht dusselig steppt .

MfG Dalai

[Der schöne Günther]

Durch was durchzusteppen? Die eigene Anwendung hat keine Schuld, das RAD Studio bekommt öfter mal seine eigenen Dateien nicht geschlossen.

[Aviator]

Ich habe mich auch gefragt welche CloseHandle() Stellen ich anspringen soll. Normalerweise verwendet man so etwas doch bei Threads und nicht bei Klassen die man per Create() erstellt hat und mit Free() freigibt, oder? Oder vergesse ich das schon die ganze Zeit, weil ich so etwas nicht weiß? Wäre gut, wenn du mir das noch beantworten könntest.

Zitat von Der schöne Günther:

Die eigene Anwendung hat keine Schuld, das RAD Studio bekommt öfter mal seine eigenen Dateien nicht geschlossen.

Das wäre dann aber neu ab XE3 (zumindest nach meinem Kenntnisstand). Frühere Versionen die ich besaß (Delphi 2009 und 2010) hatten dieses Problem nicht. Es muss doch möglich sein, dass die Anwendung korrekt geschlossen wird.

Was mir gerade noch eingefallen ist:
Ich habe die Befürchtung, dass es an neu erstellten Projekten in dieser Version liegt. Denn wenn ich ein Projekt debugge, dass ich mit 2010 erstellt und auf XE4 portiert habe, dann habe ich das Problem (wenn ich mich richtig erinnere) noch nie gehabt. Wäre das noch ein Ansatz?