Debugger problem "The breakpoint will not currently be hit. No symbols have been loaded for this document."

Question

I have recently install VS 2005 Pro and I cannot get breakpoints to work properly in my C++ Win32 application.  After compiling for Debug and placing a breakpoint, when I run my program the breakpoint indicator becomes a hollow circle with an exclamation point and I see the above message when I hover over it.

This makes no sense to me because I have verified the following:

1.  Yes, I have compiled for Debug.

2.  Output for my program indicates that "Symbols loaded".

3.  I see the .pdb file in my \<project>\debug\ folder with the correct build date/time.

Curiously, I have created other new projects under VS 2005 that seem to work fine.  The broken one has been ported from VS 2003 and now resides in a new directory.  When I compare the other project and solution debug property settings (that work) with the broken one, I see no significant differences.  The one red flag that I see is that the other projects all contain a file named "vc80.pdb" in the project's debug folder in addition to a <project name>.pdb file in the solution's debug folder (I am not sure why both the solution and the project get a debug folder).

I have seen some online discussion about needing to delete some cache files to fix this problem, but I do not find these files on my machine.

Is anyone aware of this problem and a quick fix for it?

Answer 1

Have you tried deleting the .pcb, .ncb, and .pch files and then totally rebuilding the project?  It could be that some of the colored names of routines are not right in a library or .obj file and what you're seeing is the result of the debugging thinking the routine is not part of the code space.

Tom

Answer 2

I just tried deleting all .pdb, .ncb, .pch files after completely exiting VS 2005.  Then I restarted it and "cleaned" both the project and the solution before I rebuilt the project and the solution for debug (just to be thorough).

None of which seemed to make any difference.  It creates new copies of the <project>.pdb and the <solution>.ncb, but it doesn't seem to matter - I still can't get it to stop on any of my breakpoints.

Answer 3

Hi Aaron,

Just going through the list trying to figure out something that will make it work.  A couple more questions...

1) Do all break points fail or are you trying to do one in a library?  I'm assuming this is true for all break points, but I didn't read that in the first note.

2) When you said "cleaned" did you delete the Debug folder completely?  VS 2005 will, of course, recreate it.

3) Are you sure you're looking at the righ output .EXE (I know, dumb question, but...)

There is obvioulsy something confusing it.  When you get the red circles it means that the debugger thinks you are setting a break point outside of code you would actually get to while running the program (I.E., a library that is not loaded).  You sometimes see this at runtime until a certain DLL loads while loading the program, etc. or in a library where the code was not linked in correctly or the user sets the break point in the wrong source tree or something like that.

One more thing.  You might try doing a Clear All Breakpoints just to make sure that there is not anything set that carried over from the old code.  I can't see how there could be at this point since you deleted all the files, but like I said I'm just trying to come up with things to try.  It's probably something dumb that we're just missing.

Tom

Answer 4

Hello Tom,

Thanks for showing an interest in my problem.  To answer your questions:

1. No, the breakpoints that I am trying are all located in my source (.cpp) files.  I have tried several different sources - all seem to exhibit the same behavior. 

2. I ran the "Build" menu "Clean" for both the Solution and the Project.  At one point I did also delete my Project's Debug directory and let it recreate everything - no difference.

3. Not a dumb question - I wondered about that several times, but all seems correct.  I see the name of my .exe in the Output list and it says "Symbols loaded".

Upon your suggestion, I did try "deleting all breakpoints" and resetting just one - that did not work either.  At this point I am convinced that it is something more fundamental to the fact that this is a converted project and for some reason never generates this new vc80.pdb file.  Do you find an associated "vc80.pdb" file with each of your projects?

Answer 5

I am not sure how I have missed this for so long, but here is the answer to my problem.  The Project/Properties/C++/General/Debug Information Format setting was set to "Disabled".  Changing this setting to "Program Database for Edit & Continue (/ZI)" fixes my problem.

Answer 6

This article kept popping up for me while searching for an answer, but I found a different solution after many, many hours of troubleshooting.  Thought I'd share my info in case someone else finds it useful...

