4

I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.

citizen conn
  • 15,300
  • 3
  • 58
  • 80
Walking Corpse
  • 107
  • 7
  • 31
  • 49
  • Try deleting the hidden .suo file in the solution directory. – Hans Passant Jun 22 '11 at 19:31
  • 1
    Is the C++ source code in _exactly_ the same location on the drive as when the DLL was built? Or are you running a Symbol Server with Source Indexing? – Seb Rose Jun 24 '11 at 21:58
  • The same thing is happening to me right now. I get different breakpoints hitting at different runs, unpredictably. (This is a straight VC++ MFC solution. All third-party libraries are present in source form, and are compiled with the rest of the solution.) – David Thornley Jun 30 '11 at 15:15
  • Okay, I did a Windows Update, restarted, started up the misbehaving VS2008, did a clean, did a rebuild, and I'm seeing vitally needed breakpoints in code that was compiled in the rebuild showing up with the symbols not loaded. This is a real and serious problem for me, so it's bounty time. – David Thornley Jun 30 '11 at 16:06
  • Have you tried renaming the dll in your build output directory and running the exe again.. If it runs, then you've got another copy of the dll registered somewhere else.. Also, what build config are you using (release/debug) ? – StevieG Jun 30 '11 at 17:01
  • 1
    are you sure the pdb and the dll matches? See also http://stackoverflow.com/questions/134866/windbg-dr-watson-minidump-requires-pdb-dll-originally-built-for-installed-vers – wimh Jun 30 '11 at 20:29
  • @StevieG: There's another copy, but by making a few changes in the stuff I'm compiling I can be sure it's getting the DLL I think it is. I'm using debug configuration for everything in these tests. – David Thornley Jul 01 '11 at 13:58
  • @Wimmel: The pdb and dll are made at the same time, since I'm compiling everything from scratch. – David Thornley Jul 01 '11 at 13:59
  • @David Thornley: were you able to get them breakpoints working? If not, is it possible that VS loads the debug info from another .pdb file? Maybe one that's found via symbol server or something. To check, you could simply delete/move/rename the correct .pdb file, and see if VS still reports "symbols loaded" in the debug output. – Paul Groke Jul 06 '11 at 19:38
  • @pgroke: They're working now, but they've worked before and then not worked. I'll try your suggestions next time they aren't working. Thanks. – David Thornley Jul 06 '11 at 20:19
  • @David Thornley: Ah, that's good to hear. And thanks for the reward points :) – Paul Groke Jul 06 '11 at 22:34

4 Answers4

4

I don't have a definitive answer, only a few suggestions.

  • Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.

  • Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.

  • You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.

  • A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)

  • Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.

  • Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.

Paul Groke
  • 6,259
  • 2
  • 31
  • 32
  • Getting everything fresh from source control and building helped get me going. It revealed that one file had a hardcoded dependency on the 'Release MinSize' version of a compiled dll. Once I (temporarily) changed this to Debug and rebuilt, I can step into the C++. Thanks – Greg Woods Oct 19 '12 at 10:25
0

In my case, I had renamed the C++ project. The compiler was outputting newName.lib while my other projects were still referencing oldName.lib which of course would not be removed by a Build->Clean.

I found this out by following the advice to manually clean the build directory. The subsequent linker unresolved external reference gave away the situation.

0

1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit. 2) Check if your pdb is not source information stripped

kernelman
  • 41
  • 2
  • 15
0

Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.

bryanegr
  • 351
  • 2
  • 5