Ausgabedatei kann nach Debugging nicht erstellt werden

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