Da quando ho iniziato a utilizzare Windows 7 questo problema mi ha infastidito. Di tanto in tanto vedo domande simili spuntare su forum diversi, ma non vedo mai una risposta. Ecco due scenari che quasi sempre lo riproducono:
Il modo dell'esploratore
- Con explorer, passa a una directory contenente almeno un file exe
- Passa immediatamente a una directory
- Elimina la directory appena navigata
- Rendimento Accesso alla cartella Finestra di dialogo negata in cui è richiesta l'autorizzazione per eseguire questa azione È necessaria l'autorizzazione degli amministratori per apportare modifiche a questa cartella , con i pulsanti riprovare e Annulla
- Colpire Riprova non funziona mai immediatamente. Attendere circa un minuto e quindi fare nuovamente clic su di esso funziona
Nota: se nel passaggio 2 e in attesa di un minuto o più prima di salire su una directory, il problema non si verifica e la cartella può essere eliminata
Il modo in cui Visual Studio
- Crea un progetto producendo un file exe
- eseguire l'eseguibile quindi chiuderlo
- Ricrea immediatamente il progetto (modificando ad esempio un singolo carattere in un file sorgente)
- Rendimenti irreversibile LNK1168 errore: /path/to/the.exe non possono aprire per la scrittura
Nota: se nel passaggio 2 e in attesa di un minuto o più prima di creare nuovamente, il problema non si verifica.
Alcune specifiche
- Succede sia su Windows 7 a 32 che a 64 bit, con VS2008 / 2010/2011
- Succede su 3 macchine diverse
- Non ho uno scanner antivirus di alcun tipo
- Ho un sacco di servizi disabilitati, ma nulla che impedisce a Windows di funzionare normalmente, anche UAC è disabilitato
- Succede su qualsiasi tipo di disco
- Uso sempre un account utente nel gruppo Amministratori
Ovviamente entrambi gli scenari sono molto simili ed estremamente riproducibili. Quindi ho pensato che un processo avrebbe dovuto aprire il file per qualche motivo e rilasciarlo di nuovo in seguito. Tuttavia, usando sysinternals
handle -a
il file exe in questione non viene mai visualizzato. (questo è il modo corretto di usare handle, giusto?) Quindi, mentre explorer / VS stanno segnalando di non poter accedere al file, handle.exe dice che non è in uso da nessuna parte. Questo mi lascia piuttosto all'oscuro, quindi mi chiedo se qualcuno può trovare una soluzione: perché succede e come risolverlo?
Aggiornamento in risposta alle domande poste:
- Non è stato possibile riprodurre il problema in modalità provvisoria
- Sono installate diverse estensioni della shell. Da SellExView, ecco quelli non Microsoft comuni a tutte le macchine: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Troverei i Tortoise più sospetti, sebbene sia per l'opzione 'Status Cache' sia impostata su 'Status cache solo per una cartella, senza sovrapposizioni ricorsive', cioè non c'è TortoiseCache.exe in esecuzione.
- Con il problema di Explorer, ProcessExplorer non mostra l'eseguibile. Tuttavia mostra la directory dell'eseguibile, ma continua a mostrarla anche dopo che è stata eliminata in modo che non sembri realmente correlata
- Con il problema VS, succede con VS anche quando nessuna finestra di explorer è aperta nella directory di destinazione. E ancora, ProcessExplorer non mostra l'eseguibile, né la directory in cui si trova l'eseguibile. Notare che in questa 'modalità' con VS, il problema si verifica solo quando si esegue l'eseguibile. Se non lo eseguo, posso costruirlo senza problemi di volta in volta.
- In "modalità VS" e una finestra di Explorer aperta nella directory dell'eseguibile (testata solo con un exe C #), diventa più strana: non riesco a costruire di nuovo perché VS si lamenta che l'exe viene utilizzato da un altro processo. Tuttavia, se cancello exe dalla finestra di Explorer aperta, questo funziona e, di conseguenza, la costruzione ha esito positivo. Ancora una volta, nessun riferimento in ProcessExplorer. Che sembra corrispondere ai miei risultati con handle.exe (non PE e handle usano comunque la stessa API internamente?)
Aggiornamento 2 Non può essere solo explorer: dopo aver ucciso explorer.exe, il problema VS è ancora lì.
Aggiornamento 3 L' uso di Process Monitor come suggerisce Asher rivela fatti interessanti: per la modalità explorer, ci sono 10 chiamate a IRP_MJ_CREATE all'apertura della directory. Tuttavia, solo 9 chiamate a IRP_MJ_CLEANUP. Tutto questo le chiamate provengono dall'interno shell32.dll, quindi è sicuramente non è un 3rd party installa il problema. Ed è ovviamente quello mancante IRP_MJ_CLEANUP che causa il problema: esattamente 1 minuto dopo l'apertura della directory, il processo di sistema stesso emette la chiamata IRP_MJ_CLEANUP e il file viene rilasciato e viene eliminato.
Tuttavia, non riuscivo ancora a capire perché questo accada. È un bug di explorer attivato da alcune modifiche che ho apportato?
Soluzione! Guardando attraverso i servizi che ho disabilitato, ho notato la descrizione di Application Experience , e cito, elabora le richieste di cache di compatibilità delle applicazioni per le applicazioni all'avvio . Suona familiare. E infatti, dopo aver avviato il servizio non riesco più a riprodurre nessuno dei problemi e l'output di ProcMon è diverso e più breve. Divertente però, perché dopo aver interrotto nuovamente il servizio, tutto è ancora a posto e l'output di procmon è ancora più breve.
Ho provato questo su due macchine, con tutte le cose di terze parti che funzionano felicemente e tutto va ancora bene.
Non sono sicuro che si tratti di un vero bug (si potrebbe dire "cosa ti aspetti dalla disabilitazione dei servizi"), ma non è esattamente normale che il problema scompaia semplicemente avviando un servizio e poi interrompendolo di nuovo.
Bounty va a chiunque sia in grado di fornire una visione più approfondita in questo, oppure a @Asher per avermi indicato ProcMon che alla fine mi ha portato nella giusta direzione.