Mink Machine

Breakpoint issues in Visual Studio.NET

When debugging large projects in VisualStudio.NET, I’ve sometimes noticed that the IDE has suddenly inserted breakpoints at random places in the code. This can be largely confusing, since they does not appear in the list of breakpoints and won’t go away by a simple “clear bookmarks” command. There are several causes and solutions to this issue. Some are common sense while others border on the edge of voodoo.

(And as always, don’t try this at home unless you know what you’re doing. I don’t take any responsibility for any damage you might inflict on yourself. In fact, I don’t even hear you. Sha-la-la…)

Breakpoints are stored in the .suo (solution user options) file, created by VS when you create a new solution. This file is stored in binary format, so the structure is not worth mentioning any further. it is also a hidden file, to hide from the 2 % who doesn’t check “show hidden files”. The easiest route is to delete this file, since VS will create a new one for you, but this approach is like wiping bread crumbs under your carpet.

First thing to check is the state of the breakpoints. Are they solid red, or marked with a question mark or similar? Does VS stop on all breakpoints? If yes to both questions, read on. If not, the error is most likely caused by unreachable code.

A common problem that may give birth to strange behavior is when user files are placed under solution control, resulting in debug symbols getting out of sync. Files that should not be under source control are .suo, .pdb, .csproj.user, .projdata and other files that hold local data.

Cache is another classic source of strange errors. You may have to delete the C:\Documents and Settings\<user>\VSWebCache folder (don’t forget to close VS first). Also have a look at C:\Documents and Settings\<user>\Local Settings\Application Data\assembly and see if there is a “dl2” subdir. If there is, and you find copies of your working assemblies there, you can probably delete them since it is an issue with the shadowcopy. If you’re felling lucky, you may have a look in the registry at HKCR\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\ InprocServer32 (aspnet_wp). If it’s empty, then all managed breakpoints are broken.

The breakpoint might not have been bound to the correct instance. Check the Breakpoint window in VS to see if the breakpoint has a “+” sign. By clicking this sign, you can see if multiple instances are tied to your breakpoint.

If multiple source files use the same name but is located in different paths, the debugger could be using the wrong one. This could be solved by setting the Source File Paths under Solution Properties.


No comments yet.

Post a comment

Your email address will not be published. Required fields are marked *

Featured stories

Wazzup in Vaduz

"Vaduz Castle is overlooking the town from a hill, a short walk from the center. It’s really a postcard view with the alps in the background, which I’m sure the prince enjoys as he sips his morning coffee while towering above his loyal subjects."

Alone in Kyoto

"I tried my best to sneak across the building, but the floor revealed me each time. I suppose I would make a lousy ninja."

Road trip across the American Southwest

"We drove along Route 6, Route 66 and Route 666. If there was a Route 6666, we must have missed that turn."

A journey through Iran

"I woke up freezing on a Persian rug with aching back. Behind a corner I saw the damned rooster that kept me awake during many hours."

Getting lost in Yazd

"Navigating on random while surrounded by staring old men, pointing their crooked fingers at the Godzilla Viking in surprise. It feels like I’m walking around in Mos Eisley."

Roaming in Valletta

"I passed the statue of Jean de Valette, the 49th Grand Master who laid the foundation stone to Valletta in 1566, to gaze at the golden interior of St. John’s Co-Cathedral, where he is buried in the crypt."