What would happen if complete the SRB after timeout?

OSR_Community_User · February 22, 2012, 11:18am

Hi all,
I'm writing a StorPort driver now. When I receive a READ SRB I just put it
in a queue. After I got the interrupt, I insert a DPC. Then in DPC routine,
I put out this SRB from the queue and complete the SRB by using
StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
However, after a very short time, the system will BSOD(The problem doesn't
result in my driver call stack). If I get rid of this code( I
mean StorPortNotification), system will not BSOD. I think system will
complete it automatically after timeout. So I doubt that system has already
complete it before I complete it. What would happen if I complete the SRB
twice? I know that it's very bad error if I complete the IRP twice. The
below is the analysis from windbg:

0: kd> !analyze -v
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\triage\user.ini, error 2
Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012
(UTC + 8:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
........
Loading User Symbols

Loading unloaded module list
.......Unable to enumerate user-mode unloaded modules, Win32 error 0n30
*******************************************************************************
*
*
* 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: 0000000000000002, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 0000000000000000, address which referenced memory

Debugging Details:

TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2

READ_ADDRESS: 0000000000000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000`00000000 ?? ???

PROCESS_NAME: System

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10
rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0
r8=fffffa8005807d30 r9=0000000000000000 r10=fffffa8003f716e0
r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
00000000`00000000 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800027bf3c2 to fffff800026c0620

FAILED_INSTRUCTION_ADDRESS:
+0
00000000`00000000 ?? ???

STACK_TEXT:
fffff80000b9cc48 fffff880010678d3 : 000000000000002a 0000000000000000
00000000ffffffed 000002f6daf4378d : 0x0
fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80 fffffa8000000000
fffffa8003f71578 0000000000000000 : storport!RaidpAdapterDpcRoutine+0x53
fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80 fffff80002850c40
0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc
fffff80000b9cd40 0000000000000000 : fffff80000b9d000 fffff80000b97000
fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a

STACK_COMMAND: .trap 0xfffff80000b9cab0 ; kb

FOLLOWUP_IP:
storport!RaidpAdapterDpcRoutine+53
fffff880`010678d3 ff442448 inc dword ptr [rsp+48h]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: storport!RaidpAdapterDpcRoutine+53

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a403

FAILURE_BUCKET_ID:
X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53

BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53

Followup: MachineOwner

Marvin

OSR_Community_User · February 22, 2012, 11:23am

Did you put a completion status in the SRB before you completed it?

--Mark Cariddi
OSR Open Systems Resources, Inc.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
Sent: Wednesday, February 22, 2012 11:18 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] What would happen if complete the SRB after timeout?

Hi all,
I'm writing a StorPort driver now. When I receive a READ SRB I just put it in a queue. After I got the interrupt, I insert a DPC. Then in DPC routine, I put out this SRB from the queue and complete the SRB by using
StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
However, after a very short time, the system will BSOD(The problem doesn't result in my driver call stack). If I get rid of this code( I mean StorPortNotification), system will not BSOD. I think system will complete it automatically after timeout. So I doubt that system has already complete it before I complete it. What would happen if I complete the SRB twice? I know that it's very bad error if I complete the IRP twice. The below is the analysis from windbg:

0: kd> !analyze -v
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\user.ini, error 2
Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012 (UTC + 8:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
........
Loading User Symbols

Loading unloaded module list
.......Unable to enumerate user-mode unloaded modules, Win32 error 0n30
*******************************************************************************
* *
* 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: 0000000000000002, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 0000000000000000, address which referenced memory

Debugging Details:

TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2

READ_ADDRESS: 0000000000000000

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000`00000000 ?? ???

PROCESS_NAME: System

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10
rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0
r8=fffffa8005807d30 r9=0000000000000000 r10=fffffa8003f716e0
r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
00000000`00000000 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800027bf3c2 to fffff800026c0620

FAILED_INSTRUCTION_ADDRESS:
+0
00000000`00000000 ?? ???

STACK_TEXT:
fffff80000b9cc48 fffff880010678d3 : 000000000000002a 0000000000000000 00000000ffffffed 000002f6daf4378d : 0x0
fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80 fffffa8000000000 fffffa8003f71578 0000000000000000 : storport!RaidpAdapterDpcRoutine+0x53
fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80 fffff80002850c40 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc
fffff80000b9cd40 0000000000000000 : fffff80000b9d000 fffff80000b97000 fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a

STACK_COMMAND: .trap 0xfffff80000b9cab0 ; kb

FOLLOWUP_IP:
storport!RaidpAdapterDpcRoutine+53
fffff880`010678d3 ff442448 inc dword ptr [rsp+48h]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: storport!RaidpAdapterDpcRoutine+53

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: storport

IMAGE_NAME: storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a403

FAILURE_BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53

BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53

Followup: MachineOwner

Marvin
--- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: OSR Seminars – OSR To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum

OSR_Community_User · February 22, 2012, 9:38pm

Hi Mark,
Yes. I set the SrbStatus field of SRB as SRB_STATUS_SUCCESS and then
complete it. Is there any other fields which I need to update?
Marvin

On Thu, Feb 23, 2012 at 12:24 AM, Mark Cariddi wrote:

> Did you put a completion status in the SRB before you completed it?
>
>
>
> --Mark Cariddi
>
> OSR Open Systems Resources, Inc.
>
> *
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
> Sent: Wednesday, February 22, 2012 11:18 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] What would happen if complete the SRB after timeout?
>
>
> ****
>
> Hi all,
>
> I’m writing a StorPort driver now. When I receive a READ SRB I just put it
> in a queue. After I got the interrupt, I insert a DPC. Then in DPC routine,
> I put out this SRB from the queue and complete the SRB by using
>
> StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
>
> However, after a very short time, the system will BSOD(The problem doesn’t
> result in my driver call stack). If I get rid of this code( I
> mean StorPortNotification), system will not BSOD. I think system will
> complete it automatically after timeout. So I doubt that system has already
> complete it before I complete it. What would happen if I complete the SRB
> twice? I know that it’s very bad error if I complete the IRP twice. The
> below is the analysis from windbg:
>
> ****
>
> 0: kd> !analyze -v*
>
> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\triage\oca.ini, error 2****
>
> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2****
>
> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\triage\user.ini, error 2****
>
> Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012
> (UTC + 8:00)), ptr64 TRUE
>
> Loading Kernel Symbols
>
> …
>
> …
>
> …
>
> Loading User Symbols
>
> ****
>
> Loading unloaded module list
>
> …Unable to enumerate user-mode unloaded modules, Win32 error 0n30
>
>
>
>
>
>
>
>
>
> * 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: 0000000000000002, IRQL
>
> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
>
> Arg4: 0000000000000000, address which referenced memory
>
>
>
> Debugging Details:
>
> ------------------
>
>
>
> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
>
> ****
>
> READ_ADDRESS: 0000000000000000
>
>
>
> CURRENT_IRQL: 2
>
> ****
>
> FAULTING_IP:
>
> +0
>
> 0000000000000000 ?? ??? **** > >** ** > > PROCESS_NAME: System**** > > **** > > DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT **** > >** ** > > BUGCHECK_STR: 0xD1**** > > **** > > TRAP_FRAME: fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0) **** > > NOTE: The trap frame does not contain all registers.**** > > Some register values may be zeroed or incorrect. **** > > rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10**** > > rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000 **** > > rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0**** > > r8=fffffa8005807d30 r9=0000000000000000 r10=fffffa8003f716e0 **** > > r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000**** > > r14=0000000000000000 r15=0000000000000000 **** > > iopl=0 nv up ei ng nz na po nc**** > > 0000000000000000 ?? ???
>
> Resetting default scope
>
> ****
>
> LAST_CONTROL_TRANSFER: from fffff800027bf3c2 to fffff800026c0620
>
>
>
> FAILED_INSTRUCTION_ADDRESS:
>
> +0 ****
>
> 0000000000000000 ?? ???**** > > **** > > STACK_TEXT: **** > > fffff80000b9cc48 fffff880010678d3 : 000000000000002a 0000000000000000 > 00000000ffffffed 000002f6daf4378d : 0x0**** > > fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80 fffffa8000000000 > fffffa8003f71578 0000000000000000 : storport!RaidpAdapterDpcRoutine+0x53 > **** > > fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80 fffff80002850c40 > 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc**** > > fffff80000b9cd40 0000000000000000 : fffff80000b9d000 fffff80000b97000 > fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a **** > >** ** > >** ** > > STACK_COMMAND: .trap 0xfffff80000b9cab0 ; kb**** > > **** > > FOLLOWUP_IP: **** > > storport!RaidpAdapterDpcRoutine+53**** > > fffff880010678d3 ff442448 inc dword ptr [rsp+48h]
>
>
>
> SYMBOL_STACK_INDEX: 1
>
> ****
>
> SYMBOL_NAME: storport!RaidpAdapterDpcRoutine+53
>
>
>
> FOLLOWUP_NAME: MachineOwner
>
> ****
>
> MODULE_NAME: storport
>
>
>
> IMAGE_NAME: storport.sys
>
> ****
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a403
>
>
>
> FAILURE_BUCKET_ID:
> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>
> ****
>
> BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>
>
>
>
> Followup: MachineOwner
>
> ---------
>
>
>
>
>
> Marvin
>
> — 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
>
> —
> 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
>