The way it finally worked for me -- When I go to Debug->"Attach to Process", there is an option to select the "ATTACH TO:" code types.  You have to click the SELECT... button and make sure SCRIPT CODE is selected.  Now, my breakpoints are activated.

Might have to play with these types to get it to work as you want it to.

-Dustin

Answer 7

the problem is that you missed 1 or more references between your projects or dlls.

Try creating a reference from the class with problem to the ejecution thread...

 

 

Answer 8

I have had similiar behaviour trying to debug a large solution with 28 projects in it (one of them being a web project).

Clicking on "Select..." when attaching to a process and selecting both Managed and Native seemed to have cleared it up for our situation.

Answer 9

This does not work for me.

I have a VB 2005 program (upgraded from VB6). It was working in debug, but now I get the message in the subject and whatever I do, I cannot now debug this program.

Can anyone here help me to resolve this?

Answer 10

Thanks. That helped me as well. However, for me I did not choose the "/ZI" option, since that gave me error, but the "/Zi" option worked for me.

Answer 11

Same problem you described in detail But I already have <... /ZI> so your solution does not work for me. Anybody at microsoft could describe the requirements to make a debuggable project??

Answer 12

I just thought I would add this insight to help any others that might have encountered my problem. I am working on a mixed solution where my startup project is a managed project. I had the same problem as above. I was able to get my breakpoints to get hit(unmanaged dll breakpoints) by adding the checkbox enable unmanaged debugging, from the managed project.

Answer 13

I was able to clear the "the breakpoint will not currently be hit..." message on the breakpoints by enabling unmanaged debugging and setting "attach to" to Script code. However, I am still unable to trace my code from the breakpoints - I still haven't hit the breakpoints! But atleast I am happy I am not getting the annoying message anymore.

Answer 14

Hi there,

Now using 2003 (back to 03..from 05) after a long time.

I too get the same problem. I've deleted .pdb files, did a rebuild. But stil this annoying message is there..In the configuration, debug is enabled for unmanaged code.

Any other workaround..

Regds,

Nithi

 

 

Answer 15

I just had the same problem and tried to solve it with the suggestions above; needless to say, it didn't work
Finally now I got it, somehow the solution was pretty easy and obvoius^^
I clicked  Properties (for this project)->Linker->Debugging->Generate Debug info, switch it to "yes"..

So I really don't know why this isn't preset, but it solved my problem 8)

Answer 16

In my case, the Configuration Manager had overwritten the Debug configuration with the Release configuration.
Got it working by

• In 'C/C++->General: Set 'Debug Information Format' to /ZI, and disable optimization
• In 'C/C++->Code Generation: Set Runtime Lib to Multi Threaded Debug
• In 'Linker->Debugging': Set Generate Debug Info to Yes

Seems like a bug in VS2005 to me...

Answer 17

 running VS2k5 I have solved this problem for myself after hours of hair tearing and cursing.  I had set my build configuration to "release" to create an install for a client.  He reported bugs (of course...he whos first release is bug free cast the first stone...) and when I returned to the project to debug the portion he was having problems with (a secondary form class) I could not debug the form as no breakpoints would be hit.  After reading this forum and not finding my answer, I checked build-->configuration manager--> and sure enough I had set my build config to release. Setting it BACK to debug and rebuilding fixed all my debugging woes. Hope this helps!

Answer 18

For me the issue was resolved by uninstalling the dll from GAC and reinstalling using gacutil and regasm.

Answer 19

I don't know where to ask for help so I'm trying on this topic.

I have installed VN 2003 on my machine two months ago. The debugger worked just fine... until yesterday. Now it does not stop at any breakpoints and the debug window shows

 

'csc2200.exe': Loaded 'C:\Documents and Settings\Stud\My Documents\Visual Studio Projects\csc2200\Debug\csc2200.exe', Symbols loaded.

'csc2200.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded.

'csc2200.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded.

The program '[3300] csc2200.exe: Native' has exited with code 0 (0x0).

 

Useless to say that I've tried every solution suggested above...

Actually, the settings that have led other people into trouble are correct in my case.

What else could be??

Answer 20

