Ausgabedatei kann nicht erstellt werden... warum?

[Dragon27]

Hallo zusammen,

ich habe das Problem, dass nach ein paar mal compilieren immer wieder der Fehler auftritt:

Code:

F2039 Ausgabedatei %Pfad zur Exe% kann nicht erstellt werden

Um den Fehler zu beheben, muss ich die EXE im Debug Verzeichnis löschen. Dann funktioniert es wieder genau ein mal.

Folgende Dinge habe ich bereits versucht:

UAC ist deaktiviert
Dienst zum indizieren von Dateien bei der Suche in Windows ist deaktiviert
Ordnerrechte sind auf "Jeder" darf "Alles"

Leider helfen die oben genannten Sachen nicht :(

Meine Umgebung:

Delphi XE 6 und Windows 8.1 Professional

Vielleicht hat einer von euch eine Idee wie man diesen Missstand beenden kann...

Danke für eure Hilfe!

[Bernhard Geyer]

Virenscanner deaktiviert?

[Dragon27]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1275298)

Virenscanner deaktiviert?

Ja auch probiert, leider ohne Erfolg ;)

[pelzig]

Die Ausgabedatei %Pfad zur Exe% kann nicht erstellt werden, weil die Echse vermutlich noch läuft.

Der Debugger der IDE kann nicht alles abschießen, was noch hängt.

Schau doch mal in den Taskmanager, da sollte deine Echse noch zu finden sein.

MfG

[Der schöne Günther]

Habe ich auch ständig, bevorzugt bei einem schnellen Test im "Embarcadero Default"-Ordner. Umbenennen des Projekts ("Project1" -> "Project2" -> "Project3" -> ...) ist meine einzige Abhilfe dagegen. Zieht sich seit ich dabei bin durch alle RAD Studio-Versionen.

Ich habe auch den Verdacht auf dem Virenscanner (G-Data), allerdings habe ich das RAD Studio auch schon öfter erwischt wie es selbst die .exe-Datei noch zum Lesen auf hatte und sich selbst am überschreiben hinderte...

[Dragon27]

Zitat:

Zitat von pelzig (Beitrag 1275303)

Die Ausgabedatei %Pfad zur Exe% kann nicht erstellt werden, weil die Echse vermutlich noch läuft.

Der Debugger der IDE kann nicht alles abschießen, was noch hängt.

Schau doch mal in den Taskmanager, da sollte deine Echse noch zu finden sein.

MfG

Dachte ich auch am Anfang, aber die EXE läuft nicht mehr... Virenscanner ist auch aus... Manuell kann ich die EXE ohne Probleme löschen. Falls diese noch laufen würde, sollte ich ja eine Fehlermeldung von Windows erhalten.

[jaenicke]

Zitat:

Zitat von Dragon27 (Beitrag 1275297)

Folgende Dinge habe ich bereits versucht:

UAC ist deaktiviert

Danach tritt das Problem in einer VM hier reproduzierbar auf. Ein erneutes Aktivieren der UAC hilft nicht, ich muss die VM resetten. Danach geht es... bis ich die UAC deaktiviere.

Ein weiterer Grund neben der Sicherheit das nicht zu machen, nicht einmal testweise.

Bei mir selbst war das Problem irgendein IDE Plugin, das hatte ich bei XE3 auch mal, aber ich habe leider vergessen welches. Du könntest es einmal mit einem sauberen Profil versuchen (Parameter -rTest glaube ich).

[Aviator]

Ich hatte lange Zeit selbiges Problem. Ich hatte dann mit dem Programm LockHunter (wurde mir glaube ich von "Der schöne Günther" empfohlen) herausgefunden, dass die bds.exe selbst die Datei blockiert. Nachdem ich den Prozess, der auf die Datei zugegriffen hatte, entfernt hatte, konnte ich wieder kompilieren. Der Fehler trat allerdings nur dann auf, wenn ich im DebugModus gestartet hatte. Ohne Debugger funktionierte es immer.

Bei mir hatten folgende Dinge nichts bewirkt:

• Indexer Dienst deaktieren bzw. nur den Ordner ausschließen
• Virenscanner deaktivieren
• BDS.exe mit Administratorrechten starten
• Die Rechte des Verzeichnises in dem die Exe liegt volle Berechtigungen auf den aktuellen User zu geben
• und ich meine noch einige andere Dinge die mir jetzt nicht mehr einfallen

Was schlussendlich bei mir half war, dass ich die Jedi Erweiterungen aus meiner Delphiinstallation entfernt hatte. Sogar nur die Installation der Komponenten und nicht einmal die Nutzung dieser in dem Projekt führte schon dazu, dass die Exe nicht mehr erstellt werden konnte bzw. blockiert wurde.

Hier mal noch das Thema, das ich damals hier erstellt hatte: Link
Und hier der QC Eintrag bei Emba, bei dem die Kommentare mich auf den richtigen Weg gebracht hatten: Link