Mark_Roddy · February 22, 2012, 10:45pm

Well then you’ve done something else grossly wrong. Obviously. Perhaps
some code would help.

Mark Roddy

On Wed, Feb 22, 2012 at 9:38 PM, Marvin Zhang wrote:
> Hi Mark,
> Yes. I set the SrbStatus field of SRB as SRB_STATUS_SUCCESS and then
> complete it. Is there any other fields which I need to update?
> Marvin
>
>
> On Thu, Feb 23, 2012 at 12:24 AM, Mark Cariddi wrote:
>>
>> Did you put a completion status in the SRB before you completed it?
>>
>>
>>
>> --Mark Cariddi
>>
>> OSR Open Systems Resources, Inc.
>>
>>
>>
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
>> Sent: Wednesday, February 22, 2012 11:18 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] What would happen if complete the SRB after timeout?
>>
>>
>>
>> Hi all,
>>
>> I’m writing a StorPort driver now. When I receive a READ SRB I just put it
>> in a queue. After I got the interrupt, I insert a DPC. Then in DPC routine,
>> I put out this SRB from the queue and complete the SRB by using
>>
>> StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
>>
>> However, after a very short time, the system will BSOD(The problem doesn’t
>> result in my driver call stack). ?If I get rid of this code( I
>> mean?StorPortNotification), system will not BSOD. I think system will
>> complete it?automatically after timeout. So I doubt that system has already
>> complete it before I complete it. What would happen if I complete the SRB
>> twice? I know that it’s??very bad error if I complete the IRP twice. The
>> below is the analysis from windbg:
>>
>>
>>
>> 0: kd> !analyze -v
>>
>> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
>>
>> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
>>
>> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\triage\user.ini, error 2
>>
>> Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012
>> (UTC + 8:00)), ptr64 TRUE
>>
>> Loading Kernel Symbols
>>
>> …
>>
>> …
>>
>> …
>>
>> Loading User Symbols
>>
>>
>>
>> Loading unloaded module list
>>
>> …Unable to enumerate user-mode unloaded modules, Win32 error 0n30
>>
>>
>> ***
>>
>>
>> ? ?
>>
>> * ? ? ? ? ? ? ? ? ? ? ? ?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: 0000000000000002, IRQL
>>
>> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
>>
>> Arg4: 0000000000000000, address which referenced memory
>>
>>
>>
>> Debugging Details:
>>
>> ------------------
>>
>>
>>
>> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
>>
>>
>>
>> READ_ADDRESS: ?0000000000000000
>>
>>
>>
>> CURRENT_IRQL: ?2
>>
>>
>>
>> FAULTING_IP:
>>
>> +0
>>
>> 0000000000000000 ?? ? ? ? ? ? ? ???? >> >> >> >> PROCESS_NAME: ?System >> >> >> >> DEFAULT_BUCKET_ID: ?WIN7_DRIVER_FAULT >> >> >> >> BUGCHECK_STR: ?0xD1 >> >> >> >> TRAP_FRAME: ?fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0) >> >> NOTE: The trap frame does not contain all registers. >> >> Some register values may be zeroed or incorrect. >> >> rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10 >> >> rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000 >> >> rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0 >> >> ?r8=fffffa8005807d30 ?r9=0000000000000000 r10=fffffa8003f716e0 >> >> r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000 >> >> r14=0000000000000000 r15=0000000000000000 >> >> iopl=0 ? ? ? ? nv up ei ng nz na po nc >> >> 0000000000000000 ?? ? ? ? ? ? ? ???
>>
>> Resetting default scope
>>
>>
>>
>> LAST_CONTROL_TRANSFER: ?from fffff800027bf3c2 to fffff800026c0620
>>
>>
>>
>> FAILED_INSTRUCTION_ADDRESS:
>>
>> +0
>>
>> 0000000000000000 ?? ? ? ? ? ? ? ???? >> >> >> >> STACK_TEXT: >> >> fffff80000b9cc48 fffff880010678d3 : 000000000000002a 0000000000000000 >> 00000000ffffffed 000002f6daf4378d : 0x0 >> >> fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80 fffffa8000000000 >> fffffa8003f71578 0000000000000000 : storport!RaidpAdapterDpcRoutine+0x53 >> >> fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80 fffff80002850c40 >> 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc >> >> fffff80000b9cd40 0000000000000000 : fffff80000b9d000 fffff80000b97000 >> fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a >> >> >> >> >> >> STACK_COMMAND: ?.trap 0xfffff80000b9cab0 ; kb >> >> >> >> FOLLOWUP_IP: >> >> storport!RaidpAdapterDpcRoutine+53 >> >> fffff880010678d3 ff442448 ? ? ? ?inc ? ? dword ptr [rsp+48h]
>>
>>
>>
>> SYMBOL_STACK_INDEX: ?1
>>
>>
>>
>> SYMBOL_NAME: ?storport!RaidpAdapterDpcRoutine+53
>>
>>
>>
>> FOLLOWUP_NAME: ?MachineOwner
>>
>>
>>
>> MODULE_NAME: storport
>>
>>
>>
>> IMAGE_NAME: ?storport.sys
>>
>>
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: ?4d79a403
>>
>>
>>
>> FAILURE_BUCKET_ID:
>> ?X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>>
>>
>>
>> BUCKET_ID: ?X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>>
>>
>>
>> Followup: MachineOwner
>>
>> ---------
>>
>>
>>
>>
>>
>> Marvin
>>
>> — 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
>>
>>
>> —
>> 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
>
>
> — 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

