Unfortunately things have changed in Windows 7 and the debugging tools haven’t caught up so this no longer works, but I’ll provide a solution to that once I get there…

Enabling Object Tracking

Object tracking is enabled via the FLG_MAINTAIN_OBJECT_TYPELIST GFlags option. You can enable this via the GFlags utility on the target machine, but I prefer to do it via the debugger on a per-boot basis so that I don’t have to remember to shut it off:

1: kd> !gflag + otl
Current NtGlobalFlag contents: 0x00004000
    otl - Maintain a list of objects for each type

Important note: This must be done very early in the boot process before the Ob initializes. I recommend setting an initial break in the debugger by using the WinDBG command CTRL+ALT+K and using the !gflag command at the initial break.

Once you’ve enabled the command, just hit Go and proceed to run whatever tests or do whatever you like. Once you’re ready to start inspecting objects, the path you will take will differ on Vista (and earlier) and Windows 7.

Dumping Objects Prior To Win7

Prior to Win7, life is fairly straightforward as the !object command supports walking the object list. The syntax for the command is:

!object 0 Name

Where Name is documented to be:

So, for example:

!object 0 File

!object 0 Event

!object 0 Semaphore

!object 0 Device

!object 0 Driver

Any of these will dump out all of the objects of that particular type and you can then pick through and do whatever it is you do with that information.

Dumping Objects on Win7

Now for the fun part. If you attempt to run any of the above !object  commands on a Win7 target, you’ll get the following error:

1: kd> !object 0 File
Scanning 723 objects of type 'File'
WARNING: Object header 83d8bb48 flag (42) does not have
OB_FLAG_CREATOR_INFO (4) set

The problem is that starting with Win7, that flag no longer exists. Instead, the object header tracks whether or not this feature is enabled via another field in the header. So, unfortunately, the Ob changed but the !object command wasn’t updated to reflect the changes.

We can get this back though from a gratuitously complicated debugger command that walks the list starting at an entry. Finding the starting entry could be simplified, but I’ll make you find it manually because that’s how I did it when I wrote the script and I don’t want to make it too easy on you

Also, I’ll apologize in advance for the script being on a single line and thus guaranteeing that it will require some sort of WinDBG Rosetta Stone in order to decipher (again, because that’s how I did it when I wrote it…Job security!).

First, you’ll need to dump the global type variable for the type of objects you want to see. Examples of these are IoFileObjectType, ExEventObjectType, IoDriverObjectType, etc. (if you’re having trouble finding the name of the one you want just let me know). I’ll pick the file object type:

1: kd> x nt!iofileobjecttype
82775a54 nt!IoFileObjectType = 0x83d656e0
1: kd> dt nt!_object_type 0x83d656e0
   +0x000 TypeList         : _LIST_ENTRY [ 0x83d8bb38 - 0x846022d0 ]
   +0x008 Name             : _UNICODE_STRING "File"
   +0x010 DefaultObject    : 0x0000005c Void
   +0x014 Index            : 0x1c ''
   +0x018 TotalNumberOfObjects : 0x2d3
   +0x01c TotalNumberOfHandles : 0xaa
   +0x020 HighWaterNumberOfObjects : 0x691
   +0x024 HighWaterNumberOfHandles : 0xb6
   +0x028 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x078 TypeLock         : _EX_PUSH_LOCK
   +0x07c Key              : 0x656c6946
   +0x080 CallbackList     : _LIST_ENTRY [ 0x83d65760 - 0x83d65760 ] 

Note the TypeList field. That’s the list of currently valid objects for that type in the system in the form of OBJECT_HEADER_CREATOR_INFO structures, which currently exist directly before the object header. So, TypeList entry address + sizeof(OBJECT_HEADER_CREATOR_INFO) + FIELD_OFFSET(OBJECT_HEADER, Body) is where the actual object address is. I’ll put that all together into the following command (I’m going to break it up C style with “\” characters so you can see it, please remove before actually using and make into a single line):

