1

I've yet to find a good resource for debugging RELEASE mode binaries or dumps in windbg.

I understand that debugging becomes more limited with compiler optimization enabled. But sometimes I don't have a choice--for example, crash dump analysis on a non-reproducible issue.

It'd be really nice if there were some write-up that describes what IS possible (or what to watch out for) with release binaries. Does anyone know of such a resource?

I'm looking for something like this, but with much more detail. I was hoping Advanced Windows Debugging would have something on it, but no such luck.

pepsi
  • 6,785
  • 6
  • 42
  • 74
  • I don't know of a specific resource, but if you have specific questions I may be able to help a little. Are you using WER? – i_am_jorf Jun 21 '11 at 16:26
  • possible duplicate of [Good tutorial for WinDBG?](http://stackoverflow.com/questions/4946685/good-tutorial-for-windbg) – Steve Townsend Jun 21 '11 at 16:26
  • @jeffamaphone - I don't have a specific question.. It just seems to me that this is a pretty common problem, and a lot of people would benefit from having a place to get more information – pepsi Jun 21 '11 at 16:32
  • @Steve - There are plenty of good windbg tutorials out there, but I've yet to see one cover the issue non-debug binaries. This question is specifically for binaries compiled with optimization enabled, which is much more difficult than "normal" debugging – pepsi Jun 21 '11 at 16:35

2 Answers2

4

First rule: keep all the pdbs from every build you release: both from the exe and any other dlls you produce

Second rule: try to get reproduction steps, as being able to reproduce a crash on your own machine is a far more effective use of your time than wading through a crash log.

Beyond that you're at the mercy of the gods as to how much information you can get out of a release build crash. Some crash analysis gurus can work miracles with a crash dump, but for the rest of us mere mortals it depends on the nature and reproducibility of the crash.

One thing to check is that your optimised release builds have got the 'Omit Frame Pointers' setting as 'No'. That alone will make debugging much easier as 99% of the time you'll get a vaguely meaningful stack.

Be aware that most of the time the 'this' pointer will appear as NULL in a release build, but sometimes you can navigate up and down the stack to find where it is passed as a parameter. In general though, don't rely on the display of variables in the debugger. If the values look sensible then they're probably right. If they look wildly wrong then either that's your bug, or that's just a bogus display of a variable that's been optimised out.

Oh, and check out the legendary John Robbins (the Bugslayer) for some great crash dump analysis resources.

the_mandrill
  • 29,792
  • 6
  • 64
  • 93
3

If you have PDBs, most things are possible (I debugged Windows OS DLLs solely in release mode for years!).

The thing to realize is that WinDbg will now lie to you far more often - that is, it will display what it sees, which is not always what the actual value is. For example, if you try to run dv on frame 15 on amd64, there is no way that the values displayed will be accurate, since the compiler stored the info in a register.

The other difference, is that functions will now be inlined, so the last stack of the frame may not be the actual last frame, it may be a small function that has been copy-pasted into the bigger function.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209