OSR_Community_User · February 23, 2012, 9:42am

Hi Mark,
I’m sorry that I can’t put the code on here because it contain some
algorithm of my client.
I made a experiment that I complete the SRB twice intently and I got the
similar error. But I checked my code and I think I didn’t complete the SRB
twice. Is there any possible that OS complete it after time out? I check
the TimeOutValue filed in SRB when I received and the value is 60. Does it
mean it will be timeout after 60 seconds? I can make sure that I complete
it in 60 seconds.
Marvin

On Thu, Feb 23, 2012 at 11:44 AM, Mark Roddy wrote:

> Well then you’ve done something else grossly wrong. Obviously. Perhaps
> some code would help.
>
> Mark Roddy
>
>
>
> On Wed, Feb 22, 2012 at 9:38 PM, Marvin Zhang wrote:
> > Hi Mark,
> > Yes. I set the SrbStatus field of SRB as SRB_STATUS_SUCCESS and then
> > complete it. Is there any other fields which I need to update?
> > Marvin
> >
> >
> > On Thu, Feb 23, 2012 at 12:24 AM, Mark Cariddi wrote:
> >>
> >> Did you put a completion status in the SRB before you completed it?
> >>
> >>
> >>
> >> --Mark Cariddi
> >>
> >> OSR Open Systems Resources, Inc.
> >>
> >>
> >>
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
> >> Sent: Wednesday, February 22, 2012 11:18 AM
> >> To: Windows System Software Devs Interest List
> >> Subject: [ntdev] What would happen if complete the SRB after timeout?
> >>
> >>
> >>
> >> Hi all,
> >>
> >> I’m writing a StorPort driver now. When I receive a READ SRB I just put
> it
> >> in a queue. After I got the interrupt, I insert a DPC. Then in DPC
> routine,
> >> I put out this SRB from the queue and complete the SRB by using
> >>
> >> StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
> >>
> >> However, after a very short time, the system will BSOD(The problem
> doesn’t
> >> result in my driver call stack). If I get rid of this code( I
> >> mean StorPortNotification), system will not BSOD. I think system will
> >> complete it automatically after timeout. So I doubt that system has
> already
> >> complete it before I complete it. What would happen if I complete the
> SRB
> >> twice? I know that it’s very bad error if I complete the IRP twice. The
> >> below is the analysis from windbg:
> >>
> >>
> >>
> >> 0: kd> !analyze -v
> >>
> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> >> Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
> >>
> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> >> Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
> >>
> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> >> Kits\8.0\Debuggers\x64\triage\user.ini, error 2
> >>
> >> Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012
> >> (UTC + 8:00)), ptr64 TRUE
> >>
> >> Loading Kernel Symbols
> >>
> >> …
> >>
> >> …
> >>
> >> …
> >>
> >> Loading User Symbols
> >>
> >>
> >>
> >> Loading unloaded module list
> >>
> >> …Unable to enumerate user-mode unloaded modules, Win32 error 0n30
> >>
> >>
> >>
> *****
> >>
> >>
> >>
> >>
> >> * 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: 0000000000000002, IRQL
> >>
> >> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
> >>
> >> Arg4: 0000000000000000, address which referenced memory
> >>
> >>
> >>
> >> Debugging Details:
> >>
> >> ------------------
> >>
> >>
> >>
> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
> >> Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
> >>
> >>
> >>
> >> READ_ADDRESS: 0000000000000000
> >>
> >>
> >>
> >> CURRENT_IRQL: 2
> >>
> >>
> >>
> >> FAULTING_IP:
> >>
> >> +0
> >>
> >> 0000000000000000 ?? ??? > >> > >> > >> > >> PROCESS_NAME: System > >> > >> > >> > >> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT > >> > >> > >> > >> BUGCHECK_STR: 0xD1 > >> > >> > >> > >> TRAP_FRAME: fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0) > >> > >> NOTE: The trap frame does not contain all registers. > >> > >> Some register values may be zeroed or incorrect. > >> > >> rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10 > >> > >> rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000 > >> > >> rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0 > >> > >> r8=fffffa8005807d30 r9=0000000000000000 r10=fffffa8003f716e0 > >> > >> r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000 > >> > >> r14=0000000000000000 r15=0000000000000000 > >> > >> iopl=0 nv up ei ng nz na po nc > >> > >> 0000000000000000 ?? ???
> >>
> >> Resetting default scope
> >>
> >>
> >>
> >> LAST_CONTROL_TRANSFER: from fffff800027bf3c2 to fffff800026c0620
> >>
> >>
> >>
> >> FAILED_INSTRUCTION_ADDRESS:
> >>
> >> +0
> >>
> >> 0000000000000000 ?? ??? > >> > >> > >> > >> STACK_TEXT: > >> > >> fffff80000b9cc48 fffff880010678d3 : 000000000000002a
> 0000000000000000 > >> 00000000ffffffed 000002f6daf4378d : 0x0 > >> > >> fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80
> fffffa8000000000 > >> fffffa8003f71578 0000000000000000 : > storport!RaidpAdapterDpcRoutine+0x53 > >> > >> fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80
> fffff80002850c40 > >> 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc > >> > >> fffff80000b9cd40 0000000000000000 : fffff80000b9d000
> fffff80000b97000 > >> fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a > >> > >> > >> > >> > >> > >> STACK_COMMAND: .trap 0xfffff80000b9cab0 ; kb > >> > >> > >> > >> FOLLOWUP_IP: > >> > >> storport!RaidpAdapterDpcRoutine+53 > >> > >> fffff880010678d3 ff442448 inc dword ptr [rsp+48h]
> >>
> >>
> >>
> >> SYMBOL_STACK_INDEX: 1
> >>
> >>
> >>
> >> SYMBOL_NAME: storport!RaidpAdapterDpcRoutine+53
> >>
> >>
> >>
> >> FOLLOWUP_NAME: MachineOwner
> >>
> >>
> >>
> >> MODULE_NAME: storport
> >>
> >>
> >>
> >> IMAGE_NAME: storport.sys
> >>
> >>
> >>
> >> DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a403
> >>
> >>
> >>
> >> FAILURE_BUCKET_ID:
> >> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
> >>
> >>
> >>
> >> BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
> >>
> >>
> >>
> >> Followup: MachineOwner
> >>
> >> ---------
> >>
> >>
> >>
> >>
> >>
> >> Marvin
> >>
> >> — 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
> >>
> >>
> >> —
> >> 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
> >
> >
> > — 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
>
> —
> 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
>

