Я не могу убить MyApp.vshost.exe
Мне удалось получить себя в состоянии, когда у меня нет экземпляров devenv running, но все же MyApp.vshost.exe в фоновом режиме (без видимых окон или консолей).
Я пробовал TaskManager, ProcessExplorer и командную строку (taskkill /F /IM MyApp.vshost.exe
), ни одна из них не жалуется, в командной строке даже говорится: "PID 5824 остановлен", но он все еще там.
Я знаю, что могу перезагрузиться, но я предпочел бы разобраться в этом.
Это не похоже на эту проблему (http://support.microsoft.com/kb/982551), потому что я не могу перезагрузить проблему (просто на самом деле, так извините, не сможет предоставить какую-либо дополнительную диагностику).
ИЗМЕНИТЬ
Вот как я попал в этот рассол:
![alt text]()
Ответы
Ответ 1
Мне удалось убить мой постоянный процесс vshost, выполнив следующие шаги (VS2010):
- откройте свойства моего исполняемого проекта
- на вкладке "Отладка" снимите флажок "Включить процесс хостинга Visual Studio"
- сохранить файл проекта
Вот и все, процесс остановился, и не было необходимости перезапуска Visual Studio.
Ответ 2
Кажется, это нормальное поведение для этой задачи. Когда вы его убиваете, задача перезапускается.
Поэтому я советую вам закрыть Visual Studio, которая закрывает задачу *.vshost.exe.
Ответ 3
У меня была та же проблема при работе над проектом с .NET 2.0 в качестве целевой среды.
Временное изменение целевой среды для клиента .NET 4.0 сделало эту работу для меня.
Тем не менее, я не знаю, как это (это?) связано с проблемой блокировки файлов.
Ответ 4
Возможно, та же проблема, что описана в fooobar.com/info/52932/... (ожидающие процессы ввода-вывода):
API MSDN ref говорит: "TerminateProcess инициирует завершение и немедленно возвращается. Это останавливает выполнение всех потоков в процессе и требует отмены всех ожидающий ввода-вывода. Прекращенный процесс не может выйти, пока все ожидающие ввода-вывода не будут завершены или отменены.". Это означает, что: ваш ввод-вывод может блокировать этот процесс (хотя мне интересно, как он может довести ваш процесс до 100%, I/O обычно этого не делает).