BSOD on storport!RaidpAdapterInterruptRoutine

David_Zeng · February 20, 2013, 10:03pm

Hi, All

I removed the miniport driver of a raid controller, and then restart the
OS, then the BSOD occurred.
The Windows was installed on the ESXi and the raid controller is
configured as directpath.
Another thing very strange is that if I rescan the device in device manager
after removing the device driver, everything is normal.
It seems that some information is not updated before restarting.
Anyone can help to see this problem? Thanks in advance.

Following is the memory dump information:

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000008, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 0000000000000000, address which referenced memory

Debugging Details:

READ_ADDRESS: 0000000000000000

CURRENT_IRQL: 8

FAULTING_IP:
+6662393132306537
00000000`00000000 ?? ???

PROCESS_NAME: System

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: fffff80002838930 -- (.trap 0xfffff80002838930)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa80027665e0 rbx=0000000000000000 rcx=fffffa8002970008
rdx=fffffa8002748600 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=fffff80002838ac8 rbp=fffff80002838b80
r8=fffff80001601cc0 r9=0000000000000000 r10=000000000000c619
r11=00000000000f0000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
00000000`00000000 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80001480be9 to fffff80001481640

FAILED_INSTRUCTION_ADDRESS:
+6662393132306537
00000000`00000000 ?? ???

STACK_TEXT:
fffff80002838ac8 fffff880013080d3 : 0000000000000000 fffffa8002939340
fffffa8002939340 0000000000000001 : 0x0
fffff80002838ad0 fffff8000147d47c : 0000000000000000 0000000000000001
fffffa80027123c0 0000000010fcf3d4 :
storport!RaidpAdapterInterruptRoutine+0x23
fffff80002838b00 fffff8800262c9c2 : fffff8000148af09 00000000ffffffed
fffffa8003325598 0000000000000000 : nt!KiInterruptDispatch+0x16c
fffff80002838c98 fffff8000148af09 : 00000000ffffffed fffffa8003325598
0000000000000000 0000000000000518 : intelppm+0x39c2
fffff80002838ca0 fffff8000147933c : fffff800015f3e80 fffff80000000000
0000000000000000 fffff880012fc500 : nt!PoIdle+0x52a
fffff80002838d80 0000000000000000 : fffff80002839000 fffff80002833000
fffff80002838d40 0000000000000000 : nt!KiIdleLoop+0x2c

STACK_COMMAND: .trap 0xfffff80002838930 ; kb

FOLLOWUP_IP:
storport!RaidpAdapterInterruptRoutine+23
fffff880`013080d3 4883c428 add rsp,28h

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: storport!RaidpAdapterInterruptRoutine+23

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a456

FAILURE_BUCKET_ID:
X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterInterruptRoutine+23

BUCKET_ID:
X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterInterruptRoutine+23

Followup: MachineOwner

--

Best regards,
David Zeng

David_Zeng · February 21, 2013, 9:20pm

Anyone can explain this problem?

On Thu, Feb 21, 2013 at 11:03 AM, David wrote:

