BSOD bugcheck 0xA only under Win7 x64

NTDEV
1

Hello everybody,

I’m trying to port our drivers to x64 at the moment.
All but one driver are working great, but i have one .sys file that
makes some problems.
It runs fine on XP x64 as well as Vista x64.
But when I try to load it under Win7 x64 I get a BSOD as soon as the
Driver is loaded.
I can see that it’s an invalid memory read, but i have no idea where the
adress 0x2998 is coming from.
My problem is the driver doesn’t show up in the kernel memory dump.

I’m not very experienced using winDgb when my Driver doesn’t show up in
the stack trace.
so any help would really be appreciated!

Here is the result from !analyze -v

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {2998, 2, 0, fffff80002a9ac22}

PEB is paged out (Peb.Ldr = 000000007efdf018). Type ".hh dbgerr001" for details PEB is paged out (Peb.Ldr = 000000007efdf018). Type “.hh dbgerr001”
for details
Probably caused by : ntkrnlmp.exe ( nt!KiRetireDpcList+1e2 )

Followup: MachineOwner

0: 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: 0000000000002998, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation
(only on chips which support this level of status)
Arg4: fffff80002a9ac22, address which referenced memory

Debugging Details:

PEB is paged out (Peb.Ldr = 000000007efdf018). Type ".hh dbgerr001" for details PEB is paged out (Peb.Ldr = 000000007efdf018). Type “.hh dbgerr001”
for details

READ_ADDRESS: 0000000000002998

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiRetireDpcList+1e2
fffff800`02a9ac22 8b8398210000 mov eax,dword ptr [rbx+2198h]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: Scope.exe

TRAP_FRAME: fffff80000ba2d70 – (.trap 0xfffff80000ba2d70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa80033ea000 rbx=0000000000000000 rcx=0000000000000000
rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002a9ac22 rsp=fffff80000ba2f00 rbp=fffffa8002dae060
r8=0000000000000002 r9=0000000000000000 r10=fffff80002a1f000
r11=00000000000049f9 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
nt!KiRetireDpcList+0x1e2:
fffff800`02a9ac22 8b8398210000 mov eax,dword ptr [rbx+2198h]
ds:e100:2198=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002a8eca9 to fffff80002a8f740

