Debugging Windows programs: Difference between revisions

From Wildsong
Jump to navigationJump to search
Brian Wilson (talk | contribs)
Created page with "== 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 Exce..."
 
Brian Wilson (talk | contribs)
mNo edit summary
Line 30: Line 30:


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.
Longer answer
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.


Long answer
Long answer

Revision as of 22:35, 6 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

Short answer

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.

Longer answer

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.

Long answer

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.