Driver install/startup crash on Windows 8.1

NTDEV
1

Hello everyone,

I am investigating a BSOD on windows 8.1. Our drivers works fine on windows 8 but on 8.1 it crashes on start up of the drivers.

What I noticed is that we get a IRP_MN_QUERY_INTERFACE with InterfaceType = GUID_PNP_LOCATION_INTERFACE. We do not handle this interface so we do not modify the status of the IRP and pass down to the next lower level driver using these calls :

IoSkipCurrentIrpStackLocation(io_pIrp);

IoCallDriver(m_poNextStackDevice, io_pIrp);

This causes an error : PAGE_FAULT_IN_NONPAGED_AREA (50) in the ACPI driver(next lower level driver).

Anyone ever noticed that sort of behavior ?
Any ideas what could go wrong would be appreciated.

Thank you very much

Louis

2

!analyze -v output would be a start, even better, attach a kernel debugger and step through the issue

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, December 9, 2013 12:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver install/startup crash on Windows 8.1

Hello everyone,

I am investigating a BSOD on windows 8.1. Our drivers works fine on windows 8 but on 8.1 it crashes on start up of the drivers.

What I noticed is that we get a IRP_MN_QUERY_INTERFACE with InterfaceType = GUID_PNP_LOCATION_INTERFACE. We do not handle this interface so we do not modify the status of the IRP and pass down to the next lower level driver using these calls :

IoSkipCurrentIrpStackLocation(io_pIrp);

IoCallDriver(m_poNextStackDevice, io_pIrp);

This causes an error : PAGE_FAULT_IN_NONPAGED_AREA (50) in the ACPI driver(next lower level driver).

Anyone ever noticed that sort of behavior ?
Any ideas what could go wrong would be appreciated.

Thank you very much

Louis

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Hello, I already have an attached debugger and traced and that’s how I figured what IRP I was getting and causing this crash.
Here is the !analyze -v output from the kernel dump file :
18: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffffffffffffff0, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff8000025ad8d, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)

Debugging Details:

WRITE_ADDRESS: fffff800d7735340: Unable to get special pool info
fffff800d7735340: Unable to get special pool info
fffffffffffffff0

