IoCompleteRequest cause BSOD

OSR_Community_User · March 2, 2009, 11:27pm

Hi,

When I am doing Dynamic Partitioning hot replace test for scsi miniport
driver, which service block device enumerated by my bus driver,
IoCompleteRequest cause a BSOD for query device power state IRP in my
bus driver. When DP test start, it will send a query system state IRP
(system 5, device 5) to my bus driver child PDO, I complete IRP and
return success. Then that PDO get a query device power state IRP (system
4, device 4), I also want to complete IRP and return success. But this
time, IoCompleteRequest cause a BSOD error. Error code 0x0000000a
(IRQL_NOT_LESS_OR_EQUAL), IRQL = 2, windbg told me function call
IoCompleteRequest cause the problem. I found that if I Driver Verify for
my scsi miniport driver, DP hot-replace test works fine. WDK tells me
that IoCompleteRequest can work at DISPATCH_LEVEL. And I have checked my
bus driver code, I didn’t hold any spin lock when call
IoCompleteRequest. Any suggestion is appreciate.

thanks
wayne

Maxim_S_Shatskih · March 3, 2009, 12:45am

> time, IoCompleteRequest cause a BSOD error. Error code 0x0000000a

(IRQL_NOT_LESS_OR_EQUAL), IRQL = 2, windbg told me function call

What is the stack?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

anton_bassov · March 3, 2009, 1:11am

Assuming that PIRP is valid and you crash BEFORE IoCompleteRequest() returns control, it sounds pretty much like interop - it looks like someone who registered IO completion routine with IRP does something that is not allowed at elevated IRQL in a completion routine that gets called by IoCompleteRequest()…

Anton Bassov

OSR_Community_User · March 3, 2009, 1:33am

What is the stack?

