C# breakpoint troubles in VS 2003 : Work in progress

I put my blog Contact page on a few newsgroup postings as we are seeing some strange reports of breakpoints not working in managed code. By not working I don’t mean in specific scenarios, but not working at all, under any circumstances.

I am working with one particular customer who, right now, has to uninstall and reinstall the Framework every few days to get breakpoints to work. We have made some progress (we know what is being destroyed in the registry) but not how or why.

Other customers have contacted me through the blog with other breakpoint issues, most of which are most likely user confusion. When things get a bit less mad here I will wrote some blog entries on how to diagnose common breakpoint issues. One thing that I am not is a full-time support person, so apologies to those of you who have written and expected an individual reply. I will try to cover your issues on this blog in due course.

My priority right now is to discover how breakpoints can get globally, and permanently disabled on customers machines, and to fix it. Please bear with me.

Comments (5)

  1. Dave says:

    Breakpoints do seem sketchy, I run into a situation where setting breakpoints in one solution cause VS2003 to load a similiarly named file in a different solution (which I had opened previously) and set the breakpoint in both files!

    Of course, the debugger only trips the real breakpoint, but I’ve got to manually delete the phantom breakpoint. Is this a common breakpoint issue?

  2. Richard A. Hein says:

    Usually when I have problems with breakpoints, it’s because my code is executing another version of my code somewhere … like the GAC, or whereever. If you check the versions of the assemblies being debugged, using the modules window, and look at the location it is executing from, it solves most of the problems.

    Maybe your customers have deeper problems, but this is my experience.

  3. Andy Pennell says:

    Thanks to a very helpful customer and work by one of my team we have identified a bug in Internet Explorer that will cause the destruction of certain parts of the registry if you try to remove a managed ActiveX control. Included in the destruction is the component that the debugger uses to load symbols for managed binaries. We are working with the IE team to come up with a fix. More news as we have it.

    Remember, this is for the total loss of breakpoint functionality, not for config or project-specific breakpoint troubles.

  4. Ron Cicotte says:

    I am having a similar issue with breakpoints but only in a com interop for Office (Outlook Add-in). The debugger seems to work fine in ASP.NET apps. The problem began when I removed the com object from the application.

    I have uninstalled and re-installed both VS.NET 2k3 and OFFICE 2k3 but still have the problem so it sounds like it is a similar issue. The symbols simply will not load and the app acts as if the code was never loaded. Unloading and reloading the addin in the app will allow it to function again but the debugger will not work on any com application though it does work with web apps. I have not tried it in full windows client apps yet.

    Do you think that uninstalling and re-installing the Frameworks will remove the registry settings and allow me to re-establish the debugger or is there another way to cleanup the registry without re-installing the OS?