Edit: Was lt. Kommentar bei dem User in den QC Kommentaren half, war nur die Deinstallation der JCL Experts. Dies traf bei mir nicht zu. Auch eine Installation ohne Experts führte zu diesem Verhalten.

[Bernhard Geyer]

Sind bei der Jedi-Installation die Experten installiert? Da gibts ja AFAIK welche die z.B. Debugs-Infos komprimiert an die Exe hängen. Evtl. läuft da ja was falsch.

[Aviator]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1275324)

Sind bei der Jedi-Installation die Experten installiert? Da gibts ja AFAIK welche die z.B. Debugs-Infos komprimiert an die Exe hängen. Evtl. läuft da ja was falsch.

:shock: Siehe meinen Beitrag. :stupid:

[jaenicke]

Das Problem mit dem in dem Link genannten Dienst Anwendungserfahrung kann ich hier in der VM reproduzieren.

Da der Dienst allerdings standardmäßig auf manuell steht und nicht deaktiviert ist, sollte das Problem eigentlich nicht auftauchen, wenn man nicht gerade an den Diensten selbst herumfummelt oder gewisse "Optimierungssoftware" nutzt...
Ich habe nämlich mal die Trial einer bekannten "Optimierungssoftware" (Kaputtmachsoftware im Fachjargon) installiert und getestet und rumms war der Dienst deaktiviert...

[Sir Rufo]

Na dann weiß ich ja warum das bei mir nicht passiert.

In meinen VMs (verlinkte Klone) ist das in der Basis schon alles deaktiviert, was die Platte unnütz zumüllt und der Indexer gehört auch dazu. :stupid:

[Bernhard Geyer]

Zitat:

Zitat von Aviator (Beitrag 1275329)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1275324)

Sind bei der Jedi-Installation die Experten installiert? Da gibts ja AFAIK welche die z.B. Debugs-Infos komprimiert an die Exe hängen. Evtl. läuft da ja was falsch.

:shock: Siehe meinen Beitrag. :stupid:

Hans Grobler hat auch dazu geschrieben im qc geschrieben:

Zitat:

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.

Ist ist also nicht grundsätzlich die Jedi (verwende sie auch, installiere jedoch nicht über den Installer sondern wähle mir aus was ich haben will).

[DeddyH]

Ich hatte das Problem auch, benutze die Jedis aber überhaupt nicht. Nachdem ich Win7 wegen einer Hardwareumstellung neu installiert habe, ist das Problem vom Tisch, ohne dass ich die tatsächliche Ursache herausfinden konnte. Allerdings tritt das Phänomen hier in der Firma auch auf 2 Rechnern auf.

[Jasocul]

Ich hatte das Problem bis gestern auch. Dann gab es noch andere technische Probleme, die nichts mit Delphi zu tun hatten.
Da wir die Benutzerprofile auf einem Server ablegen, habe ich das derzeitige Profil auf meinem Rechner gelöscht und dann neu eingespielt.
Damit war interessanterweise auch das hier beschriebene Problem mit Delphi verschwunden.

Die genaue Ursache konnte ich aber auch nicht klären.

[Uwe Raabe]

So, ich gebe dann auch mal eine Beobachtung zu diesem Thema zu Besten:

Heute hatte ich auch wieder dieses Problem. Mir fiel aber ein, daß ich kurz vorher die TMS Components aktualisiert hatte. Kurzerhand den TMS Component Pack Wizards rausgeworfen und der Spuk war vorbei.

Erklären kann ich das aber auch nicht...

[Jasocul]

Der Thread ist zwar schon ziemlich alt, aber mein Kollege hatte auch mit diesem Problem zu kämpfen. Da wir das beheben konnten, wollte ich euch an der Lösung teilhaben lassen. Könnte ja sein, dass immer noch Jemand mal damit zu tun hat.

Der Dienst "Anwendungserfahrung" war deaktiviert. Nachdem der Dienst auf automatisch umgestellt wurde, ist das Problem verschwunden.

Warum das so ist, weiß ich allerdings nicht.

[Redeemer]

Der Dienst "Anwendungserfahrung" ist nötig, um EXE-Dateien öfter als alle 120 Sekunden zu schreiben.
Wahrscheinlich wollten sie es "Anwendungsänderung" oder "Anwendungserstellung" nennen, aber wir kennen ja Microsoft...

[KodeZwerg]

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1396696)

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

Das sieht man doch im Taskmanager warum dafür ein extra Tool verwenden.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1396700)

Zitat:

Zitat von KodeZwerg (Beitrag 1396696)

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

Das sieht man doch im Taskmanager warum dafür ein extra Tool verwenden.

Echt, kann man mitlerweile nachschauen, welcher Prozess Handles auf eine bestimmte Datei offen hat? Hatte dazu sonst immer den ProcessExplorer verwendet, aber wenn der Taskmanager das jetzt auch kann, wäre das natürlich besser :) Wo genau müsste ich da suchen?

[Aviator]

Zitat:

Zitat von Zacherl (Beitrag 1396710)

Zitat:

Zitat von EWeiss (Beitrag 1396700)

