-1

每天至少 2 到 3 次 Visual Studio 卡住（我怀疑陷入僵局）并显示旋转的厕所碗死亡光标并在通知区域弹出可怕的“ Microsoft Visual Studio 正忙”通知：

在此处输入图像描述

过去，当这种情况发生时，Visual Studio 会保持这种状态数小时（可能直到时间结束或断电），除非我在任务管理器中使用“结束进程”将它踢到路边。

最近我注意到，每当出现这个问题时，似乎总是潜伏着另一个进程Microsoft.PythonTools.Attacher.exe——这是Visual Studio 项目的 Python 工具的一部分：

在此处输入图像描述

如果我终止该进程，那么 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。

4

1 回答 1

2

当您执行 Debug->Attach to Process 时，您会看到 VS 显示一个进程列表，并与它们一起显示您可以调试在这些进程中运行的代码类型。要获取此信息，VS 会查询各种已安装的调试引擎。所以当我们被询问时，我们会去检查一堆进程，看看发生了什么。如果它是一个 32 位进程，生活很容易——我们可以使用各种 API 来枚举模块并尝试找出进程中是否有 Python 解释器。如果它是一个 64 位进程，则生命会更艰难一些，因为我们在 VS 内部运行并且它是一个 32 位进程。我们不能使用从 32 位到 64 位进程的 API，因此我们生成了一个辅助进程来完成这项工作。

听起来这个辅助进程不知何故变成了您系统上的僵尸。如果您可以将 VS 附加到它并将任何堆栈跟踪发送回错误中，那就太好了。但是，如果辅助进程没有响应，我们还应该提供一些深度防御和超时。

最后杀死它通常应该是安全的，它没有做任何有状态的事情，我们会在需要时开始一个新的。

如果您从不使用 Debug->Attach to Process 进行 Python 调试，那么我们的 .pkgdef 文件可能会有一个微不足道的文件更新，我可以跟踪并发布它，这将使这个问题完全消失。

于 2012-05-26T05:59:07.610 回答