Dump, a few questions

NTDEV
1

Hello all.

I’ve got a dump from test machine. There are a few questions about the dump.

*******************************************************************************
* *
* 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: fffff8a010ea8886, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800e719823, address which referenced memory

Debugging Details:

READ_ADDRESS: fffff8a010ea8886 Paged pool

CURRENT_IRQL: 2

FAULTING_IP:
mydriver!f2+83 [c:\file.c @ 32]
fffff880`0e719823 0fb64026 movzx eax,byte ptr [rax+26h]

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: audiodg.exe

TRAP_FRAME: fffff8800f927550 – (.trap 0xfffff8800f927550)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8a010ea8860 rbx=0000000000000000 rcx=000000000000108c
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8800e719823 rsp=fffff8800f9276e0 rbp=fffff80002238d30
r8=0000000000000000 r9=0000000000000000 r10=fffff880009bfb20
r11=fffff8800f927740 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
mydriver!f2+0x83:
fffff8800e719823 0fb64026 movzx eax,byte ptr [rax+26h] ds:fffff8a010ea8886=00
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002089129 to fffff80002089b80

STACK_TEXT:
fffff8800f927408 fffff80002089129 : 000000000000000a fffff8a010ea8886 0000000000000002 0000000000000000 : nt!KeBugCheckEx
fffff8800f927410 fffff80002087da0 : 0000000000002257 000000000000002e 0000000000000000 0000000000000001 : nt!KiBugCheckDispatch+0x69
fffff8800f927550 fffff8800e719823 : fffffa8001ac6658 0000000000000000 00000000000001b6 fffff80002109e8a : nt!KiPageFault+0x260
fffff8800f9276e0 fffff8800e719714 : 000000000000108c 0000000000000000 fffff8a0046ee7c0 0000000000000001 : mydriver!f2+0x83 [c:\file.c @ 32]
fffff8800f927730 fffff8800e7181b0 : 000000000000108c 0000000000000001 fffff80002238d30 fffff80002238d30 : mydriver!f1+0x24 [c:\file.c @ 122]
fffff8800f927770 fffff800023aa928 : fffffa8001ac6658 000000000000108c fffff8800f927958 0000000000000001 : mydriver!LoadImageNotify+0x50 [c:\file.c @ 443]
fffff8800f927800 fffff800023aa662 : fffffa8001ac6600 fffffa800220d718 fffffa8001736ce0 0000000000000000 : nt!PsCallImageNotifyRoutines+0xdc
fffff8800f927860 fffff800023a66d7 : fffffa8001736ca0 fffffa800220d500 fffff8800f927b10 fffff8800f927b08 : nt!MiMapViewOfImageSection+0x9b2
fffff8800f9279b0 fffff800023a69de : fffffa8000000004 fffffa800220d500 fffff8800f927b10 0000000000000000 : nt!MiMapViewOfSection+0x367
fffff8800f927aa0 fffff80002088e13 : 0000000000000010 fffffa8001b5ca00 000000000017e8e8 000000000017eb01 : nt!NtMapViewOfSection+0x2bd
fffff8800f927b70 0000000076fe153a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000017e8c8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x76fe153a

STACK_COMMAND: kb

FOLLOWUP_IP:
mydriver!f2+83 [c:\file.c @ 32]
fffff880`0e719823 0fb64026 movzx eax,byte ptr [rax+26h]

FAULTING_SOURCE_LINE: c:\file.c

FAULTING_SOURCE_FILE: c:\file.c

FAULTING_SOURCE_LINE_NUMBER: 32

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: mydriver!f2+83

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mydriver

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5238815b

FAILURE_BUCKET_ID: X64_0xD1_mydriver!f2+83

BUCKET_ID: X64_0xD1_mydriver!f2+83

Followup: MachineOwner

Examining memory referenced:

1: kd> !pool fffff8a010ea8886
Pool page fffff8a010ea8886 region is Paged pool
fffff8a010ea8000 size: 820 previous size: 0 (Free) Toke
fffff8a010ea8820 size: 30 previous size: 820 (Allocated) CMNb (Protected)
*fffff8a010ea8850 size: 40 previous size: 30 (Allocated) *Proc
Pooltag Proc : Process objects, Binary : nt!ps
fffff8a010ea8890 size: 770 previous size: 40 (Free) FIcs

(I accidentally assigned existing tag to the allocation).

Why IRQL is at DISPATCH level, while MSDN says that load image notify routine is called at PASSIVE?

Even if it’s DISPATCH, the memory is allocated and doesn’t look paged out, so what causes the instruction to fail?

–
Thanking In Advance,
Mikae.

2

A few more notes:

!pte command fails for some reasons:

1: kd> !pte fffff8a010ea8886
VA fffff8a010ea8886
PXE at FFFFF6FB7DBEDF88 PPE at FFFFF6FB7DBF1400 PDE at FFFFF6FB7E280438 PTE at FFFFF6FC50087540
Unable to get PXE FFFFF6FB7DBEDF88

Quick and dirty disassembling shows that the bugcheck may be raised if MmAccessFault returns status D0000006, which is one bit (N) different from STATUS_IN_PAGE_ERROR (C0000006).

Still not quite understand what may be a reason…

3

Continue talking to myself:

Shame on me, just noticed that I allocated from PagedPool instead of NonPagedPool and then accessed the pointer from spin lock protected region.

4

> Continue talking to myself:

Shame on me, just noticed that I allocated from PagedPool instead of
NonPagedPool and then accessed the pointer from spin lock protected
region.

I was going to suggest the possibility of a spin lock, which elevates you
to DISPATCH_LEVEL. That’s what you need to watch for. The paged pool
should be used with great care.
joe

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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