Debugging Stop 0xCA - PNP_DETECTED_FATAL_ERROR

A Stop 0xCA usually indicates something is wrong with the PnP Manager or a driver/device which has a device node within the PnP Manager's Device Tree. To keep this blog post manageable (I've read through three different pages of Windows Driver documentation), I'll add the relevant links to those pages if I can.

The significant things to look at in this dump file, are the call stack and the driver object associated with the PDO (Physical Device Object). We can there is something wrong with the PCI bus or a device connected to that bus by just opening the dump file:

Let's get a overview of the nature of the dump file with:

The most important page you will want to start with is this one - IRP_MN_QUERY_DEVICE_RELATIONS

We can see a driver has deleted a PDO which has already been deleted, I found the wording of the error to be quite difficult to be honest. I decided to look into the supported dispatch routines (IRPs) which the driver object could handle with the !drvobj extension:

 

 We can see that the Major Function Code IRP_MJ_PNP is supported by device object, which has a Minor Function Code of the driver documentation which I created a link for, therefore there isn't any problem with the device being able to handle the IRP. I brought up this point, this that IRP is used to query device relations and handle RemovalRelations requests.

A BusRelations request may have also been sent to query the child devices connected to the PCI Bus, we could have caused the system to bugcheck with present Stop Code, as a result of this from Microsoft:

"Warning   A device object cannot be passed to any routine that takes a PDO as an argument until the PnP manager creates a device node (devnode) for that object. (If the driver does pass a device object, the system will bug check with Bug Check 0xCA: PNP_DETECTED_FATAL_ERROR.) The PnP manager creates the devnode in response to the IRP_MN_QUERY_DEVICE_RELATIONS request. The driver can safely assume that the PDO's devnode has been created when it receives an IRP_MN_QUERY_RESOURCE_REQUIREMENTS request."

 We can view the call stack from a Stop 0xE4, and get supported information about our theory.

To summarise, there seems to be a problem with the PnP Manager or at least the drivers for the device, and how they are handling certain IRPs. The IRP seems most likely related to the _MJ_PNP Major Function code; IRP_MN_QUERY_DEVICE_RELATIONS seems to be the specific Minor Function code where the problem might have happened. I'm also guessing that a routine was used which took a device object as a parameter, before the a device node was created within the device tree by the PnP Manager for the associated device object.