Debugging Windows programs: Difference between revisions
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 |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 15: | Line 15: | ||
follow the instructions on the Microsoft web site to install the debugger. | follow the instructions on the Microsoft web site to install the debugger. | ||
Download and install | Download and install SDK, but you only need to install the debugging tools. The SDK 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 | http://msdn.microsoft.com/library/windows/hardware/ff551063%28v=vs.85%29.aspx | ||
It will first install .Net 4.5 if you don't have it already. | |||
It will install windbg.exe (really) but ignore the notes that say everything installs in '''C:/Program Files/Microsoft SDKs/''' | It will install windbg.exe (really) but ignore the notes that say everything installs in '''C:/Program Files/Microsoft SDKs/''' | ||
It installed into '''C:/Program Files/Debugging Tools for Windows (x86)''' on one machine and into '''C:/Program Files (x86)/Windows Kits/8.1/Debuggers/x86/windbg.exe''' and '''x64/windbg.exe''' on another. | |||
=== 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 32: | ||
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. | |||
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 | ||
| Line 42: | Line 48: | ||
You should now be able to see what happened. | You should now be able to see what happened. | ||
=== Windows symbols === | |||
windbg kept complaining that it could not find symbols for ntdll.dll which bugs me because it's not one of my files!!! | |||
But you can set windbg to download the symbols from Microsoft. | |||
SRV*C:\IncidentView*http://msdl.microsoft.com/;c:/Program Files/Alsea Geospatial/incidentview | |||
ntdll.pdb | |||
Latest revision as of 06:50, 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 SDK, but you only need to install the debugging tools. The SDK 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 first install .Net 4.5 if you don't have it already.
It will install windbg.exe (really) but ignore the notes that say everything installs in C:/Program Files/Microsoft SDKs/
It installed into C:/Program Files/Debugging Tools for Windows (x86) on one machine and into C:/Program Files (x86)/Windows Kits/8.1/Debuggers/x86/windbg.exe and x64/windbg.exe on another.
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.
Windows symbols
windbg kept complaining that it could not find symbols for ntdll.dll which bugs me because it's not one of my files!!! But you can set windbg to download the symbols from Microsoft.
SRV*C:\IncidentView*http://msdl.microsoft.com/;c:/Program Files/Alsea Geospatial/incidentview
ntdll.pdb