FAULTING_IP:
ACPI!ACPIFilterIrpQueryPnpLocationInterface+89
fffff800`0025ad8d 488948f0 mov qword ptr [rax-10h],rcx

MM_INTERNAL_CODE: 0

IMAGE_NAME: mvkBus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5271b033

MODULE_NAME: mvkBus

FAULTING_MODULE: fffff80000200000 ACPI

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: ffffd00022137180 – (.trap 0xffffd00022137180)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffff800002183d8
rdx=ffffe000131d3a60 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000025ad8d rsp=ffffd00022137310 rbp=0000000000000000
r8=ffffe000131d3b30 r9=fffff800002419e8 r10=0000000070211b0e
r11=fffff800d75dd893 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
ACPI!ACPIFilterIrpQueryPnpLocationInterface+0x89:
fffff8000025ad8d 488948f0 mov qword ptr [rax-10h],rcx ds:fffffffffffffff0=???
Resetting default scope

LOCK_ADDRESS: fffff800d7752360 – (!locks fffff800d7752360)

Resource @ nt!PiEngineLock (0xfffff800d7752360) Exclusively owned
Contention Count = 7
Threads: ffffe00006fa7880-01<*>
1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff800d7752360
Thread Count : 1
Thread address: 0xffffe00006fa7880
Thread wait : 0xa581

LAST_CONTROL_TRANSFER: from fffff800d75f895c to fffff800d75d0ca0

STACK_TEXT:
ffffd00022136f98 fffff800d75f895c : 0000000000000050 fffffffffffffff0 0000000000000001 ffffd00022137180 : nt!KeBugCheckEx
ffffd00022136fa0 fffff800d74bf5ad : 0000000000000001 ffffe00006fa7880 ffffd00022137180 0000000000000001 : nt! ?? ::FNODOBFM::string'+0x177cc ffffd00022137040 fffff800d75daf2f : 0000000000000001 ffffe000006eb870 0000000000000000 ffffd00022137180 : nt!MmAccessFault+0x7ed ffffd00022137180 fffff8000025ad8d : fffff800d74896e0 fffff800d74c3811 00000000c0000002 ffffe00015065270 : nt!KiPageFault+0x12f ffffd00022137310 fffff80000258f7a : fffff800d74896e0 ffffe0001e613320 ffffe000131d3a60 ffffe0002048de40 : ACPI!ACPIFilterIrpQueryPnpLocationInterface+0x89 ffffd00022137370 fffff8000020110f : ffffe000006eb870 ffffe0001e613320 ffffe000131d3a60 0000000000000001 : ACPI!ACPIFilterIrpQueryInterface+0xea ffffd000221373b0 fffff80007b528b0 : 0000000000000007 ffffe000131d3a60 0000000000000028 ffffe0001f8b3010 : ACPI!ACPIDispatchIrp+0xef ffffd00022137420 fffff80007b4c6a1 : ffffe0001f8b3010 0000000000000000 ffffd000221374c0 fffff800d79250f8 : mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler+0x58 [r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp @ 887] ffffd00022137450 fffff800d7925138 : ffffe0002048de40 ffffd00022137590 ffffd00022137590 ffffd00020112170 : mvkBus!CMvkBaseDeviceWin::PnpDispatchHandler+0x1d1 [r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasedevicewin.cpp @ 129] ffffd00022137480 fffff800d7924b4d : 0000000000000018 ffffd000221375a9 ffffe000155dd010 00000000000007ff : nt!PnpQueryInterface+0xcc ffffd00022137510 fffff800d78cf4b8 : 00000000ffffffff ffffd000221376d8 ffffd00022137694 fffff80000000001 : nt!PnpGetDeviceLocationStrings+0x13d ffffd00022137610 fffff800d78d7507 : ffffe000155dd010 ffffe000155dd010 0000000000000001 ffffe0001e612ca0 : nt!PiProcessNewDeviceNode+0x8c4 ffffd000221377d0 fffff800d790cf8f : ffffe0001e612ca0 0000000000000001 0000000000000000 fffff800d7853542 : nt!PipProcessDevNodeTree+0x41f ffffd00022137a50 fffff800d75752f3 : 0000000100000003 0000000000000000 0000000000000000 0000000000000000 : nt!PiRestartDevice+0xaf ffffd00022137aa0 fffff800d75241b9 : fffff800d7574f50 ffffd00022137bd0 0000000000000000 ffffe000153e4e80 : nt!PnpDeviceActionWorker+0x3a3 ffffd00022137b50 fffff800d75102e4 : ffffd00020f0cd40 ffffe00006fa7880 ffffe00006fa7880 ffffe0000032f900 : nt!ExpWorkerThread+0x2b5 ffffd00022137c00 fffff800d75d72c6 : ffffd00020f00180 ffffe00006fa7880 ffffd00020f0cd40 0000000000000000 : nt!PspSystemThreadStartup+0x58 ffffd00022137c60 0000000000000000 : ffffd00022138000 ffffd00022132000 0000000000000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler+58 [r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp @ 887]
fffff800`07b528b0 488b5c2430 mov rbx,qword ptr [rsp+30h]

FAULTING_SOURCE_LINE: r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp

FAULTING_SOURCE_FILE: r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp

FAULTING_SOURCE_LINE_NUMBER: 887

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler+58

FOLLOWUP_NAME: MachineOwner

BUCKET_ID_FUNC_OFFSET: 58

FAILURE_BUCKET_ID: AV_mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler

BUCKET_ID: AV_mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler

Followup: MachineOwner

