Driver Verifier in Windows 8/8.1 has added more new debugging and testing procedures, the example in this blog post is going to be about DDI Compliance Rules, and how to debug such a bugcheck. I know this is a very easy bugcheck, but I just wanted to explain some of the parameters and the extensions we can use with it.
The first parameter contains the identifier for the broken DDI Compliance Rule, and the second parameter contains the pointer to the string which describes the broken DDI Compliance Rule.
We should discuss what are DDI Compliance Rules and what is DDI Compliance Checking. DDI Compliance Rules define how a driver and the Kernel Mode side of the operating system should interact, in order to prevent any crashes or problems. The DDI Compliance Rules apply to WDM, KMDF, NDIS and Storport drivers. In this example, since driver has broken a Windows Driver Model framework DDI (Driver Device Interface) rule, we'll look at the WDM side of things.
The DDI Compliance Checking Driver Verifier option is therefore used to check that these drivers are complying to the the DDI Rules. The exact type of rules which are checked, are related to function calls at IRQL Levels and the acquisition and release of synchronization dispatcher objects like Spinlocks.
We can use the !ruleinfo extension with the first parameter to gather information about the broken DDI rule. The !ruleinfo extension can be applied to the third parameter and fourth parameter to gather further information, although, this isn't applicable for this particular example.
We can see that the rule is named IrqlObPassive, just from reading that one word, you should be able to gather that the rule is related to an Object and a IRQL Level of Passive. The full details tell us that ObReferenceObjectByHandle function should only be called when the processor is executing at IRQL Level 0.
The ObReferenceObjectByHandle function is used to check the access permissions for creating a handle to a object, if the access permission are fine, then the handle value will be returned and added to the handle table of the appropriate process. A pointer will also be returned to the object's body.
The same rule information can be found using the dc command with the pointer to the string.
We can see that the function call was called at the wrong IRQL Level.
Looking at the call stack with the knL command, we can this the driver which potentially causing the problem.
The driver in question is called pnpnptool.sys, and is related to a Quest software program.
References:
DDI Compliance Rules (WDM)
DDI Compliance Rules
IrqlObPassive rule (WDM)
!ruleinfo (Windows Debuggers)
ObReferenceObjectByHandle
Again, this is a updated version of a previous blog post, since I will able to show things in more depth. This is a bugcheck caused by Driver Verifier finding a violation, it indicates that a process or driver has used a User-Mode handle in Kernel-Mode.
I've highlighted the two parameters which are the most important in this bugcheck. The value of the handle, and the address of the current process. Since this is a Driver Verifier bugcheck, the driver is most likely going to be displayed, so this post is more about understanding what it references and what it did wrong.
By using the !process extension, we can dump some information about the process, and view the number of handles it currently holds.
Using the !handle extension with the value of the handle being referenced in parameter 3, gives some information about the object which the handle is currently referencing. It seems to be a registry key.
Let's take a closer look into the registry key, just for academic and nerdy interest, use the !reg findkcb extension with the entire path of the registry key.
Using the address of the KCB (Key Control Block), use the !reg kcb extension, and should get output similar to this:
The reference count is 1, therefore only one process has a handle open to that registry key. The Flags indicates the name of the key is in a compressed form, and the registry key is current 9 levels deep into the registry. \REGISTRY\MACHINE\SYSTEM would be 3 levels.
The nVidia graphics card driver seemed to be causing problems. The registry key being referenced is also related to nVidia.
