Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Breakpoints aren't working!!

I am working on a medium sized project (about 50 classes) written in C#.
I am using VS.NET 2003 Architect with .NET Framework 1.1 installed (version 1.1.4322.573).

Sometimes the breakpoints I set don't work. This happens rather randomly and I haven't been able to reproduce this behaviour in smaller projects. There is another project of similar size that is written in VB.NET that produces similar results.
After moving all the files to a new solution, the problem went away for a while, but then returned, on all the development stations almost at once - presumably because of something that was checked in. We haven't been able to determine the cause though.

I am positive that the build configuration is set to Debug.

I've seen older posts regarding issues like this for Framework 1.0 SP2, but not for 1.1.

Extensive search through the net, the MSDN, and the usenet groups revealed nothing of use.

In addition to that, most of the unhandled exceptions that the program encounters break into the debugger, but there is no usable call stack available.

Gone back to debugging with message boxes, but that can hardly be called effective programming.

Has anyone encountered anything like this?

Eli Golovinsky
Sunday, January 04, 2004

This usually occurs because debug symbols get out of sync or can't be found.  From your description of this occurring across development stations, I'd guess that you've placed a file under source control that shouldn't be under source control.  If you put development .PDB files under source control, you're almost guaranteed to get the behavior you describe.

For VB.NET and VS.NET, I'm not sure of the exact list of extensions for files that shouldn't be in source control.  I generally keep a minimal set of files in source control -- if it isn't obvious that it should be there (such as a source file or project file), it probably shouldn't be. 

I'd suggest doing a search in the project directories for any file containing a part of the path to the project directories.  Note that many of Microsoft's GUI search tools don't search binary files by default.  Here's a quick way to do the search from a command prompt:

cd C:\your_project_folder
findstr /L /I /S /M C:\your_project_folder *

From this list, use your judgment to decide which files should or shouldn't be under source control.  As a general rule, anything binary probably shouldn't be and source and project files obviously should be. 

Sunday, January 04, 2004


I went over the various files in VSS to look for suspicious extentions that I don't recognize, and there were none that I don't know what they do.
There are source code files, resource files, project and solution files and a couple of VSS related files that don't seem relevant (VS.NET puts them under source control for each new project added to VSS through the IDE).

Here's the full list of extentions I have :

Any other thoughts on the matter?

Eli Golovinsky
Monday, January 05, 2004

Those extensions look fine.  Looking at one of my projects, it appears that .suo, .csproj.user, .pdb, and .projdata are the extensions for files that hold local data.  I'd try deleting them (or moving/renaming them) and rebuilding to see if that resolves the problem.  Sometimes one of these get corrupted and rebuilding from VS without manually deleting the temporary files won't resolve it.  If that doesn't work, I'd tried backing up to a revision of the project where debugging worked and then do a diff between those files and the current revisions to determine what might've changed (the VS project files are all plain text).

Monday, January 05, 2004