18: kd> lmvm ACPI
start end module name
fffff80000200000 fffff80000285000 ACPI (private pdb symbols) c:\symbols\acpi.pdb\1E7D924E107E40FDBED93E1E7F8637D92\acpi.pdb
Loaded symbol image file: ACPI.sys
Image path: \SystemRoot\System32\drivers\ACPI.sys
Image name: ACPI.sys
Timestamp: Tue Oct 08 03:40:38 2013 (5253B6F6)
CheckSum: 00080B58
ImageSize: 00085000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

4

Is the request coming in on a mvkBus driver bus PDO stack or the FDO for that bus driver. If it’s coming in on the PDO stack, it may not be valid to just forward it down the FDO stack.

I’d also suggest turning on driver verifier, with the options turned mostly up. DV does a bunch of PnP IRP checking.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, December 9, 2013 1:20 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver install/startup crash on Windows 8.1

Hello, I already have an attached debugger and traced and that’s how I figured what IRP I was getting and causing this crash.
Here is the !analyze -v output from the kernel dump file :
18: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffffffffffffff0, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff8000025ad8d, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)

Debugging Details:

WRITE_ADDRESS: fffff800d7735340: Unable to get special pool info
fffff800d7735340: Unable to get special pool info
fffffffffffffff0

FAULTING_IP:
ACPI!ACPIFilterIrpQueryPnpLocationInterface+89
fffff800`0025ad8d 488948f0 mov qword ptr [rax-10h],rcx

MM_INTERNAL_CODE: 0

IMAGE_NAME: mvkBus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5271b033

MODULE_NAME: mvkBus

FAULTING_MODULE: fffff80000200000 ACPI

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: ffffd00022137180 – (.trap 0xffffd00022137180)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffff800002183d8
rdx=ffffe000131d3a60 rsi=0000000000000000 rdi=0000000000000000 rip=fffff8000025ad8d rsp=ffffd00022137310 rbp=0000000000000000
r8=ffffe000131d3b30 r9=fffff800002419e8 r10=0000000070211b0e
r11=fffff800d75dd893 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
ACPI!ACPIFilterIrpQueryPnpLocationInterface+0x89:
fffff8000025ad8d 488948f0 mov qword ptr [rax-10h],rcx ds:fffffffffffffff0=???
Resetting default scope

LOCK_ADDRESS: fffff800d7752360 – (!locks fffff800d7752360)

Resource @ nt!PiEngineLock (0xfffff800d7752360) Exclusively owned
Contention Count = 7
Threads: ffffe00006fa7880-01<*>
1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0xfffff800d7752360
Thread Count : 1
Thread address: 0xffffe00006fa7880
Thread wait : 0xa581

LAST_CONTROL_TRANSFER: from fffff800d75f895c to fffff800d75d0ca0

STACK_TEXT:
ffffd00022136f98 fffff800d75f895c : 0000000000000050 fffffffffffffff0 0000000000000001 ffffd00022137180 : nt!KeBugCheckEx
ffffd00022136fa0 fffff800d74bf5ad : 0000000000000001 ffffe00006fa7880 ffffd00022137180 0000000000000001 : nt! ?? ::FNODOBFM::string'+0x177cc ffffd00022137040 fffff800d75daf2f : 0000000000000001 ffffe000006eb870 0000000000000000 ffffd00022137180 : nt!MmAccessFault+0x7ed ffffd00022137180 fffff8000025ad8d : fffff800d74896e0 fffff800d74c3811 00000000c0000002 ffffe00015065270 : nt!KiPageFault+0x12f ffffd00022137310 fffff80000258f7a : fffff800d74896e0 ffffe0001e613320 ffffe000131d3a60 ffffe0002048de40 : ACPI!ACPIFilterIrpQueryPnpLocationInterface+0x89 ffffd00022137370 fffff8000020110f : ffffe000006eb870 ffffe0001e613320 ffffe000131d3a60 0000000000000001 : ACPI!ACPIFilterIrpQueryInterface+0xea ffffd000221373b0 fffff80007b528b0 : 0000000000000007 ffffe000131d3a60 0000000000000028 ffffe0001f8b3010 : ACPI!ACPIDispatchIrp+0xef ffffd00022137420 fffff80007b4c6a1 : ffffe0001f8b3010 0000000000000000 ffffd000221374c0 fffff800d79250f8 : mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler+0x58 [r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp @ 887] ffffd00022137450 fffff800d7925138 : ffffe0002048de40 ffffd00022137590 ffffd00022137590 ffffd00020112170 : mvkBus!CMvkBaseDeviceWin::PnpDispatchHandler+0x1d1 [r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasedevicewin.cpp @ 129] ffffd00022137480 fffff800d7924b4d : 0000000000000018 ffffd000221375a9 ffffe000155dd010 00000000000007ff : nt!PnpQueryInterface+0xcc ffffd00022137510 fffff800d78cf4b8 : 00000000ffffffff ffffd000221376d8 ffffd00022137694 fffff80000000001 : nt!PnpGetDeviceLocationStrings+0x13d ffffd00022137610 fffff800d78d7507 : ffffe000155dd010 ffffe000155dd010 0000000000000001 ffffe0001e612ca0 : nt!PiProcessNewDeviceNode+0x8c4 ffffd000221377d0 fffff800d790cf8f : ffffe0001e612ca0 0000000000000001 0000000000000000 fffff800d7853542 : nt!PipProcessDevNodeTree+0x41f ffffd00022137a50 fffff800d75752f3 : 0000000100000003 0000000000000000 0000000000000000 0000000000000000 : nt!PiRestartDevice+0xaf ffffd00022137aa0 fffff800d75241b9 : fffff800d7574f50 ffffd00022137bd0 0000000000000000 ffffe000153e4e80 : nt!PnpDeviceActionWorker+0x3a3 ffffd00022137b50 fffff800d75102e4 : ffffd00020f0cd40 ffffe00006fa7880 ffffe00006fa7880 ffffe0000032f900 : nt!ExpWorkerThread+0x2b5 ffffd00022137c00 fffff800d75d72c6 : ffffd00020f00180 ffffe00006fa7880 ffffd00020f0cd40 0000000000000000 : nt!PspSystemThreadStartup+0x58 ffffd00022137c60 0000000000000000 : ffffd00022138000 ffffd00022132000 0000000000000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler+58 [r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp @ 887]
fffff800`07b528b0 488b5c2430 mov rbx,qword ptr [rsp+30h]

