Warum würde SYSTEM die Sperrung der Handles für ausführbare Dateien fortsetzen, nachdem die App beendet wurde?

Auf meinem Windows 7-Computer tritt ein merkwürdiges Verhalten auf. Es scheint, dass SYSTEM, wenn eine ausführbare Datei ausgeführt wird, ein Handle für die nächste Minute offen hält. Hier ist meine jüngste Begegnung:

Ich habe Steam installiert, wodurch steam.exe nach der Installation gestartet wird, um sich selbst zu aktualisieren. Es scheint so, als ob Sie dazu eine temporäre Kopie von sich selbst schreiben, diese starten, um den Download durchzuführen, und dann die Originalkopie der ausführbaren Datei überschreiben. In meinem Fall schlug dies fehl und behauptete, dass steam.exe nicht gelöscht werden konnte.

Ich habe den Ordner geöffnet und versucht, steam.exe manuell zu löschen, aber Windows hat angegeben, dass ich keine Berechtigung habe. Mein Konto ist ein Administrator und das einzige Benutzerkonto auf diesem Computer. Aber für alle Fälle habe ich den Explorer als Administrator gestartet, konnte die Datei aber immer noch nicht löschen. Ich habe die Eigenschaften der Datei auf der Registerkarte "Sicherheit" angezeigt. Es wurde jedoch nur die Meldung angezeigt, dass ich keine Berechtigung zum Anzeigen von Berechtigungen habe.

Als Nächstes öffnete ich den Process Explorer, um festzustellen, ob die Datei gesperrt ist. SYSTEM (PID 4) hat dies getan, aber als ich versuchte, das Dateihandle zu schließen, wurde ein Fehler ausgegeben, der besagte, dass das Handle ungültig war. Ich habe versucht, die Eigenschaften des Datei-Handles anzuzeigen, aber ich hatte auch keine Berechtigung dazu.

Ich habe alles außer den nicht terminierbaren Systemprozessen beendet und alle Dienste gestoppt, die ich kann, einschließlich aller AV- und Firewall-bezogenen, aber das Problem tritt weiterhin auf. Ich habe versucht, mich mit "takeown" in den Besitz der Datei zu versetzen, aber es wird behauptet, dass ich keine Erlaubnis dazu habe. Andere Leute haben behauptet, mit einem Tool namens "Unlocker" erfolgreich zu sein, aber es hatte das gleiche Problem wie Process Explorer beim Schließen des Datei-Handles.

Ich habe die Windows-Indizierung und -Suche vor langer Zeit deaktiviert und C: \ von der Indizierung ausgeschlossen, sodass die Antwort auf diese Frage für mich nicht zutrifft.

Jedes Mal nach ungefähr einer Minute verschwindet das Handle und die Datei wird sofort gelöscht. Anscheinend wurde der Versuch des Updaters, ihn zu löschen, in die Warteschlange gestellt und schließlich beendet, sobald die Datei nicht mehr gesperrt war. Leider wurde das Update bereits beendet und kann nicht fortgesetzt werden. Und wenn ich neu installiere, wird natürlich versucht, steam.exe erneut auszuführen, und ich komme zu Punkt eins zurück.

Meine Frage ist: Warum hängen diese Griffe herum und wie kann ich sie daran hindern?

Bearbeiten: Hier sind zusätzliche Informationen, wie aus Kommentaren angefordert:

C:\>fltmc instances
Filter                Volume Name                              Altitude        Instance Name      Frame  VlStatus
--------------------  -------------------------------------  ------------  ---------------------  -----  --------
KLIF                  \Device\Mup                             320400       KLIF                     0
KLIF                  C:                                      320400       KLIF                     0
KLIF                                                          320400       KLIF                     0
luafv                 C:                                      135000       luafv                    0
FileInfo              \Device\Mup                              45000       FileInfo                 0
FileInfo              C:                                       45000       FileInfo                 0
FileInfo                                                       45000       FileInfo                 0

Edit: GMER zeigt an, dass mein Antivirus-Programm (Kaspersky) immer noch aktiv ist, obwohl es in seiner eigenen Benutzeroberfläche deaktiviert und sein Dienst gestoppt wurde.

AttachedDevice  \Driver\tdx \Device\Ip     kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)
AttachedDevice  \Driver\tdx \Device\Tcp    kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)
AttachedDevice  \Driver\tdx \Device\Udp    kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)
AttachedDevice  \Driver\tdx \Device\RawIp  kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)

