Analyze -v

If you want updates on new blog posts and other such trivia, follow Analyze -v on Twitter! http://twitter.com/analyzev

Over two months since my last update! Guess I’ve been enjoying the Summer a bit too much…I plan on picking back up again in a couple of weeks when I’m back from vacation, until then look out for our upcoming issue of The NT Insider where I’ll be covering the details of DbgEng and writing your own debugger extensions.

Happy 2010 everyone! Hope it’s a healthy and prosperous year for us all.

After eight years in the community, this is my first year being nominated and selected as a Microsoft MVP. Hope this year is as good as the last eight and thanks to those who nominated me!

So why do I have to reboot when I get an IE update?

Just saw the blog from the first time with IE 7 and the screen grabs look pretty bad. I thought it would be easier than annotating listings from WinDBG, but maybe that decision needs to be revisited.

In my day to day usage of Windows, I find myself constantly being punished either for mistyping or for accidentially clicking on things. My favorite example is the accidental click on the A: drive in Explorer. On my system, this leads to instant punishment: a lock up of all things Explorer, which basically renders the entire system useless as the floppy drive grinds away looking for a disk.

Recently I also had the worst punishment of them all. I was merrily typing away an e-mail and hit the space bar at the exact moment that the, “your computer was updated, would you like to restart now?” dialog popped up. Sudddenly everything was closing around me and I had to suffer the ultimate indignity of waiting through a full system reboot.

Why this post about punishment, you ask? Because WinDBG will punish you at some point or another. A couple of weeks ago a student mentioned a cool variation of the k command. As I stood in front of the class I decided to try it on the system hooked up to the projector, so as requested I dutifully typed km into the debugger:

Punished!

WinDBG sat there for a looong time, seemingly doing nothing and ignoring my futile attempts to stop it (which left me with lots of dead air to fill, good thing I have a collection of anecdotes to go to at this point and didn’t have to resort to tap dancing). Finally WinDBG came back to life and let me know what happened:

WinDBG had gone off over the network and tried to load symbols for every module looking for something with a symbol named “m” in it. Turns out the command that I wanted was kM, which displays the call stack with hyperlinked frame numbers:

There are various things I could have done to mitigate the problem in this case (turn off unqualified symbols loads, remove the Microsoft symbol server from my symbol path, etc), but there’s always going to be some frustration like this that you’ll come across. And, of course, it will inevitably happen at the most inopportune time, when you just want the tools to work so that you can debug your own problem.

Clearly I need to come up with a better system of posting very wide debugger output (and hopefully by the time we have 128bit pointers we’re all on very high resolution monitors).