Help in debugging needed

NTDEV
1

Hi All
I need help in debugging this crash :
The system is W2K-SP4 the driver is for a USB device. It crashes during
surprise removal.

BugCheck D1, {b4214fea, 2, 0, eb1e1480}

Probably caused by : foobarc.sys ( foobarc!DumpURB+20 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
804582f4 cc int 3
0: 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: b4214fea, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: eb1e1480, address which referenced memory

Debugging Details:

READ_ADDRESS: b4214fea Special pool

CURRENT_IRQL: 2

FAULTING_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: Idle

TRAP_FRAME: 80475b28 -- (.trap ffffffff80475b28)
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=????
Resetting default scope

LAST_CONTROL_TRANSFER: from 8042bf89 to 804582f4

STACK_TEXT:
80475750 8042bf89 00000003 80475798 b4214fea
nt!RtlpBreakWithStatusInstruction
80475780 8042c57c 00000003 b4214fea eb1e1480 nt!KiBugCheckDebugBreak+0x31
80475b0c 8046b12c 00000000 b4214fea 00000002 nt!KeBugCheckEx+0x390
80475b0c eb1e1480 00000000 b4214fea 00000002 nt!KiTrap0E+0x210
80475c74 eb1e1daf 85a1ee78 b4214fe8 00000001 foobarc!DumpURB+0x20
[c:\foobar\foobarc\driverentry.c @ 531]
80475ca0 8052d7e6 85a1edc0 b4218eb8 000009f3
foobarc!InternalIOCTLCompletion+0x6f [c:\foobar\foobarc\driverentry.c @
1271]
80475cec f71e53ef 85d07028 f71e8f3a 85c0b030
nt!IovSpecialIrpCompleteRequest+0x18c
80475cf4 f71e8f3a 85c0b030 b4218eb8 c00002b6
USBPORT!USBPORT_CompleteIrp+0x29
80475d3c f71e8ac9 85d070e0 85d070ec 00000000
USBPORT!USBPORT_BadRequestFlush+0x1ae
80475d60 80433b90 85d076a8 85d07028 822bcb6c
USBPORT!USBPORT_DM_TimerDpc+0x14b
80475e60 80433a76 80471c70 ffdff848 ffdff000 nt!KiTimerListExpire+0x112
80475e8c 804676b8 80485580 00000000 000021bd nt!KiTimerExpiration+0xb6
80475ea4 80467610 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
80475ea8 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

FAULTING_SOURCE_CODE:
527: KdPrint(("URB == NULL!?\n"));
528: }
529: else
530: {

531: USHORT wFunction = pUrb->UrbHeader.Function;
532: USHORT wLength = pUrb->UrbHeader.Length;
533: USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
534:
535: switch(wFunction)
536: {

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: foobarc

IMAGE_NAME: foobarc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46935c2f

SYMBOL_NAME: foobarc!DumpURB+20

FAILURE_BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

Followup: MachineOwner

0: kd> .trap ffffffff80475b28
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=????

2

So is b4214fea valid and is it paged pool or non-paged pool?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of driver developer
Sent: Tuesday, July 10, 2007 6:53 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help in debugging needed

Hi All

I need help in debugging this crash :

The system is W2K-SP4 the driver is for a USB device. It crashes during
surprise removal.

BugCheck D1, {b4214fea, 2, 0, eb1e1480}

Probably caused by : foobarc.sys ( foobarc!DumpURB+20 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
804582f4 cc int 3
0: 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: b4214fea, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: eb1e1480, address which referenced memory

Debugging Details:

READ_ADDRESS: b4214fea Special pool

CURRENT_IRQL: 2

FAULTING_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: Idle

TRAP_FRAME: 80475b28 -- (.trap ffffffff80475b28)
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=????
Resetting default scope

LAST_CONTROL_TRANSFER: from 8042bf89 to 804582f4

STACK_TEXT:
80475750 8042bf89 00000003 80475798 b4214fea
nt!RtlpBreakWithStatusInstruction
80475780 8042c57c 00000003 b4214fea eb1e1480
nt!KiBugCheckDebugBreak+0x31
80475b0c 8046b12c 00000000 b4214fea 00000002 nt!KeBugCheckEx+0x390
80475b0c eb1e1480 00000000 b4214fea 00000002 nt!KiTrap0E+0x210
80475c74 eb1e1daf 85a1ee78 b4214fe8 00000001 foobarc!DumpURB+0x20
[c:\foobar\foobarc\driverentry.c @ 531]
80475ca0 8052d7e6 85a1edc0 b4218eb8 000009f3
foobarc!InternalIOCTLCompletion+0x6f [c:\foobar\foobarc\driverentry.c @
1271]
80475cec f71e53ef 85d07028 f71e8f3a 85c0b030
nt!IovSpecialIrpCompleteRequest+0x18c
80475cf4 f71e8f3a 85c0b030 b4218eb8 c00002b6
USBPORT!USBPORT_CompleteIrp+0x29
80475d3c f71e8ac9 85d070e0 85d070ec 00000000
USBPORT!USBPORT_BadRequestFlush+0x1ae
80475d60 80433b90 85d076a8 85d07028 822bcb6c
USBPORT!USBPORT_DM_TimerDpc+0x14b
80475e60 80433a76 80471c70 ffdff848 ffdff000 nt!KiTimerListExpire+0x112
80475e8c 804676b8 80485580 00000000 000021bd nt!KiTimerExpiration+0xb6
80475ea4 80467610 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
80475ea8 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

FAULTING_SOURCE_CODE:
527: KdPrint(("URB == NULL!?\n"));
528: }
529: else
530: {

531: USHORT wFunction = pUrb->UrbHeader.Function;
532: USHORT wLength = pUrb-> UrbHeader.Length;
533: USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
534:
535: switch(wFunction)
536: {

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: foobarc

IMAGE_NAME: foobarc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46935c2f

SYMBOL_NAME: foobarc!DumpURB+20

FAILURE_BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

Followup: MachineOwner

0: kd> .trap ffffffff80475b28
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=????

--- Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
ListServer/Forum

3

what is ur mem alloc like? from paged pool or non paged?

amitr0

On 7/10/07, driver developer wrote:
>
>
> Hi All
> I need help in debugging this crash :
> The system is W2K-SP4 the driver is for a USB device. It crashes during
> surprise removal.
>
> BugCheck D1, {b4214fea, 2, 0, eb1e1480}
>
> Probably caused by : foobarc.sys ( foobarc!DumpURB+20 )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804582f4 cc int 3
> 0: 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: b4214fea, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: eb1e1480, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: b4214fea Special pool
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> PROCESS_NAME: Idle
>
> TRAP_FRAME: 80475b28 – (.trap ffffffff80475b28)
> ErrCode = 00000000
> eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
> edi=b4218fd4
> eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> foobarc!DumpURB+0x20:
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
> ds:0023:b4214fea=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 8042bf89 to 804582f4
>
> STACK_TEXT:
> 80475750 8042bf89 00000003 80475798 b4214fea
> nt!RtlpBreakWithStatusInstruction
> 80475780 8042c57c 00000003 b4214fea eb1e1480 nt!KiBugCheckDebugBreak+0x31
> 80475b0c 8046b12c 00000000 b4214fea 00000002 nt!KeBugCheckEx+0x390
> 80475b0c eb1e1480 00000000 b4214fea 00000002 nt!KiTrap0E+0x210
> 80475c74 eb1e1daf 85a1ee78 b4214fe8 00000001 foobarc!DumpURB+0x20
> [c:\foobar\foobarc\driverentry.c @ 531]
> 80475ca0 8052d7e6 85a1edc0 b4218eb8 000009f3
> foobarc!InternalIOCTLCompletion+0x6f [c:\foobar\foobarc\driverentry.c @
> 1271]
> 80475cec f71e53ef 85d07028 f71e8f3a 85c0b030
> nt!IovSpecialIrpCompleteRequest+0x18c
> 80475cf4 f71e8f3a 85c0b030 b4218eb8 c00002b6
> USBPORT!USBPORT_CompleteIrp+0x29
> 80475d3c f71e8ac9 85d070e0 85d070ec 00000000
> USBPORT!USBPORT_BadRequestFlush+0x1ae
> 80475d60 80433b90 85d076a8 85d07028 822bcb6c
> USBPORT!USBPORT_DM_TimerDpc+0x14b
> 80475e60 80433a76 80471c70 ffdff848 ffdff000 nt!KiTimerListExpire+0x112
> 80475e8c 804676b8 80485580 00000000 000021bd nt!KiTimerExpiration+0xb6
> 80475ea4 80467610 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
> 80475ea8 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
>
> FAULTING_SOURCE_CODE:
> 527: KdPrint((“URB == NULL!?\n”));
> 528: }
> 529: else
> 530: {
> > 531: USHORT wFunction = pUrb->UrbHeader.Function;
> 532: USHORT wLength = pUrb-> UrbHeader.Length;
> 533: USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
> 534:
> 535: switch(wFunction)
> 536: {
>
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: foobarc
>
> IMAGE_NAME: foobarc.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 46935c2f
>
> SYMBOL_NAME: foobarc!DumpURB+20
>
> FAILURE_BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20
>
> BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20
>
> Followup: MachineOwner
> ---------
>
> 0: kd> .trap ffffffff80475b28
> ErrCode = 00000000
> eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
> edi=b4218fd4
> eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> foobarc!DumpURB+0x20:
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
> ds:0023:b4214fea=???
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

–

- amitr0

4

It’s special pool, I think. How are you allocating the URB? Please
post the code for the whole function.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Tuesday, July 10, 2007 09:30
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help in debugging needed

what is ur mem alloc like? from paged pool or non paged?

amitr0

On 7/10/07, driver developer wrote:

Hi All

I need help in debugging this crash :

The system is W2K-SP4 the driver is for a USB device. It crashes during
surprise removal.

BugCheck D1, {b4214fea, 2, 0, eb1e1480}

Probably caused by : foobarc.sys ( foobarc!DumpURB+20 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
804582f4 cc int 3
0: 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: b4214fea, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: eb1e1480, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: b4214fea Special pool

CURRENT_IRQL: 2

FAULTING_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: Idle

TRAP_FRAME: 80475b28 – (.trap ffffffff80475b28)
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 8042bf89 to 804582f4

STACK_TEXT:
80475750 8042bf89 00000003 80475798 b4214fea
nt!RtlpBreakWithStatusInstruction
80475780 8042c57c 00000003 b4214fea eb1e1480
nt!KiBugCheckDebugBreak+0x31
80475b0c 8046b12c 00000000 b4214fea 00000002 nt!KeBugCheckEx+0x390
80475b0c eb1e1480 00000000 b4214fea 00000002 nt!KiTrap0E+0x210
80475c74 eb1e1daf 85a1ee78 b4214fe8 00000001 foobarc!DumpURB+0x20
[c:\foobar\foobarc\driverentry.c @ 531]
80475ca0 8052d7e6 85a1edc0 b4218eb8 000009f3
foobarc!InternalIOCTLCompletion+0x6f [c:\foobar\foobarc\driverentry.c @
1271]
80475cec f71e53ef 85d07028 f71e8f3a 85c0b030
nt!IovSpecialIrpCompleteRequest+0x18c
80475cf4 f71e8f3a 85c0b030 b4218eb8 c00002b6
USBPORT!USBPORT_CompleteIrp+0x29
80475d3c f71e8ac9 85d070e0 85d070ec 00000000
USBPORT!USBPORT_BadRequestFlush+0x1ae
80475d60 80433b90 85d076a8 85d07028 822bcb6c
USBPORT!USBPORT_DM_TimerDpc+0x14b
80475e60 80433a76 80471c70 ffdff848 ffdff000 nt!KiTimerListExpire+0x112
80475e8c 804676b8 80485580 00000000 000021bd nt!KiTimerExpiration+0xb6
80475ea4 80467610 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
80475ea8 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

FAULTING_SOURCE_CODE:
527: KdPrint((“URB == NULL!?\n”));
528: }
529: else
530: {
> 531: USHORT wFunction = pUrb->UrbHeader.Function;
532: USHORT wLength = pUrb-> UrbHeader.Length;
533: USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
534:
535: switch(wFunction)
536: {

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: foobarc

IMAGE_NAME: foobarc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46935c2f

SYMBOL_NAME: foobarc!DumpURB+20

FAILURE_BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

Followup: MachineOwner
---------

0: kd> .trap ffffffff80475b28
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=???

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–

- amitr0 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

I had turned Special Pool on in Driver Verifier.The driver is a lower filter
driver for usbhub.sys.
The driver does not crash always on surprise removal.
I used NonPagedPool .

At this moment of crash this memory is invalid.
kd> dd b4214fea
b4214fea ??? ??? ??? ???

The completion routine is as follows :

NTSTATUS InternalIOCTLCompletion(IN PDEVICE_OBJECT fido, IN PIRP Irp, IN
PVOID Context)

{

ULONG uSequenceNumber;

ULONG dwControlCode;

PURB pUrb;

PUSB_DEVICE_EXTENSION pDevExt;

PIO_STACK_LOCATION stack;

pDevExt = (PUSB_DEVICE_EXTENSION) fido->DeviceExtension;

stack = IoGetCurrentIrpStackLocation(Irp);

if (Irp->PendingReturned) {

IoMarkIrpPending( Irp );

}

uSequenceNumber = (ULONG)Context;

dwControlCode = stack->Parameters.DeviceIoControl.IoControlCode;

if(IOCTL_INTERNAL_USB_SUBMIT_URB == dwControlCode)

{

pUrb = (PURB)stack->Parameters.Others.Argument1;

DumpURB( pDevExt,pUrb, TRUE, uSequenceNumber);

}

return STATUS_SUCCESS;

}

On 7/10/07, Martin O’Brien wrote:
>
> It’s special pool, I think. How are you allocating the URB? Please post
> the code for the whole function.
>
>
>
>
>
> mm
>
>
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *amitr0
> Sent: Tuesday, July 10, 2007 09:30
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Help in debugging needed
>
>
>
> what is ur mem alloc like? from paged pool or non paged?
>
>
>
>
>
> amitr0
>
>
>
>
>
>
>
> On 7/10/07, driver developer wrote:
>
>
>
> Hi All
>
> I need help in debugging this crash :
>
> The system is W2K-SP4 the driver is for a USB device. It crashes during
> surprise removal.
>
>
> BugCheck D1, {b4214fea, 2, 0, eb1e1480}
>
> Probably caused by : foobarc.sys ( foobarc!DumpURB+20 )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804582f4 cc int 3
> 0: 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: b4214fea, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: eb1e1480, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: b4214fea Special pool
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> PROCESS_NAME: Idle
>
> TRAP_FRAME: 80475b28 – (.trap ffffffff80475b28)
> ErrCode = 00000000
> eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
> edi=b4218fd4
> eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> foobarc!DumpURB+0x20:
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
> ds:0023:b4214fea=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 8042bf89 to 804582f4
>
> STACK_TEXT:
> 80475750 8042bf89 00000003 80475798 b4214fea
> nt!RtlpBreakWithStatusInstruction
> 80475780 8042c57c 00000003 b4214fea eb1e1480 nt!KiBugCheckDebugBreak+0x31
> 80475b0c 8046b12c 00000000 b4214fea 00000002 nt!KeBugCheckEx+0x390
> 80475b0c eb1e1480 00000000 b4214fea 00000002 nt!KiTrap0E+0x210
> 80475c74 eb1e1daf 85a1ee78 b4214fe8 00000001 foobarc!DumpURB+0x20
> [c:\foobar\foobarc\driverentry.c @ 531]
> 80475ca0 8052d7e6 85a1edc0 b4218eb8 000009f3
> foobarc!InternalIOCTLCompletion+0x6f [c:\foobar\foobarc\driverentry.c @
> 1271]
> 80475cec f71e53ef 85d07028 f71e8f3a 85c0b030
> nt!IovSpecialIrpCompleteRequest+0x18c
> 80475cf4 f71e8f3a 85c0b030 b4218eb8 c00002b6
> USBPORT!USBPORT_CompleteIrp+0x29
> 80475d3c f71e8ac9 85d070e0 85d070ec 00000000
> USBPORT!USBPORT_BadRequestFlush+0x1ae
> 80475d60 80433b90 85d076a8 85d07028 822bcb6c
> USBPORT!USBPORT_DM_TimerDpc+0x14b
> 80475e60 80433a76 80471c70 ffdff848 ffdff000 nt!KiTimerListExpire+0x112
> 80475e8c 804676b8 80485580 00000000 000021bd nt!KiTimerExpiration+0xb6
> 80475ea4 80467610 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
> 80475ea8 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
>
> FAULTING_SOURCE_CODE:
> 527: KdPrint((“URB == NULL!?\n”));
> 528: }
> 529: else
> 530: {
> > 531: USHORT wFunction = pUrb->UrbHeader.Function;
> 532: USHORT wLength = pUrb-> UrbHeader.Length;
> 533: USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
> 534:
> 535: switch(wFunction)
> 536: {
>
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: foobarc
>
> IMAGE_NAME: foobarc.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 46935c2f
>
> SYMBOL_NAME: foobarc!DumpURB+20
>
> FAILURE_BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20
>
> BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20
>
> Followup: MachineOwner
> ---------
>
> 0: kd> .trap ffffffff80475b28
> ErrCode = 00000000
> eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
> edi=b4218fd4
> eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010286
> foobarc!DumpURB+0x20:
> eb1e1480 668b4802 mov cx,word ptr [eax+2]
> ds:0023:b4214fea=???
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> –
>
> - amitr0 — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

6

What about the rest of the function? That is, I don’t see the code that
caused the exception in your second post.

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of driver developer
Sent: Wednesday, July 11, 2007 00:14
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help in debugging needed

I had turned Special Pool on in Driver Verifier.The driver is a lower
filter driver for usbhub.sys.

The driver does not crash always on surprise removal.

I used NonPagedPool .

At this moment of crash this memory is invalid.

kd> dd b4214fea
b4214fea ??? ??? ??? ???

The completion routine is as follows :

NTSTATUS InternalIOCTLCompletion(IN PDEVICE_OBJECT fido, IN PIRP Irp, IN
PVOID Context)

{

ULONG uSequenceNumber;

ULONG dwControlCode;

PURB pUrb;

PUSB_DEVICE_EXTENSION pDevExt;

PIO_STACK_LOCATION stack;

pDevExt = (PUSB_DEVICE_EXTENSION) fido->DeviceExtension;

stack = IoGetCurrentIrpStackLocation(Irp);

if (Irp->PendingReturned) {

IoMarkIrpPending( Irp );

}

uSequenceNumber = (ULONG)Context;

dwControlCode = stack->Parameters.DeviceIoControl.IoControlCode;

if(IOCTL_INTERNAL_USB_SUBMIT_URB == dwControlCode)

{

pUrb = (PURB)stack->Parameters.Others.Argument1;

DumpURB( pDevExt,pUrb, TRUE, uSequenceNumber);

}

return STATUS_SUCCESS;

}

On 7/10/07, Martin O’Brien wrote:

It’s special pool, I think. How are you allocating the URB? Please
post the code for the whole function.

mm

________________________________

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Tuesday, July 10, 2007 09:30
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help in debugging needed

what is ur mem alloc like? from paged pool or non paged?

amitr0

On 7/10/07, driver developer < xxxxx@gmail.com
mailto:xxxxx > wrote:

Hi All

I need help in debugging this crash :

The system is W2K-SP4 the driver is for a USB device. It crashes during
surprise removal.

BugCheck D1, {b4214fea, 2, 0, eb1e1480}

Probably caused by : foobarc.sys ( foobarc!DumpURB+20 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
804582f4 cc int 3
0: 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: b4214fea, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: eb1e1480, address which referenced memory

Debugging Details:
------------------

READ_ADDRESS: b4214fea Special pool

CURRENT_IRQL: 2

FAULTING_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: Idle

TRAP_FRAME: 80475b28 – (.trap ffffffff80475b28)
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=???
Resetting default scope

LAST_CONTROL_TRANSFER: from 8042bf89 to 804582f4

STACK_TEXT:
80475750 8042bf89 00000003 80475798 b4214fea
nt!RtlpBreakWithStatusInstruction
80475780 8042c57c 00000003 b4214fea eb1e1480
nt!KiBugCheckDebugBreak+0x31
80475b0c 8046b12c 00000000 b4214fea 00000002 nt!KeBugCheckEx+0x390
80475b0c eb1e1480 00000000 b4214fea 00000002 nt!KiTrap0E+0x210
80475c74 eb1e1daf 85a1ee78 b4214fe8 00000001 foobarc!DumpURB+0x20
[c:\foobar\foobarc\driverentry.c @ 531]
80475ca0 8052d7e6 85a1edc0 b4218eb8 000009f3
foobarc!InternalIOCTLCompletion+0x6f [c:\foobar\foobarc\driverentry.c @
1271]
80475cec f71e53ef 85d07028 f71e8f3a 85c0b030
nt!IovSpecialIrpCompleteRequest+0x18c
80475cf4 f71e8f3a 85c0b030 b4218eb8 c00002b6
USBPORT!USBPORT_CompleteIrp+0x29
80475d3c f71e8ac9 85d070e0 85d070ec 00000000
USBPORT!USBPORT_BadRequestFlush+0x1ae
80475d60 80433b90 85d076a8 85d07028 822bcb6c
USBPORT!USBPORT_DM_TimerDpc+0x14b
80475e60 80433a76 80471c70 ffdff848 ffdff000 nt!KiTimerListExpire+0x112
80475e8c 804676b8 80485580 00000000 000021bd nt!KiTimerExpiration+0xb6
80475ea4 80467610 0000000e 00000000 00000000 nt!KiRetireDpcList+0x47
80475ea8 00000000 00000000 00000000 00000000 nt!KiIdleLoop+0x28

STACK_COMMAND: kb

FOLLOWUP_IP:
foobarc!DumpURB+20 [c:\foobar\foobarc\driverentry.c @ 531]
eb1e1480 668b4802 mov cx,word ptr [eax+2]

FAULTING_SOURCE_CODE:
527: KdPrint((“URB == NULL!?\n”));
528: }
529: else
530: {
> 531: USHORT wFunction = pUrb-> UrbHeader.Function;
532: USHORT wLength = pUrb-> UrbHeader.Length;
533: USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
534:
535: switch(wFunction)
536: {

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: foobarc

IMAGE_NAME: foobarc.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46935c2f

SYMBOL_NAME: foobarc!DumpURB+20

FAILURE_BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

BUCKET_ID: 0xD1_VRF_foobarc!DumpURB+20

Followup: MachineOwner
---------

0: kd> .trap ffffffff80475b28
ErrCode = 00000000
eax=b4214fe8 ebx=00000000 ecx=000009f3 edx=b4214fe8 esi=b4218eb8
edi=b4218fd4
eip=eb1e1480 esp=80475b9c ebp=80475c74 iopl=0 nv up ei ng nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
foobarc!DumpURB+0x20:
eb1e1480 668b4802 mov cx,word ptr [eax+2]
ds:0023:b4214fea=???

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–

- amitr0 — Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>

7

Er sorry here is the DumpURB Function :
The function is rather big

I noticed that according to WinDbg , it crashes while trying to read
members of the URB
while as you noticed I little above I am checking if URB exists or not.

void DumpURB(PUSB_DEVICE_EXTENSION pDevExt, PURB pUrb, BOOLEAN
bReturnedFromHCD, ULONG uSequenceNumber)
{
PUSBD_INTERFACE_INFORMATION pInterface;
ULONG uNumInterfaces;
ULONG i=0;
ULONG p;
BOOLEAN bReadFromDevice;
int b;

if(NULL == pUrb)
{
KdPrint((“URB == NULL!?\n”));
}
else
{
USHORT wFunction = pUrb->UrbHeader.Function;//<- seems to be
crashing here according toWindbg
USHORT wLength = pUrb-> UrbHeader.Length;
USBD_STATUS lUsbdStatus = pUrb->UrbHeader.Status;
…

8

Just a general guess / suggestion (my 2.8 cents [inflation!] worth).

You crashed in the first place because the address you pulled from the IRP is currently invalid. The address is in special pool, which is good- DV is doing its job, most likely.

I can think of two very likely reasons this happened (my hunch is #2, FWIW, because you MUST have checked #1 already):

(1) You used paged pool for the allocation, and you are now at dispatch level.
(2) You freed the memory before the completion routine executed. IIRC, unlike regular pool, special pool will make the pool page invalid when it is freed and will try to keep that address invalid (eventually I would assume it may have to use the page again, but an LRU mapping strategy would minimize the potential for missing corruption by writing to freed addresses, and I rarely go wrong assuming the guys behind this are at least as clever as I am).

I’d been thinking this for a while, but I’ve not had much time for posts (as I read the original stack, I believe usbport noticed the address was completely invalid as well- but that is also a guess).

So, in a surprise remove scenario would you be freeing an URB without checking to see if it was still being used in an IRP you sent down the stack and hasn’t come back yet?

This code path might eventually try to free the memory, and you would have had a more specific DV bugcheck if it had got there, but all that shows is no feedback mechanism from a verifier can be 100% perfect [IMO].

9

Thanks Bob for your inputs.
My driver is a lower filter for usbhub.sys and I don’t any special
processing on most IRPs. I just either send them down/complete them
.So I dont do any processing for IRP_MN_SURPRISE_REMOVAL
Also I also noticed that a crash does not occur always - only sometimes.
So may be it a subtle race condition.

On 7/12/07, Bob Kjelgaard wrote:
> Just a general guess / suggestion (my 2.8 cents [inflation!] worth).
>
> You crashed in the first place because the address you pulled from the IRP is currently invalid. The address is in special pool, which is good- DV is doing its job, most likely.
>
> I can think of two very likely reasons this happened (my hunch is #2, FWIW, because you MUST have checked #1 already):
>
> (1) You used paged pool for the allocation, and you are now at dispatch level.
> (2) You freed the memory before the completion routine executed. IIRC, unlike regular pool, special pool will make the pool page invalid when it is freed and will try to keep that address invalid (eventually I would assume it may have to use the page again, but an LRU mapping strategy would minimize the potential for missing corruption by writing to freed addresses, and I rarely go wrong assuming the guys behind this are at least as clever as I am).
>
> I’d been thinking this for a while, but I’ve not had much time for posts (as I read the original stack, I believe usbport noticed the address was completely invalid as well- but that is also a guess).
>
> So, in a surprise remove scenario would you be freeing an URB without checking to see if it was still being used in an IRP you sent down the stack and hasn’t come back yet?
>
> This code path might eventually try to free the memory, and you would have had a more specific DV bugcheck if it had got there, but all that shows is no feedback mechanism from a verifier can be 100% perfect [IMO].
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

10

The special pool was allocated by someone [I’ve been assuming it was your driver, and don’t see any reason not to believe so]- allocations don’t come from there by happenstance. A surprise removal *scenario* [which was the word I used] is going to have more than a single IRP. Were open file handles closed as a result? Did a cleanup occur? Did it delete that URB prematurely?

If you do not believe that you allocated the URB, then you can use !irp to see the device objects (and !devobj to see their drivers) for the entire stack- you can also dump all the stack locations remaining if you need to understand the request path [the functions and all relevant parameters are there to be seen]. If it was asynchronous, the outermost location’s completion routine should be in the driver that created the IRP in the first place. Point is, it had to come from somewhere, and that IRP has the history. You should know why special pool was used [which ought to help scope such a search].

Alternatively, you can examine the URBs and IRPs on their way down- knowing what it was that got freed prematurely (if that is indeed the case) might offer clues as to why that happened. Your filtering activities may have caused some other driver to do something unexpected (and it may or may not be a clear bug in either case).

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of driver developer
Sent: Friday, July 13, 2007 2:59 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Help in debugging needed

Thanks Bob for your inputs.
My driver is a lower filter for usbhub.sys and I don’t any special
processing on most IRPs. I just either send them down/complete them
.So I dont do any processing for IRP_MN_SURPRISE_REMOVAL
Also I also noticed that a crash does not occur always - only sometimes.
So may be it a subtle race condition.

On 7/12/07, Bob Kjelgaard wrote:
> Just a general guess / suggestion (my 2.8 cents [inflation!] worth).
>
> You crashed in the first place because the address you pulled from the IRP is currently invalid. The address is in special pool, which is good- DV is doing its job, most likely.
>
> I can think of two very likely reasons this happened (my hunch is #2, FWIW, because you MUST have checked #1 already):
>
> (1) You used paged pool for the allocation, and you are now at dispatch level.
> (2) You freed the memory before the completion routine executed. IIRC, unlike regular pool, special pool will make the pool page invalid when it is freed and will try to keep that address invalid (eventually I would assume it may have to use the page again, but an LRU mapping strategy would minimize the potential for missing corruption by writing to freed addresses, and I rarely go wrong assuming the guys behind this are at least as clever as I am).
>
> I’d been thinking this for a while, but I’ve not had much time for posts (as I read the original stack, I believe usbport noticed the address was completely invalid as well- but that is also a guess).
>
> So, in a surprise remove scenario would you be freeing an URB without checking to see if it was still being used in an IRP you sent down the stack and hasn’t come back yet?
>
> This code path might eventually try to free the memory, and you would have had a more specific DV bugcheck if it had got there, but all that shows is no feedback mechanism from a verifier can be 100% perfect [IMO].