Debugging Windows programs: Difference between revisions
Brian Wilson (talk | contribs) mNo edit summary |
Brian Wilson (talk | contribs) mNo edit summary |
||
Line 23: | Line 23: | ||
=== You have to have the correct PDB files === | === You have to have the correct PDB files === | ||
PDB files contain debugging information that windbg.exe (or Visual Studio) needs to show you meaningful symbols instead of hex data. | PDB files contain debugging information that windbg.exe (or Visual Studio) needs to show you meaningful symbols instead of hex data. | ||
Line 31: | Line 29: | ||
So really you need to do a DEBUG release to do this kind of debugging. Live and learn. | So really you need to do a DEBUG release to do this kind of debugging. Live and learn. | ||
==== Best practice ==== | |||
Best practice for release builds: When you build for release, also build and archive a debugging copy with all its files alongside it. | Best practice for release builds: When you build for release, also build and archive a debugging copy with all its files alongside it. | ||
Then when you get crashes coming in from the field you will be able to deploy the debug version and maybe even fix the problem. | Then when you get crashes coming in from the field you will be able to deploy the debug version and maybe even fix the problem. | ||
==== More details on PDB files ==== | |||
http://www.wintellect.com/blogs/jrobbins/pdb-files-what-every-developer-must-know | http://www.wintellect.com/blogs/jrobbins/pdb-files-what-every-developer-must-know |
Revision as of 01:26, 7 November 2013
Scenario
You wrote a program that crashes on the target machine but not on your development platform. This means customers are grumbling and showing you "Unhandled Exception" messages.
In my case the error is "Attempted to read or write protected memory".
No details in the accompanying stack trace are helpful to me.
What to do
Install the debugger
You don't want to install Visual Studio, it's big and bulky. Instead follow the instructions on the Microsoft web site to install the debugger.
Download and install WDK, but you only need to install the debugging tools. The WDK runs on Windows 7, you can ignore the fact that it says it is for Win 8.1.
http://msdn.microsoft.com/library/windows/hardware/ff551063%28v=vs.85%29.aspx
It will install windbg.exe (really) but ignore the notes that say everything installs in C:/Program Files/Microsoft SDKs/ because really it goes into C:/Program Files/Debugging Tools for Windows (x86)
You have to have the correct PDB files
PDB files contain debugging information that windbg.exe (or Visual Studio) needs to show you meaningful symbols instead of hex data. There is a GUID in each PDB and it has to match the GUID in each matching DLL files, if not, forget it.
So really you need to do a DEBUG release to do this kind of debugging. Live and learn.
Best practice
Best practice for release builds: When you build for release, also build and archive a debugging copy with all its files alongside it. Then when you get crashes coming in from the field you will be able to deploy the debug version and maybe even fix the problem.
More details on PDB files
http://www.wintellect.com/blogs/jrobbins/pdb-files-what-every-developer-must-know
Connect the debugger to the crashed process
Find the process id. This is a natural step for any Linux programmer but probably unfamiliar to Windows folk. You can find the PID in the Task Manager.
Launch windbg.exe pointing it to the crashed process.
You should now be able to see what happened.