VC++ Debugger screwed?
Author
I think it was shortly after installing the 2003 toolkit, that I got some message about the dubugger when I ran it like something could not be found or whatever. I can't remember. But everytime I place a breakpoint on line of code in my program and run the debugger, it says "One or more breakpoints cannot be set and have been disabled. Execution will stop at the beginning of the program." and then the disassembly pops up. I can't debug my program, and I have a bug I gotta fix! I got rid of all the break points and placed just one on an acceptable line of code, and I still get the message. Do I need to set something in my debugger?
Seems like your symbols are incorrect.
The compiler generates "debug symbols" and the linker will use this information when generating the PE module (.exe, .dll etc) and in parallel create a .pdb file (program debug database), aka "symbols". Each PE module contains a path to the .pdb file, so the debugger can locate this information when loading a PE module.
The .pdb contains information used by the debugger, for instance to find what line in a certain .cpp file the executing code has, or a variable name of some address in memory. So, you really need a valid .pdb file for your .exe to get something useful from the debugger.
In debug builds, visual studio generats this information by default. In release builds, this information is (for some obscure reason) disabled. Are you building debug or release builds? Make sure you build debug builds.
* It's a good practice to setup your project to generate symbols for release builds also - you certianly want to be able to run release builds under the debugger.
* It's a good practice to download debug symbols for Windows binaries also to make debugging easier. I don't intend to teach this here, but the documentation for "Debugging Tools for Windows" (use google) will tell you how. John Robbin's book "Debugging Applications" is also really worth reading, and so are his articles: http://www.wintellect.com/resources/articles/articles.aspx?authorID=2
Look in the Output window of Visual Studio when you run your application. What does it say? It should be something like "Loaded symbols for..."? And once you got this working for your own application you *do* want it for all modules (kernel32.dll, ntdll.dll, advapi32.dll, msvc*.dll etc). Read links I suggested, and make Visual studio use a symbol server so you'll always have the latest windows symbol files.
The compiler generates "debug symbols" and the linker will use this information when generating the PE module (.exe, .dll etc) and in parallel create a .pdb file (program debug database), aka "symbols". Each PE module contains a path to the .pdb file, so the debugger can locate this information when loading a PE module.
The .pdb contains information used by the debugger, for instance to find what line in a certain .cpp file the executing code has, or a variable name of some address in memory. So, you really need a valid .pdb file for your .exe to get something useful from the debugger.
In debug builds, visual studio generats this information by default. In release builds, this information is (for some obscure reason) disabled. Are you building debug or release builds? Make sure you build debug builds.
* It's a good practice to setup your project to generate symbols for release builds also - you certianly want to be able to run release builds under the debugger.
* It's a good practice to download debug symbols for Windows binaries also to make debugging easier. I don't intend to teach this here, but the documentation for "Debugging Tools for Windows" (use google) will tell you how. John Robbin's book "Debugging Applications" is also really worth reading, and so are his articles: http://www.wintellect.com/resources/articles/articles.aspx?authorID=2
Look in the Output window of Visual Studio when you run your application. What does it say? It should be something like "Loaded symbols for..."? And once you got this working for your own application you *do* want it for all modules (kernel32.dll, ntdll.dll, advapi32.dll, msvc*.dll etc). Read links I suggested, and make Visual studio use a symbol server so you'll always have the latest windows symbol files.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
