REFERENCE_BY_POINTER from ntoskrnl.exe+1677bb

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 fffff8014a9e87bb : 0000000000000018 ffffe000002b2080 ffffe0000bf8cc20 0000000000000001 : nt!KeBugCheckEx
ffffd000208efa60 fffff8014ac3b046 : 0000000000080081 ffffe0000bb8fb80 ffffe00000080081 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x961b ffffd000208efaa0 fffff8014a9a4bf8 : fffff8014abc6000 ffffd000208efb50 ffffe0000bb8fb88 ffffe0000c111010 : nt!MiSegmentDelete+0x11e ffffd000208efae0 fffff8014a9b77dd : 0000000000000000 fffff8014ab45e80 ffffe000002cd900 0000000000000012 : nt!MiProcessDereferenceList+0x100 ffffd000208efb70 fffff8014a90e2e4 : ffffe000002b8040 0000000000000080 ffffe000002b8040 0000000000000000 : nt!MiDereferenceSegmentThread+0xe9 ffffd000208efc00 fffff8014a9d52c6 : fffff8014ab6f180 ffffe000002b8040 fffff8014abc7a80 0000000000000000 : nt!PspSystemThreadStartup+0x58 ffffd000208efc60 0000000000000000 : ffffd000208f0000 ffffd000208ea000 0000000000000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::string'+961b fffff8014a9e87bb 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.

A file object has a reference count of zero but a non-zero handle count.
This is invalid, each handle adds a reference so handle count should be <=
reference count.

What does your driver do? Do you open handles to local files?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

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 fffff8014a9e87bb : 0000000000000018 ffffe000002b2080
ffffe0000bf8cc20 0000000000000001 : nt!KeBugCheckEx
ffffd000208efa60 fffff8014ac3b046 : 0000000000080081 ffffe0000bb8fb80
ffffe00000080081 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x961b ffffd000208efaa0 fffff8014a9a4bf8 : fffff8014abc6000 ffffd000208efb50 ffffe0000bb8fb88 ffffe0000c111010 : nt!MiSegmentDelete+0x11e ffffd000208efae0 fffff8014a9b77dd : 0000000000000000 fffff8014ab45e80 ffffe000002cd900 0000000000000012 : nt!MiProcessDereferenceList+0x100 ffffd000208efb70 fffff8014a90e2e4 : ffffe000002b8040 0000000000000080 ffffe000002b8040 0000000000000000 : nt!MiDereferenceSegmentThread+0xe9 ffffd000208efc00 fffff8014a9d52c6 : fffff8014ab6f180 ffffe000002b8040 fffff8014abc7a80 0000000000000000 : nt!PspSystemThreadStartup+0x58 ffffd000208efc60 0000000000000000 : ffffd000208f0000 ffffd000208ea000 0000000000000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::string'+961b fffff8014a9e87bb 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.

Hi Scott,

my driver just uses WinsockKernel for sending and receiving UDP packets. I don’t open any files and I don’t know anything about the mdmmod.inf mentioned in the dump. And during our longterm tests, my driver even doesn’t open and close sockets all the time, but just sends and receives lots of packets all the time from sockets, which have been opened - in this case - 10 hours earlier. So already millions of packets will have been handled without problems.

I’ve found some other posts concerning a REFERENCE_BY_POINTER issue, but the stackdumps there always show the driver of the corresponding developer. Is there a way to detect whether my driver caused this problem?

And - apart from my driver - I found the Arg4: 0000000001000000 (or HandleCount: 16777216) interesting. Is this a limit for number of handles?

Thanks and best regards,
Johannes F.

If you’re not directly manipulating handles or reference counts in your
driver then we can eliminate this being a simple API misuse bug. It could be
a memory corruption though, so I can’t tell you for certain if you caused it
or not.

Start by trying to better characterize the corruption. This is a pool
allocation, so run:

!pool ffffe0000bf8cc20 1

Look at the addresses around the corrupted region and see if the data
patterns map to anything you might be doing.

Also, as always, try enabling Verifier and see if you get a crash earlier.

I wouldn’t put too much into the handle count value, I suspect that it’s
just part of the memory scribble.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi Scott,

my driver just uses WinsockKernel for sending and receiving UDP packets. I
don’t open any files and I don’t know anything about the mdmmod.inf
mentioned in the dump. And during our longterm tests, my driver even doesn’t
open and close sockets all the time, but just sends and receives lots of
packets all the time from sockets, which have been opened - in this case -
10 hours earlier. So already millions of packets will have been handled
without problems.

I’ve found some other posts concerning a REFERENCE_BY_POINTER issue, but the
stackdumps there always show the driver of the corresponding developer. Is
there a way to detect whether my driver caused this problem?

And - apart from my driver - I found the Arg4: 0000000001000000 (or
HandleCount: 16777216) interesting. Is this a limit for number of handles?

Thanks and best regards,
Johannes F.

And what is the object which is under-refed? your file object?

wrote in message news:xxxxx@ntdev…
> Hi Scott,
>
> my driver just uses WinsockKernel for sending and receiving UDP packets. I don’t open any files and I don’t know anything about the mdmmod.inf mentioned in the dump. And during our longterm tests, my driver even doesn’t open and close sockets all the time, but just sends and receives lots of packets all the time from sockets, which have been opened - in this case - 10 hours earlier. So already millions of packets will have been handled without problems.
>
> I’ve found some other posts concerning a REFERENCE_BY_POINTER issue, but the stackdumps there always show the driver of the corresponding developer. Is there a way to detect whether my driver caused this problem?
>
> And - apart from my driver - I found the Arg4: 0000000001000000 (or HandleCount: 16777216) interesting. Is this a limit for number of handles?
>
> Thanks and best regards,
> Johannes F.
>

Hello,

here’s the output of “!pool ffffe0000bf8cc20 1” round the given address:

ffffe0000bf8ca40 size: 20 previous size: 40 (Free) Free
ffffe0000bf8ca50 0a125d80 ffffe000 089a0160 ffffe000

ffffe0000bf8ca60 size: 150 previous size: 20 (Allocated) File
ffffe0000bf8ca70 00000400 00000180 00000000 ffffe000
ffffe0000bf8ca80 00000000 00000000 00000001 00000000
ffffe0000bf8ca90 00000000 00000000 00000000 00000000
ffffe0000bf8caa0 00000010 00000000 00000000 00000000
ffffe0000bf8cab0 00000000 00000000 400c001e 00000000
ffffe0000bf8cac0 04138340 ffffe000 00000000 00000000
ffffe0000bf8cad0 00d80005 00000000 02966ba0 ffffe000
ffffe0000bf8cae0 02966ae0 ffffe000 02412aa0 ffffc000
ffffe0000bf8caf0 02412cc0 ffffc000 093d0f58 ffffe000
ffffe0000bf8cb00 00000000 00000000 00000000 00000000
ffffe0000bf8cb10 00000000 00000000 00010000 01000100
ffffe0000bf8cb20 00044062 00000000 00f80090 00000000
ffffe0000bf8cb30 0aaa22b0 ffffc000 0000047f 00000000
ffffe0000bf8cb40 00000000 00000000 00000000 00000000
ffffe0000bf8cb50 00060001 00000000 0bf8cb58 ffffe000
ffffe0000bf8cb60 0bf8cb58 ffffe000 00060000 00000000
ffffe0000bf8cb70 0bf8cb70 ffffe000 0bf8cb70 ffffe000
ffffe0000bf8cb80 00000000 00000000 00000000 00000000
ffffe0000bf8cb90 0bf8cb90 ffffe000 0bf8cb90 ffffe000
ffffe0000bf8cba0 00000000 00000000 00000000 00000000

*ffffe0000bf8cbb0 size: 150 previous size: 150 (Allocated) *File
Pooltag File : File objects
ffffe0000bf8cbc0 00000400 00000180 00000000 ffffe000
ffffe0000bf8cbd0 00000000 00000000 00000000 00000000
ffffe0000bf8cbe0 00000000 00000000 00000000 00000000
ffffe0000bf8cbf0 00000000 00000000 01000000 00000000
ffffe0000bf8cc00 00000000 00000000 400c001e 00000000
ffffe0000bf8cc10 4ab21d80 fffff801 00000000 00000000
ffffe0000bf8cc20 00d80005 00000000 0bf728b0 ffffe000
ffffe0000bf8cc30 0c721180 ffffe000 0d454c30 ffffc000
ffffe0000bf8cc40 0d454e50 ffffc000 0b184d38 ffffe000
ffffe0000bf8cc50 00000000 00000000 00000000 00000000
ffffe0000bf8cc60 00000000 00000000 00010000 00000100
ffffe0000bf8cc70 00044042 00000000 00f800b2 00000000
ffffe0000bf8cc80 0d43cc30 ffffc000 00000000 00000000
ffffe0000bf8cc90 00000000 00000000 00000000 00000000
ffffe0000bf8cca0 00060001 00000000 0bf8cca8 ffffe000
ffffe0000bf8ccb0 0bf8cca8 ffffe000 00060000 00000000
ffffe0000bf8ccc0 0bf8ccc0 ffffe000 0bf8ccc0 ffffe000
ffffe0000bf8ccd0 00000000 00000000 00000000 00000000
ffffe0000bf8cce0 0bf8cce0 ffffe000 0bf8cce0 ffffe000
ffffe0000bf8ccf0 00000000 00000000 00000000 00000000

ffffe0000bf8cd00 size: 10 previous size: 150 (Free) Free

ffffe0000bf8cd10 size: 90 previous size: 10 (Allocated) Vadl
ffffe0000bf8cd20 016dc300 ffffe000 0b524360 ffffe000
ffffe0000bf8cd30 029a5850 ffffe000 0007f17b 0007f17d
ffffe0000bf8cd40 00000000 00000000 00000000 00000000
ffffe0000bf8cd50 0000c020 80000003 099b3700 ffffe000
ffffe0000bf8cd60 00000000 00000000 00000000 00000000
ffffe0000bf8cd70 00000000 00000000 00000000 00000000
ffffe0000bf8cd80 00000000 00000000 00000000 00000000
ffffe0000bf8cd90 00000000 00000000 00000000 00000000

ffffe0000bf8cda0 size: 130 previous size: 90 (Allocated) Irp
ffffe0000bf8cdb0 01180006 00000002 00000000 00000000
ffffe0000bf8cdc0 00000000 00000000 00000000 00000000
ffffe0000bf8cdd0 0bf8cdd0 ffffe000 0bf8cdd0 ffffe000
ffffe0000bf8cde0 00000000 00000000 000000e8 00000000
ffffe0000bf8cdf0 02010100 04000000 00000000 00000000
ffffe0000bf8ce00 00000000 00000000 00000000 00000000
ffffe0000bf8ce10 00000000 00000000 00000000 00000000
ffffe0000bf8ce20 00000000 00000000 00000001 00000000
ffffe0000bf8ce30 00000000 00000000 00000000 00000000
ffffe0000bf8ce40 00000000 00000000 00000000 00000000
ffffe0000bf8ce50 00000000 00000000 00000000 00000000
ffffe0000bf8ce60 00000000 00000000 0bf8cec8 ffffe000
ffffe0000bf8ce70 00000000 00000000 00000000 00000000
ffffe0000bf8ce80 0000000f 00000000 00000000 00000000
ffffe0000bf8ce90 00000000 00000000 00000000 00000000
ffffe0000bf8cea0 00000000 00000000 03bdde50 ffffe000
ffffe0000bf8ceb0 00000000 00000000 04cf7c04 fffff800
ffffe0000bf8cec0 0044a200 ffffe000 00000000 00000000

To me the File object at ffffe0000bf8ca60 is quite similar to the File at ffffe0000bf8cbb0, which is referenced in this BSOD. Do you think this looks like a corrupted memory?

I have my driver running on another W8.1 x64 machine with driver verifier active and all options enabled (standard and additional) now for several days without problems.

No, I don’t open any files in my driver, so I’d rather think it’s a memory corruption issue. Or perhaps perhaps perhaps it’s not a problem inside my driver - but then I’d like to find some hints or even better proofs for this approach.

Thanks and best regards,
Johannes F.

Pretty good luck to have another file object in the same page to compare it
to, gotta love that…

They’re similar, but one of them is definitely corrupted. The first file
object in the page has a reference count of 0x10 and a handle count of zero,
which could be valid:

ffffe0000bf8ca60 size: 150 previous size: 20 (Allocated) File
ffffe0000bf8ca70 00000400 00000180 00000000 ffffe000
ffffe0000bf8ca80 00000000 00000000 00000001 00000000
ffffe0000bf8ca90 00000000 00000000 00000000 00000000
ffffe0000bf8caa0 00000010 00000000 00000000 00000000

Object Header is at ffffe0000bf8caa0 and here are the first two fields:

3: kd> dt nt!_object_header
+0x000 PointerCount : Int8B
+0x008 HandleCount : Int8B

However, in your corrupted one you have a reference count of zero and a
handle count of 0x1000000, which is the reason for the crash:

*ffffe0000bf8cbb0 size: 150 previous size: 150 (Allocated) *File
Pooltag File : File objects
ffffe0000bf8cbc0 00000400 00000180 00000000 ffffe000
ffffe0000bf8cbd0 00000000 00000000 00000000 00000000
ffffe0000bf8cbe0 00000000 00000000 00000000 00000000
ffffe0000bf8cbf0 00000000 00000000 01000000 00000000

There’s also another DWORD that is different between the two
(ffffe0000bf8cbd8 in the second listing), though I can't say for certain what the range of valid values could be there so I can't say if zero at ffffe0000bf8cbd8 is valid or not.

Two things to look at from here:

  1. Are there any third party drivers on this machine or is it a clean
    install?

  2. Does the value 0x1000000 mean anything to your driver or the data that
    you’re processing?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hello,

here’s the output of “!pool ffffe0000bf8cc20 1” round the given address:

ffffe0000bf8ca40 size: 20 previous size: 40 (Free) Free
ffffe0000bf8ca50 0a125d80 ffffe000 089a0160 ffffe000

ffffe0000bf8ca60 size: 150 previous size: 20 (Allocated) File
ffffe0000bf8ca70 00000400 00000180 00000000 ffffe000
ffffe0000bf8ca80 00000000 00000000 00000001 00000000
ffffe0000bf8ca90 00000000 00000000 00000000 00000000
ffffe0000bf8caa0 00000010 00000000 00000000 00000000
ffffe0000bf8cab0 00000000 00000000 400c001e 00000000
ffffe0000bf8cac0 04138340 ffffe000 00000000 00000000
ffffe0000bf8cad0 00d80005 00000000 02966ba0 ffffe000
ffffe0000bf8cae0 02966ae0 ffffe000 02412aa0 ffffc000
ffffe0000bf8caf0 02412cc0 ffffc000 093d0f58 ffffe000
ffffe0000bf8cb00 00000000 00000000 00000000 00000000
ffffe0000bf8cb10 00000000 00000000 00010000 01000100
ffffe0000bf8cb20 00044062 00000000 00f80090 00000000
ffffe0000bf8cb30 0aaa22b0 ffffc000 0000047f 00000000
ffffe0000bf8cb40 00000000 00000000 00000000 00000000
ffffe0000bf8cb50 00060001 00000000 0bf8cb58 ffffe000
ffffe0000bf8cb60 0bf8cb58 ffffe000 00060000 00000000
ffffe0000bf8cb70 0bf8cb70 ffffe000 0bf8cb70 ffffe000
ffffe0000bf8cb80 00000000 00000000 00000000 00000000
ffffe0000bf8cb90 0bf8cb90 ffffe000 0bf8cb90 ffffe000
ffffe0000bf8cba0 00000000 00000000 00000000 00000000

*ffffe0000bf8cbb0 size: 150 previous size: 150 (Allocated) *File
Pooltag File : File objects
ffffe0000bf8cbc0 00000400 00000180 00000000 ffffe000
ffffe0000bf8cbd0 00000000 00000000 00000000 00000000
ffffe0000bf8cbe0 00000000 00000000 00000000 00000000
ffffe0000bf8cbf0 00000000 00000000 01000000 00000000
ffffe0000bf8cc00 00000000 00000000 400c001e 00000000
ffffe0000bf8cc10 4ab21d80 fffff801 00000000 00000000
ffffe0000bf8cc20 00d80005 00000000 0bf728b0 ffffe000
ffffe0000bf8cc30 0c721180 ffffe000 0d454c30 ffffc000
ffffe0000bf8cc40 0d454e50 ffffc000 0b184d38 ffffe000
ffffe0000bf8cc50 00000000 00000000 00000000 00000000
ffffe0000bf8cc60 00000000 00000000 00010000 00000100
ffffe0000bf8cc70 00044042 00000000 00f800b2 00000000
ffffe0000bf8cc80 0d43cc30 ffffc000 00000000 00000000
ffffe0000bf8cc90 00000000 00000000 00000000 00000000
ffffe0000bf8cca0 00060001 00000000 0bf8cca8 ffffe000
ffffe0000bf8ccb0 0bf8cca8 ffffe000 00060000 00000000
ffffe0000bf8ccc0 0bf8ccc0 ffffe000 0bf8ccc0 ffffe000
ffffe0000bf8ccd0 00000000 00000000 00000000 00000000
ffffe0000bf8cce0 0bf8cce0 ffffe000 0bf8cce0 ffffe000
ffffe0000bf8ccf0 00000000 00000000 00000000 00000000

ffffe0000bf8cd00 size: 10 previous size: 150 (Free) Free

ffffe0000bf8cd10 size: 90 previous size: 10 (Allocated) Vadl
ffffe0000bf8cd20 016dc300 ffffe000 0b524360 ffffe000
ffffe0000bf8cd30 029a5850 ffffe000 0007f17b 0007f17d
ffffe0000bf8cd40 00000000 00000000 00000000 00000000
ffffe0000bf8cd50 0000c020 80000003 099b3700 ffffe000
ffffe0000bf8cd60 00000000 00000000 00000000 00000000
ffffe0000bf8cd70 00000000 00000000 00000000 00000000
ffffe0000bf8cd80 00000000 00000000 00000000 00000000
ffffe0000bf8cd90 00000000 00000000 00000000 00000000

ffffe0000bf8cda0 size: 130 previous size: 90 (Allocated) Irp
ffffe0000bf8cdb0 01180006 00000002 00000000 00000000
ffffe0000bf8cdc0 00000000 00000000 00000000 00000000
ffffe0000bf8cdd0 0bf8cdd0 ffffe000 0bf8cdd0 ffffe000
ffffe0000bf8cde0 00000000 00000000 000000e8 00000000
ffffe0000bf8cdf0 02010100 04000000 00000000 00000000
ffffe0000bf8ce00 00000000 00000000 00000000 00000000
ffffe0000bf8ce10 00000000 00000000 00000000 00000000
ffffe0000bf8ce20 00000000 00000000 00000001 00000000
ffffe0000bf8ce30 00000000 00000000 00000000 00000000
ffffe0000bf8ce40 00000000 00000000 00000000 00000000
ffffe0000bf8ce50 00000000 00000000 00000000 00000000
ffffe0000bf8ce60 00000000 00000000 0bf8cec8 ffffe000
ffffe0000bf8ce70 00000000 00000000 00000000 00000000
ffffe0000bf8ce80 0000000f 00000000 00000000 00000000
ffffe0000bf8ce90 00000000 00000000 00000000 00000000
ffffe0000bf8cea0 00000000 00000000 03bdde50 ffffe000
ffffe0000bf8ceb0 00000000 00000000 04cf7c04 fffff800
ffffe0000bf8cec0 0044a200 ffffe000 00000000 00000000

To me the File object at ffffe0000bf8ca60 is quite similar to the File at
ffffe0000bf8cbb0, which is referenced in this BSOD. Do you think this looks
like a corrupted memory?

I have my driver running on another W8.1 x64 machine with driver verifier
active and all options enabled (standard and additional) now for several
days without problems.

No, I don’t open any files in my driver, so I’d rather think it’s a memory
corruption issue. Or perhaps perhaps perhaps it’s not a problem inside my
driver - but then I’d like to find some hints or even better proofs for this
approach.

Thanks and best regards,
Johannes F.

Hi Scott,

many thanks for your detailed answers. I forwarded your question about third party drivers to the testing crew which has access to this machine.

Well … does the value 0x1000000 mean anything special to my driver … hmm, there’s no piece of code where I’m setting this value directly, but for sure a combination of 0x01 and 0x00 is something used very frequently. But for a “real” memory corruption I’d have expected a bigger range to be different, not only one DWORD or a few DWORDs. Although it’s hard to say, as the surrounding 0x00 values are also not unusual.

Is there a possibility to check whether another driver accesses the mdmmod.inf file on this machine? … perhaps by using driver verifier?

Thanks and best regards,
Johannes F.

Corruptions don’t have to cover large portions of memory. For example:
imagine that you allocate a small structure out of non-paged pool, free it,
but then continue to use the structure.

And you’re right, the zeroes could be part of the corruption as well, it’s
impossible to say.

I strongly suspect this is just a red herring, something corrupted memory
and this is how we happened to trip over it.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi Scott,

many thanks for your detailed answers. I forwarded your question about third
party drivers to the testing crew which has access to this machine.

Well … does the value 0x1000000 mean anything special to my driver …
hmm, there’s no piece of code where I’m setting this value directly, but for
sure a combination of 0x01 and 0x00 is something used very frequently. But
for a “real” memory corruption I’d have expected a bigger range to be
different, not only one DWORD or a few DWORDs. Although it’s hard to say, as
the surrounding 0x00 values are also not unusual.

Is there a possibility to check whether another driver accesses the
mdmmod.inf file on this machine? … perhaps by using driver verifier?

Thanks and best regards,
Johannes F.

Hi Scott,

is it also possible that this kind of corruption happened without freeing memory and accessing it afterwards? At this time my driver should not allocate or free any memory. All the allocating and freeing is done while setting up or releasing the sockets. So if my driver accesses memory, which has never been allocated before or it writes behind the allocated range - meaning it just uses invalid pointers - could this result in such a REFERENCE_BY_POINTER or shouldn’t this always result in a DRIVER_IRQL_NOT_LESS_OR_EQUAL pointing to my driver?

Thanks and best regards,
Johannes F.

Sure. It’s pretty bad luck to have an uninitialized/invalid pointer end up
pointing into someone else’s valid memory region, but it’s possible. The O/S
doesn’t have a way to trigger a crash in this case, as far as the CPU and
O/S are concerned you’re accessing valid memory.

Good excuse to do a code review while you wait for any hits with Verifier
enabled (or for a better idea).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi Scott,

is it also possible that this kind of corruption happened without freeing
memory and accessing it afterwards? At this time my driver should not
allocate or free any memory. All the allocating and freeing is done while
setting up or releasing the sockets. So if my driver accesses memory, which
has never been allocated before or it writes behind the allocated range -
meaning it just uses invalid pointers - could this result in such a
REFERENCE_BY_POINTER or shouldn’t this always result in a
DRIVER_IRQL_NOT_LESS_OR_EQUAL pointing to my driver?

Thanks and best regards,
Johannes F.

Hi Scott,

does this mean, the driver verifier actually would check whether it’s “my valid memory” and not just “any valid memory”?

Tomorrow I should have direct access to the machine which has once shown this BSOD. Now this machine and 12 more different machines (some with driver verifier enabled) are running for several days without BSOD. But I will do some tests with driver verifier enabled for my driver and also for other drivers on this machine.And I’ve been told that it’s no clean install on this machine - so I will also have a look at the other drivers.

Thanks once more, I highly appreciate your help,
Johannes F.

>so I will also have a look at the other drivers.

Oh yes.

There are good chances one of them is to blame.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

No, it doesn’t isolate you to that extent. In truth, Verifier wouldn’t be
able to catch a stray write into someone else’s valid memory (how would
Verifier know that you’re not deliberately sharing it?).

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Hi Scott,

does this mean, the driver verifier actually would check whether it’s “my
valid memory” and not just “any valid memory”?

Tomorrow I should have direct access to the machine which has once shown
this BSOD. Now this machine and 12 more different machines (some with driver
verifier enabled) are running for several days without BSOD. But I will do
some tests with driver verifier enabled for my driver and also for other
drivers on this machine.And I’ve been told that it’s no clean install on
this machine - so I will also have a look at the other drivers.

Thanks once more, I highly appreciate your help,
Johannes F.