VS2008 调试器挂起 [英] VS2008 Debugger Hang

问题描述

我使用的是带有 SP1 的 Visual Studio 2008 Team System，并且我注意到每当我停止调试应用程序时，IDE 都会挂起数 (10-15) 秒的烦人趋势.起初我以为这只发生在 WPF 应用程序中，但我也观察到了 Windows 窗体应用程序和 ASP.NET 站点中的行为.我根据 这篇上一篇文章 对选项进行了一系列更改，并在 Google/MSDN 上进行了详尽的修改搜索，但仍然没有找到阻止这种情况的方法.

I'm using Visual Studio 2008 Team System with SP1, and I've noticed an annoying tendency for the IDE to hang for several (10-15) seconds whenever I stop debugging an application. At first I thought this only happened with WPF apps, but I've observed the behavior in Windows Forms apps and ASP.NET sites as well. I've made a series of changes to the Options based on this previous post and done exhaustive Google/MSDN searches, but still haven't found a way to stop this.

有人有什么想法吗?

@korona - 不，这并没有解决问题.不过还是谢谢你的建议.

@korona - Nope, that didn't fix it. Thanks for your suggestion, though.

ProcMon 中的更多研究显示了这个有趣的花絮，不确定是否相关:

More research in ProcMon shows this interesting tidbit, not sure if it is related:

8:45:46.6790857 AM  WindowsFormsApplication1.vshost.exe 7684    FASTIO_CHECK_IF_POSSIBLE    C:\WINXP\Microsoft.NET\Framework\v2.0.50727\CONFIG\enterprisesec.config.cch FAST IO DISALLOWED  Operation: Read, Offset: 48, Length: 12
8:45:46.6793569 AM  WindowsFormsApplication1.vshost.exe 7684    ReadFile    C:\WINXP\Microsoft.NET\Framework\v2.0.50727\CONFIG\enterprisesec.config.cch FAST IO DISALLOWED  Offset: 508, Length: 12

这会重复几次，比如数百次，然后切换到不同的路径:

This repeats several times, like hundreds of times, then it switches to a different path:

8:45:46.7470314 AM  WindowsFormsApplication1.vshost.exe 7684    FASTIO_CHECK_IF_POSSIBLE    D:\documents and settings\myusername\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch   FAST IO DISALLOWED  Operation: Read, Offset: 48, Length: 12
8:45:46.7472187 AM  WindowsFormsApplication1.vshost.exe 7684    ReadFile    D:\documents and settings\myusername\Application Data\Microsoft\CLR Security Config\v2.0.50727.42\security.config.cch   FAST IO DISALLOWED  Offset: 508, Length: 12

并再次重复多次，每次迭代的偏移量略有变化.也许无关，但是....

And repeats again many more times, with slight changes in the offset each iteration. Maybe unrelated, but....

推荐答案

查看您的 ProcMon 结果，似乎是 CreateFile() 调用一直在占用时间.我假设所有活动都在等待该线程返回.您可以在 Process Explorer(也是之前链接的 SysInternals 包的一部分)中使用属性"窗口上的线程"选项卡来验证这一点，但有一些困难.

Looking at your ProcMon results, it appears that it's that CreateFile() call that's taking all the time. I'm assuming that all activity is waiting for that thread to return. You can verify this -- with some difficulty -- in Process Explorer (also part of the SysInternals package previously linked), using the Threads tab on the Properties window.

因此，如果 CreateFile 是导致阻塞的原因，则表明它是 Windows 本身的延迟.皮埃尔所说的——注意网络共享——也是我的第一直觉.过去，当 Explorer 映射到我目前无法访问的共享时，我遇到了很多看似莫名其妙的减速，即使我当时没有对这些共享进行任何工作.

So, if CreateFile is what's causing the blockage, that would suggest that it's a delay in Windows itself. What Pierre said -- look out for network shares -- was my first instinct, too. I've had a lot of seemingly-inexplicable slowdowns in the past when Explorer had a mapping to a share that I couldn't currently reach, even though I wasn't doing any work on those shares at the time.

您能否通过取消映射所有驱动器并从网络中拔出来测试这种可能性?D: 是与 C: 分开的物理驱动器吗?如果是这样，看看将构建目录移动到 C: 是否会更快.

Can you test this possibility by unmapping all your drives and unplugging from the network? Is D: a separate physical drive from C:? If so, see if it goes faster if you move your build directory to C:.

这篇关于VS2008 调试器挂起的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！