STACK_TEXT:
fffffa60005eaa98 fffff80001759c72 : fffffa80007f7bb0 0000000000000065 fffff8000188b030 fffff8000166cc38 : nt!RtlpBreakWithStatusInstruction
fffffa60005eaaa0 fffff8000175aa2b : fffff80000000003 0000000000000000 fffff800016e7d90 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffffa60005eab00 fffff800016a7494 : fffff98002372d00 fffffa80002f2aa0 fffffa60005eb230 fffff8000173bc11 : nt!KeBugCheck2+0x6eb
fffffa60005eb170 fffff800016a712e : 000000000000000a fffff8000188b030 0000000000000002 0000000000000008 : nt!KeBugCheckEx+0x104
fffffa60005eb1b0 fffff800016a600b : 0000000000000008 fffffa80024b6590 ffff42f4a8b08000 fffffa80024b6590 : nt!KiBugCheckDispatch+0x6e
fffffa60005eb2f0 fffff8000188b030 : fffff98002372dc0 fffff8000169b0e2 0000000000000000 0000000000000000 : nt!KiPageFault+0x20b
fffffa60005eb480 fffff80001ab43f6 : fffff98002372f68 0000000000000000 0000000000000000 fffff98002372dc0 : nt!PopSystemIrpCompletion+0x2d0
fffffa60005eb520 fffff800016a9705 : fffff98002372dc0 0000000000000000 fffffa800182a101 fffff98002372f6b : nt!IovpLocalCompletionRoutine+0x116
fffffa60005eb560 fffff80001aae8c3 : fffff98002372dc0 fffff6fc0000c600 0000000100000000 fffff80001803700 : nt!IopfCompleteRequest+0x315
fffffa60005eb620 fffffa60008340bb : fffffa60005eb700 fffffa60005eb700 fffff98002372dc0 fffffa800182a1a0 : nt!IovCompleteRequest+0x43
fffffa60005eb700 fffff800017728ba : fffffa80024b7a80 fffff980047ecd03 fffff980047ecdc0 0000000000000003 : NDIS!ndisQueryPowerComplete+0xab
fffffa60005eb740 fffff80001ab43f6 : fffff980047ecf68 fffff980047ecdc0 fffff980047ecdc0 fffffa60005eb8d8 : nt!PopRequestCompletion+0x4a
fffffa60005eb780 fffff800016a9705 : fffff980047ecdc0 0000000000000000 fffffa800135b001 fffff980047ecf6b : nt!IovpLocalCompletionRoutine+0x116
fffffa60005eb7c0 fffff80001aae8c3 : fffff980047ecdc0 fffff6fb7dbf0000 0000000000000000 fffff6fc0000c6c8 : nt!IopfCompleteRequest+0x315
fffffa60005eb880 fffffa6000c873b8 : fffffa800135b1b0 0000000000000004 fffff980047ecdc0 fffffa800135b060 : nt!IovCompleteRequest+0x43
fffffa60005eb960 fffffa6000c86f3c : fffffa800135b060 fffff980047ecdc0 fffff980047ecf20 fffff98000000001 : xenpci!XenPciPowerPDO+0x2e8 [d:\work\ovmwinpv\coding\xenpci\power.c @ 222]
fffffa60005eb9b0 fffff800017611d2 : fffffa800135b060 fffff980047ecdc0 fffffa800135b060 fffffa80021ca220 : xenpci!XenPciDispatchPower+0xec [d:\work\ovmwinpv\coding\xenpci\power.c @ 55]
fffffa60005eba10 fffff80001ab7586 : fffff980047ecdc0 fffffa800135b060 fffff6fd30004d70 fffff800018d98fb : nt!IopPoHandleIrp+0x32
fffffa60005eba40 fffffa60009acb74 : fffff980047ecf20 fffff980047ecf68 fffff980047ecdc0 fffffa80021ca220 : nt!IovCallDriver+0x336
fffffa60005eba80 fffffa60009ae403 : fffff980047ecf68 0000000000000000 fffffa800135b060 fffffa800182a1a0 : NDIS!ndisQueryPower+0xa4
fffffa60005ebad0 fffff800017611d2 : fffff980047ecdc0 0000000000000002 fffffa800182a050 fffffa80021dc7f0 : NDIS!ndisPowerDispatch+0x1a3
fffffa60005ebb20 fffff80001ab7586 : fffff980047ecdc0 fffffa800182a050 fffff980047ecdc0 fffffa800182b890 : nt!IopPoHandleIrp+0x32
fffffa60005ebb50 fffffa6000cde3b0 : fffff980047ecdc0 0000000000000002 fffffa6000cdfe50 fffffa80021dc7f0 : nt!IovCallDriver+0x336
fffffa60005ebb90 fffff800017611d2 : fffffa800182bac0 fffff980047ecdc0 fffffa800182bac0 fffffa80021dc8c0 : xenconfig!XenConfigPower+0xa0 [d:\work\ovmwinpv\coding\xenconfig\xenconfig.c @ 83]
fffffa60005ebbe0 fffff80001ab7586 : fffff980047ecdc0 fffffa800182bac0 fffff980046b0f28 000000000000000d : nt!IopPoHandleIrp+0x32
fffffa60005ebc10 fffffa6000bdf660 : 0000000000000001 0000000000000000 fffffa6000be1340 fffffa80021dc8c0 : nt!IovCallDriver+0x336
fffffa60005ebc50 fffff800017705ca : fffffa800182b890 fffff980047ecdc0 fffffa8001bf7600 0000000000000000 : xenhide!XenHidePower+0xa0 [d:\work\ovmwinpv\coding\xenhide\xenhide.c @ 128]
fffffa60005ebca0 fffff800018cade3 : 0000000000000000 fffffa80007f7bb0 0000000000000080 0000000000000001 : nt!PopIrpWorker+0x3ca
fffffa60005ebd50 fffff800016e1536 : fffff800017c6680 fffffa80007f7bb0 fffffa8001020bb0 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa60005ebd80 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

Thanks
wayne

OSR_Community_User · March 3, 2009, 1:47am

