Home/ Questions/Q 64653
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T18:49:25+00:00

I’m using Visual Studio 2008 Team System with SP1, and I’ve noticed an annoying

  • 0

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.

Anyone have any ideas?

@korona – Nope, that didn’t fix it. Thanks for your suggestion, though.

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….

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. 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.

    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.

    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:.

    • 0