Taskkill/f ne tue pas un processus
Lorsque je démarre une instance expérimentale de VS à partir de VS pour le débogage et l’arrête (parfois directement à partir du VS parent), un processus zombile devenv.exe est toujours en cours d’exécution que je ne parviens pas à éliminer. Il conserve beaucoup de mes dll.
Comme je suis connecté à cette machine Win7 64 bits en tant qu'administrateur, je m'attendrais à pouvoir tuer tous les processus que je souhaite.
I tried (from Administrator command Prompt):
End Task from Task Manager.
TASKKILL /F /IM devenv.exe
PSKILL devenv.exe
Aucun ne renvoie d'erreur et TASKKILL et PSKILL ont renvoyé des messages de réussite indiquant la fin/la suppression du processus. Mais devenv.exe fonctionne toujours, il n'est pas ré-engendré car la PID reste constante. Il ne disparaît qu'au redémarrage du système, ce qui n'est pas une bonne solution.
Remarque. LockHunter montre que devenv a un verrou sur lui-même. Et il ne peut pas le déverrouiller.
La capture d'écran ci-dessus est la sortie de Process Monitor montrant que devenv est dans une sorte de boucle 'Process Profiling' (cliquez dessus avec le bouton droit de la souris et cliquez sur Ouvrir l'image dans un nouvel onglet pour la voir correctement).
Des idées comment tuer un tel processus sur Windows?
vous devez également tuer le processus enfant s'il en est créé un pour tuer votre processus avec succès
taskkill /IM "process_name" /T /F
/T = kills child process
/F = forceful termination of your process
Je viens d'avoir le même problème sur Windows Server 2008 R2 et rien n'y fait, pas de gestionnaire de tâches ni de tâches. Mais, Windows PowerShell exécuté en tant qu'administrateur a travaillé avec "kill -id pid"
Le redémarrage est la seule solution qui a fonctionné pour moi (jusqu'à présent).
Le toujours excellent Mark Russonovich a une bonne explication pour les processus impossibles à tuer.
Pour résumer, il est fort possible que cela soit dû à des requêtes d'E/S non traitées qui n'ont pas été traitées correctement (par un pilote de périphérique auquel votre programme a éventuellement accédé)
http://blogs.technet.com/b/markrussinovich/archive/2005/08/17/unkillable-processes.aspx
Les méthodes taskkill et powershell (kill) ne fonctionnaient pas pour moi; il a toujours dit accès refusé.
J'ai eu plus de chance avec ça:
wmic process where "name='myprocessname.exe'" delete
Je sais qu'il est tard, mais taskkill /im devenv.exe /t /f devrait fonctionner. le /t tue aussi les processus enfants.
Dans mon cas, après plusieurs jours de lutte contre ce problème (cela se produisait pour les processus VirtualBox et µTorrent), j’ai découvert qu’il était causé par un problème de pilote réseau provoqué par le correctif Windows Update KB4338818 (Windows 7 x64). Après la désinstallation de ce correctif, tout est revenu à la normale. Je pensais juste que cela pourrait être utile pour les autres.
Je l'ai vu plusieurs fois et ma seule solution était un redémarrage.
Vous pouvez essayer d’utiliser PowerShell: Get-Process devenv | tuer
Mais si les autres méthodes échouent, cela le sera probablement aussi. :-(
Je pourrais résoudre mon problème en corrigeant ce problème en tuant Explorer.exe, qui à son tour était accro au processus que je voulais tuer. Je suppose que cela peut aussi arriver si les processus ouvrent des interfaces via un hook qui peut être verrouillé.
tskill <pid> (ou tskill.exe <pid>) natif a fonctionné pour moi sous Windows 10, là où aucune autre réponse native ne fonctionnait.
Dans mon cas, j'avais des processus chrome.exe pour lesquels la tâche "End Task" du gestionnaire de tâches fonctionnait, mais ni taskkill /F /T /PID <pid> ni le code kill -id <pid> de powershell ne fonctionnaient (même avec les deux shells exécutés en tant qu'administrateur).
Ceci est très étrange car taskkill est censé être une meilleure version de tskill.
Dans mon cas, pour tuer toutes les instances d'une tâche donnée, j'ai utilisé FOR /F "usebackq tokens=2 skip=2" %i IN (`TASKLIST /FI "IMAGENAME eq name_of_task.exe"`) DO tskill %i
Je vais suggérer quelque chose ici parce que j'ai récemment été confronté au même problème et j'ai tout essayé dans les réponses, mais rien n'a fonctionné. J'avais des erreurs comme
ERREUR: le processus avec le PID 23908 n'a pas pu être terminé . Raison: il n'y a pas d'instance en cours d'exécution de la tâche.
en utilisant l'invite de commande. Power Shell n'a pas été utile non plus. il exécuterait simplement les commandes et aucune réponse avec le processus en cours d'exécution.
Jusqu'à ce que je décide de supprimer le fichier '.exe' associé. Comme le fichier était actif, Windows ne permettait pas la suppression, mais dans cette fenêtre d'avertissement, il m'indiquait le nom du processus qui bloquait la tâche que je voulais tuer. J'ai été capable de tuer la tâche originale et donc le processus de buggy.
Il vaut vraiment la peine d'essayer si aucune des solutions ne résout le problème.
Certains des fichiers Exe dépendants de certains services,
Vous devez donc trouver le service correspondant et vous arrêter en premier.
J'obtenais les résultats suivants avec taskkill
>taskkill /im "MyApp.exe" /t /f
ERROR: The process with PID 32040 (child process of PID 54176) could not be terminated.
Reason: There is no running instance of the task.
>taskkill /pid 54176 /t /f
ERROR: The process "54176" not found.
Ce qui a fonctionné pour moi était sysinternal'spskill
>pskill.exe -t 32040
PsKill v1.15 - Terminates processes on local or remote systems
Copyright (C) 1999-2012 Mark Russinovich
Sysinternals - www.sysinternals.com
Process 32040 killed.
Vous pouvez obtenir pskill sur le site live de sysinternal
Le même problème m'est arrivé dans VirtualBox en ce qui concerne les processus Java.
Dans mon cas, il s'agissait d'un bogue du correctif KB4338818 (Windows 7 x64) de Windows Update.
Je l'ai résolu en procédant comme suit:
- Désinstallez le correctif Windows Update KB4338818
- Installer le correctif Windows Update KB4338821
J'ai le problème avec les processus de débogage avec gdb dans Code :: Blocks . Dès qu'il est suspendu en entrant accidentellement dans des instructions hors de la portée de vos sources (comme des bibliothèques sans sources ni fonctions système), vous ne pouvez pas quitter le débogage Code :: Blocks ni à partir du gestionnaire de tâches.
Je pense que c'est une erreur dans l'implémentation de gdb dans Code :: Blocks, mais pourrait aussi l'être dans gdb;)
Ma solution:
taskkill /F /IM process.exe /T
Cela montre le PID du processus parent. Maintenant tuez le parent:
taskkill /PID yyyy
Les deux sont partis.
Terminé.
Pour moi, la façon dont cela a fonctionné est que je dois tuer le processus parent. Figure le processus parent et le tuer
taskkill /IM "parent_process_name.exe" /T /F
Si vous téléchargez gratuitement la suite Sysinternals, elle contient une application pskill.exe qui fonctionne bien pour ces types de tâches: pskill.exe "nom_processus" Il fonctionne sur ces processus même sans utiliser l’option -t.
si taskkill /F /T /PID <pid> ne fonctionne pas . Essayez d'ouvrir votre terminal par Run as Administrator.
Recherchez cmd dans le menu de votre fenêtre, cliquez avec le bouton droit de la souris sur Run as Administrator, .__ puis relancez la commande. Cela a fonctionné pour moi.
J'ai fait ce qui suit sur un PowerShell élevé:
PS C:\Windows\system32> wmic.exe /interactive:off process where "name like `'Java%'`" call terminate
sortie de commande:
Executing (\\SRV\ROOT\CIMV2:Win32_Process.Handle="3064")->terminate()
Method execution successful.
Paramètres de sortie:
instance of __PARAMETERS
{ReturnValue = 0; };
J'ai quelques informations de syntaxe sur: https://community.spiceworks.com/topic/871561-wmic-error-like-invalid-alias-verb
En tant que Francis mentionné, certains processus ne peuvent pas être interrompus à cause de
"demandes d'E/S non traitées"
Selon mon expérience, j’avais affaire à un buggy pilote graphique qui ferait planter mon jeu et ne pourrait pas le fermer. En dernier recours, je désactivé le pilote graphique et le processus ont finalement disparu.
Si votre application attend un ressource de pilote tel que le wifi ou le graphique, essayez désactivant dans gestionnaire de périphériques, vous devez creuser un peu pour voir mieux. où ils ont pendu.
Ceci n'est bien sûr pas recommandé mais parfois vous n'avez plus rien à perdre.
J'ai eu le même problème et comme beaucoup d'autres ici ont dit qu'aucune des commandes normales de Kill ne fonctionnait. Mon fichier de problème était un exécutable qui était exécuté à partir d'un partage réseau par un utilisateur sur un serveur de bureau à distance. Avec plusieurs utilisateurs partagés, il n'est pas facile de redémarrer pendant une journée de travail. Même lorsque l'utilisateur était déconnecté, le fichier exe était toujours répertorié dans le Gestionnaire des tâches. J'ai envoyé au serveur sur lequel le dossier était partagé et à partir de Gestion de l'ordinateur -> Sessions, l'utilisateur avec la session toujours ouverte à partir de ce serveur RDP, même s'il était déconnecté. Clic droit -> Fermer la session et le verrou de fichier a été libéré.
Cela me fait perdre une raison pour laquelle je ne pouvais pas mettre fin à la tâche. Le message d'erreur que je recevais à l'origine lorsque j'essaie de supprimer le fichier était "L'action ne peut pas être terminée car le fichier est ouvert dans Système".
J'espère que ceci aide quelqu'un d'autre.
J'ai rencontré le même problème que lorsque j'ai démarré une application de nœud sur le port 3000, qui ne s'est pas fermée correctement et le processus a continué à s'exécuter même après le redémarrage.
Aucune des commandes taskkill ou powershell exécutées en mode administrateur ne fonctionnait pour moi.
J'ai utilisé MS Process Expoler> Propriétés> Image> Répertoire actuel (qui était supposé être le répertoire mon projet).
Enfin, je devais redémarrer SafeMode, renommer le dossier du projet et le redémarrer. Les processus de nœud qui consommaient le port 3000 se sont tués.
J'ai eu exactement le même problème, j'ai trouvé ce correctif sur un autre site: le/T ne fonctionnerait pas.
J'ai eu le même problème, essayez d'exécuter cmd comme «Exécuter en tant qu'administrateur»
Exécuter CMD en tant qu'administrateur corrigera le problème