Debugging Stop 0xC4 - DDI Compliance Rules

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