Assuming that PIRP is valid and you crash BEFORE IoCompleteRequest() returns control, it sounds pretty much like interop - it looks like someone who registered IO completion routine with IRP does something that is not allowed at elevated IRQL in a completion routine that gets called by IoCompleteRequest()…
Yes, I agree with you. When I call IoCompleteRequest(), current IRQL is 0. But BSOD error told me that IRQL is 2. I think DISPATCH_LEVEL IRQL may cause problem in complete routine. So how can I check who raise IRQL? In IoCompleteRequest routine, I fill IO_NO_INCREMENT as the second parameter.

Thanks
wayne

David_J_Craig · March 3, 2009, 2:44am

First, IO_NO_INCREMENT has NO (NONE, NOTHING AT ALL) effect on IRQL. Expect in ALL completion routines that they may be called at DISPATCH_LEVEL unless there is some specific Microsoft defined contract that prohibits this behavior such as IRP_MJ_CREATE in the file systems. From what you said is this response you say that you completed the request, but some other driver had a BSOD. Was your driver in the stack? Provide full details of the BSOD with valid symbols and ‘analyze -v’ output.
“Wayne.Gong” wrote in message news:xxxxx@ntdev…
Assuming that PIRP is valid and you crash BEFORE IoCompleteRequest() returns control, it sounds pretty much like interop - it looks like someone who registered IO completion routine with IRP does something that is not allowed at elevated IRQL in a completion routine that gets called by IoCompleteRequest()…
Yes, I agree with you. When I call IoCompleteRequest(), current IRQL is 0. But BSOD error told me that IRQL is 2. I think DISPATCH_LEVEL IRQL may cause problem in complete routine. So how can I check who raise IRQL? In IoCompleteRequest routine, I fill IO_NO_INCREMENT as the second parameter.

Thanks
wayne

OSR_Community_User · March 3, 2009, 3:04am

Print !analyze log,

xenpci is my bus driver. Xenconfig and xenhide are filter driver on stack,
and they do nothing about power IRP, just send it down.

thanks
wayne

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff80001839ff0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
chips which support this level of status)
Arg4: fffff80001839ff0, address which referenced memory

Debugging Details:

READ_ADDRESS: fffff80001839ff0

CURRENT_IRQL: 2

FAULTING_IP:
nt!PopDiagTraceDriverVeto+0
fffff800`01839ff0 fff3 push rbx

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffffa60005eb2e0 – (.trap 0xfffffa60005eb2e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000ffffffff rbx=fffffa80021bebe0 rcx=fffffa800185b050
rdx=fffffa8001359e08 rsi=fffffa80021bebe0 rdi=fffff80001716308
rip=fffff80001839ff0 rsp=fffffa60005eb478 rbp=00000000c00000bb
r8=fffffa60005eb4d0 r9=0000000000000000 r10=0000000000000100
r11=fffffa80007f7bb0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!PopDiagTraceDriverVeto:
fffff800`01839ff0 fff3 push rbx
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000165912e to fffff80001659390