r @$t0 = @@(sizeof(nt!_object_header_creator_info) \

+ #FIELD_OFFSET(nt!_object_header, Body)); \

!list "-x \".block {as /x Res @$extret+@$t0} ;\

.block{.echo ${Res}; !object ${Res}} ; \

ad /q Res\" 0x83d8bb38" 

Note that the address used at the end of the command is from the dt output above in bold. Also remember that it’s written to occupy a single line, so it needs to get pasted into the KD prompt with no newlines and those backslashes removed. Running the command should provide you with relatively the same output at the old !object command on previous O/S releases.

If you’d like to clean up the script or, even better, turn it into a debugger extension that takes a name like !object, please let me know or send along the results. Right now it’s on my ever increases prioritized list of things to do and I’d like to take it off

The first option is the /h switch, which appears to allow for searching the process list for a process with too many open handles:

0: kd> !process /h 0n10000
Searching processes with HandleCount > 10000

The only problem with this is that it appears to stop on the first process that is above that limit. This prevents it from being a generically useful command as you’re probably looking for any processes with large handle counts. For that purpose, I’ve whipped up this WinDBG script that will search for any process with open handles above a specified amount:

.if (${/d:$arg2} != 1)
{
    .echo Performing scan for processes with handle count > ${$arg1};
    !for_each_process "$$>a<${$arg0} ${$arg1} 1";
}

.else
{
    r? @$t0 = ((nt!_eprocess *)${@#Process});
    aS handleCount "@@(@$t0->ObjectTable->HandleCount)";
    .block
    {
        .if (${handleCount} > ${$arg1})
        {
           .printf /on "Process %p has %d handles\n", @$t0, ${handleCount};
        }
    }
    ad handleCount;
}

Save that to a file called bighandle.wbs and execute the following command in WinDBG:

0: kd> $$>a<c:\\dumps\\bighandle.wbs 0n500
Performing scan for processes with handle count > 0n500
Process 848bfd40 has 5568 handles
Process 862e9530 has 579 handles
Process 86374d40 has 997 handles
Process 86334150 has 661 handles
Process 849eb4a0 has 973 handles 

Note that the double backslashes are important on the command line and it won’t work properly without them. This script could be enhanced to just grab the process with the greatest number of handles, if you want to give that a whirl and submit it pass it along to me (snoone at analyze-v dot com).

The other interesting undocumented feature of !process is bit 5 in the flags (0×20). This causes !process to include information about the process PEB in the output. This also requires that bit 4 (0×10) be present due to the fact that the PEB is process context specific. So, for example:

0: kd> !process 849eb4a0 31

(Remaining output left as an exercise to the reader.)

First thing we need to do is get the debugger notified of user module loads. Normally the OS doesn’t bother letting the kernel debugger know when a user module gets loaded, but this can be enabled via GFlags option Enable loading of kernel debugger symbols (a misnomer in this usage). Instead of running the GFlags application on the target machine, we can enable it dynamically in the debugger with the !gflags command:

0: kd> !gflag +ksl
Current NtGlobalFlag contents: 0x00040000
    ksl - Enable loading of kernel debugger symbols

Now that we have that done, we can use the sxe ld command to enable a breakpoint when the module of interest loads. Note that this could be a DLL, EXE, service, driver, whatever:

0: kd> sxe ld notepad.exe

Now I’ll run Notepad on the target machine and hopefully get a breakpoint (which indeed I did):

0: kd> g
nt!DbgLoadUserImageSymbols+0x30:
8281a182 int     3
0: kd> kc

nt!DbgLoadUserImageSymbols
nt!MiLoadUserSymbols
nt!MiMapViewOfImageSection
nt!MiMapViewOfSection
nt!MmInitializeProcessAddressSpace
nt!PspAllocateProcess
nt!NtCreateUserProcess
nt!KiFastCallEntry

You’ll note that we’re actually in the correct process context at this point:

0: kd> !process -1 0
PROCESS 84aaed40  SessionId: 1  Cid: 0000    Peb: 00000000  ParentCid: 0948
    DirBase: 7efc7600  ObjectTable: 961c2460  HandleCount:   0.
    Image: notepad.exe

So I can set a process specific breakpoint on a hot OS routine and start my analysis in the process that I’m interested in making the call that I’m interested in:

0: kd> bp /p @$proc ntfs!ntfscommoncreate
0: kd> g
Breakpoint 0 hit
Ntfs!NtfsCommonCreate:
889095fd push    94h
1: kd> kc

Ntfs!NtfsCommonCreate
Ntfs!NtfsCommonCreateCallout
nt!KiSwapKernelStackAndExit
nt!KiSwitchKernelStackAndCallout
nt!KeExpandKernelStackAndCalloutEx
Ntfs!NtfsCommonCreateOnNewStack
Ntfs!NtfsFsdCreate
nt!IofCallDriver
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
fltmgr!FltpCreate
nt!IofCallDriver
nt!IopParseDevice
nt!ObpLookupObjectName
nt!ObOpenObjectByName
nt!IopCreateFile
nt!NtOpenFile
nt!PfSnGetPrefetchInstructions
nt!PfSnBeginAppLaunch
nt!PfProcessCreateNotification
nt!PspUserThreadStartup
nt!KiThreadStartup

If you’re ever debugging a similar issue yourself, the !chkimg extension can automate all the steps taken in the blog post by leveraging a properly configured symbol server. As it turns out, in addition to indexing symbol files on a symbol server you can also index image files. This is a handy feature that’s necessary when debugging mini-dump files, due to the fact that the original image files are required when debugging dumps of that type. !chkimg is aware of this, and will attempt to file the original image from your symbol server and download it to your local symbol store.

In order to facilitate debugging kernel mini-dumps, Microsoft indexes the O/S images on the MS symbol server. This means that if you want to verify any O/S image in your target machine, all you need to do is point your symbol search path to the MS symbol server and run !chkimg.

0: kd> !chkimg ntfs
SYMSRV:  Ntfs.sys from http://msdl.microsoft.com/download/symbols
DBGHELP: c:\websymbols\Ntfs.sys\4A5BBF4512f000\Ntfs.sys - OK
0 errors : ntfs

Aliases are quite a nifty feature of WinDBG and I’m working on a post that will do them justice. In the meantime, just know that $CrashDumpPath is a built in alias that always expands out to the path of the crash dump file in any expression. For example, to quickly add the path of the crash dump file to my symbol search path, I can just call .sympath+ with the dump path alias:

0: kd> .sympath
Symbol search path is: <empty>
Expanded Symbol search path is: <empty>
0: kd> .sympath+ $CurrentDumpPath
Symbol search path is: C:\dumps\mpwhang
Expanded Symbol search path is: c:\dumps\mpwhang

This takes the variability out this step for me and also allows for easier scripting. Other built in aliases can be found on this page under the heading Automatic Aliases.

To set a process specific breakpoint, you specify the /p switch to the bp command and supply a process object address:

bp /p 84996030 ntfs!ntfscommoncreate

The process address could, for example, be retrieved from the output of the !process 0 0 command or you can use the handy $proc pseudo register to specify the current process:

bp /p @$proc ntfs!ntfscommoncreate

Much like most of these terms, you’ll find a few alternate pronounciations. The one that I use is:

Urk wull

With short u sounds.

An alternate pronounciation that you’ll sometimes hear is:

Urkel

(An homage to Steve?)

Lastly, there’s the obvious pronounciation of just sounding out the letters:

I R Q L

Though what fun is that?