Windows 7 Zugriff auf ausführbare Dateien verweigert .. von was?

14

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

  1. Navigieren Sie mit dem Explorer zu einem Verzeichnis, das mindestens eine exe-Datei enthält
  2. Gehen Sie sofort ein Verzeichnis nach oben
  3. Löschen Sie das Verzeichnis, zu dem Sie gerade navigiert haben
  4. 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
  5. 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

  1. Erstellen Sie ein Projekt, das eine Exe-Datei erzeugt
  2. Führen Sie die ausführbare Datei aus und schließen Sie sie
  3. Erstellen Sie das Projekt sofort erneut (indem Sie beispielsweise ein einzelnes Zeichen in einer Quelldatei ändern)
  4. 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.

windows-7 visual-studio stijn
quelle
2
Ein paar Fragen. Tritt das Explorer-Problem im abgesicherten Modus auf? Haben Sie Shell-Erweiterungen installiert? Wenn Sie bei Ihrem Visual Studio-Problem den Prozessmonitor ausführen und bis auf Ihre Exe-Datei filtern, wird dann nichts angezeigt, was auf die Datei zugreift?
Sgmoore
Komisch, beide Szenarien, die Sie vorschlagen, funktionieren erwartungsgemäß (keine Fehler). Wie von sgmoore vorgeschlagen, beenden Sie Process Monitor und überwachen Sie die Ordner / Dateien.
ƬᴇcƬᴇιᴇ007
@sgmoore siehe Update
Stijn
Sind Sie sich zu 100% sicher, dass dies eine Installation von Drittanbietern ausschließt, nur weil die Aufrufe von shell32.dll stammen? Ich weiß nicht genug darüber, was auf einem extrem niedrigen Niveau vor sich geht, um sicherzugehen, ob das stimmt oder nicht, aber es ist sicherlich keine Annahme, die ich gemacht hätte.
Sgmoore
@sgmoore 100% nein, aber 99% ja. Meine Schlussfolgerung basiert nicht nur auf dem, was ich hier geschrieben habe. Ich habe die Symbole für alle System-DLLs, so dass ich die vollständigen Funktionsnamen im Callstack von procmon sehe. Alle Aufrufe des Explorers beim Öffnen des Verzeichnisses stammen aus Klassen mit Namen wie CLoadIconTask, die mit "Microsoft" überschrieben sind. Da ich Programmierer bin, habe ich einige Kenntnisse in der Interpretation von Callstacks. Alles, was nicht Microsoft ist, ist in AutoRuns immer noch deaktiviert. Auf einem anderen Rechner ist dies nicht der Fall, aber die gesamte Procmon-Ausgabe ist gleich. All diese + Intuition lassen mich stark glauben, dass es nur MS ist.
28.

Antworten:

7

Ich denke, das Problem, das Sie sehen, hängt mit der thumbs.db zusammen, die der Windows Explorer erstellt. Versuchen Sie dies zu deaktivieren, starten Sie den Computer neu und überprüfen Sie, ob das Problem erneut auftritt.

Zum Deaktivieren von thumbs.db öffnen Sie den Gruppenrichtlinien-Editor (gpedit.msc) unter Benutzerkonfiguration - Systemsteuerung - Administrative Vorlagen - Ordneroptionen - Registerkarte Windows-Komponenten - Ansicht - Windows Explorer. Suchen Sie nach "Deaktivieren Sie die Zwischenspeicherung von Miniaturansichten in versteckten thumbs.db-Dateien" und aktivieren Sie die Option "Miniaturansichten nicht zwischenspeichern".

Wenn es nicht funktioniert, würde ich versuchen, es mit Sysinternals Process Monitor zu untersuchen. Verwenden Sie diese Option, um zu sehen, wer auf den Ordner zugreift, wenn der Zugriff verweigert wird. Überprüfen Sie, ob es sich tatsächlich um eine Zugriffsverweigerung oder eine Zugriffsverletzung handelt, was bedeutet, dass jemand die Datei hält.