I've just had the same problem, but I think I got the right answer to solve this.

The message that appears is this one:

"The breakpoint will not currently be hit. The source codde is different from the original version.
To allow the brekpoint to be hit when the source code is different, right-click on the breakpoint, choose..."

Solution:

1- Don't press F5 to debug.
2- Go to Menu Build/ Build .....

It will prevent the existence of the difference between the source codde and the codde of original version stated by the message...

Auf Wiedersehen

Answer 21

 

"The breakpoint will not currently be hit. No symbols have been loaded for this document."

 

1-     Install the following utility:

Windows CE .NET Utilities v1.1 for Visual Studio .NET 2003.EXE

 

2-     Run

VS2003 with Windows CE\DelDesktopCryptKey.exe

Answer 22

I tried many solutions mentioned on various forums including this one but nothing seem to work for me. Deleting all the files from "Temporary ASP.NET Files" did the trick. I am using a Web Site and a Class Library in my solution. It appears that there was a version difference between the assemblies because on recompiling the assemblies were not updated.

Answer 23

Dustin - Thanks so much. Your suggestion worked. I have also spent many, many hours trying to get over this issue and tried many different ideas. But yours worked! Thanks again!!

-Steve

 

Answer 24

on the menu goto Build

                             ConfigurationManager

                                     in the dropdown select Debug.

                             

    

 

Answer 25

 

Try this out dude

Go to inetmgr , properties , select "configaration" in the "Home Directory" . In the debuggin Tab select enable Asp net server side debuggin.

Answer 26

I was able to enable my breakpoints by opening the property page for the project launching my external executable, going to the Debug tab, and checking "Enable unmanged code debugging" checkbox.  I also made sure that all of the necessary references were there between this project and the project with the problem.

Answer 27

I have strange problem with breakpoints in Visual Studio 2008 and Vista 64. My project is small COM sever dll and registration with "Register output" option and manual unregistration are working ok. After successful manual unregistration I disabled "Register output" and trying to use regsvr32 as debugging command in project settings and set breakpoint at my DllMain then run it (F5), but my breakpoint does not work and I saw successfull registration message box with full path name of my dll file. 

I wrote small app which is using LoadLibrary to load my DLL and use it instead of regsvr32 as debugging command and in this case breakpoint is working ok and execution stops.

I saw even more strange thing when I write ATLASSERT(FALSE) in my DLLmain function and then run regsvr32 from cmd,  I got "Debug Assertion Failed" message box and hit "Retry"  to go to debug but I saw only one more error message from regsvr32 and did not go to debug. JIT debugging is enabled and it is working ok with another app but not with regsvr32.

 

Any help please.

 

Answer 28

I was able to solve problem and solution was very simple. Just in case if somebody has same problem, check what exact version regsvr32 is used in debug command. There are two versions in x64 windows with same name. One is x64 in directory system32\ and another is x86 in directory syswow64\. Visual Studio does not check what project you have and uses always version x64 from system32\ directory and as result your breakpoints in DLL will not work. You have to use version which corresponds with you project. If your DLL is 32 bits then you have ot use regsvr232 from syswow64\ as debugger command.

Regards.

Answer 29

just make any chages in the code file and run again....

 

Answer 30

And what?

Answer 31

Thank you, very much. It's  helped me  a lot !!!

Answer 32

After trying all the suggestions in this forum, and having none of them work, I was able to solve the problem simply be restarting my computer.  So, don't forget that good old trusty option if you're having issues!

Answer 33

Go to Solution Properties and expand Configuration Properties and Select Build  option and Generate Debugging Information set to True.

Answer 34

In the VS2005 IDE, Open Tools/Options and Select the Debugging node.  Make sure the "Enable Just My Code (Managed Only)" is deselected.  Even after deselecting this option you may still see the error until you start the preview and the libraries load into memory.
 try it out

Answer 35

I have had similiar behaviour trying to debug a large solution with 28 projects in it (one of them being a web project).

Clicking on "Select..." when attaching to a process and selecting both Managed and Native seemed to have cleared it up for our situation.

This was very helpful to me. Just wanna say thanks