storport miniport crashes while sending the read response

NTDEV
1

hi all,
i am writing a storport miniport driver.
i am able to send inquiry, report luns and read capactiy command successfully.
but while sending the read command response i m facing some issue.
my system crashes somewhere inbetween responding to almost 24-25 read command response.
i have tried to analysze the dump but couldn’t understood,
plz help me in resolve,

here is the dump from windbg,

*******************************************************************************
* *
* 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: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 82fc8353, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000004

CURRENT_IRQL: 2

FAULTING_IP:
storport!RaidUnitReleaseIrp+d
82fc8353 8b7104 mov esi,dword ptr [ecx+4]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: 87b57e34 – (.trap 0xffffffff87b57e34)
ErrCode = 00000000
eax=89196f68 ebx=89196f68 ecx=00000000 edx=00000000 esi=8a663b28 edi=80786158
eip=82fc8353 esp=87b57ea8 ebp=87b57eb0 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210246
storport!RaidUnitReleaseIrp+0xd:
82fc8353 8b7104 mov esi,dword ptr [ecx+4] ds:0023:00000004=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 828f1e71 to 82880394

STACK_TEXT:
87b579fc 828f1e71 00000003 f101ef61 00000065 nt!RtlpBreakWithStatusInstruction
87b57a4c 828f296d 00000003 00000004 82fc8353 nt!KiBugCheckDebugBreak+0x1c
87b57e14 8285b7eb 0000000a 00000004 00000002 nt!KeBugCheck2+0x68b
87b57e14 82fc8353 0000000a 00000004 00000002 nt!KiTrap0E+0x2cf
87b57eb0 82fc8806 89196f68 89196f68 80786158 storport!RaidUnitReleaseIrp+0xd
87b57eec 82fc8a65 8a663b28 897aa008 8a3e96e0 storport!RaUnitAsyncError+0x15e
87b57f20 82fba1d9 8a663b28 8a3e969c 8685f484 storport!RaidUnitCompleteRequest+0x101
87b57f48 8287d3b5 8a3e969c 8a3e9628 00000000 storport!RaidpAdapterDpcRoutine+0x51
87b57fa4 8287d218 87b37120 8685f400 00000000 nt!KiExecuteAllDpcs+0xf9
87b57ff4 8287c9dc 80786014 00000000 00000000 nt!KiRetireDpcList+0xd5
87b57ff8 80786014 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
WARNING: Frame IP not in any known module. Following frames may be wrong.
8287c9dc 00000000 0000001a 00d6850f bb830000 0x80786014

STACK_COMMAND: kb

FOLLOWUP_IP:
storport!RaidUnitReleaseIrp+d
82fc8353 8b7104 mov esi,dword ptr [ecx+4]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: storport!RaidUnitReleaseIrp+d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc736

FAILURE_BUCKET_ID: 0xD1_VRF_storport!RaidUnitReleaseIrp+d

BUCKET_ID: 0xD1_VRF_storport!RaidUnitReleaseIrp+d

Followup: MachineOwner

thanks,
Hitesh

2

Well you are crashing from a bad pointer (null in this case, pointing
to some object that is being read at offset 4), and you are in
storport’s DPC side IRP completion path, so I am going to guess that
you have managed to indicate to storport that the same request has
been completed more than once, or that an entirely bogus request is
being completed.

If this is entirely reproducible there are lots of things you can do
to trace request processing in your miniport. I tend to use debug
prints to record run time activity, wait for the crash to occur, and
then grovel through the trace output and the evidence in the crash to
figure out what went wrong.

Mark Roddy

On Fri, Oct 8, 2010 at 7:10 AM, wrote:
> hi all,
> i am writing a storport miniport driver.
> i am able to send inquiry, report luns and read capactiy command successfully.
> but while sending the read command response i m facing some issue.
> my system crashes somewhere inbetween responding to almost 24-25 read command response.
> i have tried to analysze the dump but couldn’t understood,
> plz help me in resolve,
>
> here is the dump from windbg,
>
> *
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ?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: 00000004, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 82fc8353, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: ?00000004
>
> CURRENT_IRQL: ?2
>
> FAULTING_IP:
> storport!RaidUnitReleaseIrp+d
> 82fc8353 8b7104 ? ? ? ? ?mov ? ? esi,dword ptr [ecx+4]
>
> DEFAULT_BUCKET_ID: ?VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: ?0xD1
>
> PROCESS_NAME: ?System
>
> TRAP_FRAME: ?87b57e34 – (.trap 0xffffffff87b57e34)
> ErrCode = 00000000
> eax=89196f68 ebx=89196f68 ecx=00000000 edx=00000000 esi=8a663b28 edi=80786158
> eip=82fc8353 esp=87b57ea8 ebp=87b57eb0 iopl=0 ? ? ? ? nv up ei pl zr na pe nc
> cs=0008 ?ss=0010 ?ds=0023 ?es=0023 ?fs=0030 ?gs=0000 ? ? ? ? ? ? efl=00210246
> storport!RaidUnitReleaseIrp+0xd:
> 82fc8353 8b7104 ? ? ? ? ?mov ? ? esi,dword ptr [ecx+4] ds:0023:00000004=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: ?from 828f1e71 to 82880394
>
> STACK_TEXT:
> 87b579fc 828f1e71 00000003 f101ef61 00000065 nt!RtlpBreakWithStatusInstruction
> 87b57a4c 828f296d 00000003 00000004 82fc8353 nt!KiBugCheckDebugBreak+0x1c
> 87b57e14 8285b7eb 0000000a 00000004 00000002 nt!KeBugCheck2+0x68b
> 87b57e14 82fc8353 0000000a 00000004 00000002 nt!KiTrap0E+0x2cf
> 87b57eb0 82fc8806 89196f68 89196f68 80786158 storport!RaidUnitReleaseIrp+0xd
> 87b57eec 82fc8a65 8a663b28 897aa008 8a3e96e0 storport!RaUnitAsyncError+0x15e
> 87b57f20 82fba1d9 8a663b28 8a3e969c 8685f484 storport!RaidUnitCompleteRequest+0x101
> 87b57f48 8287d3b5 8a3e969c 8a3e9628 00000000 storport!RaidpAdapterDpcRoutine+0x51
> 87b57fa4 8287d218 87b37120 8685f400 00000000 nt!KiExecuteAllDpcs+0xf9
> 87b57ff4 8287c9dc 80786014 00000000 00000000 nt!KiRetireDpcList+0xd5
> 87b57ff8 80786014 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2c
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 8287c9dc 00000000 0000001a 00d6850f bb830000 0x80786014
>
>
> STACK_COMMAND: ?kb
>
> FOLLOWUP_IP:
> storport!RaidUnitReleaseIrp+d
> 82fc8353 8b7104 ? ? ? ? ?mov ? ? esi,dword ptr [ecx+4]
>
> SYMBOL_STACK_INDEX: ?4
>
> SYMBOL_NAME: ?storport!RaidUnitReleaseIrp+d
>
> FOLLOWUP_NAME: ?MachineOwner
>
> MODULE_NAME: storport
>
> IMAGE_NAME: ?storport.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: ?4a5bc736
>
> FAILURE_BUCKET_ID: ?0xD1_VRF_storport!RaidUnitReleaseIrp+d
>
> BUCKET_ID: ?0xD1_VRF_storport!RaidUnitReleaseIrp+d
>
> Followup: MachineOwner
> ---------
>
>
> thanks,
> Hitesh
>
> —
> NTDEV is sponsored by OSR
>
> 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
>