none
visual studio hangs after debugging

    General discussion

  •  

    I'm debugging a windows form application locally, developed in VS 2008 (rtm), on Vista Business 32 (the machine is 64bit). The project is written entirely in C#. Everything seems to run fine during debugging. When the process is stopped, however, VS will hang 3-8 seconds. I've started small "hello world" test projects to see if they cause the same effect - and they do. I have not seen this affect when running the project without the debugger (ctrl+F5). Also, I went through the debugger FAQ, making the changes suggested, without success. Is there another option I need to look at?

    TIA  

    Tuesday, January 29, 2008 4:48 PM

All replies

  • Hi,

     

    Could you clarify what is meant by process is stopped? Are you doing a Debug -> Stop Debugging and that takes a while or is the process exiting (e.g. File -> Exit was done on debuggee) and then it takes a long time or is it when you reach break state e.g. hit a breakpoint and it takes a while before you can do anything? These could be caused by different things. The last one for example could be caused because evalutions are happening and this can be disabled via the options page.

     

    Azeem Khan

    VS Debugger.

     

    Tuesday, January 29, 2008 7:22 PM
    Moderator
  • Hi,

     

    Thanks for the response. I stop the process using both methods - Debug->Stop Debugging and File->Exit on the form. The effect is the same for either one. The anomoly occurs without any breakpoints set - I have not experimented w/ setting breakpoints to see what would happen. Here's my path to recreate the problem: Write code->hit F5->hit Stop Debugging (sometimes 'exit' on the debugee)-->VS hangs for a few seconds-->write more code.

     

    R.B.

     

     

     

    Tuesday, January 29, 2008 8:53 PM
  • rwb98147,

     

    Please make sure you have all updates from windows update. There is a patch for Vista that is requird to get VS 2008 to update properly while debugging. It appears the IDE isn't painting until you move your mouse over the windows. Please let us know if that doesn't help.

     

    Jackson

    Wednesday, January 30, 2008 8:37 PM
    Moderator
  • I'm running XP and am expereincing exactly the same problem.  Is there anything I could try?
    Cheers
    Friday, February 01, 2008 3:46 AM
  • Exactly the same problem.  Running VS 2008 on Windows XP.  Once debugging stops, the application just hangs for 5 to 10 seconds.  Very frustrating.  I don't have this problem with VS 2005 on the same machine.

    Thursday, February 14, 2008 8:06 PM
  • I HAD the same problem. I deactivated the use of the visual studio host process on the debug tab in the project settings page. Now the editor responds at once.

     

    Sunday, February 17, 2008 1:47 PM
  • This problem has returned for me.  I had recently reinstalled my XP box and updated it and things were running fine, until yesterday.  I'll check for further updates and hope that the problem disappears again.

    Tuesday, April 15, 2008 1:58 PM
  • I have the exact same problem as described above and I am running XP. One difference is that the computer I see this problem on is not hooked up to the internet and I thought that that might be part of the problem. I have looked through all the Visual Studio settings and have not found a setting that may fix this problem. I see this problem whenever I run a program in debug. If I run it without debugging (Ctrl + F5) I do not see the problem but I can't debug my code when I run that way.

    Wednesday, May 21, 2008 5:43 PM
  • I've been having this exact problem for a few months now.  I uninstalled all VS plugins (Refactor! etc) and it didn't help.  I've just now performed a full REPAIR/REINSTALL of VS2008 and it STILL hangs for as much as 20s after I finish debugging.

    Makes no difference if I'm running in release or debug mode.  Incredibly frustrating to say the least.  I was really hoping that the last resort of running the full repair would sort this out, but I'm surprised (and thoroughly annoyed) that it's had no effect. 

    Clearly I'm not the only one having this problem, and I suspect it's affecting a lot more users than just the ones posting here, so I hope MS will investigate this seriously.

    My system is XP Pro x64 SP2.
    Thursday, June 05, 2008 2:31 AM
  • I'm having this exact same problem. This only happens on a workstation that is not connected to the internet. It seems as though VS2008 is trying to send/receive info over the internet after the project application is stopped (through the project itself or through the debugger).

    I've gone through just about every option in the Tools -> Options menu and deselected any option that would appear to want to access the internet. This did nothing to help.
    Thursday, June 26, 2008 12:14 PM
  • Nastynate: Some people have had success by changing a setting in Internet Explorer.  Tools, Internet Options, Advanced tab, Security section, uncheck "Check for Publisher's Certificate Revocation" (you may need to restart IE and VS for it to take effect).

    It did nothing for me though.  The only way I've managed to get around this problem is to deactivate the Visual Studio Hosting Process on the Project Properties->Debugging tab of every single project I'm working on, and this then makes app startup very slow as well as disabling some other useful features.  Unacceptable, but the only workaround I can live with for now.

    I'm on SatDSL with a high-latency connection and a proxy/firewall that I cannot disable, which I suspect is causing similar problems as if I had no net connection at all.

    The big question for me though is: what on earth does the VS Hosting Process need internet access for?  Is it trying to download symbols off the internet?  I have a suspicion that this problem only started to affect my machine shortly after MS released the debug symbols for certain core .NET libraries via their public source server.  I had a play around with enabling stepping into System.Windows.Forms.dll as per instructions on their website (did anyone else?), but finding it very slow and cumbersome I then opted to disable it. 

    I removed all references to any online symbol servers and set all my VS options back to the way they were before I tried it.  Shortly afterwards, VS2008 started to misbehave.  I even reinstalled VS2008 from scratch but to no avail.

    So all I know is that it's likely a problem with the .vshost.exe trying to access the internet for reasons known only to itself.  And some recent change (because VS2008 wasn't always like this) has fouled it up.  Maybe a new security patch downloaded from Windows Update has interfered with it?  Perhaps a timeout value has been significantly increased (i.e. vshost was always receiving a time out error on machines with poor/no net connection, but it used to take 1s and now it takes 20s) with a recent update?

    Maybe someone could install a packet sniffer on their machine and try to determine what .vshost.exe is doing when it terminates?  I'd try it myself but I don't know of any that run on XP64.

    Maybe someone from MS could actually read this and respond to it?  (Aren't they obligated to for MSDN subscribers?)
    Thursday, June 26, 2008 6:35 PM
  • has anyone had any success solving this problem? I have it too :(
    Friday, August 15, 2008 5:47 AM
  • Same problem here, I assume when everyone has this problem that VS 2008 minimizes and maximizes on its own correct?
    Monday, August 18, 2008 3:09 PM
  • It doesn't minimize/maximize for me, but I still have the problem.  I'm about to install VS2008 SP1 to see if that fixes it.

    Are you on a 64bit OS?  What version of Windows are you running?  Are you behind a restrictive proxy/firewall?  I'm trying to see if there's a common set of circumstances for everyone experiencing this problem...

    Thanks,
    Alex
    Monday, August 18, 2008 7:36 PM
  • Yeah just to confirm, SP1 did NOT fix this issue.

    Great.
    Monday, August 18, 2008 8:39 PM
  • Well, maybe I am wrong - but seems that changing the configuration to Release, running the app and then changing it back to Debug fixed this issue for me. Could you confirm this?

    Tuesday, August 19, 2008 8:54 AM
  • ag1206d - No, this has had no effect for me.  I've been doing that regularly during my dev cycle (switching to release, running to make sure everything is ok, then switching back to debug) and it's certainly had no effect.  That would tend to imply it's something to do with project solution configs, maybe source symbols, something like that?  I've also tried cleaning/rebuilding my solutions but to no avail.  The only cure for it on my machine was to disable the Visual Studio hosting process in my projects' properties.
    Tuesday, August 19, 2008 6:40 PM
  • Quanta,
      The only way I can get this to stop is by unplugging my network connection.
    When I do this, the editor comes back immediately. 
    If the connection is plugged in, it stalls for 5-10 seconds. 
    It does not matter if I am connected to the web or not, it hangs if cable is connected.
    RM
    Tuesday, August 19, 2008 9:57 PM
  • Spizmar - yep, I can confirm that.  My VS2008 comes back instantly if I unplug the LAN from the back of my machine.

    How bizarre.

    It's clearly network related, and as I said earlier in the thread I'm behind a weird, slightly sporadic transparent proxy courtesy of my ISP, plus my DSL modem has some sort of unconfigurable firewall built into it.

    XP Firewall is disabled so that shouldn't have anything to do with it.... should it?  I wonder...

    Perhaps the VS Hosting Proc somehow tries to use the remote debugger, but it's using the wrong loopback address?  Maybe it's trying to connect into my machine on a LAN addy (like a 192.168* address) when the cable is plugged in, but uses 127.0.0.1 when it's not?

    I have submitted this thread, and the problem, to MS Product Support directly so hopefully they'll be monitoring it.  If *anyone* else on here can offer up any more info about their environment, their network config, their machine specs etc then it would be appreciated.  I want MS to have as much info as possible because I know they're having difficulties reproducing the problem.
    Tuesday, August 19, 2008 10:38 PM
  • BTW, Does anyone know why MS has blown this off?
    Even the moderators have not touched it since January!
    Tuesday, August 19, 2008 11:30 PM
  • This problem seems to be on or off for me. But recently I got a fix for a bug with Power Commands. This may have been a factor with out SP1. I say this because I currently am no loner having any debug hang issues as I had them with and without Sp1.

    Power Commands
    Thursday, August 21, 2008 12:39 AM
  • Hey Guys, I've found this solution to work if your're running VS 2008 on Vista:

    Right-click on the Visual Studio 2008 icon and 'Run as administrator'

    Hope that helps,
    Kevin
    Thursday, August 21, 2008 4:28 AM
  • zNEMz - I'm not running Power Commands at all, and the fix seems unrelated to this problem, but thanks anyway.

    Ksand - Nope, I'm running XP Pro as an Admin and I have checked my NTFS & User permissions to make sure there are no anomalies.


    MS have instructed me to try and grab a stack trace of the VS hosting process (again) but as far as I coud tell last time they got me to do this, it terminates instantly when I close my app.  So it looks like VS is the culprit, and I've sent them a stack trace of that a few weeks ago, but all they said was "the stack trace doesn't make sense".

    It surprises me a bit that they haven't at least been able to narrow it down to a likely cause, particularly when people have found that unplugging the RJ45 from their machine seems to fix the problem.  Shouldn't that be a good indicator to what's going on and/or what the cause is?  Are they trying to say that there's a huge stack in VS2008 that accesses the network whenever your program is terminated and the hosting process is enabled?
    Thursday, August 21, 2008 7:06 PM
  • Yeah this problem is still on and off for me. When its bad; its real bad and my motivation for working on the solution goes down the crapper. 
    Monday, August 25, 2008 3:46 PM
  • Jeffrey Tan is currently helping me with this, and he suggested I use WinDbg to obtain a stack trace while VS is hung, which I've done and posted to him.

    I also noticed something interesting using WinDbg.  During the hang, the last thing that happens is this:

    (1520.f34): Unknown exception - code 000006b5 (first chance)
    (1520.f34): Unknown exception - code 000006b5 (first chance)
    (1520.f34): Unknown exception - code 000006b5 (first chance)
    (1520.f34): Unknown exception - code 800706ba (first chance)
    (1520.f34): Unknown exception - code 000006b5 (first chance)
    (1520.f34): Unknown exception - code 000006b5 (first chance)
    (1520.f34): Unknown exception - code 000006b5 (first chance)
    (1520.f34): Unknown exception - code 800706ba (first chance)
    (1520.f34): Unknown exception - code 000006c5 (first chance)
    (1520.f34): Unknown exception - code 000006c5 (first chance)
    (1520.f34): Unknown exception - code 000006b5 (first chance)

    Followed immediately by this:
    ModLoad: 0a940000 0a97b000   D:\Program Files\Microsoft Visual Studio
    9.0\Common7\IDE\srcsrv.dll

    And then everything unlocks.

    I couldn't find much info on error code 000006b5, but a bit of Googling for
    000006c5 took me to this page:

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=114032

    Which seems to imply that this exception code is thrown during a call to
    gethostbyname(), and that it happens when running under WoW64 (which is the
    case here - I'm running on XP 64bit) and of course refers us back to a
    networking issue.

    Error code 800706ba seems to be related to an unavailable DCOM server.

    Could we have hit upon the answer here?  VS is trying to connect to a local
    DCOM server whenever it's using the VS hosting process, and for some reason
    it cannot resolve certain IP addresses of the local host?  Maybe when
    there's no network cable connected it doesn't even bother trying, hence it
    speeds up?
    Tuesday, August 26, 2008 5:29 AM
  •  Guys, could you all try a little experiment for me?

    I just opened a command prompt and tried "ping localhost".

    The ping request took about 7 seconds to resolve that to an IP address (and when it did, I think it was an IPv6 addy).  I'm wondering if whatever is causing that delay is what's responsible.

    Can you try the same thing and post up your results?  Thanks!

    Tuesday, August 26, 2008 5:34 AM
  • Okay I think I've found the cause of the problem - on my machine anyway.

    I went into my LAN connection properties and started disabling/enabling protocols one at a time and pinging localhost each time.  I found the culprit which was causing the incredibly slow response times for resolving localhost:

    "NWLink IPX/SPX/NetBIOS Compatible Transport Protocol"

    Soon as that was disabled, pinging localhost responded instantly.  Surprise surprise, VS worked perfectly as well!

    I'm posting this up to the thread on the newsgroup as well.  I hope this helps someone else here, but it seems like it may be more of a Windows issue than a VS issue (the ping problem being a prime example).
    Tuesday, August 26, 2008 5:47 AM
  • Where are these settings? I am using Vista 64 Ultimate. Is this in Manage Network Connections? If it is I do not have it.
    Tuesday, August 26, 2008 1:25 PM
  • This is not included for Vista so this is not the cause for my situation. I already have had 2 tech support sessions in the past two weeks. I hope I do not need another for this! Oh yeah and my Zune stopped working yesterday... YAY! :(
    Tuesday, August 26, 2008 1:29 PM
  • zNEMz - Did you try to ping localhost at a command prompt though?  If so, did you get an instant response, or did it take several seconds to resolve localhost to an IP addy?
    Tuesday, August 26, 2008 9:27 PM
  • I have this issue, but I do not use NetBIOS, and I do not use IPV6.
    I am using RDP.  During the period that VS is locked, so is everything else.
    I could make some unsupported comments about it, but for now, I will just leave it as a symptom.
    Spizmar
    Wednesday, August 27, 2008 2:07 AM
  • Yes I have tested the ping issue and it worked fine.
    Wednesday, August 27, 2008 2:44 PM
  • I've been having the same issue on a computer connected only to a closed network (problem occured in Visual Studio 2008 SP1 on both Vista x86 and x64 with SP1).  The solution of disconnecting the network cable works perfectly, but it works just as well for me to just disable the NIC in the network connections (and is less effort than getting up to unplug/plug the network cable anytime I want to debug).  If you can live without DNS on your network, using a static IPv4 setup with no DNS server specified also seems to fix the problem.  If you have other hosts you need to access by name on the network, adding them to system32\drivers\etc\hosts should work (though I haven't tried this myself yet).  This also seems to fix the issues I've had with Visual Studio randomly minimizing and maximizing after debugs, and occasionally deciding that it wants to be always-on-top (with no fix other than restarting the IDE).  Microsoft, please give us a better solution, as this really hurts productivity for developing applications on a closed test-network (ones that need to be on a network to do anything).

    Thursday, August 28, 2008 2:59 PM
  • I will try this out, but I already have a fixed IP4 address.

    Thanks
    Thursday, August 28, 2008 5:00 PM
  • If unplugging the network cable fixes the problem for you, I've been playing with a fix on my dev machine that's been working for a few days now (based on the gethostbyname() thing mentioned in Quanta's post).  What I saw through a network trace was two DNS requests being attempted for crl.microsoft.com and 6to4.ipv6.microsoft.com (apparently it's trying to update the certificate revocation list).  While I have no idea why this would cause so many unrelated issues in Visual Studio (minimize-maximize, stalling for 10-15 seconds, forcing itself always-on-top etc), I don't notice any issues anymore if I point those two hosts to 127.0.0.1 in the hosts file at %SystemRoot%\system32\drivers\etc.  I've shared this with some other developers on the closed network, and they have been amazed that they can actually be productive with VS2008 now.  This could possibly cause an issue for you if you're running a local web server on port 80 that will freak out about some strange requests, but otherwise everything's been working great for us.  Hopefully this will be helpful to others here, and especially someone at Microsoft to fix whatever is going wrong.
    Tuesday, September 02, 2008 5:41 PM
  • THANK YOU PHIL!!!

    I can verify that defining:

    127.0.0.1       crl.microsoft.com

    in :

    \windows\system32\drivers\etc\hosts

    stops the hang after debug on my system.  I am checking with other developers on my system.

    127.0.0.1       6to4.ipv6.microsoft.com

    has no apparent positive or negative effect.
    So, the crl reference times out in the ui thread, but the 6to4.ipv6 does not timeout in the UI thread.  I hope MS will check this out, so if any of you have an 'in' to pass that information along, I would appreciate it.
    Thanks
    Spizmar
    Tuesday, September 02, 2008 7:38 PM
  • Have you guys tried this which I posted on page 1?

    "Some people have had success by changing a setting in Internet Explorer.  Tools, Internet Options, Advanced tab, Security section, uncheck "Check for Publisher's Certificate Revocation" (you may need to restart IE and VS for it to take effect)."

    It sounds like your VS might be hanging while checking on Certificate store validity (who on earth knows why?), and maybe that'll help.  Apparently it's cleared the problem right up for some people.

    I'm still grabbing stack traces for Jeffrey Tan at MS and sending them to him via the newsgroups.  Although this isn't affecting me any longer, I'd still like to be able to find a fix.
    Tuesday, September 02, 2008 7:53 PM
  • I am still having the same problems with both fixes presented, localhost redirect and internet explorer options.

    In fact things were working fine at one point and I implemented these changes and things went back to being crummy.
    Wednesday, September 03, 2008 2:17 PM
  • zNEMz,

    If you are still interested in tracking down this problem, send me email (greggm on the microsoft.com email server), and we can see if we can track down the cause.

    Thanks,
    Gregg Miskelly
    Visual Studio Debugger Dev
    Thursday, September 04, 2008 6:34 PM
    Moderator
  • This is thanks to Gregg Miskelly.

    Try disabling VShost in your start up projects. Right click, properties on your project file, go to Debug and uncheck Enable the Visual Studio Hosting process. Now the software returns immediately when the stop button is pressed, or when a program is shutdown.

    The only thing I do not know is what do I lose by disabling this? If it is nothing then why is it there in the first place?
    Wednesday, September 10, 2008 4:17 PM
  • Quanta said:

    Have you guys tried this which I posted on page 1?

    "Some people have had success by changing a setting in Internet Explorer.  Tools, Internet Options, Advanced tab, Security section, uncheck "Check for Publisher's Certificate Revocation" (you may need to restart IE and VS for it to take effect)."

    It sounds like your VS might be hanging while checking on Certificate store validity (who on earth knows why?), and maybe that'll help.  Apparently it's cleared the problem right up for some people.

    I'm still grabbing stack traces for Jeffrey Tan at MS and sending them to him via the newsgroups.  Although this isn't affecting me any longer, I'd still like to be able to find a fix.


    This one did the trick for me, thanks!
    Monday, October 20, 2008 6:56 AM
  • Spizmar said:

    THANK YOU PHIL!!!

    I can verify that defining:

    127.0.0.1       crl.microsoft.com

    in :

    \windows\system32\drivers\etc\hosts

    stops the hang after debug on my system.  I am checking with other developers on my system.

    127.0.0.1       6to4.ipv6.microsoft.com

    has no apparent positive or negative effect.
    So, the crl reference times out in the ui thread, but the 6to4.ipv6 does not timeout in the UI thread.  I hope MS will check this out, so if any of you have an 'in' to pass that information along, I would appreciate it.
    Thanks
    Spizmar



    This fixed it for me as well.  Thanks to Phil for digging up the cure. This was a very frustrating problem!  I have to debug on a machine that's not connected to the internet and it was making my life miserable.

     

    Thursday, November 13, 2008 2:20 PM
  • I had been doing some remote debugging and had a load of extra symbol servers defined in my debugging options, i unchecked these and it fixed itself.
    Monday, December 08, 2008 10:46 AM
  • Hi All,

    If the above-mentioned fixes don't work for you try to clear out all (or some at least) breakpoints you have (event if they are disabled).
    It solved the issue in my case.

    Cheers,
    Tomasz
    Wednesday, May 13, 2009 1:44 PM
  • I'm having this issue as well, but my pauses tend to be for about 1-2 minutes. It also seems to only occur in certain code sections while it works fine in others. I generally see 25% CPU usage (I have a quad processor system) during the hang period, then it drops to zero once it frees up. I get the same behavior when clicking on the call stack.

    I've tried all the solutions here save the Visual Studio Hosting Process fix, as I don't have this option in my Debug Properties section. Is this option not available in VS 2008?

    Sometimes (but far from always) I get an entry similar to this in the Windows Error Reporting log:
    6/3/2009 3:16 PM    Application Hang    Hanging application devenv.exe, version 9.0.21022.8, hang module hungapp, version 0.0.0.0, hang address 0x00000000.


    It's possible this is an entirely different issue though..

    Kevin
    Thursday, June 04, 2009 10:52 PM
  • Hi All,

    If the above-mentioned fixes don't work for you try to clear out all (or some at least) breakpoints you have (event if they are disabled).
    It solved the issue in my case.

    Cheers,
    Tomasz
    I unplugged the network cable and still had the problem.  It was clearly a breakpoint issue in my case.  As soon as I removed all breakpoints from the Debug menu, everything went back to normal. I wonder how many breakpoints can VS take.
    Tuesday, July 28, 2009 3:16 PM
  • JEMU above has the answer to what i was seeing. During debugging, if you clicked the stop button or closed the form, there was a very annoying wait of 10 to 20 seconds before the editor would give you back control. To fix, right click on your project name (not solution name), select Properties, then the Debug tab, then deselect the "Enable the Visual studio hosting process" check box. My VS has run fine ever since I made the change, however, you may experience this again if you open a project created from an earlier version of Studio, and automatically run the upgrade to 2008 Wizard. This property setting is the same by default with each project, so do yourself a favor and print a copy of the fix instructions and keep them somewhere so you can find them.

    Sunday, August 30, 2009 7:44 PM
  • Marc - Have you tried the "ping" test I posted earlier in the thread?

    If you go into a Command Prompt and type "ping localhost" [Enter] how long does it take your machine to resolve localhost to an IP address?

    For me, that was another symptom of the root problem.  While VS was having these problems, my machine would take upwards of 10-15s to resolve localhost to an IP address.  This turned out to be some interference from an installed NetWare protocol.  As soon as I removed the protocol from all of my network adapters, my pings to localhost resolved instantly and VS worked again.
    Monday, August 31, 2009 6:03 PM
  • I use VC# 2008 Express Edition SP1 (on Windows Vista 32 bit,and Windows XP) The IDE hang about 10 seconds after I stop bebuging by press STOP button in the IDE. I see this happen only when I connect to an internal network (10.0. ..) that can't go out to the internet. But when I connect to an internet,my IDE dosn't hang out. For me, I found that remove check in Internet Explorer->Tools-> Internet Options->Advance Tab->Security->Check publisher certificate revocation resolves my problem :)

    for related detail please refer to this:
    http://blogs.msdn.com/alimaz/archive/2008/10/16/check-for-publisher-s-certificate-revocation-slowing-down-sharepoint.aspx

    check for publisher's certificate revocation slowing down SharePoint
    While working on an engagement deploying a medium farm on Windows 2008 with no internet connection I noticed a considerable performance hit causing by check for publisher's certificate revocation which is on by default.

    Basically by having this option set, all managed code go through a cert check against crl.microsoft.com (Certification revocation check) by .net runtime before startup. While disabling this option is not recommended for security reasons, for a development environment with no internet connectivity turning off this check should increase the overall performance.

    In order to disable this option simply go to Internet Options and uncheck "Check for publisher's certificate revocation" under advanced tab.

    Saturday, September 19, 2009 6:23 PM
  • I used Process Monitor application in order to see registry/file activity after "Stop" button was pressed.
    I highlighted operations that took over 0,3 seconds and the results for devenv.exe process are:

     

    CloseFile - [Here *vshosts.exe file for one of the projects]

    About 7-8 of these events each with delay between 1,0 and 2,0 seconds -> NotifyChangeDirectory - [Here the directory path for one of the projects in solution] - Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME
    One of these "NotifyChangeDirectory" was with "NOTIFY ENUM DIR" status and took about 4,0 seconds before "ThreadExit" occured which took another 1,2 seconds until finally "QueryOpen" - [Here one of the ".csproj" files] - "FAST IO DISALLOWED" occured

    RegCloseKey - HKCU\Software\Classes

     


    At the very begginning of the log I found:
    RegOpenKey - "HKLM\SOFTWARE\Wow6432Node\Microsoft\CTF\KnownClasses" - "Desired Access: Read" - that took about 2,1 seconds before next RegOpenKey - "HKLM"


    Total delay after "Stop" for me was about 15-20 seconds.

    For now it seems that unchecking ""Check for publisher's certificate revocation" works and no noticeable delay occur.



    Configuration used:
    Windows Server 2008 R2 Enterprise 64 bit
    Visual Studio 2008 SP1
    DHCP Enabled
    IPv6 Enabled (but not used)
    • Edited by Georgi Ganchev Wednesday, October 07, 2009 1:54 PM Added "Configuration used:"
    Wednesday, October 07, 2009 1:46 PM
  • This worked for me.  Not sure its the best solution, but it fixed my issue immediately, so thanks.  It was driving me nuts.
    Wednesday, February 10, 2010 11:00 AM
  • this worked for me :

    "Some people have had success by changing a setting in Internet Explorer.  Tools, Internet Options, Advanced tab, Security section, uncheck "Check for Publisher's Certificate Revocation" (you may need to restart IE and VS for it to take effect)."


    I think this explains the "Unplug lan cable solution" :

    No network => No certificate cheking = uncheck the certificate checkbbox in IE.

    Hoe this helps.

    had the same problem on VS 2008 SP1 in Windows 2003 SP2 R2 Entreprise x64.
    Wednesday, March 03, 2010 4:38 PM
  • i tryed the certificate check disabling and also disabling the visual studio hosting process and nothing changed

    the start of the debug process is not too fast but it's acceptable but the exiting means a core it 100% loaded for 20-25 seconds. this happens only in one solution. this  solution contains some libraries, some console apps, some webservices and a website. i used process monitor to check it out. i've included the actual log.

    799    12:38:26,3332250    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    Thread ID: 2204, User Time: 0.0156250, Kernel Time: 0.0000000
    800    12:38:26,3332432    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    Thread ID: 4672, User Time: 0.0000000, Kernel Time: 0.0000000
    801    12:38:49,4269233    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    Thread ID: 4844, User Time: 0.0156250, Kernel Time: 0.0156250
    802    12:38:49,5480050    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    Thread ID: 680, User Time: 0.0156250, Kernel Time: 0.0000000

    before and after i have normal registry read and write stuff, io etc that happens fast one after the other. on line 801 a thread exits within ~23 seconds after the previous event happened (line 800). the reported user and kenel time are quite small but a core is running full speed all this time.

    as i said this happnes only in one solution and does not manifest itself when using the libraries within another solution. this happens when running console apps, webservices, windows services within this solution in debug or release mode.

    any help is highly apreciated

    Thursday, May 06, 2010 10:01 AM
  • i continued to profile and noticed something funny. let me show you:

    1479    13:51:16,4046624    devenv.exe    3312    RegQueryValue    HKCR\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}\AppID    0.0000028    SUCCESS    3140    Type: REG_SZ, Length: 78, Data: {667524BE-9EC0-4196-91C9-C6ED1F7A899D}
    1480    13:51:16,4046734    devenv.exe    3312    RegCloseKey    HKCR\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}    0.0000021    SUCCESS    3140   
    1481    13:51:16,4046794    devenv.exe    3312    RegQueryKey    HKCU\Software\Classes    0.0000021    SUCCESS    3140    Query: Name
    1482    13:51:16,4046856    devenv.exe    3312    RegOpenKey    HKCU\Software\Classes\AppID\{667524BE-9EC0-4196-91C9-C6ED1F7A899D}    0.0000045    NAME NOT FOUND    3140    Desired Access: Read
    1483    13:51:16,4046916    devenv.exe    3312    RegOpenKey    HKCR\AppID\{667524BE-9EC0-4196-91C9-C6ED1F7A899D}    0.0000055    NAME NOT FOUND    3140    Desired Access: Read
    1484    13:51:16,4047045    devenv.exe    3312    RegCloseKey    HKCR\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}    0.0000021    SUCCESS    3140   
    1485    13:51:22,6316663    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    3328    Thread ID: 3328, User Time: 0.0000000, Kernel Time: 0.0000000
    1486    13:51:22,6318974    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    5440    Thread ID: 5440, User Time: 0.0000000, Kernel Time: 0.0000000
    1487    13:51:46,3943156    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    5784    Thread ID: 5784, User Time: 0.0468750, Kernel Time: 0.0156250
    1488    13:51:46,4010360    devenv.exe    3312    Thread Exit        0.0000000    SUCCESS    2916    Thread ID: 2916, User Time: 0.0468750, Kernel Time: 0.0000000
    1489    13:51:46,4679557    devenv.exe    3312    RegCloseKey    HKCU\Software\Classes    0.0000035    SUCCESS    3140   
    1490    13:51:46,4679664    devenv.exe    3312    RegCloseKey    HKCU\Software\Classes    0.0000020    SUCCESS    3140   
    1491    13:51:46,4679779    devenv.exe    3312    RegOpenKey    HKLM\Software\Microsoft\COM3    0.0000136    SUCCESS    3140    Desired Access: Read
    1492    13:51:46,4679989    devenv.exe    3312    RegQueryValue    HKLM\SOFTWARE\Microsoft\COM3\REGDBVersion    0.0000047    SUCCESS    3140    Type: REG_BINARY, Length: 8, Data: BC 01 00 00 00 00 00 00
    1493    13:51:46,4680101    devenv.exe    3312    RegCloseKey    HKLM\SOFTWARE\Microsoft\COM3    0.0000021    SUCCESS    3140   
    1494    13:51:46,4680355    devenv.exe    3312    RegOpenKey    HKLM\Software\Microsoft\COM3    0.0000076    SUCCESS    3140    Desired Access: Read
    1495    13:51:46,4680470    devenv.exe    3312    RegQueryValue    HKLM\SOFTWARE\Microsoft\COM3\REGDBVersion    0.0000027    SUCCESS    3140    Type: REG_BINARY, Length: 8, Data: BC 01 00 00 00 00 00 00
    1496    13:51:46,4680558    devenv.exe    3312    RegCloseKey    HKLM\SOFTWARE\Microsoft\COM3    0.0000019    SUCCESS    3140   

     

    on line 1484 thread 3140 does something after that another thread does something.

    on line 1489 the same thread resumes work after ~30 seconds. the funny thing is that the duration is almost exact. all this time the a core is full throttle. in process explorer this thread has start address 0x159c and is a thread that probably exists when i close the ide.

    what could be keeping this thread busy for exactly 30seconds?

    Thursday, May 06, 2010 11:46 AM
  • evrika!

    seems that the .suo file gotten to 3,6megs and as soon as i deteled that bloody file the whole thing just got unbelievable snappy. seems that this file keeps track of whick projects should be loaded, which files are open, which branches are collapsed/expanded and more... something like a project state. mine probably got fat and corrupted and that caused the unbelievable slowness. this must have been the most nigtmarrish microsoft product experience i've ever had. caused me much grief and frustration but it is now solved.

    after playing around the solution and closing the project got the .suo file to ~80k. this is a big difference! my computer runs sane again. seems that the case is solved. :)

    as a bonus it seems that the ide is also using less memory besides running a lot faster than before.

    Friday, May 07, 2010 9:47 AM
  • Trade ya - Vista Business x86 here. All I did was OPEN a solution and I have the IDE dimmed down and it's been doing only GOD knows what for past 90+ minutes. It's also eating 90+% of the available CPUs in the system so the mouse is literally stuggeling to keep up and it's taken nearly 10 minutes to type this in!!

    I can not work like this!


    cmillens
    Monday, December 06, 2010 9:34 PM
  • Clearly they have as I am STILL having this problem more than 2 years later!
    cmillens
    Monday, December 06, 2010 9:37 PM
  • I had the same problem and tried the following:

    • unchecked "Check for Publisher Certificate Revocation" in IE
    • added the DNS entries in the 'hosts' file
    • de-activated the Visual Studio Hosting process
    • Isolated VS2008 from the network/internet

    None of it helped.  In the end I deleted the .suo file in the project directory and it solved the problem.

    (Win Server 2008 R2 x64, VS2008)

    Tuesday, March 29, 2011 8:35 PM
  • Deleting the .suo file worked for me using VS2010 too.
    Tuesday, May 22, 2012 4:04 PM
  • I HAD the same problem. I deactivated the use of the visual studio host process on the debug tab in the project settings page. Now the editor responds at once.

     

    Thanks, solved my problem.

    AndrewR

    Thursday, April 11, 2013 8:39 AM