Visual Studio 2008 SP1 Stepping and Breakpoint Issues

Question

 

Last Update: 10/21/2008

Many of you have reported the issue documented at http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/c800abbc-5a67-4c43-bf61-e6d86f48658b and we thank you for that.  The details provided are helping us understand and ultimately fix the problem.  
 

This issue may impact you if ALL of the following conditions are met:

-          You have Visual Studio 2008 with SP1 installed

-          You are developing a managed language project (C#, VB, etc)

-          Your project makes use of multiple threads

-          You are debugging your project on a multi-processor or multi-core machine

 

The potential symptoms include:

-          When stepping through your project, sometimes your application continues running when it should have stepped.

-          When stepping through your project, sometimes breakpoints that should be hit are not.

 

The first available fix is now here as part of Microsoft Silverlight Tools for Visual Studio 2008 SP1 (RC1).
http://www.microsoft.com/downloads/details.aspx?FamilyId=c22d6a7b-546f-4407-8ef6-d60c8ee221ed
This package will revert some debugger behavior back to that of the original release, while still maintaining the rest of the updates that went into SP1.

A stand-alone fix is also under development and will be made available as soon as possible.

If you do not want to install Silverlight Tools, there is an alternative work around that may eliminate these issues for you until the stand-alone fix is ready.
Workaround:

1)      Open Visual Studio but do not open any projects.

2)      Start the Task Manager (Ctrl+Shift+Esc) and navigate to the “Processes” tab.

3)      Right-click on devenv.exe and select “Set Affinity…” (this option is only available on multi-processor or multi-core machines).

4)      Uncheck every CPU except one and click OK.

5)      Open your project and debug as normal.

 

Workaround notes and limitations:

-          If you restart Visual Studio, you will have to repeat these steps.

-          If you are attaching to a process to debug, you should perform the above steps on your target process before attaching Visual Studio.  (If you are debugging foo.exe, change the affinity on foo.exe.)

-          If you are specifically testing or debugging your process to see how it works on a multi-core or multi-processor system, this workaround will not be sufficient since it forces your process to use a single processor or core when executing.
-       Will not work on single-core machines that can run multiple threads simultaneously (e.g. Perntium 4 with Hyperthreading)

 

Once again, please check back here regularly as we will update this posting when a fix is available.

 

Thank you!

The Visual Studio Debugger Team

 

---

Brad Sullivan - Program Manager - Visual Studio Debugger

Answer 1

I have the single step issue and neither the patch nor the workaround works for me.

Unchecking 'Enable Property evaluation..." didn't help either.

Is there any other workaround available atm despite getting rid of sp1?

Answer 2

We are experiencing this problem in a C++ project that does not make use of multiple threads.

Answer 3

I also have the single step issue and the Silverlight install did not work.

My application is a C++ dll that is multi-threaded. Debugging is by attaching to an exe. My system is quad-core.

What do you recommend I do to get my debugger working properly?

Answer 4

For those of you who are having trouble with your native C++ applications, it would help us a lot if you could provide some additional details.  For exampe:
- How did you break into the debugger?
- Where in the code are you?
- What kind of step are you taking (F10, F11)?
- What happens after you step?
- What did you expect to happen after you step?

Thanks.

---

Brad Sullivan - Program Manager - Visual Studio Debugger

Answer 5

Update: 11/14/2008

A stand-alone patch is now available to fix this issue.  Please download this patch from the following location:

http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796

If you have Visual Studio Standard Edition installed on a 64-bit operating system, you should install the 64-bit remote debugger before applying this patch.  This download can be found here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=440ec902-3260-4cdc-b11a-6a9070a2aaab

Thanks.

---

Brad Sullivan - Program Manager - Visual Studio Debugger

Answer 6

Does this mean that its ok to apply the patch on 64 bit os if you non standard editions? Or should we always  install the 64-bit remote debugger before applying this patch?

Many Thanks

---

preet

Answer 7

After installing the patch I have sometimes a 100% CPU time (on a dual core machine) followed by an application crash (not VS but the application which should be debugged). Before the 100% CPU time VS doesn't respond.

Answer 8

I've installed this patch but it hasn't resolved the problem. 
Has the patch resolved the issue for anybody else?

Answer 9

I installed the patch but it doesn't fix anything.  I still have the problem saying "the breakpoint will not currently be hit. The document is not loaded."  Very disappointed.

