New POBJECT_TYPE exports documented in the WDK

When calling ObReferenceObjectByHandle, ObReferenceObjectByPointer, or ObOpenObjectByPointer you should be passing a non NULL value for the POBJECT_TYPE ObjectType parameter (more on why you should never pass NULL in a later post). Before Windows Vista there were only two documented types in the DDK, *IoFileObjectType and *ExEventObjectType (these are exported as a POBJECT_TYPE* which is why you need the *). These allowed you to safely pass in a HANDLE that represented an event or file object from a user mode application to your driver and get the underlying kernel mode object. In Vista WDK there are two new documented (doronh:  added for clarity) types, *PsProcessType and *PsThreadType. With these newly documented types, you can now safely pass a HANDLE which represents a process or a thread. Furthermore, these types are available to you in previous versions of Windows (I just confirmed that they are present on Windows XP SP2).

Comments (6)

  1. Foolhardy says:

    These exports are very old: they’ve been exported since NT 3.1 gold, along with some others:







    By NT 3.51, there is also:




    And by 5.2:






    There are some version gaps, but those were the versions easiest for me to check. Note that with the exception of desktop, windowstation and job, all of those object types existed in NT 3.1 gold (they just weren’t exported right away). There are still some missing, like (presumably) CmKeyObjectType. Once exported, an object type was never de-exported (it’s not like the underlying object types were going anywhere).

    It’s just that PsProcessObjectType wasn’t documented until now (although the 2003 SP1 IFSKit definately lists ExEventObjectType, ExSemaphoreObjectType, IoFileObjectType, and PsThreadType in the ObOpenObjectByPointer documentation). See

  2. Yes, I am quite aware of the exported list (link /dump /exports ntosrknl.exe | findstr ObjectType will list them).  I am pointing out that these types are now documented and can now be used safely.  

    There is a difference between presence in the export table and documentation.  Once documented, there is a guarantee of permanence.  Lack of documentation means that these exports can disappear if the kernel team wants them to at any time…and just because they have not so far is not a guarantee that they won’t in the future (for example alot of undocumented and previously exported functions shell functions disappeared in Vista, could easily happen with undocumented kernel exports).

  3. Foolhardy says:

    You are correct that one should stick to the documented interfaces, because the undocumented ones are private to the OS and subject to change.

    However, ExEventObjectType, ExSemaphoreObjectType, IoFileObjectType, and PsThreadType were previously documented and sanctioned for use in the IFS Kit (even published freely on the web), so the new WDK is only adding one new type: PsProcessType.

    Furthermore, this is a new piece of documentation, not a new part of the OS. You said "In Vista there are two new types…"– this is inaccurate because the exports themselves are as old as NT (much older than just XP SP2). The only thing that has changed is their documentation, which is a property of the software development kit, not the OS.

    Also, the reluctance to document some of the other core object types, such as MmSectionObjectType, SeTokenType and ExMutantObjectType baffles me. Are the kernel designers seriously planning to not have sections, mutexes or token objects in a future version of the kernel? We’re not talking about patching the dispatcher table here.

  4. > documented and sanctioned for use in the IFS Kit (even published freely on the web)

    correct, but the IFS kit used to cost $$$ and is now free, which is why I was pointing out the types.  Yes, if you had the IFS kit you knew about them, but now they are documented in the WDK itself (since it contains the IFS kit for free)

    > Furthermore, this is a new piece of documentation

    I thought I was being clear, I guess not. I introduced the old types as "there were only two documented types in the DDK" and when I refered to "there are two new types," the documented aspect infered from the previous statement. I updated the entry to be more clear.

    > Also, the reluctance to document some of the other core object types

    You can have the core object types without having to document them and still remove them. They could be removed and the internal components which use them could be modified.  Just because the types are not publicly exported does not mean they go away ;).  Remember the point of documenting them is sanctioning their use.  If you can make a case as to why a driver needs these additional types, they might be doc’ed.  For instance, where you are going to get a token handle on which you can use SeTokenType and then use the underlying kernel object?

  5. In a previous post I wrote about the newly documented POBJECT_TYPE variables for Vista. You can pass

  6. This post concludes my trilogy (see parts 1 and 2 ) on PBOJECT_TYPE (although I do reserve the right