FAILED_INSTRUCTION_ADDRESS:
nt!PopDiagTraceDriverVeto+0
fffff800`01839ff0 fff3 push rbx

STACK_TEXT:
fffffa60005eb198 fffff8000165912e : 000000000000000a fffff80001839ff0
0000000000000002 0000000000000008 : nt!KeBugCheckEx
fffffa60005eb1a0 fffff8000165800b : 0000000000000008 0000000000000240
0000000000000000 fffffa80021f16d0 : nt!KiBugCheckDispatch+0x6e
fffffa60005eb2e0 fffff80001839ff0 : fffff8000183cf3c fffff9800474adc0
fffff8000164d0e2 0000000000000000 : nt!KiPageFault+0x20b
fffffa60005eb478 fffff8000183cf3c : fffff9800474adc0 fffff8000164d0e2
0000000000000000 0000000000000000 : nt!PopDiagTraceDriverVeto
fffffa60005eb480 fffff80001a663f6 : fffff9800474af68 0000000000000000
0000000000000000 fffff9800474adc0 : nt!PopSystemIrpCompletion+0x1dc
fffffa60005eb520 fffff8000165b705 : fffff9800474adc0 0000000000000000
fffffa800185b101 fffff9800474af6b : nt!IovpLocalCompletionRoutine+0x116
fffffa60005eb560 fffff80001a608c3 : fffff9800474adc0 fffff8000170b500
fffff9800479e000 00000000000001f0 : nt!IopfCompleteRequest+0x315
fffffa60005eb620 fffffa60008300bb : fffffa60005eb700 fffffa60005eb700
fffff9800474adc0 fffffa800185b1a0 : nt!IovCompleteRequest+0x43
fffffa60005eb700 fffff800017248ba : fffffa800218e920 fffff98004644d03
fffff98004644dc0 0000000000000003 : NDIS!ndisQueryPowerComplete+0xab
fffffa60005eb740 fffff80001a663f6 : fffff98004644f68 fffff98004644dc0
fffff98004644dc0 fffffa60005eb8d8 : nt!PopRequestCompletion+0x4a
fffffa60005eb780 fffff8000165b705 : fffff98004644dc0 0000000000000000
fffffa8001358701 fffff98004644f6b : nt!IovpLocalCompletionRoutine+0x116
fffffa60005eb7c0 fffff80001a608c3 : fffff98004644dc0 fffff80001a66400
fffff9800479ef70 fffff9800479ee10 : nt!IopfCompleteRequest+0x315
fffffa60005eb880 fffffa6000c96380 : fffff98000000005 fffffa8000000004
fffff98004644dc0 fffffa8001358730 : nt!IovCompleteRequest+0x43
fffffa60005eb960 fffffa6000c95f3c : fffffa8001358730 fffff98004644dc0
fffff98004644f20 fffff98000000001 : xenpci!XenPciPowerPDO+0x2c0
[d:\work\ovmwinpv\coding\xenpci\power.c @ 216]
fffffa60005eb9b0 fffff800017131d2 : fffffa8001358730 fffff98004644dc0
fffffa8001358730 fffffa8001ed1f40 : xenpci!XenPciDispatchPower+0xec
[d:\work\ovmwinpv\coding\xenpci\power.c @ 55]
fffffa60005eba10 fffff80001a69586 : fffff98004644dc0 fffffa8001358730
fffff6fd30004d50 fffff8000188b8fb : nt!IopPoHandleIrp+0x32
fffffa60005eba40 fffffa60009a8b74 : fffff98004644f20 fffff98004644f68
fffff98004644dc0 fffffa8001ed1f40 : nt!IovCallDriver+0x336
fffffa60005eba80 fffffa60009aa403 : fffff98004644f68 0000000000000000
fffffa8001358730 fffffa800185b1a0 : NDIS!ndisQueryPower+0xa4
fffffa60005ebad0 fffff800017131d2 : fffff98004644dc0 0000000000000002
fffffa800185b050 fffffa80021e2da0 : NDIS!ndisPowerDispatch+0x1a3
fffffa60005ebb20 fffff80001a69586 : fffff98004644dc0 fffffa800185b050
fffff98004644dc0 fffffa800185a280 : nt!IopPoHandleIrp+0x32
fffffa60005ebb50 fffffa6000ced3b0 : fffff98004644dc0 0000000000000002
fffffa6000ceee50 fffffa80021e2da0 : nt!IovCallDriver+0x336
fffffa60005ebb90 fffff800017131d2 : fffffa800185a4b0 fffff98004644dc0
fffffa800185a4b0 fffffa80021b1180 : xenconfig!XenConfigPower+0xa0
[d:\work\ovmwinpv\coding\xenconfig\xenconfig.c @ 83]
fffffa60005ebbe0 fffff80001a69586 : fffff98004644dc0 fffffa800185a4b0
fffff98004732e50 fffffa600000000d : nt!IopPoHandleIrp+0x32
fffffa60005ebc10 fffffa6000bdb660 : 0000000000000001 0000000000000000
fffffa6000bdd340 fffffa80021b1180 : nt!IovCallDriver+0x336
fffffa60005ebc50 fffff800017225ca : fffffa800185a280 fffff98004644dc0
fffffa80017e7000 fffff98004660c00 : xenhide!XenHidePower+0xa0
[d:\work\ovmwinpv\coding\xenhide\xenhide.c @ 128]
fffffa60005ebca0 fffff8000187cde3 : 0000000000000000 fffffa80007f7bb0
0000000000000080 0000000000000001 : nt!PopIrpWorker+0x3ca
fffffa60005ebd50 fffff80001693536 : fffff80001778680 fffffa80007f7bb0
fffffa8001020bb0 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa60005ebd80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
xenpci!XenPciPowerPDO+2c0 [d:\work\ovmwinpv\coding\xenpci\power.c @ 216]
fffffa6000c96380 4c8d0d89950000 lea r9,[xenpci! ?? ::FNODOBFM::string’ (fffffa60`00c9f910)]

