Come trovi quale processo tiene aperto un file in Windows?

Una cosa che mi infastidisce di Windows è il vecchio errore di violazione della condivisione . Spesso non è possibile identificare ciò che lo tiene aperto. Di solito è solo un editor o un esploratore che punta solo a una directory pertinente, ma a volte ho dovuto ricorrere al riavvio della mia macchina.

Qualche suggerimento su come trovare il colpevole?

Ho avuto successo con Sysinternals Process Explorer . Con questo, puoi cercare per trovare quale processo (i) ha un file aperto e puoi usarlo per chiudere gli handle se vuoi. Certo, è più sicuro chiudere l'intero processo. Esercitare cautela e giudizio.

Per trovare un file specifico, utilizzare l'opzione di menu Find->Find Handle or DLL... Digita in parte del percorso del file. L'elenco dei processi verrà visualizzato di seguito.

Se si preferisce la riga di comando, la suite Sysinternals include la maniglia della riga di comando , che elenca le maniglie aperte. Alcuni esempi su come usarlo:

• c:\Program Files\SysinternalsSuite>handle.exe |findstr /i e:\ - trova tutti i file aperti dall'unità E:
• c:\Program Files\SysinternalsSuite>handle.exe |findstr /i file-or-path-in-question

È possibile utilizzare Resource Monitor per questo che è integrato con Windows 7, 8 e 10.

1. Apri Monitor risorse , che puoi trovare
   • Con la ricerca di monitor di risorse o resmon.exe nel menu di avvio, o
   • Come pulsante nella scheda Prestazioni nel Task Manager
2. Vai alla scheda CPU
3. Utilizzare il campo di ricerca nella sezione Maniglie associate
   • Vedi la freccia blu nella schermata qui sotto

Quando hai trovato l'handle, puoi identificare il processo guardando la colonna Immagine e / o PID.

Puoi quindi provare a chiudere l'applicazione come faresti normalmente oppure, se ciò non è possibile, fai clic con il pulsante destro del mouse sulla maniglia e termina il processo direttamente da lì. Vai tranquillo!

Copiato dalla mia risposta originale: https://superuser.com/a/643312/62

Prova il comando openfiles .

Stai molto attento con le maniglie di chiusura; è ancora più pericoloso di quanto pensi, a causa del riciclaggio dell'handle: se chiudi l'handle del file e il programma apre qualcos'altro, quel handle di file originale che hai chiuso può essere riutilizzato per quel "qualcos'altro". E ora indovina cosa succede se il programma continua, pensando che stia funzionando sul file (di cui hai chiuso l'handle), quando in realtà quell'handle di file punta ora a qualcos'altro.

vedi il post di Raymond Chen su questo argomento

Supponiamo che un servizio di indice di ricerca abbia un file aperto per l'indicizzazione ma si sia bloccato temporaneamente e si desideri eliminare il file, quindi forzare (involontariamente) la chiusura dell'handle. Il servizio dell'indice di ricerca apre il suo file di registro per registrare alcune informazioni e l'handle nel file eliminato viene riciclato come handle nel file di registro. L'operazione bloccata viene infine completata e il servizio dell'indice di ricerca alla fine riesce a chiudere quel handle aperto, ma finisce involontariamente chiudendo l'handle del file di registro.

Il servizio dell'indice di ricerca apre un altro file, ad esempio un file di configurazione per la scrittura in modo che possa aggiornare alcuni stati persistenti. L'handle per il file di registro viene riciclato come handle per il file di configurazione. Il servizio dell'indice di ricerca desidera registrare alcune informazioni, quindi scrive nel suo file di registro. Sfortunatamente, l'handle del file di registro è stato chiuso e l'handle è stato riutilizzato per il suo file di configurazione. Le informazioni registrate vanno nel file di configurazione, corrompendole.

Nel frattempo, un altro handle che hai forzato chiuso è stato riutilizzato come handle mutex, utilizzato per impedire la corruzione dei dati. Quando viene chiuso l'handle del file originale, viene chiuso l'handle del mutex e si perdono le protezioni contro il danneggiamento dei dati. Più a lungo viene eseguito il servizio, più gli indici vengono danneggiati. Alla fine, qualcuno nota che l'indice sta restituendo risultati errati. E quando si tenta di riavviare il servizio, non riesce perché i suoi file di configurazione sono stati danneggiati.

Si segnala il problema alla società che effettua il servizio dell'indice di ricerca e determinano che l'indice è stato danneggiato, il file di registro ha interrotto misteriosamente la registrazione e il file di configurazione è stato sovrascritto con garbage. Ad un povero tecnico viene assegnato il compito senza speranza di capire perché il servizio corrompe gli indici e i file di configurazione, ignaro del fatto che l'origine della corruzione è che hai forzato la chiusura di un handle.

