RE: getting bug check 0x109 on server 2012.
It's not only pointer mismanagement, but also potentially state mismanagement.
For instance reinitializing an event that is being waited on in another thread.
Or letting an on stack event do out of scope while still in use.
debt from my phone
Sent: 7/22/2012 2:07 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] getting bug check 0x109 on server 2012.
I can't answer the specific questions, but whenever you get a corruption
message, the most probable cause is storing through an incorrect pointer.
When declaring a local variable for any kind of pointer, you should always
initialize it to NULL, otherwise you may have a perfectly addressible
pointer to an invalid address, such as free storage in the heap or a
perfectly valid allocated object that had been used earlier. The bad news
is that when you corrupt some innocent bystander, you can corrupt
something that all users of that object know to be perfectly valid (an
index or a pointer, just to name a couple), and therefore blindly use it
without checking it. This can in turn damage another structure...anyway,
the worst one I dealt with was (thankfully) in application space and was
absolutely reproducible, and was SEVENTH-level damage before it was
detected (via an access fault). Using the Driver Verifier and enabling
special pool *might* discover if it is a problem in your driver, but it is
not a sure thing.
Some people may try to convince you that writing
WHATEVER * w = NULL;
is "inefficient". You may dismiss these people as totally clueless, and
ignore them, since they are wrong. If all paths of code lead to w being
set before it is used, the compiler will eliminate the unnecessary
initialization: net cost, 0. If there exists any path by which w will not
be set before it is used, the initialization will remain and the access
fault happens in your driver, making it easy to isolate. If an
unnecessary initialization is left in, it costs you, one the average, 1/2
of a CPU clock to execute it on a two-unit pipelined/cached superscalar
architecture; this means each of these initializations, on 2.8GHz Pentium
4, cost you 175 PICOseconds. Big whoop!
(Note that the Core series of processors can dispatch more than two
instructions per clock cycle)
If you are allocating objects from the heap, it is considered Best
Practice to initialize them to 0. This will detect a similar type failure
of using uninitialized pointer fields in heap objects. The cost is again
1/2 a CPU clock cycle per initialization, on the average (remember that,
since the object is newly-allocated, parts of it are already in the L1
Finally, it is ideal if you have at most one pointer to a heap object, and
you set that pointer to NULL after any operation that frees it. Another
good policy is to set IRP pointers to NULL immediately after enqueueing
them or completing them or passing them down to a lower-level driver
(there are numerous exceptions to this last case, such as when an IRP is
When confronted with memory damage problems, I do not first turn to Driver
Verifier, because it is already being used and would have caught the
problem already; instead, I read the code looking for the above problems
and fix them first. It is surprising how frequently this works.
Note also that problems like these in tbe Driver world are often hard to
reproduce because the are the result of particular concurrency
relationships in the code. So your driver almost always damages something
completely harmless, but if some other component of the system thought IT
owned the storage at that time, you're screwed.
The same is true of other drivers; one of your structures may get damaged
by some other driver, leading you to use what you think is a perfectly
valid pointer to store sonething which corrupts yet another structure, and
a damage cascade ensues. Also keep in mind that these detections can
happen tens of billions of instructions after the actual damage is done.
In human terms, think of it as someone removed a manhole cover, and later
someone else walks down the street and falls in. The issue is not that
someone fell in, but who removed the cover? Given the potential time
lags, think of the fact that this cover was removed in the 13th century,
but nobody fell into it (or even noticed it was open) until this morning.
The report that it is the IDT table may be a gratuitous outcome of a
damage cascade. Then again, some piece of malware on that machine might
be deliberately messing with te IDT, and server 2012 is the first version
that is able to detect this, and your driver isn't even involved in the
> Hi Experts,
> Need some suggestions, on how to debug a server. Asking this because it
> is not a client machine which I can connect through 1394,etc.
> I am debugging one critical structure corruption ( bugcheck code 0x109)
> bug. While long run with my application which has a driver component I am
> getting the BSOD. I got kernel memory dump but it is not having relevant
> starck trace and it is pointing to nt module but I am sure that my drivers
> causing this issue.
> From bugcheck code it seems some structure getting corrupted and fourth
> argument of the bugcheck code is indicating that structure type could be
<...excess quoted lines suppressed...>
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at