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:

Zitat von Der schöne Günther (Beitrag 1256941)

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

Delphi-Quellcode:

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:

Zitat von Dalai (Beitrag 1256944)

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.

Delphi-Quellcode:

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:

Zitat von Aviator (Beitrag 1256946)

Zitat:

Zitat von Dalai (Beitrag 1256944)

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.

Delphi-Quellcode:

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:

Zitat von Aviator (Beitrag 1257288)

Zitat:

Zitat von Aviator (Beitrag 1256946)

Zitat:

Zitat von Dalai (Beitrag 1256944)

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.

Delphi-Quellcode:

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:

Zitat von Der schöne Günther (Beitrag 1257307)

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?

[Dalai]

Ach, du meine Güte. Kann es sein, dass ich die ganze Zeit auf dem Holzweg war, weil ich dachte, mit Ausgabedatei wäre eine Datei gemeint, die das kompilierte Programm verwendet, aber eigentlich Ausgabedatei das Kompilat (EXE, DCU) meint?

Sollte dem so sein, so vergesst, was ich geschrieben habe, und ich ziehe mich verschämt in meine Ecke zurück.

Ergänzung:

Zitat:

Zitat von 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?

Nein, siehe CloseHandle:

Zitat:

The CloseHandle function closes handles to the following objects:

Access token
Communications device
Console input
Console screen buffer
Event
File
File mapping
I/O completion port
Job
Mailslot
Memory resource notification
Mutex
Named pipe
Pipe
Process
Semaphore
Thread
Transaction
Waitable timer

Und da ich fälschlicherweise annahm, dein Programm würde irgendeine Datei öffnen, müsste die ggf. mit CloseHandle wieder geschlossen werden. Aber wie gesagt: Vergiss meinen Einwurf, da er auf falschen Annahmen basierte.

MfG Dalai

[Aviator]

Zitat:

Zitat von Dalai (Beitrag 1257313)

Ach, du meine Güte. Kann es sein, dass ich die ganze Zeit auf dem Holzweg war, weil ich dachte, mit Ausgabedatei wäre eine Datei gemeint, die das kompilierte Programm verwendet, aber eigentlich Ausgabedatei das Kompilat (EXE, DCU) meint?

Sollte dem so sein, so vergesst, was ich geschrieben habe, und ich ziehe mich verschämt in meine Ecke zurück.

MfG Dalai

Hallo Dalai,
ja das Kompilat ist gemeint, das von Delphi erstellt wird. Du kennst doch bestimmt die Meldung "Ausgabedatei XY kann nicht erstellt werden..." wenn du z.B. die Anwendung noch offen hast, wenn du neu kompilieren willst.

Aber ist kein Problem. Verständnisprobleme kann man immer haben. ;) Aber da du ja jetzt weisst was gemeint ist, hättest du vielleicht doch eine Idee?

[Dalai]

Tritt das denn sowohl mit Release als auch Debug-Konfiguration auf?

MfG Dalai

[Aviator]

Zitat:

Zitat von Dalai (Beitrag 1257316)

Tritt das denn sowohl mit Release als auch Debug-Konfiguration auf?

MfG Dalai

In der Release Konfiguration kann man ja bekanntlich nicht debuggen :stupid: deshalb kann ich das so leider nicht sagen. Wenn ich die Datei per Debugger starte (im Release), dann wird diese immer wieder richtig freigegeben. Im Debug Modus reicht es, nur mit dem Debugger zu starten (ohne Breakpoints an denen ich anhalte) und die Datei wird schon nicht mehr richtig entsperrt. Auch wenn ich die Datei kille (STRG + F2 oder Stop Taste) dann wird sie ebenfalls nicht richtig entsperrt. Ich hoffe du/ihr kannst/könnt mir weiterhelfen.

[Dalai]

Vorschlag: Die Optionen der Debug-Konfiguration so lange an die Release-Konfiguration anpassen, bis es nicht mehr auftritt. Irgendwann hast du den Übeltäter.

MfG Dalai

[Aviator]

Hier noch ein kleines Update: Sobald ich Delphi beende nachdem die Datei nicht mehr erzeugt werden kann und es neu starte, funktioniert das Erstellen der Datei wieder für einige Zeit. Natürlich auch mit Debugger. Ohne funktioniert es sowieso immer. Vielleicht hilft das noch weiter bei der Fehlersuche.

Zitat:

Zitat von Dalai (Beitrag 1257322)

Vorschlag: Die Optionen der Debug-Konfiguration so lange an die Release-Konfiguration anpassen, bis es nicht mehr auftritt. Irgendwann hast du den Übeltäter.
MfG Dalai

Danke schonmal für den Hinweis, aber ohne es jetzt probiert zu haben (aus Mangel an Zeit) und zu wissen was ich ändern könnte, glaube ich nicht, dass der Fehler an den Projektoptionen liegt. Ich glaube eher, dass sich der Debugger o. ä. nicht richtig beendet und somit der Zugriff auf die Datei gesperrt bleibt.