Tried deleting the Debug directory (under the assumption that the problem is with unsynched PDB's).
That made matters even worse. The breakpoints stopped working AT ALL..
I don't really know when the whole thing broke down, so there is no revision for which I am certain the breakpoints will work.
I'm going to try and copy the project files (all of them) to another (new) workstation and see how it goes there.
Thanks for your help. It's nice to know that at least Somebody had a couple of good ideas :).

Eli Golovinsky
Monday, January 05, 2004

what happens if you specifically ad debugger statements to your code? (e.g. System.Diagnostics.Debugger.Break())

Monday, January 05, 2004

I had same simptoms in the past.  And I think I figured a reason why since I did not have this problem for a while now.

I was glad that namespaces got easier and I could package my files for the same project in subfolders (something that in Visual C++ was not a feasible option).

So I put emphasis to namespaces and folders having a structure like that:


Gues what.  I could debug Namespace1\Form.cs but when it was coming to Namespace2\Form.cs my breakpoints did not work at run-time.
I don't remember now what build error I got once but it was very related to the issue of files named the same, and I corrected one occurence: as a side effect breakpoints started working for that form.  After I renamed all files with duplicated names (without changing the class names though) I did not have problems wth elusive breakpoints.

Check this out if this could be your case too.

Vadim Katsman
Friday, January 16, 2004

I've seen weird behavior like that caused by the shadow copy cache. In my case I'd been poking around with the Reflector tool which I think is why they got shadow copied, but it can happen for other reasons too.

In any case, have a look in

C:\Documents and Settings\<your userid>\Local Settings\Application Data\assembly

and see if there's a "dl2" subdir, if so drill down and see if copies of the assemblies you're working with are there. In my experience I've always just blown the whole dl2 folder away without any trouble, but I can't guarantee that won't have any side effects. It may be a longshot but it's worth a look if you're stiill having trouble.

Also, when you're debugging your app, check the output pane to see the exact paths the various dll's you're debugging are being loaded from--this will often clue you in if you've got extra copies somewhere being loaded that don't match up with your pdbs.

Wednesday, January 28, 2004


The Breakpoint will not currently be hit. No Symbols have been loaded for this document.

Criteria For Resolution:


- Correctly be able to debug ASP.NET Web Applications on your Windows XP machine.



- In IIS, the “Cache ISAPI Applications” CheckBox was not selected.



1)      Open up the IIS Management Console (Start -> Run -> Type: inetmgr)

2)      Right-click on the Default Web Site Tab and choose Properties.

3)      Choose the Home Directory Tab.

4)      In the Application Settings section, choose the Configuration Button.

5)      Choose the Mappings Tab and ensure that the “Cache ISAPI Applications” checkbox is selected.

Monday, February 02, 2004

Make sure you've got the solution/project configuration set up to do a Debug build rather than Release.

If you've set it up to build in Release mode, debugging just plain ol' doesn't work.

Friday, March 05, 2004

Pathetic...I've been building Microsoft Software for 15 years and just started working with .NET this is why Java/UNIX is kicking Bill Gates Ass..  NO ONE HAS AN ANSWER TO THIS...AND ALL THIS POINTIFICATING IS  BULL SHIT!  I'VE TRIED Everything

Unacceptable Development Environment
Saturday, March 06, 2004

While you hove the module open click on "Build" select "Configuration Manager"  on the configuration manager select "Debug" from the drop down box under the "Active Solution Configuration:" heading. 

Monday, March 08, 2004

I Had this problem today.
It was because I was ignoring a build error in another form, and running the project anyway.

By removing the build error, the debugger worked as normal.

Hope this helps.

Monday, March 08, 2004

I got this same problem today and I was able to fix it based on one of the postings from here. My problem was that I was building in Release mode instead of debug mode. How It got to release mode is a whole different story.

Monday, March 08, 2004

I too have the above comment. Bu the project was set to release mode. I got this same problem today and I was able to fix it based on one of the postings from here. My problem was that I was building in Release mode instead of debug mode.

Sunday, March 14, 2004

I got this same problem today and I was able to fix it based on one of the postings from here. My problem was that I was building in Release mode instead of debug mode.

>How It got to release mode is a whole different story.

My story - set it to release mode yesterday while playing with deployment options & forgot to set it back.

Why wan't this post much higher in the list of things to try?

Wednesday, March 17, 2004

Here ya go :)

1) exit visual studio
2) delete entire
"c:\Documents and Settings\(YouUser)\VSWebCache folder
3) load back vstudio (web project)

I had no side effects or any problems, just loaded back VS set my breakpoints, set my start page and debugging is back.

Thursday, March 25, 2004

Somebody told something about Source Safe integration. So I got it working by selecting all dll's and pdb's and ensuring that those were NOT read-only. I had versions of compiled dll's in Source Safe. After setting read-only to false debugging started to work fine in my multi dll Windows forms application.

Thursday, August 12, 2004

*  Recent Topics

*  Fog Creek Home