Odd STOP 0xD1 parameters...

I got the following today in some 10-year-old code of mine, and I
couldn’t reproduce afterwards. Note that Parameters 1 and 4 are the
same address, but most odd is that Parameter 3 is 8, which I’ve never
seen before and couldn’t find documented anywhere. The code is fine,
and the EBP was also uncorrupted and pointed to valid memory on the
stack. My guess is that this indicates some kind of instruction /
execute fault or something along those lines, however I usually see MCA
exceptions in those very rare cases. I was running Driver Verifier at
the time on most of the drivers in the system, including this one that
(allegedly) caused the crash Anyone know for sure what this BugCheck
means? (Thanks!)

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: ba4068d6, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: ba4068d6, address which referenced memory

FAULTING_IP:
Trace!TraceWorkerRoutine+116
ba4068d6 8845d7 mov byte ptr [ebp-29h],al

PROCESS_NAME: System

TRAP_FRAME: f78d2cc0 – (.trap fffffffff78d2cc0)
ErrCode = 00000010
eax=00000000 ebx=85f7c0b0 ecx=00000002 edx=84710402 esi=808a76c0
edi=864a5db0
eip=ba4068d6 esp=f78d2d34 ebp=f78d2d80 iopl=0 nv up ei pl zr na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Trace!TraceWorkerRoutine+0x116:
ba4068d6 8845d7 mov byte ptr [ebp-29h],al
ss:0010:f78d2d57=ba
Resetting default scope

LAST_CONTROL_TRANSFER: from ba4068d6 to 80886a69

STACK_TEXT:
f78d2cc0 ba4068d6 badb0d00 84710402 0001602d nt!KiTrap0E+0x2a1
f78d2d80 8087adbd 85f7a0e0 00000000 864a5db0
Trace!TraceWorkerRoutine+0x116 [d:\wave\platform\trace\sys\trace.c @
1994]
f78d2dac 809418f4 85f7a0e0 00000000 00000000 nt!ExpWorkerThread+0xeb
f78d2ddc 80887f4a 8087acd2 00000000 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

What this means (param1 == param4) is that you have a PAGEd function
which is raising to dispatch level and then taking page fault on the
code segment that you are executing. Did you mark TraceWorkerRoutine as
pageable or any FORCEINLINE functions it may call as pageable?

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Taed Wynnell
Sent: Monday, August 20, 2007 8:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Odd STOP 0xD1 parameters…

I got the following today in some 10-year-old code of mine, and I
couldn’t reproduce afterwards. Note that Parameters 1 and 4 are the
same address, but most odd is that Parameter 3 is 8, which I’ve never
seen before and couldn’t find documented anywhere. The code is fine,
and the EBP was also uncorrupted and pointed to valid memory on the
stack. My guess is that this indicates some kind of instruction /
execute fault or something along those lines, however I usually see MCA
exceptions in those very rare cases. I was running Driver Verifier at
the time on most of the drivers in the system, including this one that
(allegedly) caused the crash Anyone know for sure what this BugCheck
means? (Thanks!)

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: ba4068d6, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: ba4068d6, address which referenced memory

FAULTING_IP:
Trace!TraceWorkerRoutine+116
ba4068d6 8845d7 mov byte ptr [ebp-29h],al

PROCESS_NAME: System

TRAP_FRAME: f78d2cc0 – (.trap fffffffff78d2cc0)
ErrCode = 00000010
eax=00000000 ebx=85f7c0b0 ecx=00000002 edx=84710402 esi=808a76c0
edi=864a5db0
eip=ba4068d6 esp=f78d2d34 ebp=f78d2d80 iopl=0 nv up ei pl zr na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Trace!TraceWorkerRoutine+0x116:
ba4068d6 8845d7 mov byte ptr [ebp-29h],al
ss:0010:f78d2d57=ba
Resetting default scope

LAST_CONTROL_TRANSFER: from ba4068d6 to 80886a69

STACK_TEXT:
f78d2cc0 ba4068d6 badb0d00 84710402 0001602d nt!KiTrap0E+0x2a1
f78d2d80 8087adbd 85f7a0e0 00000000 864a5db0
Trace!TraceWorkerRoutine+0x116 [d:\wave\platform\trace\sys\trace.c @
1994]
f78d2dac 809418f4 85f7a0e0 00000000 00000000 nt!ExpWorkerThread+0xeb
f78d2ddc 80887f4a 8087acd2 00000000 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


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

Taed Wynnell wrote:

I got the following today in some 10-year-old code of mine, and I
couldn’t reproduce afterwards. Note that Parameters 1 and 4 are the
same address, but most odd is that Parameter 3 is 8, which I’ve never
seen before and couldn’t find documented anywhere. The code is fine,
and the EBP was also uncorrupted and pointed to valid memory on the
stack. My guess is that this indicates some kind of instruction /
execute fault or something along those lines, however I usually see
MCA exceptions in those very rare cases. I was running Driver
Verifier at the time on most of the drivers in the system, including
this one that (allegedly) caused the crash Anyone know for sure what
this BugCheck means? (Thanks!)

Yes. You’re executing paged code at DISPATCH IRQL.

If you’re not a minidriver, then set the pageability declarations for
your functions right (#pragma alloc_text)

If you *are* a minidriver, then be careful if you spawn your own
threads: some port drivers call MMPageEntireDriver for their minidrivers.

MH.