Bugcheck Analysis IoCompleteRequest

NTDEV
1

hello

any ideea what exactely happens here? i’m writing a minimal uart driver and the crash appears kinda randomly when i increase the baud rate in my tests

thanks

here it is the windbg output

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is: srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 1) UP Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp1_gdr.070304-2232
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a8e48
Debug session time: Sun Apr 22 02:53:14.449 2007 (GMT+3)
System Uptime: 0 days 0:41:50.169
Loading Kernel Symbols
…
Loading User Symbols
…
Loading unloaded module list
…
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {22, 2, 0, 80828cb2}

Probably caused by : uart16550.sys ( uart16550!DpcForIsr+53 )

Followup: MachineOwner

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

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000022, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80828cb2, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000022

CURRENT_IRQL: 2

FAULTING_IP:
nt!IopfCompleteRequest+c
80828cb2 8a4e22 mov cl,byte ptr [esi+22h]

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0xA

PROCESS_NAME: test.exe

TRAP_FRAME: fa026f08 – (.trap fffffffffa026f08)
ErrCode = 00000000
eax=00000001 ebx=f9f60410 ecx=00000000 edx=00000000 esi=00000000 edi=ffdffa40
eip=80828cb2 esp=fa026f7c ebp=fa026f94 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!IopfCompleteRequest+0xc:
80828cb2 8a4e22 mov cl,byte ptr [esi+22h] ds:0023:00000022=??
Resetting default scope

LAST_CONTROL_TRANSFER: from 80828cb2 to 80826493

STACK_TEXT:
fa026f08 80828cb2 badb0d00 00000000 fa026f30 nt!KiTrap0E+0x2a1
fa026f94 f9f60463 81000016 ff42d0e0 fa026ff4 nt!IopfCompleteRequest+0xc
fa026fa4 80828878 ff42d09c ff42d028 00000000 uart16550!DpcForIsr+0x53 [c:\ss\uart16550.c @ 141]
fa026ff4 80820813 f8d5ed54 00000000 00000000 nt!KiRetireDpcList+0xca
fa026ff8 f8d5ed54 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x38
WARNING: Frame IP not in any known module. Following frames may be wrong.
80820813 00000000 0000000a bb835b75 00000128 0xf8d5ed54

STACK_COMMAND: kb

FOLLOWUP_IP:
uart16550!DpcForIsr+53 [c:\ss\uart16550.c @ 141]
f9f60463 eb29 jmp uart16550!DpcForIsr+0x7e (f9f6048e)