OSR_Community_User · February 23, 2012, 10:47am

I made another experiment that I just set a timer when I received a SRB and
complete the SRB in timer routine. And I met the same problem. The code
snippet is as below:

BOOLEAN ScsiOpReadWrite(PSCSI_REQUEST_BLOCK PSrb,
PHW_DEVICE_EXTENSION DeviceExtension,
BOOLEAN IsWrite
)
{
…
static BOOLEAN firstTime = TRUE;
if(firstTime)
{
firstTime = FALSE;
DeviceExtension->PSrbTemp = PSrb;

StorPortNotification(RequestTimerCall,DeviceExtension,WatchDogTimer,10);
return FALSE;
}else
{
PSrb->SrbStatus = SRB_STATUS_ERROR;
return TRUE;
…
}

VOID
WatchDogTimer(
IN PVOID ext
)
{
PHW_DEVICE_EXTENSION DeviceExtension = ext;
DeviceExtension->PSrbTemp->SrbStatus = SRB_STATUS_SUCCESS;
DebugPrint((1,“WatchDogTimer\n”));

StorPortNotification(RequestComplete,DeviceExtension,DeviceExtension->PSrbTemp);

}

On Thu, Feb 23, 2012 at 10:42 PM, Marvin Zhang wrote:

> Hi Mark,
> I’m sorry that I can’t put the code on here because it contain some
> algorithm of my client.
> I made a experiment that I complete the SRB twice intently and I got the
> similar error. But I checked my code and I think I didn’t complete the SRB
> twice. Is there any possible that OS complete it after time out? I check
> the TimeOutValue filed in SRB when I received and the value is 60. Does it
> mean it will be timeout after 60 seconds? I can make sure that I complete
> it in 60 seconds.
> Marvin
>
>
> On Thu, Feb 23, 2012 at 11:44 AM, Mark Roddy wrote:
>
>> Well then you’ve done something else grossly wrong. Obviously. Perhaps
>> some code would help.
>>
>> Mark Roddy
>>
>>
>>
>> On Wed, Feb 22, 2012 at 9:38 PM, Marvin Zhang wrote:
>> > Hi Mark,
>> > Yes. I set the SrbStatus field of SRB as SRB_STATUS_SUCCESS and then
>> > complete it. Is there any other fields which I need to update?
>> > Marvin
>> >
>> >
>> > On Thu, Feb 23, 2012 at 12:24 AM, Mark Cariddi wrote:
>> >>
>> >> Did you put a completion status in the SRB before you completed it?
>> >>
>> >>
>> >>
>> >> --Mark Cariddi
>> >>
>> >> OSR Open Systems Resources, Inc.
>> >>
>> >>
>> >>
>> >> From: xxxxx@lists.osr.com
>> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
>> >> Sent: Wednesday, February 22, 2012 11:18 AM
>> >> To: Windows System Software Devs Interest List
>> >> Subject: [ntdev] What would happen if complete the SRB after timeout?
>> >>
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> I’m writing a StorPort driver now. When I receive a READ SRB I just
>> put it
>> >> in a queue. After I got the interrupt, I insert a DPC. Then in DPC
>> routine,
>> >> I put out this SRB from the queue and complete the SRB by using
>> >>
>> >> StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
>> >>
>> >> However, after a very short time, the system will BSOD(The problem
>> doesn’t
>> >> result in my driver call stack). If I get rid of this code( I
>> >> mean StorPortNotification), system will not BSOD. I think system will
>> >> complete it automatically after timeout. So I doubt that system has
>> already
>> >> complete it before I complete it. What would happen if I complete the
>> SRB
>> >> twice? I know that it’s very bad error if I complete the IRP twice.
>> The
>> >> below is the analysis from windbg:
>> >>
>> >>
>> >>
>> >> 0: kd> !analyze -v
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\triage\user.ini, error 2
>> >>
>> >> Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012
>> >> (UTC + 8:00)), ptr64 TRUE
>> >>
>> >> Loading Kernel Symbols
>> >>
>> >> …
>> >>
>> >> …
>> >>
>> >> …
>> >>
>> >> Loading User Symbols
>> >>
>> >>
>> >>
>> >> Loading unloaded module list
>> >>
>> >> …Unable to enumerate user-mode unloaded modules, Win32 error 0n30
>> >>
>> >>
>> >>
>> *****
>> >>
>> >>
>> >>
>> >>
>> >> * 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: 0000000000000002, IRQL
>> >>
>> >> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
>> >>
>> >> Arg4: 0000000000000000, address which referenced memory
>> >>
>> >>
>> >>
>> >> Debugging Details:
>> >>
>> >> ------------------
>> >>
>> >>
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
>> >>
>> >>
>> >>
>> >> READ_ADDRESS: 0000000000000000
>> >>
>> >>
>> >>
>> >> CURRENT_IRQL: 2
>> >>
>> >>
>> >>
>> >> FAULTING_IP:
>> >>
>> >> +0
>> >>
>> >> 0000000000000000 ?? ??? >> >> >> >> >> >> >> >> PROCESS_NAME: System >> >> >> >> >> >> >> >> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT >> >> >> >> >> >> >> >> BUGCHECK_STR: 0xD1 >> >> >> >> >> >> >> >> TRAP_FRAME: fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0) >> >> >> >> NOTE: The trap frame does not contain all registers. >> >> >> >> Some register values may be zeroed or incorrect. >> >> >> >> rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10 >> >> >> >> rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000 >> >> >> >> rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0 >> >> >> >> r8=fffffa8005807d30 r9=0000000000000000 r10=fffffa8003f716e0 >> >> >> >> r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000 >> >> >> >> r14=0000000000000000 r15=0000000000000000 >> >> >> >> iopl=0 nv up ei ng nz na po nc >> >> >> >> 0000000000000000 ?? ???
>> >>
>> >> Resetting default scope
>> >>
>> >>
>> >>
>> >> LAST_CONTROL_TRANSFER: from fffff800027bf3c2 to fffff800026c0620
>> >>
>> >>
>> >>
>> >> FAILED_INSTRUCTION_ADDRESS:
>> >>
>> >> +0
>> >>
>> >> 0000000000000000 ?? ??? >> >> >> >> >> >> >> >> STACK_TEXT: >> >> >> >> fffff80000b9cc48 fffff880010678d3 : 000000000000002a
>> 0000000000000000 >> >> 00000000ffffffed 000002f6daf4378d : 0x0 >> >> >> >> fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80
>> fffffa8000000000 >> >> fffffa8003f71578 0000000000000000 : >> storport!RaidpAdapterDpcRoutine+0x53 >> >> >> >> fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80
>> fffff80002850c40 >> >> 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc >> >> >> >> fffff80000b9cd40 0000000000000000 : fffff80000b9d000
>> fffff80000b97000 >> >> fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a >> >> >> >> >> >> >> >> >> >> >> >> STACK_COMMAND: .trap 0xfffff80000b9cab0 ; kb >> >> >> >> >> >> >> >> FOLLOWUP_IP: >> >> >> >> storport!RaidpAdapterDpcRoutine+53 >> >> >> >> fffff880010678d3 ff442448 inc dword ptr [rsp+48h]
>> >>
>> >>
>> >>
>> >> SYMBOL_STACK_INDEX: 1
>> >>
>> >>
>> >>
>> >> SYMBOL_NAME: storport!RaidpAdapterDpcRoutine+53
>> >>
>> >>
>> >>
>> >> FOLLOWUP_NAME: MachineOwner
>> >>
>> >>
>> >>
>> >> MODULE_NAME: storport
>> >>
>> >>
>> >>
>> >> IMAGE_NAME: storport.sys
>> >>
>> >>
>> >>
>> >> DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a403
>> >>
>> >>
>> >>
>> >> FAILURE_BUCKET_ID:
>> >> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>> >>
>> >>
>> >>
>> >> BUCKET_ID: X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>> >>
>> >>
>> >>
>> >> Followup: MachineOwner
>> >>
>> >> ---------
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Marvin
>> >>
>> >> — 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
>> >>
>> >>
>> >> —
>> >> 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
>> >
>> >
>> > — 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
>>
>> —
>> 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
>>
>
>

