Pourquoi parfois Windows ne peut pas tuer un processus?

En ce moment, j'essaie d'exécuter / déboguer mon application dans Visual Studio, mais il ne peut pas la créer car la dernière instance de la app.vshost.exeest toujours en cours d'exécution. Ensuite, en utilisant le Gestionnaire des tâches, j'essaie de le tuer, mais il reste là sans aucun signal d'activité.

Au-delà de ce cas particulier (peut-être un bogue Visual Studio), je suis très curieux de savoir pourquoi, parfois, Windows ne peut pas tuer un processus?

Pouvez-vous, un développeur éclairé lié au système d'exploitation, veuillez essayer d'expliquer?

(Et s'il vous plaît, ne lancez pas une bataille Unix / Linux / Mac contre Windows.)

La cause est généralement un pilote qui ne répond pas et qui a des demandes d' E / S inachevées en cours.

Voir l'entrée de blog de Mark Russinovich Unkillable Processes ( archive )

Une raison possible: vous ne pouvez pas tuer une tâche attachée à un débogueur.

Le seul moyen d'arrêter la tâche est à partir du débogueur lui-même.

Une des raisons serait que vous n'avez pas la permission de le tuer. Par exemple, si le processus s'exécute en tant qu'administrateur et que vous êtes un utilisateur normal.

Ouvrez la page Propriétés du projet, accédez à l' onglet Débogage et cochez «Activer le débogage de code non géré». Ou, décochez l'option pour utiliser le processus hôte.

Si le dernier app.vshost.exe est toujours en cours d'exécution, connectez-vous simplement à ce processus avec le débogueur.

Doit être trouvé dans le menu sous Debug-> AttachToProcess puis choisissez le processus de suspension et connectez-vous.

Ma seule expérience de développement au niveau du système d'exploitation était à l'école supérieure, mais je soupçonne que ce qui se passe est le suivant (ou quelque chose de similaire):

Une erreur s'est produite lors de l'exécution de la dernière instance que le débogueur a tenté de gérer, mais un autre problème a provoqué l'échec (peut-être qu'une assertion de débogage a été rencontrée, mais avant de pouvoir cliquer sur la boîte de dialogue pour abandonner / réessayer / ignorer, une autre interruption a été déclenchée , peut-être en raison d'un pointeur nul). Le résultat, après avoir arrêté le débogage, était que le débogueur attendait toujours votre réponse à la première assertion de débogage, de sorte qu'il ne laisserait pas le processus se terminer. Mais le débogueur s'est terminé lorsque vous avez arrêté le débogage (ou l'avez-vous fait?), Transformant le processus en zombie ou son arbre en zombies. Lorsque vous avez essayé de tuer le processus zombie, une erreur similaire à celle-ci s'est produite, mais le gestionnaire de tâches ne vous en a pas parlé:

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.

Si vous décidez d'essayer la même chose sur le parent (dans mon cas, le parent était le processus de débogage, msvsmon.exe), cela échoue de la même manière:

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.

Le parent a été lancé par l'IDE, mais l'IDE a coupé le cordon ombilical, vous avez donc maintenant deux processus zombies. Vous ne pouvez pas attacher un débogueur au processus que vous déboguez, car il y a déjà un débogueur (zombie) attaché, et vous ne pouvez pas attacher un débogueur au débogueur (zombie) parce que, comme Visual Studio vous le dira lorsque vous essayez :

Impossible de joindre le processus. Une opération n'est pas légale dans l'état actuel.

Les zombies sont toujours suffisamment bien dans la table de processus pour vous empêcher d'exécuter une autre instance via le débogueur, mais vous pourriez probablement démarrer une autre instance en dehors de l'EDI très bien.

Cela résout le problème plus spécifique de la création par VS d'un processus zombie. Mais, les processus zombies ne meurent souvent pas. Eh bien, souvent sous Windows, parfois sous Linux, pas avant de les tirer avec un fusil de chasse. Ou était-ce un arrêt? Mais méfiez-vous de l'application accidentelle des mises à jour Windows en attente.

J'ai été excité par certaines des réponses précédentes qui suggéraient de se joindre au débogueur, mais ce qui précède est le résultat que j'ai obtenu. Je soumets donc ma réponse et je redémarre pour nettoyer la table de processus.

Peut-être qu'un examen de certains des outils cités ici pourrait conduire à des réponses?

https://stackoverflow.com/questions/49988/really-killing-a-process-in-windows

(Tout à l'heure, j'ai découvert que pskill était le seul de plusieurs outils pouvant tuer un processus exécuté sous la session Windows 7 d'un utilisateur, à partir d'une session d'un autre utilisateur (ou des informations d'identification, je suppose.)

Vous pouvez!

Utilisation de ProcessHacker (clic droit sur le processus) -> Terminator.

Si vous utilisez VS pour déboguer le processus et que vous le tuez avec le gestionnaire de tâches, VS ne peut pas le gérer correctement.

Donc, VS débogue toujours le processus cible, mais vous ne pouvez pas simplement appuyer sur arrêter le processus dans VS. Quittez simplement votre VS et vous verrez votre processus se terminer.