High Kernel CPU usage when debugging under vista
I upgraded to windows vista rtm on the 19th of January. I ran into issues very quickly while trying to debug my WinForms application. Essentially if i launch the process from within visual studio, i get an extremely high number of context switches per second and this consumes the kernel cpu time, causing the debugger to run incredibly slowly.
I posted this information to connect on the 19th and today it was closed and marked as Resolved (wont fix) with no indication why. This certainly doesnt help me, as I need to resolve the issue, even if it means upgrading my machine.
The issue is here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252882
Can anyone help me with this? I really just need to know what is going on and I've invested over 10 hours of my time trying to figure out what was happening and following up on connect. Its very frustrating to see the issue as closed all the sudden with no indication why.
Thanks,
-Brooke
I'm still having problems with this. I have replicated the issue on my computer, a friends computer, my laptop (running x64 Vista). The one thing in common is they all are running Vista.
I even tried installing VS.NET 2008 Beta 2 and I still get the high CPU usage there. The issues on Connect are marked as closed with absolutely zero feedback on why they were closed or how I can work around them. This issue continues to frustrate me on a day to day basis. If Microsoft knows what the issue is and has resolved it, can I please just know a timeframe for the release of the fix and where the problem lies?
I'm extremely concerned that as of VS.NET 2008 Beta 2 the issue has not been resolved. If it's an issue with Vista is there a known hotfix?
One additional thing that I've discovered is that while the CPU is spiked if I click on a line in VS.NET to create a breakpoint, VS.NET starts moving quickly for a bit, then hangs at some point later. However, I can keep clicking a breakpoint on and off and something about doing that triggers something in the debugger and gets it out of its loop
-Brooke
Brooke,
I am sorry that you didn't receive any feedback about the status of your bug. When an issue is reported multiple times, we usually use one single bug to track the issue. I took a look at the history of your bug. It was resolved as a duplicate of the bug described here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=231133&wa=wsignin1.0
which has also been closed because it was a duplicate of an internal bug on the CLR. The CLR team is looking at the issue for Visual Studio 2008.
Thank you very much for reporting the issue and all of your diligence in investigating the issue.
The Visual Studio Debugger Team
Jackson,
Thanks a ton for your response. It's good to hear from somebody inside Microsoft. I was tracking those other bugs, but they were marked as closed as well and there wasnt really an indication why they were closed either. The last activity with any text on the above issue was 3 months before my post, and it wasnt closed until 6/14/2007, and when that happened there wasnt any indication why or what was fixed.
I think it would be of great benefit to customers using Connect if you could provide the module where the problem resides in the defect. The reason I mention this is that I debugged this project since 2.0 beta under 2003, and it wasnt till I upgraded to Windows Vista that I started having the debugging troubles. Hence it was very difficult for me to determine whether the problem was in Vista or the CLR.
Its kind of like when you see forum posts where somebody says, "I have this problem" followed by "Never mind, i fixed it" without telling anybody how they fixed it. Then you come in half a year later and have the same issue but have no idea how to fix it.
If it is in the CLR, we are at beta 2 for 3.5, so can we make this a priority for 3.5 and/or a 2.0 service pack? Its a really nasty problem, as it essentially makes debugging impossible if you launch the app with the debugger attached, which you need to for edit/continue support.
Thanks again for all your help with this.
-Brooke
Brooke,
From the text in the bug, it appears it should be fixed for the rtm release of the CLR. I'm sorry that this wasn't clarified better in the connect resolution. Because the original version of the bug was opened internally, the other bugs were resolved as duplicates of that bug.
Jackson
Jackson,
Can you confirm this will be in 3.5 RTM? I still struggle with this on a day to day basis and as of Beta 2 it is not fixed, even though Beta 2 came out after the defect was marked closed in your bugtracking system on Connect. I really don't want to let this slip through the cracks, and it seems like it has at least up to beta 2 of VS 2008/.NET 3.5.
Thanks,
-Brooke