Ho usato Handle con successo per trovare tali processi in passato.

Lockhunter ( http://lockhunter.com/ ) funziona su sistemi a 32 e 64 bit.

Who Lock Me funziona bene e fa divertire le persone con il nome!

Giusto per chiarire, è più probabile che questo sia il risultato di comportamenti errati delle app di terze parti che non utilizzano correttamente la chiamata API CreateFile di quanto non lo siano in Windows stesso. Forse è una conseguenza del design di CreateFile, ma fatto è fatto e non possiamo tornare indietro.

Fondamentalmente quando si apre un file in un programma Windows hai la possibilità di specificare un flag che consenta l'accesso condiviso. Se non si specifica il flag, il programma accede in modo esclusivo al file.

Ora, se Explorer sembra essere il colpevole qui, potrebbe essere il caso che sia solo in superficie e che il vero colpevole sia qualcosa che installa un'estensione shell che apre tutti i file in una cartella per i propri scopi ma è anche gung-ho nel farlo, o che non si ripulisce correttamente dopo se stesso. Symantec AV è qualcosa che ho già visto fare prima, e non sarei sorpreso se anche altri programmi AV fossero da biasimare. Anche i plug-in di controllo del codice sorgente potrebbero essere difettosi.

Quindi non proprio una risposta, ma solo alcuni consigli per non incolpare sempre Windows per quello che potrebbe essere un programma di terze parti scritto male (qualcosa che può accadere anche su qualsiasi altro sistema operativo che ha il blocco implicito dei file, ma qualsiasi sistema operativo basato su unix ha accesso condiviso da predefinito).

Su un server remoto, quando si controlla una condivisione di rete, qualcosa di semplice come la console Gestione computer può visualizzare queste informazioni e chiudere il file.

Apropos Explorer con un file aperto: "Quando questo accade su un file che devi eliminare, hai la possibilità di forzare la chiusura dell'handle o il riavvio".

Puoi semplicemente terminare Explorer.

Se questa è una cosa singola (Explorer normalmente non tiene aperto questo file), immagino che disconnettersi e riconnettersi farà il trucco.

Altrimenti, uccidi il processo di desktop Explorer e fai quello che vuoi mentre non c'è più. Innanzitutto avvia una copia di cmd.exe (è necessaria un'interfaccia utente per eseguire la pulizia prevista). Assicurarsi che non siano in esecuzione Explorer non desktop. Quindi uccidi l'ultimo Explorer con, ad esempio, Task Manager. Fai quello che vuoi nel prompt dei comandi. Infine, esegui Explorer dal prompt dei comandi e diventerà il desktop.

Immagino che potrebbe esserci qualche spiacevolezza residua se alcuni programmi systray non riescono a gestire il riavvio della shell.

I file possono essere bloccati dai processi locali (lo sblocco è lo strumento da utilizzare) e dall'accesso ai file che arriva attraverso le condivisioni.

Esiste una funzione integrata in Windows che mostra quali file sul computer locale sono aperti / bloccati dal computer remoto (che ha il file aperto tramite una condivisione file):

* Select "Manage Computer" (Open "Computer Management")
* click "Shared Folders"
* choose "Open Files"

Lì puoi persino chiudere il file con forza.

C'è anche la vista dei file aperti di NirSoft .

Con Process Hacker puoi identificare quali processi trattengono facilmente i tuoi file:

Le risposte sopra elencate riguardano situazioni in cui un processo del programma tiene aperto l'handle del file, che (fortunatamente) è per la maggior parte del tempo, tuttavia in alcuni casi (come accade attualmente su questo sistema), il sistema stesso mantiene un handle di file Aperto.

È possibile identificare questa situazione seguendo le istruzioni per trovare il processo di gestione dell'handle di file con Process Explorer sopra e notando che il nome del processo è elencato come 'sistema', oppure seguendo le istruzioni usando il monitoraggio delle risorse e notando che non viene mostrata alcuna immagine avere un filehandle aperto sul tuo file di interesse (anche se ovviamente qualcosa fa come non puoi modificare / cancellare ecc il file).

In tal caso, l'opzione (per quanto ne so) è quella di riavviare o dimenticare di fare qualsiasi cosa con quel file.

Un attimo fa mi sono rivolto a Exteneded Task Manager dal blog di Jeremy Zawodny, ed è ottimo per rintracciare ulteriori informazioni anche sui processi. +1 anche per Process Explorer come sopra, soprattutto per l'uccisione di processi che il Task Manager standard non terminerà.

C'è uno strumento FILEMON e mostra file e handle aperti. È difficile tenere il passo con il suo display se lo guardi dal vivo, lo fa così rapidamente. Ma puoi impedirne la visualizzazione dal vivo e puoi guardare tutte le attività di apertura / scrittura dei file. Ora di proprietà di Microsoft ma originariamente di Sysinternals