STACK_TEXT:
fffff80000ba2c28 fffff80002a8eca9 : 000000000000000a 0000000000002998 0000000000000002 0000000000000000 : nt!KeBugCheckEx
fffff80000ba2c30 fffff80002a8d920 : fffff88000000100 0000000000000800 0000030000000000 fffff8800410469d :
nt!KiBugCheckDispatch+0x69
fffff80000ba2d70 fffff80002a9ac22 : fffffa8002dae128 fffffa8002dae060 fffffa8002cab270 fffffa80031d9d60 : nt!KiPageFault+0x260
fffff80000ba2f00 fffff80002a95865 : 0000000000000000 fffffa800421d300 0000000000000000 fffff880040ed700 :
nt!KiRetireDpcList+0x1e2
fffff80000ba2fb0 fffff80002a9567c : 0000000000000200 fffff88003bc28d2 fffffa8002cab270 fffffa80031d9d60 :
nt!KxRetireDpcList+0x5
fffff8800599abe0 fffff80002ad9113 : fffff80002a8b576 fffff80002a8b5e2 00000000000000bd fffff8800599ac01 :
nt!KiDispatchInterruptContinue
fffff8800599ac10 fffff80002a8b5e2 : 00000000000000bd fffff8800599ac01 fffffa80018c6540 0000000002bc0730 :
nt!KiDpcInterruptBypass+0x13
fffff8800599ac20 0000000010c0b479 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!KiInterruptDispatch+0x212
000000000018e720 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x10c0b479

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiRetireDpcList+1e2
fffff800`02a9ac22 8b8398210000 mov eax,dword ptr [rbx+2198h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!KiRetireDpcList+1e2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4c1c44a9

FAILURE_BUCKET_ID: X64_0xA_nt!KiRetireDpcList+1e2

BUCKET_ID: X64_0xA_nt!KiRetireDpcList+1e2

Followup: MachineOwner

Kind regards,
Julian

2

As it happens on load why don’t you put a break point in driver entry and see what is causing it?

3

It looks like some O/S data structures might have become corrupted. Have you
tried running your driver under Verifier?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“julian schmidt” wrote in message
news:xxxxx@ntdev…
> Hello everybody,
>
> I’m trying to port our drivers to x64 at the moment.
> All but one driver are working great, but i have one .sys file that makes
> some problems.
> It runs fine on XP x64 as well as Vista x64.
> But when I try to load it under Win7 x64 I get a BSOD as soon as the
> Driver is loaded.
> I can see that it’s an invalid memory read, but i have no idea where the
> adress 0x2998 is coming from.
> My problem is the driver doesn’t show up in the kernel memory dump.
>
> I’m not very experienced using winDgb when my Driver doesn’t show up in
> the stack trace.
> so any help would really be appreciated!
>
> Here is the result from !analyze -v
>
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck A, {2998, 2, 0, fffff80002a9ac22}
>
> PEB is paged out (Peb.Ldr = 000000007efdf018). Type ".hh dbgerr001" for <br>&gt; details<br>&gt; PEB is paged out (Peb.Ldr = 000000007efdf018). Type “.hh dbgerr001” for
> details
> Probably caused by : ntkrnlmp.exe ( nt!KiRetireDpcList+1e2 )
>
> Followup: MachineOwner
> ---------
>
> 0: 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: 0000000000002998, memory referenced
> Arg2: 0000000000000002, IRQL
> Arg3: 0000000000000000, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation
> (only on chips which support this level of status)
> Arg4: fffff80002a9ac22, address which referenced memory
>
> Debugging Details:
> ------------------
>
> PEB is paged out (Peb.Ldr = 000000007efdf018). Type ".hh dbgerr001" for <br>&gt; details<br>&gt; PEB is paged out (Peb.Ldr = 000000007efdf018). Type “.hh dbgerr001” for
> details
>
> READ_ADDRESS: 0000000000002998
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!KiRetireDpcList+1e2
> fffff80002a9ac22 8b8398210000 mov eax,dword ptr [rbx+2198h]<br>&gt;<br>&gt; DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br>&gt;<br>&gt; BUGCHECK_STR: 0xA<br>&gt;<br>&gt; PROCESS_NAME: Scope.exe<br>&gt;<br>&gt; TRAP_FRAME: fffff80000ba2d70 -- (.trap 0xfffff80000ba2d70)<br>&gt; NOTE: The trap frame does not contain all registers.<br>&gt; Some register values may be zeroed or incorrect.<br>&gt; rax=fffffa80033ea000 rbx=0000000000000000 rcx=0000000000000000<br>&gt; rdx=000000000000002f rsi=0000000000000000 rdi=0000000000000000<br>&gt; rip=fffff80002a9ac22 rsp=fffff80000ba2f00 rbp=fffffa8002dae060<br>&gt; r8=0000000000000002 r9=0000000000000000 r10=fffff80002a1f000<br>&gt; r11=00000000000049f9 r12=0000000000000000 r13=0000000000000000<br>&gt; r14=0000000000000000 r15=0000000000000000<br>&gt; iopl=0 nv up di pl zr na po nc<br>&gt; nt!KiRetireDpcList+0x1e2:<br>&gt; fffff80002a9ac22 8b8398210000 mov eax,dword ptr [rbx+2198h]
> ds:e100:2198=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from fffff80002a8eca9 to fffff80002a8f740
>
> STACK_TEXT:
> fffff80000ba2c28 fffff80002a8eca9 : 000000000000000a 0000000000002998
> 0000000000000002 0000000000000000 : nt!KeBugCheckEx
> fffff80000ba2c30 fffff80002a8d920 : fffff88000000100 0000000000000800
> 0000030000000000 fffff8800410469d : nt!KiBugCheckDispatch+0x69
> fffff80000ba2d70 fffff80002a9ac22 : fffffa8002dae128 fffffa8002dae060
> fffffa8002cab270 fffffa80031d9d60 : nt!KiPageFault+0x260
> fffff80000ba2f00 fffff80002a95865 : 0000000000000000 fffffa800421d300
> 0000000000000000 fffff880040ed700 : nt!KiRetireDpcList+0x1e2
> fffff80000ba2fb0 fffff80002a9567c : 0000000000000200 fffff88003bc28d2
> fffffa8002cab270 fffffa80031d9d60 : nt!KxRetireDpcList+0x5
> fffff8800599abe0 fffff80002ad9113 : fffff80002a8b576 fffff80002a8b5e2
> 00000000000000bd fffff8800599ac01 : nt!KiDispatchInterruptContinue
> fffff8800599ac10 fffff80002a8b5e2 : 00000000000000bd fffff8800599ac01
> fffffa80018c6540 0000000002bc0730 : nt!KiDpcInterruptBypass+0x13
> fffff8800599ac20 0000000010c0b479 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiInterruptDispatch+0x212
> 000000000018e720 0000000000000000 : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 : 0x10c0b479
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> nt!KiRetireDpcList+1e2
> fffff800`02a9ac22 8b8398210000 mov eax,dword ptr [rbx+2198h]
>
> SYMBOL_STACK_INDEX: 3
>
> SYMBOL_NAME: nt!KiRetireDpcList+1e2
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4c1c44a9
>
> FAILURE_BUCKET_ID: X64_0xA_nt!KiRetireDpcList+1e2
>
> BUCKET_ID: X64_0xA_nt!KiRetireDpcList+1e2
>
> Followup: MachineOwner
> ---------
>
>
> Kind regards,
> Julian
>
>

