Here's a live kernel dump of a Windows system with the win32kbase_rs module loaded, opened in WinDbg. We can use the !poolused command to get an idea of memory allocations made with this new RstG pool tag.

We can see that there have been a few allocations with the RstG pool tag, totaling 368 bytes.

Note that Microsoft describes this pool tag as "GDITAG_RUST_GLOBALS". If you've got a recent enough version of WinDbg / Debugging Tools for Windows, you can find this pool tag description in amd64\triage\pooltag.txt in your debugger install location.

Here's the new Rust-related pool tag descriptions in pooltag.txt:

Rust - win32kbase_rs.sys - GDITAG_RUST
RstG - win32kbase.sys - GDITAG_RUST_GLOBALS

You can find out more about the Rust pool tag in my other thread, which looks more specifically at the Rust code: https://infosec.exchange/@cxiao/110366048880535679

7/

I generally build one of these #windbg scripts for every library I work with. My debugger instance often has 20+ of these loaded. It's such a massive productivity boost for me.

You can even go so far as to set up means by which certain scripts can automatically load when they detect certain modules loaded (e.g.: load this script if you see dwarf.dll in the module list).

Play with it... I guarantee it'll make you more productive too :)

6/

But the real magic happens with that "getPreferredRuntimeTypedObject" method.

When #windbg displays something (or binds a name in 'dx'), it tries to find the "runtime type" of an object (usually via v-tables or RTTI).

Scripts, however, can hook into this with a "getPreferredRuntimeTypedObject" method.

Here, this method literally just says "the runtime type of any Dwarf_Die_s" is the type "Dwarf_Die_s" **WITHIN** dwarf.dll.

Now, I get a *LOT* better experience in locals/watch magically!

5/

So instead I have a #windbg #JavaScript script that I've written specifically for helping me with libdwarf. I can add things to it as I'm going along live in the script editing window of WinDbg preview.

Let's take a look at one small piece of this:

A few things are familiar from the #AdventOfCode examples:

1) I associate this class with Dwarf_Die_s (typeSignatureExtension)

2) I add some properties (die_offset and tag). The implementations of those aren't important right now...

2/

#windbg uses a lot of libraries. Some are internal. Some are #oss.

To demonstrate this in a way you can follow, I'll talk about one of the OSS ones (so you can go build from source if you so desire).

For parsing DWARF information, we (currently) use libdwarf:

https://www.prevanders.net/dwarf.html

Since I'm often looking at Linux/Mac/etc... and the debugger, I often need to debug the debugger (including understanding what's going on in those libraries). Let's take an example...

7/

And now, it's a simple matter of projection to the "getPriority" method we just added.

Any method in a #windbg #JavaScript script can just be called via the @$scriptContents alias. It's literally the amalgamation of the namespaces of all executed scripts.

At the end, it's a simple .Sum() and we have the answer!

I'll note that there are *LOTS* of things which can be extended in #windbg with techniques like this:

- Processes
- Threads
- Modules
- Stack Frames
- Target Types
etc...

@osandov I've *tried* to pay attention to both -- especially since #windbg started supporting post-mortem #linux debugging (including kernel cores).

It's certainly super interesting to see other perspectives and tools in that space.

7/

So let's use this and get our answer to #AdventOfCode day 2 solely from the #windbg 'dx' EE:

Each array index of the @$guide variable is a "round" so we'll project that using .Select to the @$scoreGame method we created earlier...

Once we have the results from each individual round, we can simply .Sum() them to get the final answer.

And there it is: entirely from the expression evaluator with no "scripting" involved!