Bug in call usage verifier

NTDEV
1

Hi,

Last week I came across what looks like a bug in call usage verifier. The
symptoms are: if my driver leaks memory, CUV corrupts memory on driver exit.
If you also run driver verifier, it asserts on CUV reading from a free
memory block while unloading the driver. I didn’t step through and ignore
the asserts, but believe at some point it must write to freed memory,
because another driver of mine fails with corrupted memory a few moments
later.

I fixed the leak in my driver, and all the issues I was seeing go away, but
wondered if there was a recommended reporting strategy for possible bugs in
CUV (or a debug CUV)? Hopefully I can help prevent some future CUV user from
scratching his head. It took me a little while to figure out I should
disable CUV, which then allowed driver verifier to give me a nice memory
leak notification.

I could probably easily put the leak back, and make CUV fail again to help
track this down.

  • Jan
2

Interesting bug. Was this problem apparent when you were running CUV *and* driver verifier at the same time?

Given that CUV is not included in the WDK (there ARE other plans in progress to support/maintain/enhance it), I think the most effective problem reporting method was the one you just used.

I hope there’ll be more news about CUV in the relatively near future – Sorry I can’t be more specific just now…

Peter
OSR

3

> Interesting bug. Was this problem apparent when you were running CUV

*and* driver verifier at the same time?

If I put the memory leak back in and run driver verifier (all drivers with
most options set except low memory simulation), I get the crash below if I
disable my driver in device manager (causing it to unload).

The OS is a full checked build of 32-bit W2k3 SP1. The symbols are coming
from the MSFT symbol server. The DDK is the standard W2k3 sp1 DDK.

If I don’t have driver verifier running, I don’t get this crash, but another
driver fails moments later with what looks like memory corruption. If I
disable CUV and run driver verifier, I get a leaked memory crash from driver
verifier.

If I fix the leak in my driver, this crash and the memory corruption in the
other driver go away. I unfortunately don’t have any way to just ignore this
invalid read, to see if an invalid write eventually happens (unless you know
a magic option to tell driver verifier to only trap on writes to freed
special pool). I’m making the assumption ddk_ext\verifier\pooltrak.cpp is
part of call usage verifier.

  • Jan

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: 8908cff4, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: ba955d9c, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)

Debugging Details:

*** Error in in reading nt!_ETHREAD @ 00000000
*** Error in in reading nt!_ETHREAD @ 00000000
*** Error in in reading nt!_ETHREAD @ 00000000

READ_ADDRESS: 8908cff4 Special pool

FAULTING_IP:
MyDrv!DDKExtPoolDeleteEntry+91
[d:\dnsrv\sdktools\ddk\ddk_ext\verifier\pooltrak.cpp @ 743]
ba955d9c 8b07 mov eax,[edi]

MM_INTERNAL_CODE: 0

IMAGE_NAME: MyDrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44ce5d5b

MODULE_NAME: MyDrv

FAULTING_MODULE: ba933000 MyDrv

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD5

CURRENT_IRQL: 1

LOCK_ADDRESS: 807a4340 – (!locks 807a4340)
NTSDEXTS: Unable to resolve ntdll!RtlCriticalSectionList
NTSDEXTS: Please check your symbols

PNP_TRIAGE:
Lock address : 0x807a4340
Thread Count : 1
Thread address: 0x85dd13f0
Thread wait : 0x105f7d3d

LAST_CONTROL_TRANSFER: from 8063717b to 8075cc0c

STACK_TEXT:
f78e2504 8063717b 00000003 00000000 ba955d9c
nt!RtlpBreakWithStatusInstruction
f78e2550 806380d8 00000003 c0448460 00089016 nt!KiBugCheckDebugBreak+0x19
f78e28e8 80638527 00000050 8908cff4 00000000 nt!KeBugCheck2+0x5b2
f78e2908 80712841 00000050 8908cff4 00000000 nt!KeBugCheckEx+0x1b
f78e297c 8077f524 00000000 8908cff4 00000000 nt!MmAccessFault+0x1bd3
f78e297c ba955d9c 00000000 8908cff4 00000000 nt!KiTrap0E+0xe4
f78e2a34 ba955e13 01ffffff 859d8e20 ba95596f
MyDrv!DDKExtPoolDeleteEntry+0x91
[d:\dnsrv\sdktools\ddk\ddk_ext\verifier\pooltrak.cpp @ 743]
f78e2a40 ba95596f ba95b200 f78e2a54 ba955a46 MyDrv!DDKExtPoolClearList+0x28
[d:\dnsrv\sdktools\ddk\ddk_ext\verifier\pooltrak.cpp @ 841]
f78e2a4c ba955a46 f78e2afc 8095b89a 859d8e20 MyDrv!DDKPlusUninitialize+0x67
[d:\dnsrv\sdktools\ddk\ddk_ext\verifier\utility.cpp @ 1684]
f78e2a54 8095b89a 859d8e20 0000007c 859d8ed4 MyDrv!DDK_DriverUnload+0x1f
[d:\dnsrv\sdktools\ddk\ddk_ext\verifier\init.cpp @ 211]
f78e2afc 80989f58 f78e2b18 00000001 000a15e8 nt!IopUnloadDriver+0x256
f78e2b20 80632d0e 859d8e20 00000000 85db2688 nt!IopUnloadAttachedDriver+0xb0
f78e2b44 8098a18b e1b96708 00000016 e1686c80
nt!IopRemoveLockedDeviceNode+0x306
f78e2b64 8098a36d 85db2688 00000002 e1686c80
nt!IopDeleteLockedDeviceNode+0x99
f78e2b9c 809902b0 85db27f0 e1686c80 00000002
nt!IopDeleteLockedDeviceNodes+0x89
f78e2c30 809906f6 e143da38 e2eb5a58 806018ac
nt!PiProcessQueryRemoveAndEject+0xa3e
f78e2c4c 80990ea0 f78e2c74 85dd13f0 808b9d7c
nt!PiProcessTargetDeviceEvent+0x6c
f78e2d80 80772064 82fe56d0 00000000 85dd13f0 nt!PiWalkDeviceList+0x582
f78e2dac 80a07678 82fe56d0 00000000 00000000 nt!ExpWorkerThread+0x12e
f78e2ddc 80781346 80771f36 00000001 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
MyDrv!DDKExtPoolDeleteEntry+91
[d:\dnsrv\sdktools\ddk\ddk_ext\verifier\pooltrak.cpp @ 743]
ba955d9c 8b07 mov eax,[edi]

FAULTING_SOURCE_CODE:
No source found for ‘d:\dnsrv\sdktools\ddk\ddk_ext\verifier\pooltrak.cpp’

4

Thanks, Jan, for taking the time to repro this problem and post the bugcheck output. It’s very much appreciated.

Looks to me like CUV a Driver Verifier are arguing about who should be returning those leaked pool allocations… And Driver Verifier is winning :slight_smile:

Peter
OSR