4

I don’t have a remote debugging machine at the moment. So I have to rely on crash dumps.

5

what process is “Scope.exe”?

On Thu, Sep 16, 2010 at 4:22 PM, wrote:

> I don’t have a remote debugging machine at the moment. So I have to rely on
> crash dumps.
>
> —
> 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
>

6

I tried using verifier but got the same result.
No driver verifier bugcheck occurs.

Scope.exe is my main application which dynamically loads the faulty driver on runtime.

julian

7

>>I don’t have a remote debugging machine at the moment. So I have to rely on crash dumps

Use DbgPrint than in your driver entry and narrow it.

8

ok, this was a good tip.
I narrowed it down to a call to this function, setting the fpu mode to round down

setRCdown proc
;fstcw oldcw
fstcw word ptr [rcx] ;rcx = param 1
mov rax,[rcx] ; return value is old cw word

mov rbx, 0f3ffh
and [rcx], rbx

mov rbx, 0800h;0400h
or [rcx], rbx ;set rc to round down
fldcw [rcx]
ret
setRCdown endp

now i’m just wondering why this is working on XP and Vista, but causes a BSOD on Win7…

Thanks for the help so far!
Julian

9

okay, i studied the Floating-Point Support for 64-Bit Drivers on MSDN
http://msdn.microsoft.com/en-us/library/ff545910(VS.85).aspx

replaced the fpu control register commands with SSE control register commands, and now everything is working fine! Thanks for your time!

Julian

10

No, you are actually relying on us to analyze your crash dumps since you
don’t have the tools to do it. Target systems with multi-CPU capability are
dirt cheap, and are part of the cost of developing in the kernel.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@soniccore.de
Sent: Thursday, September 16, 2010 5:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD bugcheck 0xA only under Win7 x64

I don’t have a remote debugging machine at the moment. So I have to rely on
crash dumps.

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

11

julian schmidt wrote:

I’m trying to port our drivers to x64 at the moment.
All but one driver are working great, but i have one .sys file that
makes some problems.
It runs fine on XP x64 as well as Vista x64.
But when I try to load it under Win7 x64 I get a BSOD as soon as the
Driver is loaded.
I can see that it’s an invalid memory read, but i have no idea where the
adress 0x2998 is coming from.
My problem is the driver doesn’t show up in the kernel memory dump.

I’m not very experienced using winDgb when my Driver doesn’t show up in
the stack trace.
so any help would really be appreciated!

Does your driver have an interrupt? The stack trace shows that the
system was trying to fire any pending DPCs after handling an interrupt.
It’s possible you have a problem in the way you are queueing the DPC.
It’s also quite possible that you’ve simply overwritten some memory in a
critical data structure.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.