> Hi, All
>
> I removed the miniport driver of a raid controller, and then restart the
> OS, then the BSOD occurred.
> The Windows was installed on the ESXi and the raid controller is
> configured as directpath.
> Another thing very strange is that if I rescan the device in device
> manager after removing the device driver, everything is normal.
> It seems that some information is not updated before restarting.
> Anyone can help to see this problem? Thanks in advance.
>
> Following is the memory dump information:
>
> kd> !analyze -v
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> 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 kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 0000000000000000, memory referenced
> Arg2: 0000000000000008, IRQL
> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
> Arg4: 0000000000000000, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 0000000000000000
>
> CURRENT_IRQL: 8
>
> FAULTING_IP:
> +6662393132306537
> 0000000000000000 ?? ??? > > PROCESS_NAME: System > > DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT > > BUGCHECK_STR: 0xD1 > > TRAP_FRAME: fffff80002838930 -- (.trap 0xfffff80002838930) > NOTE: The trap frame does not contain all registers. > Some register values may be zeroed or incorrect. > rax=fffffa80027665e0 rbx=0000000000000000 rcx=fffffa8002970008 > rdx=fffffa8002748600 rsi=0000000000000000 rdi=0000000000000000 > rip=0000000000000000 rsp=fffff80002838ac8 rbp=fffff80002838b80 > r8=fffff80001601cc0 r9=0000000000000000 r10=000000000000c619 > r11=00000000000f0000 r12=0000000000000000 r13=0000000000000000 > r14=0000000000000000 r15=0000000000000000 > iopl=0 nv up ei ng nz na pe nc > 0000000000000000 ?? ???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from fffff80001480be9 to fffff80001481640
>
> FAILED_INSTRUCTION_ADDRESS:
> +6662393132306537
> 0000000000000000 ?? ??? > > STACK_TEXT: > fffff80002838ac8 fffff880013080d3 : 0000000000000000 fffffa8002939340 > fffffa8002939340 0000000000000001 : 0x0 > fffff80002838ad0 fffff8000147d47c : 0000000000000000 0000000000000001 > fffffa80027123c0 0000000010fcf3d4 : > storport!RaidpAdapterInterruptRoutine+0x23 > fffff80002838b00 fffff8800262c9c2 : fffff8000148af09 00000000ffffffed > fffffa8003325598 0000000000000000 : nt!KiInterruptDispatch+0x16c > fffff80002838c98 fffff8000148af09 : 00000000ffffffed fffffa8003325598 > 0000000000000000 0000000000000518 : intelppm+0x39c2 > fffff80002838ca0 fffff8000147933c : fffff800015f3e80 fffff80000000000 > 0000000000000000 fffff880012fc500 : nt!PoIdle+0x52a > fffff80002838d80 0000000000000000 : fffff80002839000 fffff80002833000 > fffff80002838d40 0000000000000000 : nt!KiIdleLoop+0x2c > > > STACK_COMMAND: .trap 0xfffff80002838930 ; kb > > FOLLOWUP_IP: > storport!RaidpAdapterInterruptRoutine+23 > fffff880013080d3 4883c428 add rsp,28h
>
> SYMBOL_STACK_INDEX: 1
>
> SYMBOL_NAME: storport!RaidpAdapterInterruptRoutine+23
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: storport
>
> IMAGE_NAME: storport.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a456
>
> FAILURE_BUCKET_ID:
> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterInterruptRoutine+23
>
> BUCKET_ID:
> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterInterruptRoutine+23
>
> Followup: MachineOwner
>
>
> –
>
> Best regards,
> David Zeng
>

–

Best regards,
David Zeng

Alex_Grig · February 22, 2013, 12:35am

What driver?

OSR_Community_User · February 22, 2013, 1:31am

At a first guess, it looks like a call to location 00000000’00000000. You
can tell this because rip is zero. What you need to do is disassemble the
instructions in the routine; the instruction shown is most likely the
instruction following the call. What you are seeing is an instruction
that removes 28h (40 decimal) bytes of parameters from the stack…which
looks kind of weird, because normally the call sequnce does not push
arguments onto the stack, but moves them to a preallocated argument block
which has already been allocated. I suspect that you will find the
instruction right before this one is
call [rx]
where rx is one of those registers that shows as zero in the dump, such as
rbx or r9, to suggest two possibilities. right before the call, we would
see some register being loaded with a pointer, and then the rx I cited is
loaded from some multiple-of-sizeof(void*), followed by the call.
Whatever is supposed to be in that table isn’t there, but NULL is, and you
call off to East Hyperspace with the ensuing BSOD.

I am not a file system expert, but it could be a call via a table which
has a NULL pointer, perhaps the consequence of having removed the driver
in question.

Based on general programming knowledge, it is possible that a driver
called a miniport to initialize a dispatch table, and the removal of the
driver in question meant that the table was never initialized. But that’s
pure guesswork on my part.
joe

Anyone can explain this problem?

