Stop 0xCA's are relatively rare but fortunately they're usually quite easy to debug. It's also one of those bugchecks where there isn't a strict debugging methodology and therefore each individual case will need to be examined. In the example crash below, I hope to provide you with some insights in where you should look if you do happen to stumble upon this bugcheck.
Rich (BB code):
PNP_DETECTED_FATAL_ERROR (ca)
PnP encountered a severe error, either as a result of a problem in a driver or
a problem in PnP itself. The first argument describes the nature of the
problem, the second argument is the address of the PDO. The other arguments
vary depending on argument 1.
Arguments:
Arg1: 0000000000000002, Invalid PDO
An API which requires a PDO has been called with either an FDO,
a PDO which hasn't been initialized yet (returned to PnP in a
QueryDeviceRelation/BusRelations), or some random piece of
memory.
Arg2: ffff800e9fce5060, Purported PDO.
Arg3: 0000000000000000, Driver object.
Arg4: 0000000000000000
The first parameter of the bugcheck reveals why we crashed. We appear to have passed an invalid physical device object to an API (function) which requires one. The description then provides us with two hints to why the physical device object may be invalid.
Rich (BB code):
7: kd> knL
# Child-SP RetAddr Call Site
00 ffffe90e`7c4411f8 fffff805`536327d5 nt!KeBugCheckEx
01 ffffe90e`7c441200 fffff805`57962d1e nt!IoGetDevicePropertyData+0x144f45 << API in question
02 ffffe90e`7c441250 fffff805`57962cc0 partmgr!PmGetDevicePropertyData+0x52
03 ffffe90e`7c4412c0 fffff805`57949b4d partmgr!PM_DISK::GetPnpProperty+0x10
04 ffffe90e`7c4412f0 fffff805`57949a17 partmgr!SC_DEVICE::Initialize+0x4d
05 ffffe90e`7c441350 fffff805`57962135 partmgr!SC_DISK::Initialize+0x17
06 ffffe90e`7c4413a0 fffff805`57961a17 partmgr!PM_DISK::Initialize+0x3d
07 ffffe90e`7c4413d0 fffff805`57960289 partmgr!PmCollectTelemetry+0x177
08 ffffe90e`7c4415e0 fffff805`57944097 partmgr!PmSendTelemetry+0x51
09 ffffe90e`7c441a50 fffff805`5315a435 partmgr!PmNotificationWorkItem+0x337
0a ffffe90e`7c441b00 fffff805`53025975 nt!IopProcessWorkItem+0x135
0b ffffe90e`7c441b70 fffff805`53117e25 nt!ExpWorkerThread+0x105
0c ffffe90e`7c441c10 fffff805`531fcdd8 nt!PspSystemThreadStartup+0x55
0d ffffe90e`7c441c60 00000000`00000000 nt!KiStartSystemThread+0x28
The call stack reveals the API which was excepting a valid physical device object. If we check the
MSDN documentation, we can see that it takes a physical device object as one of its parameters. Let's dump the stack frame and examine the registers.
Rich (BB code):
7: kd> .frame /r 01
01 ffffe90e`7c441200 fffff805`57962d1e nt!IoGetDevicePropertyData+0x144f45
rax=ffff800e9fce5a68 rbx=ffff800e9fce5060 rcx=00000000000000ca
rdx=0000000000000002 rsi=0000000000000000 rdi=ffffe90e7c441420
rip=fffff805536327d5 rsp=ffffe90e7c441200 rbp=0000000000000002
r8=ffff800e9fce5060 r9=0000000000000000 r10=ffff800e8c181000
r11=fffff0783c1e0000 r12=0000000000000000 r13=0000000000000200
r14=ffff800e9fce5060 r15=ffffe90e7c441880
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00000246
nt!IoGetDevicePropertyData+0x144f45:
fffff805`536327d5 cc int 3
As we can see, the device object has been saved in a few different registers which is likely due to the calling convention and compiler optimisations. Nevertheless, we can see that it is passed to the function which caused the crash. Let's examine the device object and see what we can find.
Rich (BB code):
7: kd> !devobj ffff800e9fce5060
Device object (ffff800e9fce5060) is for:
Cannot read info offset from nt!ObpInfoMaskToOffset
\Driver\tcesd DriverObject ffff800e8c1f0e00
Current Irp 00000000 RefCount 0 Type 00000007 Flags 00000050
Vpb ffff800ea36d7ac0 SecurityDescriptor ffffb9864f15e5e0 DevExt ffff800e9fce51b0 DevObjExt ffff800e9fce5a68
ExtensionFlags (0x00000002) DOE_DELETE_PENDING
Characteristics (0x00000100) FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffff800ea1705960 \Driver\partmgr
Device queue is not busy.
I've highlighted the driver responsible for this device object. Let's keep a note of that. Other than that, the !devobj command doesn't reveal much useful information. Let's dump the device object extension structure.
Rich (BB code):
7: kd> dt _DEVOBJ_EXTENSION ffff800e`9fce5a68
nt!_DEVOBJ_EXTENSION
+0x000 Type : 0n13
+0x002 Size : 0
+0x008 DeviceObject : 0xffff800e`9fce5060 _DEVICE_OBJECT
+0x010 PowerFlags : 0
+0x018 Dope : (null)
+0x020 ExtensionFlags : 2
+0x028 DeviceNode : (null) << No device node created
+0x030 AttachedTo : (null)
+0x038 StartIoCount : 0n0
+0x03c StartIoKey : 0n0
+0x040 StartIoFlags : 0
+0x048 Vpb : (null)
+0x050 DependencyNode : (null)
+0x058 InterruptContext : (null)
+0x060 InterruptCount : 0n0
+0x068 VerifierContext : (null)
Ah! We've found the issue! All physical device objects which have initialised correctly should have a device node associated with them, and as we can see, there doesn't appear to be any device node.
Rich (BB code):
7: kd> lmvm tcesd
Browse full module list
start end module name
fffff805`578b0000 fffff805`5790c000 tcesd T (no symbols)
Loaded symbol image file: tcesd.sys
Image path: \SystemRoot\system32\drivers\tcesd.sys
Image name: tcesd.sys
Browse all global symbols functions data
Timestamp: Wed Jul 6 23:37:22 2016 (577D8822)
CheckSum: 0003A81D
ImageSize: 0005C000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
When a system boots, the PnP Manager will send out a PnP IRP with the minor code of IRP_MN_QUERY_DEVICE_RELATIONS, to check which devices are connected to the all the buses on the motherboard. This enables the PnP Manager to build a device tree of all the device nodes in the system and keep track of who is present and who isn't. For example, take a USB mouse, when you plug the device into the USB port, the aforementioned IRP will be generated by the PnP Manager to check which device has been connected. And when you eject or remove the mouse, a similar IRP will be sent to state to the PnP Manager that the device has now been removed.
It is the responsibility of the associated device driver to respond appropriately to the request from the PnP Manager. Otherwise, you'll end up with a Stop 0xCA bugcheck as shown above. The MSDN documentation also states the following:
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.
The Disk Keeper driver is responsible for passing the appropriate PDO pointers back to the PnP Manager, and therefore removing the driver appeared to resolve the issue.
Original Thread -
PNP_DETECTED_FATAL_ERROR on shutdown or restart? partmgr.sys (partmgr.sys+22d1e) - Windows Crashes and Blue Screen of Death (BSOD) Help and Support