Asher
quelle
1
Thumbs.db existiert in win7 nicht.
Kinokijuf
1
ja tut es. Gehen Sie zu Ordneroptionen und aktivieren Sie "Versteckte Dateien, Ordner und Laufwerke
Asher
1
Windows 7 verwendet den Cache für lokale Miniaturansichten ( %userprofile%\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db), es sei denn, die Ressource ist remote (wie auf einer Netzwerkfreigabe). Zu diesem Zeitpunkt wird ein am thumbs.dbRemotestandort gespeicherter Cache verwendet (dies kann von GP deaktiviert werden).
ƬᴇcƬᴇιʜ007
2
upvoted: Obwohl ich keine Option "Thumbnails nicht zwischenspeichern" habe, hat mich die Verwendung von ProcMon schließlich an einen Ort gebracht, da es im Gegensatz zu ProcessExplorer oder Handle Beweise für das Problem liefert: Genau 1 Minute nach dem Öffnen des Verzeichnisses oder dem Ausführen der Exe gibt es ein IRP_MJ_CLEANUP Vorgang aus dem System-Prozess, der die Datei freizugeben scheint: Direkt nach diesem Ereignis kann ich das Verzeichnis wieder löschen. Ich werde dies weiter untersuchen, wenn ich aus den von ProcMon bereitgestellten Informationen einen Sinn ziehen kann.
27.
3
@kinokijuf Ich habe gerade bemerkt, dass Sie mit Ahsers Antwort rumgespielt haben. Ich habe keine Ahnung, warum Sie es tun, aber es macht keinen Sinn: Zuerst sagen Sie in Fettdruck, dass es keine thumbs.db gibt. Dann bearbeiten Sie Ashers Antwort so, dass der Teil, in dem er sagt, wie thums.db deaktiviert werden soll, unbrauchbar wird ("Do Not Cache Thumnbnails" ist für XP). Bitte machen Sie solche Dinge nicht.
28.
3

Sind Sie sicher, dass Sie kein Sicherheitsprodukt installiert haben?

Die von Ihnen beschriebenen Szenarien stimmen mit der Theorie überein, dass ein Produkt auf jede ausführbare Datei zugreift, auf die Sie auf irgendeine Weise zugreifen, so dass ein exklusiver Zugriff unmöglich wird. Dies muss kein Antivirus sein, es kann sich beispielsweise um einen Indexer für die schnelle Suche oder was auch immer (sogar ein Virus) handeln.

Man kann diese Theorie testen, indem man im abgesicherten Modus bootet, in dem überhaupt keine Produkte außer Windows gestartet werden.

Das beste Tool zum Verfolgen von Dateizugriffen ist Process Monitor . Ein weiteres hervorragendes Tool, um alle Startprodukte zu finden und wieder einzuschalten, ist Autoruns .

Harrymc
quelle
Die Indizierung ist von, die Windows-Suche ist ebenfalls deaktiviert. Ich habe keine Sicherheits- oder Suchwerkzeuge von Drittanbietern. Im Grunde ist Ihr Vorschlag, alle Tools von Drittanbietern in Autoruns zu deaktivieren und dann eins nach dem anderen zu aktivieren?
27.
Wenn dies beim Start im abgesicherten Modus nicht der Fall ist, ist es absolut sicher, dass ein installiertes Produkt dafür verantwortlich ist. Sie können Autoruns verwenden, um Startelemente in Stapeln zu deaktivieren und den Computer neu zu starten, bis Sie sie finden. Der Vorteil von Autoruns ist, dass Sie Elemente auf einfache Weise wieder aktivieren sowie die aktuelle Situation speichern / wiederherstellen / vergleichen können. Aber noch besser erst einen Systemwiederherstellungspunkt erstellen, nur für den Fall.
Harrymc
deaktivierte alles, was nicht von Microsoft stammt, unter Anmeldung, Explorer, Internet Explorer und Diensten. Problem besteht immer noch. Gibt es eine Möglichkeit zu vergleichen, was im normalen Modus und im abgesicherten Modus geladen wird?
27.
Grundsätzlich wird alles, was Sie in Autoruns sehen, nur im normalen Modus geladen.
Harrymc
Nun, mit Ausnahme von Diensten, Netzwerk usw.
Harrymc
2

Datei oder Verzeichnis können dann im Kernel-Modus geöffnet werden 

handle -a

wird nicht angezeigt und ProcMon zeigt IRP-Anforderungen vom / zum Systemprozess an.

Es gibt einen Teil des Windows-Kernels, der allen Prozessen zugeordnet ist, und einen anderen Teil des Windows-Kernels, der in einem separaten Prozess ausgeführt wird. Letzteres wird als Windows Executive bezeichnet.

Dies wird also durch Dateien oder Verzeichnisse verursacht, die im Windows Executive-Prozess im Kernelmodus geöffnet wurden.

Mikhail Kupchik
quelle
1

Es kann sich um den Explorer handeln, der Symbole und Metadaten aus der Exe liest.

kinokijuf
quelle
Dies ist eine mögliche Erklärung für den Explorer, jedoch nicht für Visual Studio, es sei denn, der Explorer zeigt diesen Ordner gleichzeitig an. @stijn: Geschieht dies in Visual Studio ohne Explorer?
Harrymc
@ Harrymc siehe Update, passiert nicht ohne Explorer (na ja, explorer.exe läuft noch, befindet sich aber nicht im Verzeichnis der exe)
27.
Und wie behebt man dieses Problem?
Simon Sheehan