We have WFP filter driver.
We allocate and pass localRedirectContext buffer as part of FWPS_CONNECT_REQUEST.
As per documentation, “Note Starting with Windows 8, memory allocated for localRedirectContext will have its ownership taken by WFP, and will be freed when the proxied flow is removed.”
But during driver unload, randomly verifier gives bugcheck 0xC4 for this buffer.
How to make sure system frees this buffer before driver unloads?
Any help is appreciated
Are you having a problem or is this a theoretical question?
@MBond2 We get a BSOD under driver verifier
presumably, it printed an error message? Maybe share that and !analyze -v
*
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: ffffb28ac499e318, name of the driver having the issue.
Arg3: ffffb28aba29a770, verifier internal structure with driver information.
Arg4: 000000000000000f, 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.
KEY_VALUES_STRING: 1
Key : Analysis.CPU.Sec
Value: 2
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on CCILT381
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.Sec
Value: 3
Key : Analysis.Memory.CommitPeak.Mb
Value: 79
Key : Analysis.System
Value: CreateObject
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
BUGCHECK_CODE: c4
BUGCHECK_P1: 62
BUGCHECK_P2: ffffb28ac499e318
BUGCHECK_P3: ffffb28aba29a770
BUGCHECK_P4: f
IMAGE_NAME: MyFilter.sys
MODULE_NAME: MyPacketFilter
FAULTING_MODULE: fffff802afa80000 MyFilter
VERIFIER_DRIVER_ENTRY: dt nt!_MI_VERIFIER_DRIVER_ENTRY ffffb28aba29a770
Symbol nt!_MI_VERIFIER_DRIVER_ENTRY not found.
BLACKBOXACPI: 1 (!blackboxacpi)
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff30b9eabf3d8 fffff802745dbe44 : 00000000000000c4 0000000000000062 ffffb28ac499e318 ffffb28aba29a770 : nt!KeBugCheckEx
fffff30b9eabf3e0 fffff802745eb179 : ffffb28aba29a770 fffff30b9eabf4d0 ffffb28ac499e1d0 ffffb28ac12eeb50 : nt!VerifierBugCheckIfAppropriate+0xe0
fffff30b9eabf420 fffff80274099dc2 : ffffb28aba29a770 0000000000000000 0000000000000001 ffffb28ac12eeb30 : nt!VfPoolCheckForLeaks+0x49
fffff30b9eabf460 fffff802745cd502 : 0000000000020000 ffffb28ac499e1d0 fffff80274825eb0 fffff80274825eb0 : nt!VfTargetDriversRemove+0x11e5d6
fffff30b9eabf4e0 fffff802742fe503 : ffffb28ac499e1d0 fffff30b9eabf610 0000000000000001 00000000ffffffff : nt!VfDriverUnloadImage+0x3e
fffff30b9eabf510 fffff80274379e01 : 0000000000000000 00000000ffffffff ffff00b600000001 ffff9b8f981c8bc0 : nt!MiUnloadSystemImage+0x2eb
fffff30b9eabf6b0 fffff80274379d2e : ffffb28abfb81c90 fffff30b9eabf850 0000000000000000 ffffb28abfb81cc0 : nt!MmUnloadSystemImage+0x41
fffff30b9eabf6e0 fffff8027424d950 : ffffb28abfb81c90 fffff30b9eabf850 ffffb28abfb81a00 fffff30b9eabf750 : nt!IopDeleteDriver+0x4e
fffff30b9eabf730 fffff80273e4ec07 : 0000000000000000 0000000000000000 fffff30b9eabf850 ffffb28abfb81cc0 : nt!ObpRemoveObjectRoutine+0x80
fffff30b9eabf790 fffff8027406c2b2 : 0000000000000000 ffffb28abfb81cc0 0000000000000000 00000000000000ff : nt!ObfDereferenceObjectWithTag+0xc7
fffff30b9eabf7d0 fffff80273e3d9d2 : 00000012a05f2000 0000000000000001 ffffe00196d40910 0000000000000000 : nt!IopCompleteUnloadOrDelete+0x172872
fffff30b9eabf890 fffff8027424a270 : ffffb28ad48c1220 0000000000000000 0000000000000000 0000000000000000 : nt!IopDecrementDeviceObjectRef+0x162
fffff30b9eabf8f0 fffff8027424d950 : ffffb28a9bf7ebc0 0000000000000000 ffffb28ad48c11f0 0000000000000000 : nt!IopDeleteFile+0x210
fffff30b9eabf970 fffff802742f0724 : 0000000000000000 ffffb28ad48c11f0 fffff802742f0520 ffffb28a9bee8a20 : nt!ObpRemoveObjectRoutine+0x80
fffff30b9eabf9d0 fffff80273ecd6b5 : ffffb28ac1737040 fffff802742f0520 ffffb28a9bee8a20 ffffb28a00000000 : nt!ObpProcessRemoveObjectQueue+0x204
fffff30b9eabfa70 fffff80273f108e5 : ffffb28ac1737040 0000000000000080 ffffb28a9bf06080 0000000000000000 : nt!ExpWorkerThread+0x105
fffff30b9eabfb10 fffff8027400f368 : ffffe001963b6180 ffffb28ac1737040 fffff80273f10890 0000000000000000 : nt!PspSystemThreadStartup+0x55
fffff30b9eabfb60 0000000000000000 : fffff30b9eac0000 fffff30b9eab9000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x28
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: 0xc4_62_LEAKED_POOL_IMAGE_MyFilter.sys
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {b6cc83c1-fb44-e263-63db-d1e9ebb9fc14}
“and will be freed when the proxied flow is removed” - so what is your unload routine doing? At some point you have to call FwpsRedirectHandleDestroy. See the the massive WDF based sample on github: https://github.com/microsoft/Windows-driver-samples/blob/main/network/trans/WFPSampler/syslib/HelperFunctions_FwpObjects.cpp
Yes, we do call FwpsRedirectHandleDestroy in Unload() but still randomaly get above BSOD for leak of localredirectcontext passed to FwpsApplyModifiedLayerData.