Debugging Stop 0x18 - REFERENCE_BY_POINTER

I've found a new interesting bugcheck which is commonly related to objects and handles. Please note before reading, this a Minidump file, and some of the extensions which you would use may not work in this example, unless you have a Kernel Memory dump available.

Objects are system resources and managed by a sub system called the Object Manager. There are a range of different objects, and here's the complete list:

Process - The 'box' of virtual address space in which thread objects execute and are controlled.

Thread - Executable object for a process.

Job - A group of processes connected to one object (More Information here - Job Objects (Windows))

Section - A area of shared memory.

File - Opened file or I/O device.

Token - Security privileges and properties for a process or thread.

Event - Synchronization and notification mechanism.

Semaphore - Synchronization mechanism which allows a certain number of threads access to a resource. 

Mutex - Allows only one thread to have access to a resource (it's like a key).

Timer - Notifies a thread when a certain amount of time has occurred. 

IoCompletion - I/O Completion port

Key - Registry key (managed by configuration manager)

Directory - Held within the object manager namespace and used to store other objects.

TpWorkerFactory - Collection of threads assigned to complete a certain task (Worker Threads).

TmRm (Resource Manager), TmTx (Transaction), TmTm (Transaction Manager) and TmEn (Enlistment) - Used by the Kernel Transaction Manager.

WindowStation -  Read here - Windows Stations

Desktop - Read here - Windows Desktops 

Now, you understand all the different types of objects, you must remember that references to an object are called handles. In order, to fully deference and delete an object, all the handles to that object must be closed.

In the current case of this bugcheck, it seems that the handle/reference count may have dropped below zero when there were still open handles to that object or not, or the reference count dropped to zero when there were still remaining open handles. We can see from reading the description of the bugcheck, that the reference count is incremented by 1 when a handle is opened and decremented by 1 when a handle is closed. Please also note that Kernel Mode components of the operating system can reference objects with pointers and not handles.

In this example, we would use the !object extension with the address of the object to obtain the handle count and pointer count, and the type of object being referenced.

We could also use the dt nt!_OBJECT_HEADER data structure with the same parameter to obtain familiar information about the object.

I noticed in the call stack the nt!NtWriteFile routine which is used to write data to file objects. I'm guessing the object may have been a file object which was being used by Google Chrome since parameter 2 matched the object address for the chrome.exe process.

Kernel Mode components and device drivers must increment the reference count for an object if they wish to acquire it, since doing so, will ensure the object isn't deallocated whilst in this use, which may be another reason why the bugcheck has occurred.