After years of dodging it, I am finally making an effort to learn the WINDBG.EXE symbolic debugger for Win32 apps, or, as I have taken to calling it, "Windbag." I think this name fits because this tool seems to:
1) Never give you a straight answer to what you are trying to ask (e.g. "where did my executable crash?");and
2) Always give you a bunch of other boilerplate information about other things, which is of highly dubious utility, e.g.
Product: WinNt, suite: EmbeddedNT SingleUserTS
Debug session time: Mon Jun 1 11:52:38.000 2009 (GMT-6)
System Uptime: not available
Process Uptime: 0 days 0:00:16.000
SYMCHK: ~glh00008.tmp FAILED - Image is split correctly, but ~glh00008.dbg is missing (is that even object code? and what does "split" mean?)
I am posting here because I seriously do need as much help with this thing as I can possibly get. I am posting a list of questions below. But my inane side rant is that Windbag has perhaps the worst user interface I have ever seen in a Windows application. It reminds me of some UNIX app that was really-not-meant-to-have-a-GUI-but-does. Unfortunately, Windbag doesn't have the excuse of being, old, open-source, or unimportant. This Windbag thing makes me feel like a hyperactive 6 year old trying to configure EMacs. The entire program seems to have been designed in an effort to provoke me into throwing things.
What is the role of the /Oy (omit frame pointers) optimization with respect to PDB files? If I have an EXE built with /Oy, and have the correct PDB files, should I then be able to see a real call stack for the app? Or does /Oy prevent this even in the presence of PDBs?
Why are the "Open Executable," "Open Crash Dump," etc. menu items grayed out once I've opened or saved a "workspace?" How do I get these items to be enabled once more without closing Windbag entirely? I tried to use "Clear Workspace" but the dialog that popped up provoked some kind of primeval aversion in my adrenal cortex (it's one of those dialogs where the user has to pick various things to throw back and forth over a fence using buttons with labels like >> and <... Grrrrr! How does that have anything to do with "Clear Workspace?" )
Generally, how am I supposed to use this thing?As I understand it, I am supposed to take a .dmp file from the problematic machine and then feed it to Windbag, along with the relevant symbols files (PDBs and perhaps maybe some other kind I don't know about). Some of these symbols will come from a Microsoft website, and some of them will have to come from me. There is an SRV* syntax that I can put into the relevant dialog box in Windbag to combine these symbols paths, e.g.
I think that setting this path is a part of my Windbag "workspace," and that as a result if I have different versions of my own PDBs hanging around, I will need distinct "workspaces" for each. Is this correct? It is the impression I get from the, um, Windbag GUI, but it seems ridiculous to make me browse around all of the time for different versions of my PDBs. I think a much better approach would have been to simply require the PDBs and the DMP to coexist in the same folder.. is there support for that mode of operation? Or would that have been too, um, primitive?
In any case, once Windbag knows where to get symbols, I think I should be able to see stack traces after loading my DMP file. But this isn't working. I see a few examples of what seem like function names in the Windbag call stack, but none of them tell me anything other than "you're dumber than me" (which, I think, is all the Wizard-of-Oz @$$-clowns up in Redmond really want me to know.)
Does anyone have any suggestions? As always, I have failed to consider the impact of DCOM widget-thriftiness or CWhiffleSnaffle storage padding or some other equally crucial aspect of Win32 that I should feel guilty about not knowing more thoroughly. I know there is some provision for giving Windbag source code files as well, but I can't see why it should need these to show me a stack trace, and the source is very scattered. I really don't want to have to browse to every single folder that Windbag might need, especially since it uses that nausea-inducing folder selection dialog (the one with a big treeview with a textbox below it... this program is like a museum of bad GUI ideas).
Incidentally, I noticed that the first Windbag-related link I found on Microsoft.com had a video explaining symbol servers posted, which I did not watch. I think that the type of person who thinks that watching videos on the web is a good way to learn is generally not the same type of person who needs to do in-depth debugging of a Win32 app. I don't know anyone over 30 who voluntarily watches web videos (particularly instructional videos), nor do I know anyone under 30 who does real Win32 programming any more ("it's too hard... what would I do with all that money anyway... waaaaaaaaah.") So I don't think that video is getting many hits. Feel free to flame me if you actually watched it.
Wow, what an overwhelming response. You're such a beautiful audience... give yourselves a round of applause.
I have started trying to get what I need using the CDB tool. My favorite granola-slurping widget-marshallers provided this to me in the same MSI as Windbag. I managed to get basically the same information out of CDB as I was getting from Windbg (i.e. an infuriatingly lame, bogus excuse for a real call stack), but without the annoying preponderance of animated dogs or effeminate-looking gradient effects. So, I was starting to develop some small optimism for CDB.
Then, I accidentally typed "syncheck" into it instead of "symcheck." Of course, there's only one proper response to such an error... 5 minutes of silent, unresponsive lockup followed by 20 pages of gibberish.
Oh, gosh, I sure hope no one ever expects me to do anything without Visual Studio, golly, how would I ever get stack traces? Oh, gee, how would I ever figure out how to include files without StdAfx.h? Oooh, I hope no one ever asks me to do something hard like assembler, and if they do I hope it's x86 because having 5,000 instructions sure will make everything easier. Jiminy, if this were any easier college students from India could do it!
Still sorting throught all your comments... I am pleasantly surprised to see that all of your previous bravado toward me is backed up by a solid knowledge of Microsoft's debugger. Clearly, this is an all-important topic, since as we've already established Microsoft is the world's greatest company and anyone who doesn't use a symbolic debugger is an idiot. So it's no surprise that I've gotten so many good responses. Anything less would be a form of hypocrisy, and surely a bunch of respectable VB.NET developers such as yourselves would never indulge in hypocrisy.
More seriously, don't ever ask Windbag to do the obvious. For example, don't set its "symbol path" to the folder where the appropriate copies of your app's PDB files get built. If you do, not only will Windbag still not work, it will also trash that folder with a bunch of folders named after all the DLL files in C:\windows\system32.
The more I think about this, I think that I need to empower the scalable enterprise before my remote GAC tier will G.C. the W.C. Does it sound like I'm on the right track?
Wow, I can't believe I am finally getting in to post on this thread, the CS server has been so bogged down with all these responses. -- I feel your pain. I haven't heard any responses on mine, but I think I'm being obtuse there.
As for your windbg issues:
The splitting issue (regarding *.tmp, *.dbg) has to do with the symbol file for the binary executable can't be found. Do I assume correctly that you're working out of the debug folder of your build? Is VS deleting all temporary files after each build?
Naturally, I'm just chock full of information, but I'm having trouble bringing out the answers. Why are you using windbg instead of the stack tracers within VS? Did this fail on a production machine? As for actually bringing up the app and using it alongside my answer, to survey the scene, I'm not seemingly able to find a "windbg.exe" on my Vista machine (home prem). I'm not in the mood to call up my XP desktop at the office (I'm working on other things atm) so I can't figure where it is in a stock XP location either. Here's the odd bit, I've got the 6.0 SDK on my laptop, along with VS2k8, so one would think those things would be laying around on my disk somewhere, but noooo.... Actually, a quick check via goog says I've probably not got the stuff to do windbg on this laptop, since I'm not into kernel mode with this laptop. I see a new installer in my future, ya know?
Just curious, has this give you any sort of the information you're looking for? http://msdn.microsoft.com/en-us/library/cc266373.aspx While I admit it's rather sparse, it does have some input, such as those grayed out sessions you were referring to.
Ok, so while I don't feel I've contributed manifestly to your problem, I'm going to try one more time: http://msdn.microsoft.com/en-us/library/2kxx5t2c(VS.80).aspx the /Oy flag. It removes a part of the call-stack frame-up, so as to make the code faster, and (most likely) less easily debuggable code: http://en.wikipedia.org/wiki/Call_stack
I assume your just trolling, so thanks for the laugh. On the slight chance you wanted someone to help you, your 2 posts after only a couple hours probably turned off anyone who would have possibly cared enough to think about your questions. Anyways, I don't see anyone here heaping praise on VB.NET, but have fun with your debugging.
tsss, everyone knows you should debug via that button thingy in the IDE. Only linux nerds debug via the command line.
tsss, everyone knows you should debug via that button thingy in the IDE. Only linux nerds debug via the command line.Except linux nerds don't run debug via windbg.exe... don'cha know?