Advanced Search
Welcome to Omgili,
Omgili (Oh My God I Love It ;) is a search engine for discussions. With Omgili you can find answers and solutions, debates, discussions, personal experiences, opinions and more... To learn more about Omgili click here.

This is a complete preview of the discussion as it was indexed by Omgili crawlers. Use this preview if the original discussion is unavailable.
Click here to view the original discussion.

What is your favourite Windbg tip/trick?

I have come to realize that Windbg is a very powerful debugger for the Windows platform & I learn something new about it once in a while.

Can fellow Windbg users share some of their mad skills? ps: I am not looking for a nifty command, those can be found in the documentation.

How about sharing tips on doing something that one couldn't otherwise imagine could be done with windbg?

E.g. Some way to generate statistics about memory allocations when a process is run under windbg.

My favorite WinDbg tip is to read Advanced Windows Debugging by Mario Hewardt and Daniel Pravat:

My favorite tip is to follow Tess Ferrandez' blogging about Windows and .NET debugging.

Start with http://blogs.msdn.com/tess/archive/2007/04/19/windbg-scripts-and-tools.aspx

My favorite is the recently (sort of) discovered command .cmdtree (it's undocumented, but referenced in previous release notes).

This can assist in bringing up another window (that can be docked) to display helpful or commonly used commands.

This can help make the user much more productive using the tool. Initially talked about here: http://blogs.msdn.com/debuggingtoolbox/archive/2008/09/17/special-command-execute-commands-from-a-customized-user-interface-with-cmdtree.aspx Excellent example here: http://www.dumpanalysis.org/blog/index.php/2008/09/18/cmdtreetxt-for-cda-checklist/ Example:

I've just read this blog post on a very handy command called ".cmdtree".

This one doesn't quite fit your question but I thought it's very cool and should mention it.

Following command: dpp esp Range comes very handy when looking on stack for C++ objects with vtables, especially when working with release builds when quite a few things get optimized away. Being able to load an arbitrary PE file as dump is neat: windbg -z mylib.dll Query GetLastError() with: !gle !error error_number helps to decode common error codes.

Almost 60% of the commands I use everyday.. dv /i /t ??

This kM (kinda undocumented) generates links to frames .frame x !analyze -v !lmi ~

My favorite is Getting an exception call stack from the catch block by Slava Oks (Microsoft C++ specific).

Using it to diagnose .NET memory leaks, with SOS. http://msdn.microsoft.com/en-us/magazine/cc163833.aspx http://msdn.microsoft.com/en-us/magazine/cc164138.aspx http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

Do not use Windbg .heap -stat command, it will sometimes give you incorrect output. Instead use DebugDiags memory reporting. Having the currect numbers you can then use windbg's .heap -flt ...

Command.

I like to use advanced breakpoint commands, such as using breakpoints to create new one-shot breakpoints.

The "tip" I use most often is one that will save you from having to touch that pesky mouse so often: Alt-1 Alt-1 will place focus into the command window so that you can actually type a command and so that up-arrow actually scrolls through command history.

However, it doesn't work if your focus is already in the scrollable command history. Peeve: why the heck are key presses ignored while the focus is in a source window?

It's not like you can edit the source code from inside windbg.

Alt-1 to the rescue.

To investigate a memory leak in a crash dump (since I prefer by far UMDH for live processes). The strategy is that objects are all allocated with the same size. Feed the !heap -h 0 command to WinDbg command line version cdb.exe (for greater speed) to get all heap allocations: "C:\Program Files\Debugging Tools for Windows\cdb.exe" -c "!heap -h 0;q" -z [DumpPath] >

DumpHeapEntries.log Use cygwin to grep the list of allocations, grouping them by size: grep "busy ([[:alnum:]]\+)" DumpHeapEntries.log \ | gawk '{ str = $8;

Gsub(/\(|\)/, "", str);

Print "0x" str " 0x" $4 }' \ | sort \ | uniq -c \ | gawk '{ printf "%10.2f %10d %10d ( %s = %d )\n", $1*strtonum($3)/1024, $1, strtonum($3), $2, strtonum($2) }' \ | sort >

DumpHeapEntriesStats.log You get a table that look like this 8489.52 707 12296 ( 0x3000 = 12288 ) 11894.28 5924 2056 ( 0x800 = 2048 ) 13222.66 846250 16 ( 0x2 = 2 ) 14120.41 602471 24 ( 0x2 = 2 ) 31539.30 2018515 16 ( 0x1 = 1 ) 38902.01 1659819 24 ( 0x1 = 1 ) 40856.38 817 51208 ( 0xc800 = 51200 ) 1196684.53 25529270 48 ( 0x24 = 36 ) Then if your objects have vtables, just use the dds command to seek some of the heap allocations in DumpHeapEntriesStats.log to know the type of the objects that are taking all the memory.

0:075> dds 3be7f7e8 3be7f7e8 00020006 3be7f7ec 090c01e7 3be7f7f0 0b40fe94 SomeDll!TSomeType::`vftable' 3be7f7f4 3be7f7f8 Thats cheezy but it works :)

One word (well, ok, three) : DML , i.e.

Debugger Markup Language . This is a fairly recent addition to Windbg and it's not documented in the help file.

There is however some documentation in "dml.doc" in the installation directory for the Debugging Tools for Windows. Basically, this is an html like syntax you can add to your debugger scripts for formatting and, more importantly, linking.

You can use links to call other scripts, or even the same script. My day-to-day work involves maintenance on a meta-modeler that provides generic objects and relationship between objects for a large piece of C++ software.

At first, to ease debugging, I had written a simple dump script that extracts relevant information from these objects. Now, with DML, I've been able to add links to the output, allowing the same script to be called again on related objects.

This allows for much faster exploration of a model. Here's a simplified example.

Assume the object under introspection has a relationship called "reference" to another object.

R @$t0 = $arg1 $$ arg1 is the adress of an object to examine $$ dump some info from $t0 $$ allow the user to examine our reference aS /x myref @@(&((<C++ type of the reference>*)@$t0)->reference ) .block { .printf /D "<link cmd=\"$$>a<

<full path to this script>

${myref}\">dump Ref</link>

" } Obviously this a pretty canned example but this stuff is really invaluable for me.

Instead of hunting around in very complex objects for the right data members (which usually took up to a minute and various casting and dereferencing trickery), everything is automated in one click !

Discussion Title: What is your favourite Windbg tip/trick?
Title Keywords: What  your  favourite  Windbg  tip/trick?