Pool allocations check - Verifier bug ?

Hi Guys!

I run verifier and I during uninstall my driver I received bug check from verifier,
but “Current Pool Allocations = 0”, so why verifier rise bug check ? (verifier bug?)

Dump log:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000062, A driver has forgotten to free its pool allocations prior to unloading.
Arg2: ffffe0018a7964d0, name of the driver having the issue.
Arg3: ffffe0018a797b60, verifier internal structure with driver information.
Arg4: 0000000000700000, total # of (paged+nonpaged) allocations that weren’t freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

20: kd> !verifier 3 MySuperDriver.sys

Verify Level 209bb … enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Io subsystem checking enabled
Deadlock detection enabled
DMA checking enabled
Security checks enabled
Miscellaneous checks enabled
DDI compliance checking enabled

Summary of All Verifier Statistics

RaiseIrqls 0x2
AcquireSpinLocks 0x3
Synch Executions 0x0
Trims 0x1f53

Pool Allocations Attempted 0x33e3f
Pool Allocations Succeeded 0x33e3f
Pool Allocations Succeeded SpecialPool 0x33e3f
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x1 for 00001860 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x1 for 00000070 bytes

fffff80093ccb020: Unable to get special pool info
fffff80093ccb020: Unable to get special pool info
Driver Verification List

Entry State NonPagedPool PagedPool Module

ffffe00187815d50 Loaded 00000000 00000000 mysuperdriver.sys

Current Pool Allocations 00000000 00000000
Current Pool Bytes 00000000 00000000
Peak Pool Allocations 00000001 00000001
Peak Pool Bytes 00000070 00001860

20: kd> !poolused -> can not find my driver pool tag - clean

Bob

Strange. Are you running an older debugger maybe? Also, what kind of driver
is this (KMDF, NDIS, etc.)?

Arg4 says you have 0x700000 outstanding pool allocations at time of unload,
which would be bad :slight_smile: Were you running stress or anything?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi Guys!

I run verifier and I during uninstall my driver I received bug check from
verifier,
but “Current Pool Allocations = 0”, so why verifier rise bug check ?
(verifier bug?)

Dump log:
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000062, A driver has forgotten to free its pool allocations
prior to unloading.
Arg2: ffffe0018a7964d0, name of the driver having the issue.
Arg3: ffffe0018a797b60, verifier internal structure with driver information.
Arg4: 0000000000700000, total # of (paged+nonpaged) allocations that weren’t
freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

20: kd> !verifier 3 MySuperDriver.sys

Verify Level 209bb … enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Io subsystem checking enabled
Deadlock detection enabled
DMA checking enabled
Security checks enabled
Miscellaneous checks enabled
DDI compliance checking enabled

Summary of All Verifier Statistics

RaiseIrqls 0x2
AcquireSpinLocks 0x3
Synch Executions 0x0
Trims 0x1f53

Pool Allocations Attempted 0x33e3f
Pool Allocations Succeeded 0x33e3f
Pool Allocations Succeeded SpecialPool 0x33e3f
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x1 for 00001860 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x1 for 00000070 bytes

fffff80093ccb020: Unable to get special pool info
fffff80093ccb020: Unable to get special pool info
Driver Verification List

Entry State NonPagedPool PagedPool Module

ffffe00187815d50 Loaded 00000000 00000000
mysuperdriver.sys

Current Pool Allocations 00000000 00000000
Current Pool Bytes 00000000 00000000
Peak Pool Allocations 00000001 00000001
Peak Pool Bytes 00000070 00001860

20: kd> !poolused -> can not find my driver pool tag - clean

Bob

It is KMDF driver.

I run Verifier (with standard check scenario) and targeted my driver, then restart host.
I run stress tests on my driver - and it is OK - no BugChecks from Verifier.
And at the end I decided to test my driver with “uninstall scenario” - so I try uninstall my driver, and then Verifier raise a BugCheck…