FAULTING_SOURCE_LINE: r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp

FAULTING_SOURCE_FILE: r:\vpg_software\vp\kernel\libs\mvkbasedriver\driver_release_w7_x64\src\mvkbasechilddevicewin.cpp

FAULTING_SOURCE_LINE_NUMBER: 887

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler+58

FOLLOWUP_NAME: MachineOwner

BUCKET_ID_FUNC_OFFSET: 58

FAILURE_BUCKET_ID: AV_mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler

BUCKET_ID: AV_mvkBus!CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler

Followup: MachineOwner

18: kd> lmvm ACPI
start end module name
fffff80000200000 fffff80000285000 ACPI (private pdb symbols) c:\symbols\acpi.pdb\1E7D924E107E40FDBED93E1E7F8637D92\acpi.pdb
Loaded symbol image file: ACPI.sys
Image path: \SystemRoot\System32\drivers\ACPI.sys
Image name: ACPI.sys
Timestamp: Tue Oct 08 03:40:38 2013 (5253B6F6)
CheckSum: 00080B58
ImageSize: 00085000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

How does !irp for that IRP look?

Do you by any chance forward it from PDO to the lower FDO?

6

!irp doesn’t give that much information :

38: kd> !irp ffffcf80`01cf8ea0
Irp is active with 1 stacks 1 is current (= 00000000)
No Mdl: No System Buffer: Thread 00010028: Irp stack trace.
cmd flg cl Device File Completion-Context

[1b, 8] 0 0 ffffe0001ffa6de0 00000000 00000000-00000000
\DRIVER\VERIFIER_FILTER
Args: fffff801f0a876e0 00010028 ffffd0002213d590 00000000

I enabled Driver Verifier for the mvkbus.sys(FDO) driver but couldn’t find any information specific.

Could you tell me how to figure the IRP is coming from either (PDO or FDO) looking at the stack?

Thank you

Louis

7

How does your CMvkBaseChildDeviceWin::PnpQueryInterfaceHandler function look?

What is m_poNextStackDevice? Where do you get it from?

Why it’s called CMvkBaseChildDeviceWin? Does it handle child device PDO?

8

You seem to have your own C++ framework with your own PNP implementation.

This is not wise. As simple it may look, PNP/power is quite difficult to get right, especially when you need to implement a bus driver. You think it works, and then it crashes when the OS slightly changes.

Switch to KMDF.

9

I see your parent FDO just forwards the QUERY_INTERFACE IRP to its stack. This is VERY wrong.

An IRP is allocated with certain number of stack locations, which is taken from the topmost DEVICE_OBJECT in the stack. There are no stack locations for another stack.

Only by chance, if your FDO sits directly over a PDO, this will work, if you roll back the stack with IoSkipIrpStackLocation. This will NOT work if there is DriverVerifier’s filter DO attached, which you see.

To properly forward the IRP to the lower stack, you need to allocate a new IRP, copy the parameters to its stack, send it down, and when it completes, copy the status back to the original IRP.

10

I read this and I think a little clarity needs to be added

  1. for the FDO, you must send the QI down the stack to the attached device, not directly to the PDO. Sometimes the attached device and the PDO are the same, sometimes they are not, so they are not functionally equivalent.

  2. for the PDO, you cannot take the IRP send to the PDO and just send it down the parent stack. As grigor said, there are not enough stack locations for this to work. You need to allocate an irp that is big enough for the parent stack. BUT, the documentation says if a PDO doesn’t handle QI request, it should complete it, not send it down the parent stack, http://msdn.microsoft.com/en-us/library/windows/hardware/ff551687(v=vs.85).aspx

If a bus driver does not export the requested interface and therefore does not handle this IRP for a child PDO, the bus driver leaves Irp->IoStatus.Status as is and completes the IRP.>

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Tuesday, December 10, 2013 9:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver install/startup crash on Windows 8.1

I see your parent FDO just forwards the QUERY_INTERFACE IRP to its stack. This is VERY wrong.

An IRP is allocated with certain number of stack locations, which is taken from the topmost DEVICE_OBJECT in the stack. There are no stack locations for another stack.

Only by chance, if your FDO sits directly over a PDO, this will work, if you roll back the stack with IoSkipIrpStackLocation. This will NOT work if there is DriverVerifier’s filter DO attached, which you see.

To properly forward the IRP to the lower stack, you need to allocate a new IRP, copy the parameters to its stack, send it down, and when it completes, copy the status back to the original IRP.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

"2) for the PDO, you cannot take the IRP send to the PDO and just send it down
the parent stack. As grigor said, there are not enough stack locations for this
to work. You need to allocate an irp that is big enough for the parent stack.
BUT, the documentation says if a PDO doesn’t handle QI request, it should
complete it, not send it down the parent stack,
http://msdn.microsoft.com/en-us/library/windows/hardware/ff551687(v=vs.85).aspx

If a bus driver does not export the requested interface and therefore
does not handle this IRP for a child PDO, the bus driver leaves
Irp->IoStatus.Status as is and completes the IRP.>"

-It fixed my problem, I was always sending IRP for a child PDO down the parent stack instead of completing the IRP. it’s funny that it worked for winXP, Vista, win7 and Win8 since 2005. Only found this flaw causing issue in windows 8.1 OS.

Thanks very much to you guys!