Eine Neuinstallation von Delphi ist zur Zeit eine nicht gern von mir gesehene Option, da alle Projekte noch zusätzliche Komponenten verwenden und ich diese installieren müsste. Somit ist eine Fehlersuche bei den Projekten ohne ThirdParty Tools/Komponenten leider auch nicht möglich.

[Dalai]

Ich meinte nicht, dass der Fehler in den Projektoptionen liegen könnte, sondern deren Ursache, die den Debugger zu diesem Fehlverhalten veranlassen. Ob das tatsächlich so ist, weiß ich natürlich nicht, aber so viele Optionen sind es ja nicht, die man umschalten muss.

MfG Dalai

[TiGü]

Debuggst du eine 32-Bit oder 64-Bit Anwendung?

Ich habe manchmal das Problem, dass sich der 64-Bit Debugger aufhängt oder Dateien nicht freigibt.
Lässt sich im Task-Manager als dbkw64_XX_0.exe (Embarcadero Debugger Kernel) finden und beenden (XX steht für eine Versionsnummer, bei XE3 ist es 17).

[Der schöne Günther]

Siehe auch hier:

http://qc.embarcadero.com/wc/qcmain.aspx?d=103862

Hauptsächlich scheint es (wie bei mir) der "Anwendungserfahrung"-Dienst zu sein. Gerne sind allerdings auch 3rd Party-Plugins schuld, die Jedis und cnPack waren wohl auch mal dabei.

[Aviator]

Hallo und danke für die Antworten.

Zitat:

Zitat von TiGü (Beitrag 1257476)

Debuggst du eine 32-Bit oder 64-Bit Anwendung?

Eigentlich nur 32-bit Anwendungen. Habe bisher noch keine 64-bit Anwendung gedebuggt bzw. überhaupt geschrieben außer einmal eine ShellExtension, welche ich aber nicht debugge bzw. nicht weiß, wie es funktioniert. Ist hier aber im Moment weniger das Problem.

Zitat:

Zitat von Der schöne Günther (Beitrag 1257484)

Hauptsächlich scheint es (wie bei mir) der "Anwendungserfahrung"-Dienst zu sein. Gerne sind allerdings auch 3rd Party-Plugins schuld, die Jedis und cnPack waren wohl auch mal dabei.

Der Dienst selbst ist bei mir ja gestartet. Wenn es das gleiche Problem wie bei dir wäre, dann würde das Problem damit ja gelöst (So meine Vermutung). CN-Pack und die Jedis habe ich installiert. CN-Pack überall und die Jedis sowohl auf meinem Firmen PC als auch auf dem Privaten nicht aber auf dem Notebook.

Ich habe gerade mal mein Projekt so abgeändert, dass die Jedis nicht mehr auf dem Notebook benutzt werden und ich das Projekt kompilieren kann. Nach circa 10 Debugvorgängen hatte ich das Problem immer noch nicht. Ich glaube das mit den Jedis werde ich mal nachverfolgen und den folgenden Tipp anwenden.

Zitat:

Zitat von Embarcadero QC

Well, I seemed to have solved my problem, when going through all my libraries, I saw that Jedi Library installs IDE experts, removing these additions from the Jcl-install under "IDE Experts" solved the problem completely for apps that use to crash after only one build.

Noch zur Information: Als ich gestern Abend mein Projekt gedebuggt habe, ist der Debugger mit einer Exception abgeschmiert. Ich habe diese Exception mal bei Goolge eingegeben und er hat mich zum Plugin (oder wie auch immer man das bezeichnen mag) AQTime geführt. AQTime hatte ich aber schon vor längerer Zeit deinstalliert, da es ebenfalls zur Abstürzen der IDE geführt hatte. Nach der Deinstallation traten die Abstürze nicht mehr auf.
Ich habe also versucht (da ich dachte es liegt am fehlenden AQTime) die Delphi Installation zu reparieren, sodass er AQTime vielleicht wieder installiert. Stattdessen hat mir das Setup meine gesamte Installation gekillt und ich musste alles neu installieren. Sowohl Delphi als auch alle Komponenten.

Insofern schade, dass dein Beitrag (Günther) nicht früher kam und ich die Jedis direkt ohne diese "Experts" installiert habe. Werde mich aber sofort dran setzen und Bericht erstatten, sobald ich alles erledigt und auch getestet habe.

[Aviator]

Hi Leute,

es sieht so aus, als hätte ich das Problem endlich gefunden. Ich bedanke mich für die tatkräftige Unterstützung und für die vielen Tipps, vor allem aber bei Günther für den Link zum QC Eintrag der mich schlussendlich auf den richtigen Weg gebracht hat.

Tatsächlich waren es die Jedi Tools. Sobald ich diese deinstalliert habe, konnte ich ohne Probleme debuggen. Sobald sie wieder installiert waren, hing das Projekt wieder. Auch die Jedi Experts (wie im QC beschrieben) bei der Installation der JCL zu entfernen brachte keine Abhilfe. Ich habe die Jedis jetzt komplett entfernt und baue mir meine Komponente drum herum mit Standardkomponenten zusammen oder erstelle mir früher oder später meine eigene(n) Komponente(n).


Nochmals danke für die super Hilfe und die bei diesem Thread zu 100% informativen Antworten. :thumb::thumb::thumb::thumb: