Hello,
on one of our testing machines I’ve seen a REFERENCE_BY_POINTER bluescreen after some days of continuous testing. Multiple other testing machins run for days without problem and driver verifier also doesn’t report any problems.
I’d looking for ideas how to detect whether my driver caused this BSOD and perhaps how to trigger this effect on my development machine in order to properly fix it.
Here’s the !analyze -v and followup !object ffffe0000bf8cc20 output:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
REFERENCE_BY_POINTER (18)
Arguments:
Arg1: ffffe000002b2080, Object type of the object whose reference count is being lowered
Arg2: ffffe0000bf8cc20, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: 0000000001000000, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object’s reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object?s reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.
Debugging Details:
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x18
PROCESS_NAME: System
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
LAST_CONTROL_TRANSFER: from fffff8014a9e87bb to fffff8014a9ceca0
STACK_TEXT:
ffffd000208efa58 fffff801
4a9e87bb : 0000000000000018 ffffe000
002b2080 ffffe0000bf8cc20 00000000
00000001 : nt!KeBugCheckEx
ffffd000208efa60 fffff801
4ac3b046 : 0000000000080081 ffffe000
0bb8fb80 ffffe00000080081 00000000
00000000 : nt! ?? ::FNODOBFM::string'+0x961b ffffd000
208efaa0 fffff8014a9a4bf8 : fffff801
4abc6000 ffffd000208efb50 ffffe000
0bb8fb88 ffffe0000c111010 : nt!MiSegmentDelete+0x11e ffffd000
208efae0 fffff8014a9b77dd : 00000000
00000000 fffff8014ab45e80 ffffe000
002cd900 0000000000000012 : nt!MiProcessDereferenceList+0x100 ffffd000
208efb70 fffff8014a90e2e4 : ffffe000
002b8040 0000000000000080 ffffe000
002b8040 0000000000000000 : nt!MiDereferenceSegmentThread+0xe9 ffffd000
208efc00 fffff8014a9d52c6 : fffff801
4ab6f180 ffffe000002b8040 fffff801
4abc7a80 0000000000000000 : nt!PspSystemThreadStartup+0x58 ffffd000
208efc60 0000000000000000 : ffffd000
208f0000 ffffd000208ea000 00000000
00000000 00000000`00000000 : nt!KiStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::string'+961b fffff801
4a9e87bb cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string’+961b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 52718d9c
BUCKET_ID_FUNC_OFFSET: 961b
FAILURE_BUCKET_ID: 0x18_CORRUPT_REF_COUNT_nt!??::FNODOBFM::string
BUCKET_ID: 0x18_CORRUPT_REF_COUNT_nt!??::FNODOBFM::string
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x18_corrupt_ref_count_nt!??::fnodobfm::string
FAILURE_ID_HASH: {f79c57ae-b68f-40b5-de2a-a8ffc9173143}
Followup: MachineOwner
0: kd> !object ffffe0000bf8cc20
Object: ffffe0000bf8cc20 Type: (ffffe000002b2080) File
ObjectHeader: ffffe0000bf8cbf0 (new version)
HandleCount: 16777216 PointerCount: 0
Directory Object: 00000000 Name: \Windows\System32\DriverStore\FileRepository\mdmmod.inf_amd64_6cf9ad660a173dab\mdmmod.inf {HarddiskVolumeShadowCopy3}
Thanks and best regards,
Johannes F.