Arg4 - 0000000000700000 - that value should be shifted,
because in Verifier summary we see: “Peak Pool Bytes 00000070 - NonPagedPool” -
that is correct, because my driver alloc 0x70 memory during works and free it.
I see this in WinDbg - this pool is freed correctly (ExFreePoolWithTag in driver call EvtDestroyCallback) - after that I see this pool is marked as - no memory access.

Restarting the machine does not explicitly unload your driver, so you
wouldn’t get this crash on reboot.

Which OS are you on? I can’t repro a situation where Arg4 is a shift of the
number of bytes allocated (I tried 8.1 and 10).

Any outstanding KMDF object allocations? They are tagged with the first four
characters of your driver name.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

It is KMDF driver.

I run Verifier (with standard check scenario) and targeted my driver, then
restart host.
I run stress tests on my driver - and it is OK - no BugChecks from Verifier.
And at the end I decided to test my driver with “uninstall scenario” - so I
try uninstall my driver, and then Verifier raise a BugCheck…

Arg4 - 0000000000700000 - that value should be shifted,
because in Verifier summary we see: “Peak Pool Bytes 00000070 -
NonPagedPool” -
that is correct, because my driver alloc 0x70 memory during works and free
it.
I see this in WinDbg - this pool is freed correctly (ExFreePoolWithTag in
driver call EvtDestroyCallback) - after that I see this pool is marked as -
no memory access.

Does your driver happen to be a network driver? There are some documented cases where a network driver allocates an NBL context, which is cached by the OS when freed. Your driver is charged with the allocation, but even if you free the context it still lives in a NDIS cache, and driver verifier leak detection can incorrectly claim you have a leak.

Jan

On 7/8/16, 2:16 AM, “xxxxx@lists.osr.com on behalf of xxxxx@gmail.com” wrote:

Hi Guys!

I run verifier and I during uninstall my driver I received bug check from verifier,
but “Current Pool Allocations = 0”, so why verifier rise bug check ? (verifier bug?)

Dump log:


Bugcheck Analysis



DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000062, A driver has forgotten to free its pool allocations prior to unloading.
Arg2: ffffe0018a7964d0, name of the driver having the issue.
Arg3: ffffe0018a797b60, verifier internal structure with driver information.
Arg4: 0000000000700000, total # of (paged+nonpaged) allocations that weren’t freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

20: kd> !verifier 3 MySuperDriver.sys

Verify Level 209bb … enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Io subsystem checking enabled
Deadlock detection enabled
DMA checking enabled
Security checks enabled
Miscellaneous checks enabled
DDI compliance checking enabled

Summary of All Verifier Statistics

RaiseIrqls 0x2
AcquireSpinLocks 0x3
Synch Executions 0x0
Trims 0x1f53

Pool Allocations Attempted 0x33e3f
Pool Allocations Succeeded 0x33e3f
Pool Allocations Succeeded SpecialPool 0x33e3f
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0

Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x1 for 00001860 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x1 for 00000070 bytes

fffff80093ccb020: Unable to get special pool info
fffff80093ccb020: Unable to get special pool info
Driver Verification List

Entry State NonPagedPool PagedPool Module

ffffe00187815d50 Loaded 00000000 00000000 mysuperdriver.sys

Current Pool Allocations 00000000 00000000
Current Pool Bytes 00000000 00000000
Peak Pool Allocations 00000001 00000001
Peak Pool Bytes 00000070 00001860

20: kd> !poolused -> can not find my driver pool tag - clean

Bob


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

I’m testing it on Win Server 2012R2.

No my driver is not a NDIS driver, but! my driver is a BUS driver and one of PDOs is created for a NDIS drvier (Virtual Ethernet).

The first simple thing you can do is write your own allocation/deallocation routines that would perform all allocations/deallocations within your driver.

The allocation routine, on success, would increment a global counter atomically (InterlockedIncrement(&MyGlobalPoolCounter):wink: while the deallocation routine would decrement the same counter atomically (InterlockedDecrement(&MyGlobalPoolCounter);). The counter would be initialized to zero within DriverEntry.

When your driver unloads, you should run the following assertion before the unload routine returns:

ASSERT (MyGlobalPoolCounter == 0 );