Dlaczego czasami system Windows nie może zabić procesu?

Obecnie próbuję uruchomić / debugować moją aplikację w programie Visual Studio, ale nie można jej utworzyć, ponieważ ostatnia instancja app.vshost.exenadal działa. Następnie, używając Menedżera zadań, próbuję go zabić, ale pozostaje tam bez sygnału aktywności.

Poza tym szczególnym przypadkiem (być może błędem Visual Studio) jestem bardzo ciekawy technicznych powodów, dla których Windows czasami nie może zabić procesu?

Czy oświecony programista związany z systemem operacyjnym może spróbować wyjaśnić?

(I proszę, nie zaczynaj bitwy Unix / Linux / Mac przeciwko Windows.)

Przyczyną jest zwykle jakiś niereagujący sterownik, który ma niedokończone żądania We / Wy w toku.

Zobacz wpis na blogu Marka Russinowicza Procesy nie do zabicia ( archiwum )

Jeden możliwy powód: nie możesz zabić zadania dołączonego do debuggera.

Jedynym sposobem na zatrzymanie zadania jest sam debugger.

Jednym z powodów byłoby to, że nie masz pozwolenia na zabicie go. Np. Jeśli proces działa jako administrator i jesteś zwykłym użytkownikiem.

Otwórz stronę Właściwości projektu, przejdź do karty Debugowanie i zaznacz „Włącz debugowanie niezarządzanego kodu”. Lub odznacz opcję korzystania z procesu hosta.

Jeśli ostatni plik app.vshost.exe nadal działa, po prostu połącz się z tym procesem za pomocą debugera.

Powinien być znaleziony w menu pod Debuguj-> AttachToProcess, a następnie wybierz proces zawieszania i połącz się z nim.

Moje jedyne doświadczenie w programowaniu na poziomie systemu operacyjnego było w szkole, ale podejrzewam, że dzieje się to (lub coś podobnego):

Wystąpił błąd podczas uruchamiania ostatniej instancji, którą debuger próbował obsłużyć, ale jakiś inny problem spowodował, że to się nie powiodło (być może napotkano potwierdzenie debugowania, ale zanim można było kliknąć okno dialogowe Abort / Retry / Ignore, uruchomiono kolejną przerwę , może z powodu pustego wskaźnika). W wyniku tego, po zatrzymaniu debugowania, debuger nadal czekał na twoją odpowiedź na pierwsze stwierdzenie debugowania, więc proces nie został zakończony. Ale potem debuger zakończył się, gdy przestałeś debugować (czy zrobiłeś to?), Zamieniając proces w zombie lub jego drzewo w zombie. Podczas próby zabicia procesu zombie wystąpił błąd podobny do tego, ale menedżer zadań nie powiedział o tym:

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.

Jeśli zdecydujesz się wypróbować to samo na obiekcie nadrzędnym (w moim przypadku rodzicem był proces debugowania, msvsmon.exe), nie powiedzie się to w ten sam sposób:

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.

Rodzic został założony przez IDE, ale IDE przecięło pępowinę, więc teraz masz dwa procesy zombie. Nie możesz dołączyć debugera do procesu, który debugowałeś, ponieważ jest już podłączony debugger (zombie) i nie możesz dołączyć debugera do debugera (zombie), ponieważ, jak Visual Studio powie ci, kiedy spróbujesz :

Nie można dołączyć do procesu. W obecnym stanie operacja nie jest legalna.

Zombie nadal znajdują się w tabeli procesów wystarczająco dobrze, aby uniemożliwić uruchomienie innej instancji za pośrednictwem debugera, ale prawdopodobnie można uruchomić inną instancję poza środowiskiem IDE.

Rozwiązuje to bardziej konkretny problem polegający na tym, że VS tworzy proces zombie. Ale procesy zombie często nie umierają. Cóż, często na Windowsie, czasem na Linuksie, dopóki nie zastrzelisz ich strzelbą. Czy to było zamknięcie? Ale uważaj na przypadkową aplikację oczekujących aktualizacji systemu Windows.

Byłem podekscytowany niektórymi wcześniejszymi odpowiedziami, które sugerowały dołączenie się do debuggera, ale powyższy wynik jest wynikiem. Przesyłam więc swoją odpowiedź i uruchamiam ponownie, aby wyczyścić tabelę procesów.

Być może analiza niektórych cytowanych tu narzędzi może prowadzić do odpowiedzi?

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

(Właśnie teraz odkryłem, że pskill jest jedynym z kilku narzędzi, które mogą zabić proces działający w ramach sesji Windows 7 jednego użytkownika z sesji innego użytkownika (lub, jak sądzę, poświadczeń).

Możesz!

Korzystanie z ProcessHacker (kliknij proces prawym przyciskiem myszy) -> Terminator.

Jeśli używasz VS do debugowania procesu i zabijasz go za pomocą menedżera zadań, a następnie VS nie może sobie z tym dobrze poradzić.

Więc VS nadal debuguje proces docelowy, ale nie można po prostu nacisnąć zatrzymać procesu w VS. Wystarczy wyjść z VS i zobaczysz, że proces się kończy.