On Thu, Feb 21, 2013 at 11:03 AM, David wrote:
>
>> Hi, All
>>
>> I removed the miniport driver of a raid controller, and then restart the
>> OS, then the BSOD occurred.
>> The Windows was installed on the ESXi and the raid controller is
>> configured as directpath.
>> Another thing very strange is that if I rescan the device in device
>> manager after removing the device driver, everything is normal.
>> It seems that some information is not updated before restarting.
>> Anyone can help to see this problem? Thanks in advance.
>>
>> Following is the memory dump information:
>>
>> kd> !analyze -v
>>
>> *****
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>>
>>
>> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
>> 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 kernel debugger is available get stack backtrace.
>> Arguments:
>> Arg1: 0000000000000000, memory referenced
>> Arg2: 0000000000000008, IRQL
>> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
>> Arg4: 0000000000000000, address which referenced memory
>>
>> Debugging Details:
>> ------------------
>>
>>
>> READ_ADDRESS: 0000000000000000
>>
>> CURRENT_IRQL: 8
>>
>> FAULTING_IP:
>> +6662393132306537
>> 0000000000000000 ?? ??? >> >> PROCESS_NAME: System >> >> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT >> >> BUGCHECK_STR: 0xD1 >> >> TRAP_FRAME: fffff80002838930 -- (.trap 0xfffff80002838930) >> NOTE: The trap frame does not contain all registers. >> Some register values may be zeroed or incorrect. >> rax=fffffa80027665e0 rbx=0000000000000000 rcx=fffffa8002970008 >> rdx=fffffa8002748600 rsi=0000000000000000 rdi=0000000000000000 >> rip=0000000000000000 rsp=fffff80002838ac8 rbp=fffff80002838b80 >> r8=fffff80001601cc0 r9=0000000000000000 r10=000000000000c619 >> r11=00000000000f0000 r12=0000000000000000 r13=0000000000000000 >> r14=0000000000000000 r15=0000000000000000 >> iopl=0 nv up ei ng nz na pe nc >> 0000000000000000 ?? ???
>> Resetting default scope
>>
>> LAST_CONTROL_TRANSFER: from fffff80001480be9 to fffff80001481640
>>
>> FAILED_INSTRUCTION_ADDRESS:
>> +6662393132306537
>> 0000000000000000 ?? ??? >> >> STACK_TEXT: >> fffff80002838ac8 fffff880013080d3 : 0000000000000000
>> fffffa8002939340 >> fffffa8002939340 0000000000000001 : 0x0 >> fffff80002838ad0 fffff8000147d47c : 0000000000000000
>> 0000000000000001 >> fffffa80027123c0 0000000010fcf3d4 : >> storport!RaidpAdapterInterruptRoutine+0x23 >> fffff80002838b00 fffff8800262c9c2 : fffff8000148af09
>> 00000000ffffffed >> fffffa8003325598 0000000000000000 : nt!KiInterruptDispatch+0x16c >> fffff80002838c98 fffff8000148af09 : 00000000ffffffed
>> fffffa8003325598 >> 0000000000000000 0000000000000518 : intelppm+0x39c2 >> fffff80002838ca0 fffff8000147933c : fffff800015f3e80
>> fffff80000000000 >> 0000000000000000 fffff880012fc500 : nt!PoIdle+0x52a >> fffff80002838d80 0000000000000000 : fffff80002839000
>> fffff80002833000 >> fffff80002838d40 0000000000000000 : nt!KiIdleLoop+0x2c >> >> >> STACK_COMMAND: .trap 0xfffff80002838930 ; kb >> >> FOLLOWUP_IP: >> storport!RaidpAdapterInterruptRoutine+23 >> fffff880013080d3 4883c428 add rsp,28h
>>
>> SYMBOL_STACK_INDEX: 1
>>
>> SYMBOL_NAME: storport!RaidpAdapterInterruptRoutine+23
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> MODULE_NAME: storport
>>
>> IMAGE_NAME: storport.sys
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a456
>>
>> FAILURE_BUCKET_ID:
>> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterInterruptRoutine+23
>>
>> BUCKET_ID:
>> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterInterruptRoutine+23
>>
>> Followup: MachineOwner
>>
>>
>> –
>>
>> Best regards,
>> David Zeng
>>
>
>
>
> –
>
> Best regards,
> David Zeng
>
> —
> NTDEV is sponsored by OSR
>
> 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

Alex_Grig · February 22, 2013, 11:08am

Looks like the driver was unloaded without disabling interrupts and/or without storport caring to disconnect interrupt vector.

Asking another time: What device is that?

David_Zeng · February 24, 2013, 8:30pm

It’s a raid controller.

I disabled the interrupts when I uninstall the device.
I guess Stoport does not disconnect the interrupt vector.

I use MSI and didn’t register the HwInterrupt routine. So I doubt storport
call HwInterrupt instead of MSI interrupt routine.
But why?

On Sat, Feb 23, 2013 at 12:06 AM, wrote:

> Looks like the driver was unloaded without disabling interrupts and/or
> without storport caring to disconnect interrupt vector.
>
> Asking another time: What device is that?
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

Best regards,
David Zeng

Alex_Grig · February 25, 2013, 12:19am

I’m not sure ESX provides virtual MSI interrupts for the guests.
If you’re writing a miniport, you should be prepared to handle legacy interrupts, too.

David_Zeng · February 26, 2013, 1:43am

Thanks all!

I register a dummy HwInterrupt to avoid this BSOD.

On Mon, Feb 25, 2013 at 1:20 PM, wrote:

> I’m not sure ESX provides virtual MSI interrupts for the guests.
> If you’re writing a miniport, you should be prepared to handle legacy
> interrupts, too.
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–

Best regards,
David Zeng