Diese scheinen jedoch alle für Netzwerkdienste bestimmt zu sein. Ich sehe nichts im Zusammenhang mit dem Dateisystem. Könnte einer von diesen die Ursache des Problems sein?

Bearbeiten: Ich habe den Kaspersky KLIF-Filter deaktiviert, aber das Sperrproblem bleibt bestehen.

Bearbeiten: Ich habe das spezifische Problem mit Steam gelöst, indem ich das Installationsprogramm installiert und beendet habe, bevor es steam.exe starten konnte. Anschließend habe ich es im abgesicherten Modus neu gestartet und dort ausgeführt. Anscheinend ist das, was die ausführbare Datei sperrt, im abgesicherten Modus nicht vorhanden.

Obwohl ich diesen speziellen Fall gelöst habe, taucht das Problem auch an anderer Stelle auf, sodass ich immer noch gerne verstehen möchte, was passiert.

Mach Folgendes:

1. Deaktivieren Sie die Indizierung für den problematischen Speicherort.

2. Aktivieren Sie den "Application Experience" -Dienst und setzen Sie ihn auf "Automatisch".

Das ist es.

Wenn Ihr Problem weiterhin besteht, ist es möglicherweise Superfetch, obwohl das Deaktivieren mir kein Glück gebracht hat.

KLIF ist der Kaspersky AV-Treiber. Es ist ziemlich wahrscheinlich, dass es damit zu tun hat.

In einem solchen Fall würde ich mich an Kaspersky wenden und um Rat fragen.

Es gibt jedoch noch eine andere Möglichkeit, die Sie zuerst ausprobieren können: Deaktivieren Sie den Treiber (unter HKLM\SYSTEM\CurrentControlSet\Services), indem Sie den KLIFSchlüsselnamen suchen oder einen ähnlichen Namen verwenden und den REG_DWORDWert Startauf 4(was bedeutet, deaktiviert) setzen und anschließend neu starten. Dies sollte verhindern, dass der KAV-Filtertreiber geladen wird. Anschließend können Sie fltmcdas Ergebnis überprüfen.

Die Ausgabe von GMER, die Sie angegeben haben, ist für den vorliegenden Fall irrelevant, da sie nur Netzwerkverbindungen und keine Dateivorgänge betrifft. Anscheinend haben Sie so etwas wie Kaspersky Internet Security installiert (oder es befindet sich immer noch im Ruhezustand auf Ihrem Computer).

Bearbeiten: Nur FYI luafvist für die FS-Virtualisierung in Verbindung mit der Benutzerkontensteuerung verantwortlich. Dh wenn Sie keinen Zugriff auf eine Datei haben, wird diese in einem separaten Ordner in Ihrem Profil abgelegt. FileInfogehört zu SuperFetch - was eigentlich Teil Ihres Problems sein könnte, aber ich selbst hatte kein ähnliches Problem unter Windows 7. Es wird im Allgemeinen nicht empfohlen, SuperFetch zu deaktivieren, obwohl dies möglich ist.

Ich hatte dieses Problem, weil eine ausführbare Java-Datei geöffnet war und ich die Anwendungserfahrung deaktiviert hatte. Vielen Dank!!! (Ich hatte auch Probleme mit Dateien, die eine Minute lang nicht gespeichert wurden und erst eine Minute nach dem Schließen gelöscht werden konnten ...)

Dies passierte mir einmal und es stellte sich heraus, dass es sich um einen Remotecomputer handelte, auf dem der Freigabeordner geöffnet war.

1. Verwenden Sie Handle , um herauszufinden, in welchem ​​Prozess sich die Datei befindet
2. (Es war System in meinem Fall)
3. Versuchen Sie, den Griff zu schließen: handle.exe -c E14 -p 4. Ihr Datei-Handle wird in der Ausgabe Ihrer Suche nach dem Datei-Handle gefunden, und die Prozess-ID wird wahrscheinlich für das System identisch sein.
4. Es wird ausgegeben Error closing handle: T
5. Als ich das googelte, stellte ich fest, dass dies mit dem Netzwerk zusammenhängt
6. Ich habe auf einem anderen Rechner gefunden, ich hatte tatsächlich den Ordner geöffnet. Schloss es. Alles gut.

Ich hatte dieses Problem beim Versuch, einen Ordner umzubenennen. Ich musste den Serverdienst stoppen, während ich die Umbenennung durchführte. Nur ein Neustart hat nicht geholfen, da der Systemprozess den Ordner erneut gesperrt hat, sobald der Serverdienst neu gestartet wurde. Dies würde wahrscheinlich auch das hier erwähnte Problem lösen .