Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

WinDbg, Debugger Objects, and JavaScript! Oh, My!

WinDbg, Debugger Objects, and JavaScript! Oh, My!

In case you’ve missed it, there are tons of changes going on under the covers in WinDbg. There is a fundamental paradigm shift going on in terms of how WinDbg grants access and presents data to the user and it can lead to some pretty cool results.

Let’s take a concrete example of the old way versus the new way. Say you want to look up every process in the system. In the old way, you would run the following command:

This gives you some nice output that lists the processes in the system:

Cool. But, what if I want to know more about the processes? For example, maybe I want to see every thread in every process. Off to the documentation I go to see if there’s a flag specific to this command that I can pass to get the details I want. In this case I can pass “2” and I get to see some thread details:

Excellent! OK, now I want to know which threads are impersonating…Womp, womp. Sorry, there’s not a flag for that. Even worse, my choices for getting this information kind of suck at this point: I can write my own debugger extension or I can write my own Debugger Command Program using the WinDbg scripting language (ha!).

Enter the world of the debugger object model. Instead of running a command that will list the processes in the system, the debugger provides access to an array of objects that represent each process in the system. You can dump this array using the dx command:

Note that each object has several properties, including a property that gives us access to all of the threads within the process (Threads). So, if I want to see all of the threads in the processes I can perform a LINQ query and ask for all threads in all processes:

OK, I admit that wasn’t intuitively obvious to ME, but now we’ll get to see why this is cool…

Back to my original issue of needing only threads that are impersonating, I can do another LINQ query to filter to only the threads that are impersonating. I’ll base this on a property of the ETHREAD kernel object that is part of each thread debugger object:

Again I will agree that this isn’t intuitively obvious, but it’s pretty cool and provides a new way to navigate crash dump files.

Another cool feature of debugger objects is that they’re also exposed via JavaScript. So, instead of writing a debugger extension in C++ to list all the processes in the system, you can write some JavaScript instead:

To run the command just save it in a .js file and perform the following steps:

Pretty neat!

To provide another example, we had a question on our WinDbg forum about how you might find all of the active file handles to a particular device object. In the old way this would be quite painful. You’d end up running the following command:

And searching the output for the address that you’re interested in.
In the new way, each debugger process object has a property that returns you an array of the handles in the process. With a bit of JavaScript we can use this data to find the file objects that reference our device object:
Example of the results:
I’ve glossed over a lot of things in that script and we’ll certainly be writing more about all of this in the future, but in the meantime there’s some interesting documentation available on MSDN:
dx command:
Writing LINQ queries in WinDbg
JavaScript Debugger Example Scripts
Native Debugger Objects in JavaScript Extensions
 Defrag Tools #170 – Debugger – JavaScript Scripting