FAULTING_SOURCE_CODE:
137: if (context & DPC_FOR_WRITE) {
138: DbgPrint(“dpc for isr write\n”);
139: KeSynchronizeExecution(pDeviceData->pIntObj, IoStartNextPacket_Synch, pDevice);
140: IoCompleteRequest(pIrp, IO_NO_INCREMENT);

141: return ;
142: }
143:
144: if (context & DPC_FOR_READ) {
145: DbgPrint(“dpc for isr read\n”);
146: KeSetEvent(&pDeviceData->RecvBufferNotEmptyEvent, 0, FALSE);

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: uart16550!DpcForIsr+53

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: uart16550

IMAGE_NAME: uart16550.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 462aa3d6

FAILURE_BUCKET_ID: 0xA_uart16550!DpcForIsr+53

BUCKET_ID: 0xA_uart16550!DpcForIsr+53

Followup: MachineOwner

2

Ok, problem solved: the parametter passed to IoCompleteRequest is sometimes null. But the weird thing is that in these cases the DpcForIsr call seems to appear outta nowhere: for a single IoRequestForDpc from the interrupt routine a get two DpcForIsr calls(one with the good pIrp and one with pIrp==null). Any ideea which may be the explanation ?

Thanks!

3

Bad code. When a DPC is scheduled, it is placed in a queue. When a
processor becomes available, the DPC is removed from the queue and another
can be queued anytime after that. Doing queues for DPCs is difficult. Make
sure all accesses to data common between the ISR and DPC is properly
controlled by an interrupt spinlock. Also make sure there is no way you can
process two interrupts from your device that resolve to the same IRP. How
that logic is constructed can contribute to this error. How does the ISR
know what IRP to associate with each invocation? Any chance your hardware
is interrupting two or more times for the same interrupt?

wrote in message news:xxxxx@ntdev…
> Ok, problem solved: the parametter passed to IoCompleteRequest is
> sometimes null. But the weird thing is that in these cases the DpcForIsr
> call seems to appear outta nowhere: for a single IoRequestForDpc from the
> interrupt routine a get two DpcForIsr calls(one with the good pIrp and one
> with pIrp==null). Any ideea which may be the explanation ?
>
> Thanks!
>

4

You pass NULL pIrp to IoCompleteRequest - is it so?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> hello
>
> any ideea what exactely happens here? i’m writing a minimal uart driver and
the crash appears kinda randomly when i increase the baud rate in my tests
>
> thanks
>
> here it is the windbg output
>
>
> Microsoft (R) Windows Debugger Version 6.6.0007.5
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [C:\WINDOWS\MEMORY.DMP]
> Kernel Complete Dump File: Full address space is available
>
> Symbol search path is:
srvc:\Symbolshttp://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows Server 2003 Kernel Version 3790 (Service Pack 1) UP Free x86
compatible
> Product: Server, suite: TerminalServer SingleUserTS
> Built by: 3790.srv03_sp1_gdr.070304-2232
> Kernel base = 0x80800000 PsLoadedModuleList = 0x808a8e48
> Debug session time: Sun Apr 22 02:53:14.449 2007 (GMT+3)
> System Uptime: 0 days 0:41:50.169
> Loading Kernel Symbols
>
…
…
> Loading User Symbols
> …
> Loading unloaded module list
> …
>

>

> * Bugcheck Analysis

>

>
*
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck A, {22, 2, 0, 80828cb2}
>
> Probably caused by : uart16550.sys ( uart16550!DpcForIsr+53 )
>
> Followup: MachineOwner
> ---------
>
> kd> !analyze -v
>

>

> * Bugcheck Analysis

>

>
*
>
> IRQL_NOT_LESS_OR_EQUAL (a)
> 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 a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000022, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 80828cb2, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 00000022
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!IopfCompleteRequest+c
> 80828cb2 8a4e22 mov cl,byte ptr [esi+22h]
>
> DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: test.exe
>
> TRAP_FRAME: fa026f08 – (.trap fffffffffa026f08)
> ErrCode = 00000000
> eax=00000001 ebx=f9f60410 ecx=00000000 edx=00000000 esi=00000000 edi=ffdffa40
> eip=80828cb2 esp=fa026f7c ebp=fa026f94 iopl=0 nv up ei ng nz na pe nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
> nt!IopfCompleteRequest+0xc:
> 80828cb2 8a4e22 mov cl,byte ptr [esi+22h]
ds:0023:00000022=??
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 80828cb2 to 80826493
>
> STACK_TEXT:
> fa026f08 80828cb2 badb0d00 00000000 fa026f30 nt!KiTrap0E+0x2a1
> fa026f94 f9f60463 81000016 ff42d0e0 fa026ff4 nt!IopfCompleteRequest+0xc
> fa026fa4 80828878 ff42d09c ff42d028 00000000 uart16550!DpcForIsr+0x53
[c:\ss\uart16550.c @ 141]
> fa026ff4 80820813 f8d5ed54 00000000 00000000 nt!KiRetireDpcList+0xca
> fa026ff8 f8d5ed54 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x38
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 80820813 00000000 0000000a bb835b75 00000128 0xf8d5ed54
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> uart16550!DpcForIsr+53 [c:\ss\uart16550.c @ 141]
> f9f60463 eb29 jmp uart16550!DpcForIsr+0x7e (f9f6048e)
>
> FAULTING_SOURCE_CODE:
> 137: if (context & DPC_FOR_WRITE) {
> 138: DbgPrint(“dpc for isr write\n”);
> 139: KeSynchronizeExecution(pDeviceData->pIntObj, IoStartNextPacket_Synch,
pDevice);
> 140: IoCompleteRequest(pIrp, IO_NO_INCREMENT);
> > 141: return ;
> 142: }
> 143:
> 144: if (context & DPC_FOR_READ) {
> 145: DbgPrint(“dpc for isr read\n”);
> 146: KeSetEvent(&pDeviceData->RecvBufferNotEmptyEvent, 0, FALSE);
>
>
> SYMBOL_STACK_INDEX: 2
>
> SYMBOL_NAME: uart16550!DpcForIsr+53
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: uart16550
>
> IMAGE_NAME: uart16550.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 462aa3d6
>
> FAILURE_BUCKET_ID: 0xA_uart16550!DpcForIsr+53
>
> BUCKET_ID: 0xA_uart16550!DpcForIsr+53
>
> Followup: MachineOwner
> ---------
>
>
>