Perché a volte Windows non può uccidere un processo?

In questo momento sto cercando di eseguire / eseguire il debug della mia applicazione in Visual Studio, ma non è possibile crearla perché l'ultima istanza di app.vshost.exeè ancora in esecuzione. Quindi, usando Task Manager sto cercando di ucciderlo, ma rimane lì senza alcun segnale di attività.

Al di là di quel caso particolare (forse un bug di Visual Studio), sono molto curioso dei motivi tecnici per cui a volte Windows non può uccidere un processo?

Può, uno sviluppatore collegato al sistema operativo illuminato, provare a spiegare?

(E per favore non iniziare una battaglia Unix / Linux / Mac contro Windows.)

La causa è in genere un driver che non risponde che ha richieste di I / O non completate in corso.

Vedi il blog di Mark Russinovich Unkillable Processes ( archivio )

Un possibile motivo: non è possibile uccidere un'attività collegata a un debugger.

L'unico modo per interrompere l'attività è dal debugger stesso.

Uno dei motivi sarebbe che non hai il permesso di ucciderlo. Ad esempio, se il processo è in esecuzione come amministratore e sei un utente normale.

Apri la pagina Proprietà per il progetto, vai alla scheda Debug e seleziona "Abilita debug di codice non gestito". In alternativa, deseleziona l'opzione per l'utilizzo del processo host.

Se l'ultimo app.vshost.exe è ancora in esecuzione, connettiti a quel processo con il debugger.

Dovrebbe essere trovato nel menu in Debug-> AttachToProcess quindi scegliere il processo di sospensione e connettersi ad esso.

La mia unica esperienza di sviluppo a livello di sistema operativo è stata alla scuola elementare, ma sospetto che ciò che sta accadendo sia questo (o qualcosa di simile):

Si è verificato un errore durante l'esecuzione dell'ultima istanza che il debugger ha tentato di gestire, ma alcuni altri problemi hanno causato l'errore (forse si è verificata un'asserzione di debug, ma prima di poter fare clic sulla finestra di dialogo per interrompere / riprovare / ignorare, è stata attivata un'altra interruzione , forse a causa di un puntatore nullo). Il risultato, dopo l'interruzione del debug, è stato che il debugger stava ancora aspettando la tua risposta alla prima asserzione di debug, quindi non avrebbe potuto interrompere il processo. Ma poi il debugger è terminato quando hai interrotto il debug (o l'hai fatto?), Trasformando il processo in uno zombi o il suo albero in zombi. Quando hai tentato di uccidere il processo di zombi, si è verificato un errore simile a questo, ma il task manager non te lo ha detto:

C:\Windows\system32>taskkill /pid 9564 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.

Se decidessi di provare la stessa cosa sul genitore (nel mio caso il genitore era il processo di debugger, msvsmon.exe), fallisce allo stesso modo:

C:\Windows\system32>taskkill /pid 22520 /f /t
ERROR: The process with PID 9564 (child process of PID 22520) could not be
terminated.
Reason: There is no running instance of the task.
ERROR: The process with PID 22520 (child process of PID 13964) could not be
terminated.
Reason: There is no running instance of the task.

Il genitore è stato avviato dall'IDE, ma l'IDE ha tagliato il cordone ombelicale, quindi ora hai due processi di zombi. Non è possibile collegare un debugger al processo di debug, poiché è già collegato un debugger (zombie) e non è possibile collegare un debugger al debugger (zombie) perché, come Visual Studio ti dirà quando proverai :

Impossibile collegarsi al processo. Un'operazione non è legale nello stato corrente.

Gli zombi sono ancora nella tabella dei processi sufficientemente bene da impedirti di eseguire un'altra istanza tramite il debugger, ma probabilmente potresti avviare un'altra istanza al di fuori dell'IDE.

Questo risolve il problema più specifico di avere VS che crea un processo di zombi. Ma i processi di zombi spesso non muoiono. Bene, spesso su Windows, a volte su Linux, non fino a quando non li spari con un fucile. O è stato un arresto? Ma attenzione all'applicazione accidentale di aggiornamenti di Windows in sospeso.

Mi sono emozionato per alcune delle risposte precedenti che suggerivano di collegarmi con il debugger, ma quanto sopra è il risultato che ho ottenuto. Quindi sto inviando la mia risposta e riavvio per ripulire la tabella dei processi.

Forse un esame di alcuni degli strumenti citati qui potrebbe portare a risposte?

/programming/49988/really-killing-a-process-in-windows

(Proprio ora ho scoperto che pskill era l'unico di numerosi strumenti che potevano uccidere un processo in esecuzione sotto la sessione di Windows 7 di un utente, dalla sessione di un altro utente (o credenziali, suppongo.)

Puoi!

Utilizzando ProcessHacker (tasto destro del mouse sul processo) -> Terminator.

Se stai usando VS per eseguire il debug del processo e lo uccidi con il task manager, allora VS non riesce a gestirlo bene.

Quindi VS sta ancora eseguendo il debug del processo di destinazione, ma non è possibile premere il processo di arresto in VS. Basta uscire dal VS e vedrai il processo terminare.