Zitat:

Zitat von KodeZwerg (Beitrag 1396696)

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

Das sieht man doch im Taskmanager warum dafür ein extra Tool verwenden.

Echt, kann man mitlerweile nachschauen, welcher Prozess Handles auf eine bestimmte Datei offen hat? Hatte dazu sonst immer den ProcessExplorer verwendet, aber wenn der Taskmanager das jetzt auch kann, wäre das natürlich besser :) Wo genau müsste ich da suchen?

Das frage ich mich auch. Ich hatte dafür eine andere Software benutzt die mit Der schöne Günther damals bei dem gleichen Problem empfohlen hatte.

[KodeZwerg]

Ich kenne viele Situationen wo ich eine Datei nicht löschen/updaten etc kann weil die Datei "offen" ist.
"Offen" ist nicht das selbe wie "Ich starte eine Anwendung und hab ein Fenster".

Simples Beispiel:
Man hat eine Datei, editiert diese (je nach Editier-Programm, es kann auch ein Debugger oder AntiVirus Software etc sein), solange nun diese Datei editiert wird, ist sie gesperrt bzw offen oder um es auf den Punkt zu bringen "FileIsInUse".
(Es gibt auch Editier-Programm die eine Datei nicht "offen" halten, also bitte darüber jetzt nicht streiten.)

ProcessExplorer könnte eventuell helfen, Taskmanager ist dafür glaube ich nicht geeignet aber da gehe ich mal jetzt nicht drauf ein. Beide haben den Nachteil, sie sind nicht in der Lage "jeden" Prozess zu killen.
Unlocker kann auch nicht "jeden" Prozess killen, aber bietet halt einen Neustart mit Datei Löschung an.
Unlocker hat halt den (für mich jedenfalls) Mega-Vorteil, ich klick rechts auf die Datei und mir werden nur Prozesse angezeigt die auch mit der Datei verbunden sind, also hab ich sofort auf einen Blick Klarheit an was es liegt.

Das ist nur meine Meinung, ich will damit niemanden etwas aufzwingen, nur helfen den Übeltäter zu entlarven um das Problem zu beseitigen.

Ps: Angenommen ein Prozess sperrt ein Verzeichniss was man löschen möchte, da hilft weder ProcessExplorer noch Taskmanager.

[Jasocul]

Zitat:

Zitat von KodeZwerg (Beitrag 1396696)

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

Der Übeltäter ist die bds.exe. Man könnte also Delphi jedesmal neu starten, wenn man zuviel Zeit hat. :wink:
Wenn ich mich richtig erinnere, passiert das auch nur, wenn man im Debug-Modus ist.

[Redeemer]

Könntet ihr aufhören, über das Problem zu spekulieren, ohne es zu kennen?

Zitat:

Zitat von KodeZwerg (Beitrag 1396696)

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

Hilft hier nicht. Man kann mit der EXE alles machen, was man möchte, nur nicht schreiben. Man kann sie öffnen, verschieben und (im Windows Explorer) sogar löschen usw.

Zitat:

Zitat von Jasocul (Beitrag 1396726)

Zitat:

Zitat von KodeZwerg (Beitrag 1396696)

Ich selbst hatte mit Delphi noch nicht diesen Fehler, aber ich würde mal das Programm Unlocker einsetzen, das zeigt dir wer der Übeltäter ist.
(Falls die .exe tatsächlich noch offen sein sollte)

Der Übeltäter ist die bds.exe. Man könnte also Delphi jedesmal neu starten, wenn man zuviel Zeit hat. :wink:
Wenn ich mich richtig erinnere, passiert das auch nur, wenn man im Debug-Modus ist.

Nein, das Problem ist Windows. Es hat nichts mit der BDS zu tun. Du kannst zum Beispiel (je nachdem, wie dein Browser das implementiert, z.B. in Firefox) keine EXE-Dateien herunterladen, die in weniger als 2 Minuten herunterladen werden.
IDE neustarten hilft allenfalls zufällig, weil dadurch die Grenze von 120 Sekunden überschritten wird.

[KodeZwerg]

Gibt es eine Möglichkeit diesen Fehler problemlos zu reproduzieren?
Ich würde mir das gerne mal anschauen um mir meine Eigene Meinung darüber zu bilden.

[Redeemer]

Ja, Anwendungserfahrung ausmachen. (Windows 7)

[KodeZwerg]

Da bin ich dann zu spät, ich habe gerade erst mein Windows 7 UE samt Lizenz-Key verkauft.
(Wobei ich eh alle "Microsoft-Komfort-Features" von Hause aus deaktiviert hatte/habe.)
Vielleicht lade ich mir nochmal ein ISO zum testen herunter, ohne Key war das glaub ich 30 Tage lang möglich.

[jaenicke]

Dieser Dienst wird leider von manchen Tuning-Tools deaktiviert, weil den die meisten User ja nicht brauchen...
Und die anderen merken hoffentlich nicht, dass es an dem Tool lag... aber auf diesem Prinzip basieren diese Tools eben.