每天至少两到三次Visual Studio被卡住(我怀疑死锁)并显示旋转马桶 - 死亡光标并弹出可怕的“ Microsoft Visual Studio忙碌< / em>“通知区域中的通知:
过去,当发生这种情况时,Visual Studio将会持续数小时(可能直到时间结束或断电),除非我在任务管理器中将其“踢完”进入路边。
最近我注意到,当问题出现时,似乎总是潜伏着另一个过程 - Microsoft.PythonTools.Attacher.exe
- 这是Python Tools for Visual Studio project的一部分:
如果我杀了那个进程,那么Visual Studio设法将自己从任何致命的拥抱中解脱出来并且可以继续前进,这就是我每次VS都会注意到的。
虽然我安装了Visual Studio 1.0的Python工具,但我正在处理的项目是用C#编写的普通的ASP.NET MVC3应用程序。我没有使用任何Python代码或库,而且我只运行一个Visual Studio实例。
我还观察到,这个过程并不总是在整个开发过程中开始/出现,并且当它开始时,它似乎开始随机时间(即它在第一个小时或两个之后不存在然后它神奇地出现在任务管理器的进程列表中),但是当它发生时,我知道我在某些时候会遇到麻烦。
有谁知道为什么这个过程似乎是随机启动的,为什么它会以如此戏剧性的方式干扰Visual Studio呢?
我在Windows 7 Ultimate x64 SP1上运行Visual Studio 2010 Premium SP1。
答案 0 :(得分:2)
当您执行Debug-&gt; Attach to Process时,您将看到VS显示一个进程列表,并显示它们可以调试的代码类型,这些代码在这些进程中运行。要获取此信息,VS将查询各种已安装的调试引擎。因此,当我们被查询时,我们会检查一系列流程以查看正在发生的事情。如果它的32位处理过程很简单 - 我们可以使用各种API来枚举模块,并尝试找出过程中是否有Python解释器。如果它是一个64位的进程生命有点困难,因为我们在VS内运行它是一个32位进程。我们不能使用从32位到64位进程的API,因此我们生成一个帮助程序进程来完成工作。
听起来这个辅助过程在某种程度上变成了你系统上的僵尸。如果你可以将VS连接到它并将任何堆栈跟踪发送回bug中,那就太棒了。但是如果帮助程序没有响应,我们还应该提供一些深度防御和超时。
最后杀死它通常应该是安全的,它没有做任何有状态的事情,我们会在需要时开始新的。
如果您从未使用Debug-&gt;附加到Process for Python调试,我们的.pkgdef文件可能会有一个简单的文件更新,我可以追踪并发布,这会使这个问题完全消失。