Seit ich Windows 7 benutze, stört mich dieses Problem. Von Zeit zu Zeit tauchen ähnliche Fragen in verschiedenen Foren auf, aber ich habe nie eine Antwort gefunden. Hier sind zwei Szenarien, die es fast immer reproduzieren:
Der Entdecker-Weg
- Navigieren Sie mit dem Explorer zu einem Verzeichnis, das mindestens eine exe-Datei enthält
- Gehen Sie sofort ein Verzeichnis nach oben
- Löschen Sie das Verzeichnis, zu dem Sie gerade navigiert haben
- Die Renditen Ordner Zugriff verweigert Dialog unter Angabe Sie Erlaubnis benötigen diese Aktion benötigen Sie die Erlaubnis von Administratoren auszuführen Änderungen in diesem Ordner zu machen , mit den Tasten versuchen Sie es erneut und Abbrechen
- Das Schlagen von Try Again funktioniert nie sofort. Etwa eine Minute warten und dann erneut darauf klicken funktioniert
Hinweis: Wenn Sie in Schritt 2 mindestens eine Minute warten, bevor Sie ein Verzeichnis öffnen, tritt das Problem nicht auf und der Ordner kann gelöscht werden
Der Visual Studio Weg
- Erstellen Sie ein Projekt, das eine Exe-Datei erzeugt
- Führen Sie die ausführbare Datei aus und schließen Sie sie
- Erstellen Sie das Projekt sofort erneut (indem Sie beispielsweise ein einzelnes Zeichen in einer Quelldatei ändern)
- Ergibt den schwerwiegenden Fehler LNK1168: /path/to/the.exe kann nicht zum Schreiben geöffnet werden
Hinweis: Wenn Sie in Schritt 2 vor dem erneuten Erstellen mindestens eine Minute warten, tritt das Problem nicht auf.
Einige Angaben
- Passiert sowohl unter Windows 7 32 als auch 64 Bit mit VS2008 / 2010/2011
- Passiert auf 3 verschiedenen Maschinen
- Ich habe keinen Virenscanner
- Ich habe eine Reihe von Diensten deaktiviert, aber nichts, was Windows daran hindert, normal zu laufen. Die Benutzerkontensteuerung ist ebenfalls deaktiviert
- Passiert auf jeder Art von Disc
- Ich verwende immer ein Benutzerkonto in der Gruppe Administratoren
Offensichtlich sind beide Szenarien sehr ähnlich und extrem reproduzierbar. Also dachte ich, ein Prozess muss die Datei aus irgendeinem Grund geöffnet haben und sie später wieder freigeben. Verwenden Sie jedoch sysinternals
handle -a
Die betreffende exe-Datei wird nie angezeigt. (Das ist die richtige Art, Handle zu verwenden, oder?) Während Explorer / VS meldet, dass sie nicht auf die Datei zugreifen können, gibt handle.exe an, dass sie nirgendwo verwendet wird. Das macht mich eher ratlos, also frage ich mich, ob jemand eine Lösung finden kann: Warum passiert das und wie kann man es lösen?
Update als Antwort auf die gestellten Fragen:
- Ich konnte das Problem im abgesicherten Modus nicht reproduzieren
- Eine Reihe von Shell-Erweiterungen sind installiert. Von SellExView sind hier die Nicht-Microsoft-Geräte aufgeführt, die allen Computern gemeinsam sind: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Ich würde die Tortoise am verdächtigsten finden, obwohl für beide die Option 'Status-Cache' auf 'Status-Cache nur für einen Ordner, keine rekursiven Überlagerungen' gesetzt ist, dh es wird keine TortoiseCache.exe ausgeführt.
- Beim Explorer-Problem zeigt ProcessExplorer die ausführbare Datei nicht an. Es wird zwar das Verzeichnis der ausführbaren Datei angezeigt, es wird jedoch auch nach dem Löschen weiterhin angezeigt, sodass dies nicht wirklich verwandt zu sein scheint
- Beim VS-Problem tritt es auch dann auf, wenn im Zielverzeichnis kein Explorer-Fenster geöffnet ist. Auch hier zeigt ProcessExplorer weder die ausführbare Datei noch das Verzeichnis an, in dem sich die ausführbare Datei befindet. Beachten Sie, dass in diesem Modus mit VS das Problem nur beim Ausführen der ausführbaren Datei auftritt. Wenn es nicht läuft, kann ich es immer wieder problemlos erstellen.
- Im 'VS-Modus' und in einem Explorer-Fenster, das im Verzeichnis der ausführbaren Datei geöffnet ist (getestet nur mit einer C # -Exe), wird es seltsamer: Ich kann nicht erneut erstellen, da VS sich beschwert, dass die Exe von einem anderen Prozess verwendet wird. Wenn ich jedoch die Exe aus dem geöffneten Explorer-Fenster lösche, funktioniert dies und folglich ist das Erstellen erfolgreich. Auch hier gibt es keinerlei Referenzen im ProcessExplorer. Welche Ergebnisse stimmen mit denen von handle.exe überein? (Verwenden PE und handle sowieso nicht intern dieselbe API?)
Update 2 Es kann nicht nur Explorer sein: Nach dem Beenden von explorer.exe ist das VS-Problem immer noch vorhanden.
Update 3 Verwenden von Process Monitor, wie Asher vorschlägt, enthüllt interessante Fakten: Für den Explorer-Modus gibt es 10 Aufrufe von IRP_MJ_CREATE beim Öffnen des Verzeichnisses. Es werden jedoch nur 9 Aufrufe an IRP_MJ_CLEANUP gesendet. Alle diese Aufrufe stammen aus der Datei shell32.dll, sodass es sich definitiv nicht um ein Installationsproblem eines Drittanbieters handelt. Und es ist offensichtlich das eine fehlende IRP_MJ_CLEANUP, das das Problem verursacht: Genau 1 Minute nach dem Öffnen des Verzeichnisses gibt der Systemprozess selbst den IRP_MJ_CLEANUP-Aufruf aus und die Datei wird freigegeben und gelöscht.
Ich konnte jedoch immer noch nicht herausfinden, warum dies passiert. Handelt es sich um einen Explorer-Bug, der durch eine von mir vorgenommene Änderung ausgelöst wurde?
Lösung! Bei der Durchsicht der von mir deaktivierten Dienste ist mir die Beschreibung für Application Experience aufgefallen , und ich zitiere: Verarbeitet Anforderungen für den Anwendungskompatibilitäts-Cache für Anwendungen, wenn diese gestartet werden . Kommt mir bekannt vor. Tatsächlich kann ich nach dem Start des Dienstes keines der Probleme mehr reproduzieren und die Ausgabe von ProcMon ist anders und kürzer. Witzig, denn nach dem erneuten Beenden des Dienstes ist immer noch alles in Ordnung und die Ausgabe von procmon ist immer noch kürzer.
Ich habe es auf zwei Computern versucht, auf denen alles, was von Drittanbietern kommt, gut läuft und alles noch in Ordnung ist.
Ich bin nicht sicher, ob dies ein echter Fehler ist (man könnte sagen, was Sie mit dem Deaktivieren von Diensten erwarten), aber es ist nicht ganz normal, dass das Problem einfach dadurch behoben wird, dass ein Dienst gestartet und dann wieder gestoppt wird.
Bounty geht an jeden, der einen tieferen Einblick in dieses Thema geben kann, und an @Asher, der mich auf ProcMon aufmerksam gemacht hat, was mich schließlich in die richtige Richtung geführt hat.