OSR_Community_User · February 23, 2012, 11:44am

It seems that I find the why I’m wrong, but I can’t understand it.
When I got the SRB, I do nothing and just let it go. The default SrbStatus
is SRB_STATUS_PENDING, so I didn’t modify it. However, when I get the
second SRB, I find the SRB is the same with the first one which I just let
go. I mean these two SRB pointers are same. Could anyone help me to explain
it?
I think I may misunderstand the basic concept of StorPort driver. How to
set a SRB as pending and how to complete the SRB?
Thanks.

On Thu, Feb 23, 2012 at 11:47 PM, Marvin Zhang wrote:

> I made another experiment that I just set a timer when I received a SRB
> and complete the SRB in timer routine. And I met the same problem. The code
> snippet is as below:
>
> BOOLEAN ScsiOpReadWrite(PSCSI_REQUEST_BLOCK PSrb,
> PHW_DEVICE_EXTENSION DeviceExtension,
> BOOLEAN IsWrite
> )
> {
> …
> static BOOLEAN firstTime = TRUE;
> if(firstTime)
> {
> firstTime = FALSE;
> DeviceExtension->PSrbTemp = PSrb;
>
> StorPortNotification(RequestTimerCall,DeviceExtension,WatchDogTimer,10);
> return FALSE;
> }else
> {
> PSrb->SrbStatus = SRB_STATUS_ERROR;
> return TRUE;
> …
> }
>
> VOID
> WatchDogTimer(
> IN PVOID ext
> )
> {
> PHW_DEVICE_EXTENSION DeviceExtension = ext;
> DeviceExtension->PSrbTemp->SrbStatus = SRB_STATUS_SUCCESS;
> DebugPrint((1,“WatchDogTimer\n”));
>
> StorPortNotification(RequestComplete,DeviceExtension,DeviceExtension->PSrbTemp);
>
> }
>
>
> On Thu, Feb 23, 2012 at 10:42 PM, Marvin Zhang wrote:
>
>> Hi Mark,
>> I’m sorry that I can’t put the code on here because it contain some
>> algorithm of my client.
>> I made a experiment that I complete the SRB twice intently and I got the
>> similar error. But I checked my code and I think I didn’t complete the SRB
>> twice. Is there any possible that OS complete it after time out? I check
>> the TimeOutValue filed in SRB when I received and the value is 60. Does it
>> mean it will be timeout after 60 seconds? I can make sure that I complete
>> it in 60 seconds.
>> Marvin
>>
>>
>> On Thu, Feb 23, 2012 at 11:44 AM, Mark Roddy wrote:
>>
>>> Well then you’ve done something else grossly wrong. Obviously. Perhaps
>>> some code would help.
>>>
>>> Mark Roddy
>>>
>>>
>>>
>>> On Wed, Feb 22, 2012 at 9:38 PM, Marvin Zhang wrote:
>>> > Hi Mark,
>>> > Yes. I set the SrbStatus field of SRB as SRB_STATUS_SUCCESS and then
>>> > complete it. Is there any other fields which I need to update?
>>> > Marvin
>>> >
>>> >
>>> > On Thu, Feb 23, 2012 at 12:24 AM, Mark Cariddi
>>> wrote:
>>> >>
>>> >> Did you put a completion status in the SRB before you completed it?
>>> >>
>>> >>
>>> >>
>>> >> --Mark Cariddi
>>> >>
>>> >> OSR Open Systems Resources, Inc.
>>> >>
>>> >>
>>> >>
>>> >> From: xxxxx@lists.osr.com
>>> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
>>> >> Sent: Wednesday, February 22, 2012 11:18 AM
>>> >> To: Windows System Software Devs Interest List
>>> >> Subject: [ntdev] What would happen if complete the SRB after timeout?
>>> >>
>>> >>
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I’m writing a StorPort driver now. When I receive a READ SRB I just
>>> put it
>>> >> in a queue. After I got the interrupt, I insert a DPC. Then in DPC
>>> routine,
>>> >> I put out this SRB from the queue and complete the SRB by using
>>> >>
>>> >> StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
>>> >>
>>> >> However, after a very short time, the system will BSOD(The problem
>>> doesn’t
>>> >> result in my driver call stack). If I get rid of this code( I
>>> >> mean StorPortNotification), system will not BSOD. I think system will
>>> >> complete it automatically after timeout. So I doubt that system has
>>> already
>>> >> complete it before I complete it. What would happen if I complete the
>>> SRB
>>> >> twice? I know that it’s very bad error if I complete the IRP twice.
>>> The
>>> >> below is the analysis from windbg:
>>> >>
>>> >>
>>> >>
>>> >> 0: kd> !analyze -v
>>> >>
>>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>>> >> Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
>>> >>
>>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>>> >> Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
>>> >>
>>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>>> >> Kits\8.0\Debuggers\x64\triage\user.ini, error 2
>>> >>
>>> >> Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491
>>> 2012
>>> >> (UTC + 8:00)), ptr64 TRUE
>>> >>
>>> >> Loading Kernel Symbols
>>> >>
>>> >> …
>>> >>
>>> >> …
>>> >>
>>> >> …
>>> >>
>>> >> Loading User Symbols
>>> >>
>>> >>
>>> >>
>>> >> Loading unloaded module list
>>> >>
>>> >> …Unable to enumerate user-mode unloaded modules, Win32 error
>>> 0n30
>>> >>
>>> >>
>>> >>
>>> *****
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> * 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: 0000000000000002, IRQL
>>> >>
>>> >> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
>>> >>
>>> >> Arg4: 0000000000000000, address which referenced memory
>>> >>
>>> >>
>>> >>
>>> >> Debugging Details:
>>> >>
>>> >> ------------------
>>> >>
>>> >>
>>> >>
>>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>>> >> Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
>>> >>
>>> >>
>>> >>
>>> >> READ_ADDRESS: 0000000000000000
>>> >>
>>> >>
>>> >>
>>> >> CURRENT_IRQL: 2
>>> >>
>>> >>
>>> >>
>>> >> FAULTING_IP:
>>> >>
>>> >> +0
>>> >>
>>> >> 0000000000000000 ?? ??? >>> >> >>> >> >>> >> >>> >> PROCESS_NAME: System >>> >> >>> >> >>> >> >>> >> DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT >>> >> >>> >> >>> >> >>> >> BUGCHECK_STR: 0xD1 >>> >> >>> >> >>> >> >>> >> TRAP_FRAME: fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0) >>> >> >>> >> NOTE: The trap frame does not contain all registers. >>> >> >>> >> Some register values may be zeroed or incorrect. >>> >> >>> >> rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10 >>> >> >>> >> rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000 >>> >> >>> >> rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0 >>> >> >>> >> r8=fffffa8005807d30 r9=0000000000000000 r10=fffffa8003f716e0 >>> >> >>> >> r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000 >>> >> >>> >> r14=0000000000000000 r15=0000000000000000 >>> >> >>> >> iopl=0 nv up ei ng nz na po nc >>> >> >>> >> 0000000000000000 ?? ???
>>> >>
>>> >> Resetting default scope
>>> >>
>>> >>
>>> >>
>>> >> LAST_CONTROL_TRANSFER: from fffff800027bf3c2 to fffff800026c0620
>>> >>
>>> >>
>>> >>
>>> >> FAILED_INSTRUCTION_ADDRESS:
>>> >>
>>> >> +0
>>> >>
>>> >> 0000000000000000 ?? ??? >>> >> >>> >> >>> >> >>> >> STACK_TEXT: >>> >> >>> >> fffff80000b9cc48 fffff880010678d3 : 000000000000002a
>>> 0000000000000000 >>> >> 00000000ffffffed 000002f6daf4378d : 0x0 >>> >> >>> >> fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80
>>> fffffa8000000000 >>> >> fffffa8003f71578 0000000000000000 : >>> storport!RaidpAdapterDpcRoutine+0x53 >>> >> >>> >> fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80
>>> fffff80002850c40 >>> >> 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc >>> >> >>> >> fffff80000b9cd40 0000000000000000 : fffff80000b9d000
>>> fffff80000b97000 >>> >> fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> STACK_COMMAND: .trap 0xfffff80000b9cab0 ; kb >>> >> >>> >> >>> >> >>> >> FOLLOWUP_IP: >>> >> >>> >> storport!RaidpAdapterDpcRoutine+53 >>> >> >>> >> fffff880010678d3 ff442448 inc dword ptr [rsp+48h]
>>> >>
>>> >>
>>> >>
>>> >> SYMBOL_STACK_INDEX: 1
>>> >>
>>> >>
>>> >>
>>> >> SYMBOL_NAME: storport!RaidpAdapterDpcRoutine+53
>>> >>
>>> >>
>>> >>
>>> >> FOLLOWUP_NAME: MachineOwner
>>> >>
>>> >>
>>> >>
>>> >> MODULE_NAME: storport
>>> >>
>>> >>
>>> >>
>>> >> IMAGE_NAME: storport.sys
>>> >>
>>> >>
>>> >>
>>> >> DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a403
>>> >>
>>> >>
>>> >>
>>> >> FAILURE_BUCKET_ID:
>>> >> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>>> >>
>>> >>
>>> >>
>>> >> BUCKET_ID:
>>> X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>>> >>
>>> >>
>>> >>
>>> >> Followup: MachineOwner
>>> >>
>>> >> ---------
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Marvin
>>> >>
>>> >> — 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
>>> >>
>>> >>
>>> >> —
>>> >> 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
>>> >
>>> >
>>> > — 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
>>>
>>> —
>>> 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
>>>
>>
>>
>

