Crash under verifier

NTDEV
1

Hi,
I am experiencing a rare crash when my driver is under verifier. My driver is a volume upper filter and is using the MmGetSystemAddressForMDLSafe to peek at user buffers.
The crash indicates that the memory got corrupted(PFN_LIST_CORRUPT) , and by examining all the threads I see another thread in which driver verifier call MmTrimAllSystemPagableMemory because I acquired a spinlock which my be relevant. I do not know where to start looking, so any advice will be great.
Here is the !analyze -v output:

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

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

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\dump
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x804805c0
Debug session time: Wed Jan 12 09:15:40 2005
System Uptime: 0 days 6:55:49.876
Loading Kernel Symbols
....................................................................................
Loading unloaded module list
..........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 4E, {7, 13908, 180e1, 0}

Probably caused by : memory_corruption ( nt!MiFlushSectionInternal+449 )

Followup: MachineOwner

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

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc). If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 00000007, A driver has unlocked a page more times than it locked it
Arg2: 00013908, page frame number
Arg3: 000180e1, current share count
Arg4: 00000000, 0

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x4E

LAST_CONTROL_TRANSFER: from 8043cab5 to 8044b1c3

STACK_TEXT:
eb433af8 8043cab5 8544c620 83bef1c8 83070b08 nt!MiDecrementReferenceCount+0x37
eb433bb4 8043c4e5 e4558474 e4558478 e4558478 nt!MiFlushSectionInternal+0x449
eb433bf4 8040ea6e 83070b08 0000011d 00001000 nt!MmFlushSection+0x1a3
eb433cd0 8040e2c1 83f8b734 00000000 00000001 nt!CcFlushCache+0x3f4
eb433d0c 80412a82 8544d468 80473500 8544c620 nt!CcWriteBehind+0xc5
eb433d78 804168ce 8544d468 00000000 00000000 nt!CcWorkerThread+0x12c
eb433da8 80453844 8544d468 00000000 00000000 nt!ExpWorkerThread+0xae
eb433ddc 80468022 80416820 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!MiFlushSectionInternal+449
8043cab5 83c604 add esi,0x4

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!MiFlushSectionInternal+449

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 40d1d183

STACK_COMMAND: kb

IMAGE_NAME: memory_corruption

BUCKET_ID: 0x4E_nt!MiFlushSectionInternal+449

Followup: MachineOwner

Regards,
ERAN.

2

You’ve probaboy toasted some internal data structure by overwriting the end
of yours, and the next thing after is owned by the thread that crashes…
These ones are quite difficult to track down, especially if Driver Verifier
doesn’t catch the overwrite…

Try changing your allocation routine to add a safety margin on the
allocated memory and let that extra memory be filled with some
test-pattern, then check the test-pattern at regular intervals.

Also, make sure you don’t overwrite memory BEFORE the start of your memory
(i.e. using negative offset into a buffer, perhaps by getting overflows in
calculations, or some such).

–
Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 01/12/2005 05:25:27 PM:

Hi,
I am experiencing a rare crash when my driver is under verifier. My
driver is a volume upper filter and is using the
MmGetSystemAddressForMDLSafe to peek at user buffers.
The crash indicates that the memory got corrupted(PFN_LIST_CORRUPT)
, and by examining all the threads I see another thread in which
driver verifier call MmTrimAllSystemPagableMemory because I acquired
a spinlock which my be relevant. I do not know where to start
looking, so any advice will be great.
Here is the !analyze -v output:
icrosoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\dump\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.
com/download/symbols;c:\dump
Executable search path is:
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86 compatible
Product: WinNt
Kernel base = 0x80400000 PsLoadedModuleList = 0x804805c0
Debug session time: Wed Jan 12 09:15:40 2005
System Uptime: 0 days 6:55:49.876
Loading Kernel Symbols

…

Loading unloaded module list
…
Loading User Symbols

*******************************************************************************

*
*
* Bugcheck Analysis
*
*
*

*******************************************************************************

Use !analyze -v to get detailed debugging information.
BugCheck 4E, {7, 13908, 180e1, 0}
Probably caused by : memory_corruption ( nt!MiFlushSectionInternal+449 )
Followup: MachineOwner

kd> !analyze -v

*******************************************************************************

*
*
* Bugcheck Analysis
*
*
*

*******************************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie:
calling
MmUnlockPages twice with the same list, etc). If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 00000007, A driver has unlocked a page more times than it locked it
Arg2: 00013908, page frame number
Arg3: 000180e1, current share count
Arg4: 00000000, 0
Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x4E
LAST_CONTROL_TRANSFER: from 8043cab5 to 8044b1c3
STACK_TEXT:
eb433af8 8043cab5 8544c620 83bef1c8 83070b08
nt!MiDecrementReferenceCount+0x37
eb433bb4 8043c4e5 e4558474 e4558478 e4558478
nt!MiFlushSectionInternal+0x449
eb433bf4 8040ea6e 83070b08 0000011d 00001000 nt!MmFlushSection+0x1a3
eb433cd0 8040e2c1 83f8b734 00000000 00000001 nt!CcFlushCache+0x3f4
eb433d0c 80412a82 8544d468 80473500 8544c620 nt!CcWriteBehind+0xc5
eb433d78 804168ce 8544d468 00000000 00000000 nt!CcWorkerThread+0x12c
eb433da8 80453844 8544d468 00000000 00000000 nt!ExpWorkerThread+0xae
eb433ddc 80468022 80416820 00000000 00000000
nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!MiFlushSectionInternal+449
8043cab5 83c604 add esi,0x4
SYMBOL_STACK_INDEX: 1
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!MiFlushSectionInternal+449
MODULE_NAME: nt
DEBUG_FLR_IMAGE_TIMESTAMP: 40d1d183
STACK_COMMAND: kb
IMAGE_NAME: memory_corruption
BUCKET_ID: 0x4E_nt!MiFlushSectionInternal+449
Followup: MachineOwner

Regards,
ERAN.

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT0000ABB6