FAULTING_SOURCE_CODE:
212: PoStartNextPowerIrp(Irp);
213: #endif
214: status = Irp->IoStatus.Status;
215: IoCompleteRequest(Irp, IO_NO_INCREMENT);

216: FUNCTION_OUT(DBG_POWER);
217:
218: return status;
219: }
220:

SYMBOL_STACK_INDEX: d

SYMBOL_NAME: xenpci!XenPciPowerPDO+2c0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: xenpci

IMAGE_NAME: xenpci.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49acdd67

FAILURE_BUCKET_ID: X64_0xA_VRF_CODE_AV_BAD_IP_xenpci!XenPciPowerPDO+2c0

BUCKET_ID: X64_0xA_VRF_CODE_AV_BAD_IP_xenpci!XenPciPowerPDO+2c0

Followup: MachineOwner

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!IopDeviceTreeLock (0xfffff800017ffd20) Shared 1 owning
threads
Threads: fffffa80019df5a0-01<*>
KD: Scanning for held locks.

Resource @ nt!PiEngineLock (0xfffff800017ffc20) Exclusively owned
Contention Count = 2
Threads: fffffa80019df5a0-01<*>
KD: Scanning for held
locks…
2988 total locks, 2 locks currently held

kd> !thread fffffa80019df5a0
THREAD fffffa80019df5a0 Cid 0004.0158 Teb: 0000000000000000 Win32Thread:
0000000000000000 READY
Not impersonating
DeviceMap fffff88000005390
Owning Process 0 Image:
Attached Process fffffa80007f53d0 Image: System
Wait Start TickCount 5269 Ticks: 0
Context Switch Count 784
UserTime 00:00:00.000
KernelTime 00:00:00.421
Win32 Start Address nt!ExpWorkerThread (0xfffff80001665f4c)
Stack Init fffffa6001ccfdb0 Current fffffa6001ccf830
Base fffffa6001cd0000 Limit fffffa6001cca000 Call 0
Priority 13 BasePriority 12 PriorityDecrement 1 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child
: Call Site
fffffa6001ccf870 fffff8000165ef8a : 0000000000000000 fffff80001778680
0000000000000000 fffffa80019df5a0 : nt!KiSwapContext+0x7f
fffffa6001ccf9b0 fffff8000165e596 : 0000000000000000 0000000000000000
fffff800017968f8 fffffa800000000d : nt!KiSwapThread+0x2fa
fffffa6001ccfa20 fffff8000183d40d : fffffa8000000002 fffffa8001c55e08
fffffa8000000001 fffffa8000000000 : nt!KeWaitForMultipleObjects+0x2d6
fffffa6001ccfaa0 fffff80001844d9b : fffffa80021f1880 0000000000000005
fffffa6001ccfc78 fffffa80021f16d0 : nt!PopSleepDeviceList+0xed
fffffa6001ccfb80 fffff80001845244 : 0000000000000000 fffffffffffe7960
fffffa6003faab30 0000000000000000 : nt!PoBroadcastSystemState+0x2ab
fffffa6001ccfc10 fffff80001a444ec : 0000000000000610 fffffa6003faab30
fffff800017968f8 fffffa60000005d1 : nt!PnprQuiesceDevices+0xe4
fffffa6001ccfc40 fffff80001666066 : fffff80000000001 fffff80001a43f00
fffff800017968f8 fffffa80019df5a0 : nt!PnpReplacePartitionUnit+0x5ec
fffffa6001ccfcf0 fffff8000187cde3 : fffffa6003faab60 fffffffe9a5f4400
fffffa80019df5a0 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa6001ccfd50 fffff80001693536 : fffff80001778680 fffffa80019df5a0
fffffa8001049bb0 0000000000000000 : nt!PspSystemThreadStartup+0x57
fffffa6001ccfd80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

