Prev: kbfiltr sample and Windows Vista...
Next: play sound from kernelmode
From: Guenter on 7 Dec 2006 02:54
I read a data stream from a device with a high speed bulk endpoint. Data
rate is 10 MByte/s. I use 4 buffers with 64kbytes of size, overlapped. Buffer
is passed as MDL. This is in the limit recommented by the paper:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q832430

The blue screen occurs rarely on different PC's after hours or days. Here is
the analysis:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (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: 00000060, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f874d4df, address which referenced memory

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


READ_ADDRESS: 00000060

CURRENT_IRQL: 2

FAULTING_IP:
usbehci!EHCI_PollActiveAsyncEndpoint+139
f874d4df ff7660 push dword ptr [esi+0x60]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: 80548c6c -- (.trap ffffffff80548c6c)
ErrCode = 00000000
eax=81f13218 ebx=8197bf30 ecx=8197bfb8 edx=81f13618 esi=00000000 edi=81f13100
eip=f874d4df esp=80548ce0 ebp=80548cf0 iopl=0 nv up ei pl nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
usbehci!EHCI_PollActiveAsyncEndpoint+139:
f874d4df ff7660 push dword ptr [esi+0x60] ds:0023:00000060=????????
Resetting default context

LAST_CONTROL_TRANSFER: from f874d8a6 to f874d4df

STACK_TEXT:
80548cf0 f874d8a6 81e179dc 0197bf30 8197bf30
usbehci!EHCI_PollActiveAsyncEndpoint+0x139
80548d4c f874f3d3 81e179dc 8197bf30 80548d7c
usbehci!EHCI_PollAsyncEndpoint+0x98
80548d5c f7fd92ba 81e179dc 8197bf30 805418a8 usbehci!EHCI_PollEndpoint+0x1f
80548d7c f7fda578 026c6f50 81e170e0 8197bdb8 USBPORT!USBPORT_PollEndpoint+0xe8
80548da4 f7fdded0 81e17028 50457270 805418a8
USBPORT!USBPORT_CoreEndpointWorker+0x2be
80548dd4 f7febfb0 81e17028 805418a8 81e17028 USBPORT!USBPORT_DpcWorker+0x18a
80548e10 f7fec128 81e17028 00000001 80551b80
USBPORT!USBPORT_IsrDpcWorker+0x37e
80548e2c 80540d5d 81e1764c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
80548e50 80540cd6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46


FOLLOWUP_IP:
usbehci!EHCI_PollActiveAsyncEndpoint+139
f874d4df ff7660 push dword ptr [esi+0x60]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: usbehci!EHCI_PollActiveAsyncEndpoint+139

MODULE_NAME: usbehci

IMAGE_NAME: usbehci.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107d62

STACK_COMMAND: .trap ffffffff80548c6c ; kb

BUCKET_ID: 0xD1_usbehci!EHCI_PollActiveAsyncEndpoint+139

Followup: MachineOwner

Thaks for any idea.

Guenter

From: Vetzak on 7 Dec 2006 05:37

You probably pass a null-pointer: faulting address 60h in instruction
push dword ptr [esi+0x60] means esi equals null. Your IRP processing
may be wrong: race condition, forgot to spinlock data, or similar.

Guenter schreef:

> I read a data stream from a device with a high speed bulk endpoint. Data
> rate is 10 MByte/s. I use 4 buffers with 64kbytes of size, overlapped. Buffer
> is passed as MDL. This is in the limit recommented by the paper:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q832430
>
> The blue screen occurs rarely on different PC's after hours or days. Here is
> the analysis:
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pagable (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: 00000060, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f874d4df, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000060
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> usbehci!EHCI_PollActiveAsyncEndpoint+139
> f874d4df ff7660 push dword ptr [esi+0x60]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> TRAP_FRAME: 80548c6c -- (.trap ffffffff80548c6c)
> ErrCode = 00000000
> eax=81f13218 ebx=8197bf30 ecx=8197bfb8 edx=81f13618 esi=00000000 edi=81f13100
> eip=f874d4df esp=80548ce0 ebp=80548cf0 iopl=0 nv up ei pl nz na po cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
> usbehci!EHCI_PollActiveAsyncEndpoint+139:
> f874d4df ff7660 push dword ptr [esi+0x60] ds:0023:00000060=????????
> Resetting default context
>
> LAST_CONTROL_TRANSFER: from f874d8a6 to f874d4df
>
> STACK_TEXT:
> 80548cf0 f874d8a6 81e179dc 0197bf30 8197bf30
> usbehci!EHCI_PollActiveAsyncEndpoint+0x139
> 80548d4c f874f3d3 81e179dc 8197bf30 80548d7c
> usbehci!EHCI_PollAsyncEndpoint+0x98
> 80548d5c f7fd92ba 81e179dc 8197bf30 805418a8 usbehci!EHCI_PollEndpoint+0x1f
> 80548d7c f7fda578 026c6f50 81e170e0 8197bdb8 USBPORT!USBPORT_PollEndpoint+0xe8
> 80548da4 f7fdded0 81e17028 50457270 805418a8
> USBPORT!USBPORT_CoreEndpointWorker+0x2be
> 80548dd4 f7febfb0 81e17028 805418a8 81e17028 USBPORT!USBPORT_DpcWorker+0x18a
> 80548e10 f7fec128 81e17028 00000001 80551b80
> USBPORT!USBPORT_IsrDpcWorker+0x37e
> 80548e2c 80540d5d 81e1764c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
> 80548e50 80540cd6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
>
>
> FOLLOWUP_IP:
> usbehci!EHCI_PollActiveAsyncEndpoint+139
> f874d4df ff7660 push dword ptr [esi+0x60]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: usbehci!EHCI_PollActiveAsyncEndpoint+139
>
> MODULE_NAME: usbehci
>
> IMAGE_NAME: usbehci.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107d62
>
> STACK_COMMAND: .trap ffffffff80548c6c ; kb
>
> BUCKET_ID: 0xD1_usbehci!EHCI_PollActiveAsyncEndpoint+139
>
> Followup: MachineOwner
>
> Thaks for any idea.
>
> Guenter

From: Guenter on 7 Dec 2006 09:29

Hello Vetzak,

Thank you for your answer. The IRP comes from the user mode. It is prepared
by the IO manager. The buffer in the MDL is prepared by the io manager forced
with the flag DO_DIRECT_IO. The synchronization of the driver was checked by
several programmers. It seems to be correct.

I do not understand why the stack frame does not contain my driver.

Thanks
Guenter
"Vetzak" wrote:

>
> You probably pass a null-pointer: faulting address 60h in instruction
> push dword ptr [esi+0x60] means esi equals null. Your IRP processing
> may be wrong: race condition, forgot to spinlock data, or similar.
>
> Guenter schreef:
>
> > I read a data stream from a device with a high speed bulk endpoint. Data
> > rate is 10 MByte/s. I use 4 buffers with 64kbytes of size, overlapped. Buffer
> > is passed as MDL. This is in the limit recommented by the paper:
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q832430
> >
> > The blue screen occurs rarely on different PC's after hours or days. Here is
> > the analysis:
> > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> > An attempt was made to access a pagable (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: 00000060, memory referenced
> > Arg2: 00000002, IRQL
> > Arg3: 00000000, value 0 = read operation, 1 = write operation
> > Arg4: f874d4df, address which referenced memory
> >
> > Debugging Details:
> > ------------------
> >
> >
> > READ_ADDRESS: 00000060
> >
> > CURRENT_IRQL: 2
> >
> > FAULTING_IP:
> > usbehci!EHCI_PollActiveAsyncEndpoint+139
> > f874d4df ff7660 push dword ptr [esi+0x60]
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0xD1
> >
> > TRAP_FRAME: 80548c6c -- (.trap ffffffff80548c6c)
> > ErrCode = 00000000
> > eax=81f13218 ebx=8197bf30 ecx=8197bfb8 edx=81f13618 esi=00000000 edi=81f13100
> > eip=f874d4df esp=80548ce0 ebp=80548cf0 iopl=0 nv up ei pl nz na po cy
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
> > usbehci!EHCI_PollActiveAsyncEndpoint+139:
> > f874d4df ff7660 push dword ptr [esi+0x60] ds:0023:00000060=????????
> > Resetting default context
> >
> > LAST_CONTROL_TRANSFER: from f874d8a6 to f874d4df
> >
> > STACK_TEXT:
> > 80548cf0 f874d8a6 81e179dc 0197bf30 8197bf30
> > usbehci!EHCI_PollActiveAsyncEndpoint+0x139
> > 80548d4c f874f3d3 81e179dc 8197bf30 80548d7c
> > usbehci!EHCI_PollAsyncEndpoint+0x98
> > 80548d5c f7fd92ba 81e179dc 8197bf30 805418a8 usbehci!EHCI_PollEndpoint+0x1f
> > 80548d7c f7fda578 026c6f50 81e170e0 8197bdb8 USBPORT!USBPORT_PollEndpoint+0xe8
> > 80548da4 f7fdded0 81e17028 50457270 805418a8
> > USBPORT!USBPORT_CoreEndpointWorker+0x2be
> > 80548dd4 f7febfb0 81e17028 805418a8 81e17028 USBPORT!USBPORT_DpcWorker+0x18a
> > 80548e10 f7fec128 81e17028 00000001 80551b80
> > USBPORT!USBPORT_IsrDpcWorker+0x37e
> > 80548e2c 80540d5d 81e1764c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
> > 80548e50 80540cd6 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
> >
> >
> > FOLLOWUP_IP:
> > usbehci!EHCI_PollActiveAsyncEndpoint+139
> > f874d4df ff7660 push dword ptr [esi+0x60]
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: usbehci!EHCI_PollActiveAsyncEndpoint+139
> >
> > MODULE_NAME: usbehci
> >
> > IMAGE_NAME: usbehci.sys
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 41107d62
> >
> > STACK_COMMAND: .trap ffffffff80548c6c ; kb
> >
> > BUCKET_ID: 0xD1_usbehci!EHCI_PollActiveAsyncEndpoint+139
> >
> > Followup: MachineOwner
> >
> > Thaks for any idea.
> >
> > Guenter
>
>
From: Vetzak on 8 Dec 2006 05:38

> I do not understand why the stack frame does not contain my driver.

That's because your request is handled in a different thread context,
hence a different stack. Handling of USB transfers happens
asynchronously.

From: Guenter on 13 Dec 2006 04:30
Conclusion:

We have reduced the number of buffers that are used at the same time to one
with a size of 256000 bytes. In this configuration we have running 4 PC in
the last week without blue screen.

I have no final evidence if my driver makes a mistake by passing the
parameters to the USB bus driver, but there is still a little doubt if the
problem may be caused by the EHCI driver.

Thank you for discussion.

Guenter
 | 
Pages: 1
Prev: kbfiltr sample and Windows Vista...
Next: play sound from kernelmode