Mark_Roddy · February 23, 2012, 6:04pm

Storport will only complete the SRBs that it owns - i.e. ones that it
has queued on its own queues waiting to be given to your miniport. It
will not time out the ones that you own - SRBs that you accepted in
your startio routine and that you have either out on the hardware or
queued internally.

I think the most reasonable explanation is that you are completing the
same srb twice because of a coding error. Storport works rather well
these days.

Mark Roddy

On Thu, Feb 23, 2012 at 9:42 AM, Marvin Zhang wrote:
> Hi Mark,
> I’m sorry that I can’t put the code on here because it contain some
> algorithm of my client.
> I made a experiment that I complete the SRB twice intently and I got the
> similar error. But I checked my code and I think I didn’t complete the SRB
> twice. Is there any possible that OS complete it after time out? I check
> the?TimeOutValue filed in SRB when I received and the value is 60. Does it
> mean it will be timeout after 60 seconds? I can make sure that I complete it
> in 60 seconds.
> Marvin
>
>
> On Thu, Feb 23, 2012 at 11:44 AM, Mark Roddy wrote:
>>
>> Well then you’ve done something else grossly wrong. Obviously. Perhaps
>> some code would help.
>>
>> Mark Roddy
>>
>>
>>
>> On Wed, Feb 22, 2012 at 9:38 PM, Marvin Zhang wrote:
>> > Hi Mark,
>> > Yes. I set the SrbStatus field of SRB as SRB_STATUS_SUCCESS and then
>> > complete it. Is there any other fields which I need to update?
>> > Marvin
>> >
>> >
>> > On Thu, Feb 23, 2012 at 12:24 AM, Mark Cariddi wrote:
>> >>
>> >> Did you put a completion status in the SRB before you completed it?
>> >>
>> >>
>> >>
>> >> --Mark Cariddi
>> >>
>> >> OSR Open Systems Resources, Inc.
>> >>
>> >>
>> >>
>> >> From: xxxxx@lists.osr.com
>> >> [mailto:xxxxx@lists.osr.com] On Behalf Of Marvin Zhang
>> >> Sent: Wednesday, February 22, 2012 11:18 AM
>> >> To: Windows System Software Devs Interest List
>> >> Subject: [ntdev] What would happen if complete the SRB after timeout?
>> >>
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> I’m writing a StorPort driver now. When I receive a READ SRB I just put
>> >> it
>> >> in a queue. After I got the interrupt, I insert a DPC. Then in DPC
>> >> routine,
>> >> I put out this SRB from the queue and complete the SRB by using
>> >>
>> >> StorPortNotification( RequestComplete, DeviceExtension, pCurrentSrb );
>> >>
>> >> However, after a very short time, the system will BSOD(The problem
>> >> doesn’t
>> >> result in my driver call stack). ?If I get rid of this code( I
>> >> mean?StorPortNotification), system will not BSOD. I think system will
>> >> complete it?automatically after timeout. So I doubt that system has
>> >> already
>> >> complete it before I complete it. What would happen if I complete the
>> >> SRB
>> >> twice? I know that it’s??very bad error if I complete the IRP twice.
>> >> The
>> >> below is the analysis from windbg:
>> >>
>> >>
>> >>
>> >> 0: kd> !analyze -v
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\triage\oca.ini, error 2
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\winxp\triage.ini, error 2
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\triage\user.ini, error 2
>> >>
>> >> Connected to Windows 7 7600 x64 target at (Thu Feb 23 00:06:19.491 2012
>> >> (UTC + 8:00)), ptr64 TRUE
>> >>
>> >> Loading Kernel Symbols
>> >>
>> >> …
>> >>
>> >> …
>> >>
>> >> …
>> >>
>> >> Loading User Symbols
>> >>
>> >>
>> >>
>> >> Loading unloaded module list
>> >>
>> >> …Unable to enumerate user-mode unloaded modules, Win32 error 0n30
>> >>
>> >>
>> >>
>> >> ***
>> >>
>> >>
>> >> ? ?
>> >>
>> >> * ? ? ? ? ? ? ? ? ? ? ? ?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: 0000000000000002, IRQL
>> >>
>> >> Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
>> >>
>> >> Arg4: 0000000000000000, address which referenced memory
>> >>
>> >>
>> >>
>> >> Debugging Details:
>> >>
>> >> ------------------
>> >>
>> >>
>> >>
>> >> TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows
>> >> Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
>> >>
>> >>
>> >>
>> >> READ_ADDRESS: ?0000000000000000
>> >>
>> >>
>> >>
>> >> CURRENT_IRQL: ?2
>> >>
>> >>
>> >>
>> >> FAULTING_IP:
>> >>
>> >> +0
>> >>
>> >> 0000000000000000 ?? ? ? ? ? ? ? ???? >> >> >> >> >> >> >> >> PROCESS_NAME: ?System >> >> >> >> >> >> >> >> DEFAULT_BUCKET_ID: ?WIN7_DRIVER_FAULT >> >> >> >> >> >> >> >> BUGCHECK_STR: ?0xD1 >> >> >> >> >> >> >> >> TRAP_FRAME: ?fffff80000b9cab0 -- (.trap 0xfffff80000b9cab0) >> >> >> >> NOTE: The trap frame does not contain all registers. >> >> >> >> Some register values may be zeroed or incorrect. >> >> >> >> rax=fffffa8005807d30 rbx=0000000000000000 rcx=fffffa8005807d10 >> >> >> >> rdx=fffffa8005807d10 rsi=0000000000000000 rdi=0000000000000000 >> >> >> >> rip=0000000000000000 rsp=fffff80000b9cc48 rbp=fffffa8003f714b0 >> >> >> >> ?r8=fffffa8005807d30 ?r9=0000000000000000 r10=fffffa8003f716e0 >> >> >> >> r11=fffffa8005807d30 r12=0000000000000000 r13=0000000000000000 >> >> >> >> r14=0000000000000000 r15=0000000000000000 >> >> >> >> iopl=0 ? ? ? ? nv up ei ng nz na po nc >> >> >> >> 0000000000000000 ?? ? ? ? ? ? ? ???
>> >>
>> >> Resetting default scope
>> >>
>> >>
>> >>
>> >> LAST_CONTROL_TRANSFER: ?from fffff800027bf3c2 to fffff800026c0620
>> >>
>> >>
>> >>
>> >> FAILED_INSTRUCTION_ADDRESS:
>> >>
>> >> +0
>> >>
>> >> 0000000000000000 ?? ? ? ? ? ? ? ???? >> >> >> >> >> >> >> >> STACK_TEXT: >> >> >> >> fffff80000b9cc48 fffff880010678d3 : 000000000000002a
>> >> 0000000000000000 >> >> 00000000ffffffed 000002f6daf4378d : 0x0 >> >> >> >> fffff80000b9cc50 fffff800026d3a9c : fffff80002842e80
>> >> fffffa8000000000 >> >> fffffa8003f71578 0000000000000000 : >> >> storport!RaidpAdapterDpcRoutine+0x53 >> >> >> >> fffff80000b9cc90 fffff800026d0d8a : fffff80002842e80
>> >> fffff80002850c40 >> >> 0000000000000000 fffff88001067880 : nt!KiRetireDpcList+0x1bc >> >> >> >> fffff80000b9cd40 0000000000000000 : fffff80000b9d000
>> >> fffff80000b97000 >> >> fffff80000b9cd00 0000000000000000 : nt!KiIdleLoop+0x5a >> >> >> >> >> >> >> >> >> >> >> >> STACK_COMMAND: ?.trap 0xfffff80000b9cab0 ; kb >> >> >> >> >> >> >> >> FOLLOWUP_IP: >> >> >> >> storport!RaidpAdapterDpcRoutine+53 >> >> >> >> fffff880010678d3 ff442448 ? ? ? ?inc ? ? dword ptr [rsp+48h]
>> >>
>> >>
>> >>
>> >> SYMBOL_STACK_INDEX: ?1
>> >>
>> >>
>> >>
>> >> SYMBOL_NAME: ?storport!RaidpAdapterDpcRoutine+53
>> >>
>> >>
>> >>
>> >> FOLLOWUP_NAME: ?MachineOwner
>> >>
>> >>
>> >>
>> >> MODULE_NAME: storport
>> >>
>> >>
>> >>
>> >> IMAGE_NAME: ?storport.sys
>> >>
>> >>
>> >>
>> >> DEBUG_FLR_IMAGE_TIMESTAMP: ?4d79a403
>> >>
>> >>
>> >>
>> >> FAILURE_BUCKET_ID:
>> >> ?X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>> >>
>> >>
>> >>
>> >> BUCKET_ID: ?X64_0xD1_CODE_AV_NULL_IP_storport!RaidpAdapterDpcRoutine+53
>> >>
>> >>
>> >>
>> >> Followup: MachineOwner
>> >>
>> >> ---------
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Marvin
>> >>
>> >> — 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
>> >>
>> >>
>> >> —
>> >> 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
>> >
>> >
>> > — 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
>>
>> —
>> 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
>
>
> — 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

Girish_Basrur · February 26, 2012, 10:25pm

@Mark:

I thought Storport does timeout the SRBs accepted by the miniport driver in the StartIo routine but not completed within the value specified in Srb->TimeOutValue by issuing a hierarchical reset after the timeout period. Is my understanding incorrect?

Girish Basrur.

OSR_Community_User · February 26, 2012, 10:33pm

I think it will complete SRB after timeout if there is nobody complete it.

On Mon, Feb 27, 2012 at 11:28 AM, wrote:

> @Mark:
> > > > > >
> I thought Storport does timeout the SRBs accepted by the miniport driver
> in the StartIo routine but not completed within the value specified in
> Srb->TimeOutValue by issuing a hierarchical reset after the timeout period.
> Is my understanding incorrect?
>
> Girish Basrur.
>
>
>
> —
> 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
>