kd> !thread fffffa80019df5a0
THREAD fffffa80019df5a0 Cid 0004.0158 Teb: 0000000000000000 Win32Thread:
0000000000000000 READY
Not impersonating
DeviceMap fffff88000005390
Owning Process 0 Image:
Attached Process fffffa80007f53d0 Image: System
Wait Start TickCount 5269 Ticks: 0
Context Switch Count 784
UserTime 00:00:00.000
KernelTime 00:00:00.421
Win32 Start Address nt!ExpWorkerThread (0xfffff80001665f4c)
Stack Init fffffa6001ccfdb0 Current fffffa6001ccf830
Base fffffa6001cd0000 Limit fffffa6001cca000 Call 0
Priority 13 BasePriority 12 PriorityDecrement 1 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child
: Call Site
fffffa6001ccf870 fffff8000165ef8a : 0000000000000000 fffff80001778680
0000000000000000 fffffa80019df5a0 : nt!KiSwapContext+0x7f
fffffa6001ccf9b0 fffff8000165e596 : 0000000000000000 0000000000000000
fffff800017968f8 fffffa800000000d : nt!KiSwapThread+0x2fa
fffffa6001ccfa20 fffff8000183d40d : fffffa8000000002 fffffa8001c55e08
fffffa8000000001 fffffa8000000000 : nt!KeWaitForMultipleObjects+0x2d6
fffffa6001ccfaa0 fffff80001844d9b : fffffa80021f1880 0000000000000005
fffffa6001ccfc78 fffffa80021f16d0 : nt!PopSleepDeviceList+0xed
fffffa6001ccfb80 fffff80001845244 : 0000000000000000 fffffffffffe7960
fffffa6003faab30 0000000000000000 : nt!PoBroadcastSystemState+0x2ab
fffffa6001ccfc10 fffff80001a444ec : 0000000000000610 fffffa6003faab30
fffff800017968f8 fffffa60000005d1 : nt!PnprQuiesceDevices+0xe4
fffffa6001ccfc40 fffff80001666066 : fffff80000000001 fffff80001a43f00
fffff800017968f8 fffffa80019df5a0 : nt!PnpReplacePartitionUnit+0x5ec
fffffa6001ccfcf0 fffff8000187cde3 : fffffa6003faab60 fffffffe9a5f4400
fffffa80019df5a0 0000000000000080 : nt!ExpWorkerThread+0x11a
fffffa6001ccfd50 fffff80001693536 : fffff80001778680 fffffa80019df5a0
fffffa8001049bb0 0000000000000000 : nt!PspSystemThreadStartup+0x57
fffffa6001ccfd80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

OSR_Community_User · March 3, 2009, 3:18am

David Craig wrote:

Was your driver in the stack? Provide full details of the BSOD with
valid symbols and ‘analyze -v’ output.