Answer 10

Brad,

I am hoping to debug classic asp project in VS2008.  Unfortunately, the default development web server does not like classic asp, and attaching debugger to the project has problem with breakpoints - "The breakpoint will not currently be attached.  The document is not loaded."  I tried all suggestions provided by Microsoft.  However, the SP1 of VS2008 still does not enable classic asp debugging and this patch still does not solve the breakpoints issue.  Would you let me know when Microsoft comes up with any real solution?

Thank you!

Answer 11

It did not fix the problem for me either.

Answer 12

No dice, this did not fix it at all. We really need to get this bug handled! (VS2008 Team w/ SP1, Server 08 Std)

Answer 13

Is there solution yet for the breakpoint issue - breakpoint not hitting? If so, please let me know.

Environment:
Dell D830 Centrino Duo; Vista Business 32bit x86; VS 2008 Professional Sp1, .NET Framework 3.5 Sp1; and applied the hotfixes KB957912 and KB967631.

The application is in ASP .NET and C#.

The breakpoint is set in the PageLoad, which should hit every time, ideally.

Problem:
The Breakpoint which is set in the detailed page hits for the first time opening of the detailed page (from a GridView row) but does NOT hit upon immediate reopening the same record after closing (whether page data updated last time or not). Also, if the record was last updated, the values are not bound for the updated elements (only), but they are really updated in the database. Upon hit of a Reset button (which calls a function to discard any changed values on the page and re-bind the original page field data from database), only then the breakpoint hits, also the last updated fields' data is bound then. I tried to debug to see why the data is not bound to the page elements, but the breakpoint does not hit!

Does anyone know a solution for this?

Answer 14

Finally!!!, I identified the problem for my above mentioned breakpoint issue - not stopping at times at the set breakpoint.

It looks like an IE8 bug that is the culprit here, as I found. When my default browser is set to IE8, THE BREAKPOINT DOES NOT HIT (after page data saved and page reloaded) and also does not bind updated data on the page!. IE7 as well Firefox breaks at the set breakpoint and binds the data correctly.

I am not an expert on the subject, but this what I noticed.

Hope this helps few others!

Answer 15

After installing the path, the issue still exists. I start the debugger (C# project). VS stucks and then kills the debugging process (in addition devenv eats the cpu time of one core).

This is so annoying - can't work with such an issue!

Microsoft: Where is a working hotfix to solve this issue!!!!!

Answer 16

Phalguna: You installed both hot fixes.  Did you notice any adverse behavior with both of them?  My immediate problem was fixed with KB957912, and I am not sure if I should load KB967631 particularly since MS has not written a KB article explaining its purpose yet.

Brad Sullivan: Can you explain the differences and similarities of the two hot fixes?

---

ERJ MCSD MCDBA

Answer 17

Joeller,

I installed both the hotfixes for VS 2008, only after I noticed the breakpoint issue with IE8 + VS 2008 debug. The hotfixes did NOT help address my issue as yet, at least on my system, a Dell D830, Core 2 Duo. 
 
Initially after installing one of these 2 hot fixes I saw a BSD!!! while in VS 2008 for the first time in 1.5 years; and after that I uninstalled the patches and again reinstalled both of them. After that, I did not notice any adverse effects after reinstall of these 2 patches.

I tested with Firefox and found the breakpoint works well on my machine. So on this basis, I was thinking that this problem might NOT be with VS 2008, but with IE 8.

May be for now, as an alternate try debugging with different browser for the breakpoint issue. Hope it works well for you!

Answer 18

I got the same issue too.  I have the silverlight tools installed, I have IE8...  The problem is occuring with IE8 and Chrome.

I have a core i7.

Answer 19

Guys,

I put the following statement which turns off caching, at the beginning of Page_Load(), then the breakpoint problem is resolved for me. VS 2008 breaks at the set breakpoint now. Everything worked fine for me. Hope this works for you too.

Response.Cache.SetCacheability(HttpCacheability.NoCache);

Answer 20

None of the fixes works.  It's nearly impossible to debug now with this bug.

Please can a Microsoft employee reply about this.

Thanks,

Answer 21

Nothing is working, I have tried each and every trick mentioned above... my C# website is published over IIS and i want to debug it,
Code is in C# and Editor is VS 2008, I have tried IE 8 and FireFox too... my break points are displaying the same warning message ....

Please do something ... :-(