I would like to understand the issue more or ideally fix it.
The only proper solution is to fix the bug with that driver otherwise you're going to have to remove it.
Rich (BB code):
4: kd> !stack -p
Call Stack : 10 frames
## Stack-Pointer Return-Address Call-Site
00 ffffbd837e616ae8 fffff805278be5a1 nt!KeBugCheckEx+0
Parameter[0] = 00000000000000a0
Parameter[1] = 0000000000000001
Parameter[2] = 0000000000000006
Parameter[3] = ffffd30c461aae00
01 ffffbd837e616af0 fffff8052772c299 nt!PopAllocateIrp+1921bd (perf)
Parameter[0] = ffffd30c46742b70 // Pointer to _DEVICE_OBJECT
Parameter[1] = (unknown)
Parameter[2] = ffffd30c3693c202 // I should image this is a pointer to the _IRP if it were to be allocated
Parameter[3] = (unknown)
02 ffffbd837e616bc0 fffff8052772c1d2 nt!PopRequestPowerIrp+b9
Parameter[0] = ffffd30c46742b70
Parameter[1] = ffffd30c3693c202
Parameter[2] = 0000000000000001 // _DEVICE_POWER_STATE?
Parameter[3] = (unknown)
03 ffffbd837e616c50 fffff805912a83e7 nt!PoRequestPowerIrp+22
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
04 ffffbd837e616ca0 ffffd30c3693c010 nvhda64v+83e7 (leaf)
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
So, the driver calls
PoRequestPowerIrp which in turn internally calls
PopRequestPowerIrp, really all this function does is create the requested power IRP and then push it to the top of the device stack associated to that device object, which you can see below, which is why that particular device object is given in the second parameter rather than the device object we were actually allocating the power IRP for.
Rich (BB code):
4: kd> !devstack ffffd30c461aae00
!DevObj !DrvObj !DevExt ObjectName
> ffffd30c461aae00 \Driver\ksthunk ffffd30c461aaf50 Cannot read info offset from nt!ObpInfoMaskToOffset
ffffd30c46742b70 \Driver\NVHDA ffffd30c46742cc0 InfoMask field not found for _OBJECT_HEADER at ffffd30c46742b40
ffffd30c4660cb70 \Driver\HDAudBus ffffd30c4660de20 Cannot read info offset from nt!ObpInfoMaskToOffset
This was my immediate thought and it seems to be correct, we haven't allocated enough pool to be able to create the IRP object which is why the allocation fails.
Rich (BB code):
4: kd> !error c000009a
Error code: (NTSTATUS) 0xc000009a (3221225626) - Insufficient system resources exist to complete the API.
From looking at the ReactOS source code which is a pretty accurate port of most of the Windows APIs, it would seem that it returns this status code if
IoAllocateIrp fails to return an IRP object.
Rich (BB code):
4: kd> dt _DEVICE_OBJECT -y StackSize ffffd30c`461aae00
nt!_DEVICE_OBJECT
+0x04c StackSize : 7 ''
The documentation for
IoAllocateIrp does state that the stack size must be at least equal to the stack size of the next lower device object, however, it can be one greater than it, but it would seem that the stack size is 5 greater?
Rich (BB code):
4: kd> dt _DEVICE_OBJECT -y StackSize ffffd30c46742b70
nt!_DEVICE_OBJECT
+0x04c StackSize : 2 ''
It looks like the pool allocation would have been between 712 and 856 bytes. If you were more interested in why this pool allocation is failing, then you could enable Driver Verifier on that particular driver using Pool Tracking and Special Pool?