I have a bus driver, NDIS miniport, SCSI miniport driver and two filter
drivers in my object. Bus driver will enumerate network and block
devices which NDIS/SCSI miniport driver will service them. DP hot
replace test will simulate a fake S4 power state, so it will send some
query/set power IRPs to my drivers. This test case is passed in my NDIS
miniport network driver since on that test, DTM won’t start Driver
Verify. But for SCSI miniport driver, if I disable Driver Verify and do
test manually, it can pass. But BSOD after I enable standard Driver
Verify setting. So I guess some driver in NDIS/SCSI miniport driver
stack register a complete routine that running at DISPATCH_LEVEL make
Driver Verify unhappy. Anybody has some experience on DP hot-replace
test for a real physical device? How did you do that in your driver?

Thanks
wayne

OSR_Community_User · March 3, 2009, 5:54am

I found something strange.

I have tried to use a full virtual mode windows to pass this test case.
But also fail. . That’s to say I didn’t initialize any para-virtual
devices, all block and network device are working on full virtual HVM
mode which enumerated by Xen and service by a well known driver.( Intel
IDE driver service block device and Rtl8139 driver service network
device). Then I use Driver Verify standard setting to trace ataport.sys
atapi.sys and intelide.sys. After reboot to make Driver Verify effect, I
use ‘pnpcpu.exe -replace’ to do DP hot replace test manually on a stand
alone windows server 2008 x64 DC, also get BSOD. From dump file, i get
the following log. It looks like that pciide.sys also has some problem
for this test. Does anybody can help me to have a try on a real physical
machine for this test?

Thanks
wayne

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff8000184e030, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation
(only on chips which support this level of status)
Arg4: fffff8000184e030, address which referenced memory

Debugging Details:

READ_ADDRESS: fffff8000184e030

CURRENT_IRQL: 2

FAULTING_IP:
nt!PopSystemIrpCompletion+2d0
fffff800`0184e030 488d4c2450 lea rcx,[rsp+50h]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffffa6002874670 – (.trap 0xfffffa6002874670)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=fffffa80015c0450 rcx=fffffa800137e010
rdx=0000000000000001 rsi=0000000000000010 rdi=0000000000000000
rip=fffff8000184e030 rsp=fffffa6002874800 rbp=0000000000000001
r8=0000000000000000 r9=0000000000000000 r10=0000000000000100
r11=fffffa8001993480 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!PopSystemIrpCompletion+0x2d0:
fffff800`0184e030 488d4c2450 lea rcx,[rsp+50h]
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000166a12e to fffff8000166a390

FAILED_INSTRUCTION_ADDRESS:
nt!PopSystemIrpCompletion+2d0
fffff800`0184e030 488d4c2450 lea rcx,[rsp+50h]

STACK_TEXT:
fffffa6002874528 fffff8000166a12e : 000000000000000a fffffa6002874530 fffff8000166900b : 0000000000000008 nt!KiBugCheckDispatch+0x6e fffffa6002874670 fffff8000184e030 : fffff980043dae10 fffffa6002874800 fffff80001a773f6 : fffff980043daf70 nt!PopSystemIrpCompletion+0x2d0 fffffa60028748a0 fffff8000166c705 : fffff980043dae10 nt!IovpLocalCompletionRoutine+0x116 fffffa60028748e0 fffff80001a718c3 : fffff980043dae10 nt!IopfCompleteRequest+0x315 fffffa60028749a0 fffffa6000c7f70a : fffff980043dae10 nt!IovCompleteRequest+0x43 fffffa6002874a80 fffffa6000c7fb62 : fffff980043dae10 PCIIDEX!PdoSetPowerState+0x86 fffffa6002874ab0 fffff800017241d2 : fffff980043dae10 PCIIDEX!PciIdeDispatchPower+0x22 fffffa6002874ae0 fffff80001a7a586 : fffff980043dae10 nt!IopPoHandleIrp+0x32 fffffa6002874b10 fffffa6000d151f5 : fffff980043daf28 nt!IovCallDriver+0x336 fffffa6002874b50 fffffa6000d1503b : fffff980043dae10 ataport!FdoSetSystemPowerState+0xb5 fffffa6002874b80 fffffa6000d15e62 : fffff980043dae10 ataport!FdoSetPowerState+0x23 fffffa6002874bb0 fffff800017241d2 : fffff980043dae10 ataport!IdePortDispatchPower+0x22 fffffa6002874be0 fffff80001a7a586 : fffff980043dae10 nt!IopPoHandleIrp+0x32 fffffa6002874c10 fffffa6000be4660 : 0000000000000001 nt!IovCallDriver+0x336 fffffa6002874c50 fffff800017335ca : fffffa800134de10 fffffa6002874ca0 fffff8000188dde3 : fffffffffa0a1f00 nt!PopIrpWorker+0x3ca fffffa6002874d50 fffff800016a4536 : fffff80001789680 nt!PspSystemThreadStartup+0x57 fffffa6002874d80 0000000000000000 : 0000000000000000 nt!KiStartSystemThread+0x16 fffff8000184e030 0000000000000002 0000000000000008 : nt!KeBugCheckEx fffffa80019cc4d0 ffff993b61f60e00 fffffa80019cc4d0 : fffff8000165e0e2 fffff980043dae10 fffffa6000d1556b : nt!KiPageFault+0x20b 0000000000000000 0000000000000000 fffff980043dae10 : 0000000000000000 fffffa8001345a01 fffff980043daf73 : fffffa6000b55500 fffffa800137b7b0 fffff98001d90e10 : 0000000000000002 fffff980043dae10 fffffa8001345a10 : 0000000000000000 fffffa800134c050 fffff980043dae10 : 0000000000000002 fffffa8001345a10 fffffa8001bf10a0 : fffffa8001345a10 0000000000000000 0000000000000000 : 0000000000000002 fffff980043dae10 fffffa8001bf10a0 : fffffa800134c050 fffffa8001993538 fffff80001713193 : fffff8000168fb1d 0000000000000000 fffff98001d90fb8 : 0000000000000002 fffffa800134c050 fffffa8001b57990 : fffffa800134c050 fffff98004234ca0 fffffa800000000d : 0000000000000000 fffffa6000be6340 fffffa8001b57990 : fffff980043dae10 fffff98004234c00 fffffa6002874d00 : xenhide+0x1660 fffffa8001993480 0000000000000080 0000000000000001 : fffffa8001993480 fffffa8001ee73f0 0000000000000001 : 0000000000000000 0000000000000000 0000000000000000 :

STACK_COMMAND: kb

FOLLOWUP_IP:
PCIIDEX!PdoSetPowerState+86
fffffa60`00c7f70a b803010000 mov eax,103h

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: PCIIDEX!PdoSetPowerState+86

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: PCIIDEX

IMAGE_NAME: PCIIDEX.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 479198a5

FAILURE_BUCKET_ID: X64_0xA_VRF_CODE_AV_BAD_IP_PCIIDEX!PdoSetPowerState+86

BUCKET_ID: X64_0xA_VRF_CODE_AV_BAD_IP_PCIIDEX!PdoSetPowerState+86

Followup: MachineOwner

OSR_Community_User · March 3, 2009, 2:26pm

Gong, do you have this fix installed?

http://support.microsoft.com/kb/961324

I am not sure that was the problem, but it seems similar at a quick look.

Dan

OSR_Community_User · March 3, 2009, 9:02pm

xxxxx@microsoft.com wrote:

Gong, do you have this fix installed?

http://support.microsoft.com/kb/961324

I am not sure that was the problem, but it seems similar at a quick look.

Yes, the hotfix disappears BSOD. But new question comes,

1, Does this hotfix applied on Windows Server 2008 R2 beta?
2, When I create submission to Microsoft for my drivers, can I update
this hotfix to the target windows system?

Thanks
wayne

OSR_Community_User · March 4, 2009, 9:50am

Sorry Wayne, I don’t know the answers to your latest two questions. Hopefully you can ask some contact person for the certification program that you are working on. I am not familiar enough with these programs.

Dan