Bug Check 0x139 KERNEL_SECURITY_CHECK_FAILURE ?

Hi,

I have created the driver for our device and it is running on windows 7 (32 bit), xp (32bit) successfully. But when I have installed the driver in windows 8 (64 bit). The windows is crashed (blue scree). showing the error message KERNEL_SECURITY_CHECK_FAILURE.

anyone can you please explain why this error is coming only in 64 bit OS and what is the reason behind that.

Thanks.
Raku

Read the rest of the crash info in the !analyze -v … That will usually tell you the exact reason. The most typical cause is corruption of a data structure in pool.

Ok,

But why its happen in 64 bit OS not in 32 bit OS ?

There’s no way to answer that question with the info you’ve provided.

I get the following details:

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: fffff88003591080, Address of the trap frame for the exception that caused the bugcheck
Arg3: fffff88003590fd8, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

FAULTING_MODULE: fffff800d3818000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 53a182a2

TRAP_FRAME: fffff88003591080 – (.trap 0xfffff88003591080)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800a5f0458 rbx=0000000000000000 rcx=0000000000000003
rdx=fffffa800a577de8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800d383289f rsp=fffff88003591210 rbp=0000000000000000
r8=fffff880177ac760 r9=0000000000000668 r10=0000000000000801
r11=fffff880177ab0a0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl nz na po cy
nt!ExInterlockedInsertHeadList+0x97:
fffff800`d383289f cd29 int 29h
Resetting default scope

EXCEPTION_RECORD: fffff88003590fd8 – (.exr 0xfffff88003590fd8)
ExceptionAddress: fffff800d383289f (nt!ExInterlockedInsertHeadList+0x0000000000000097)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000003

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x139

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff800d3871769 to fffff800d3872440

I also got the faulty source code:

FAULTING_SOURCE_LINE_NUMBER: 38
FAULTING_SOURCE_CODE:
35: m_devices.InterlockedInsertHead(this);
36: m_dorecovery = FALSE;

37: }

But I am not getting what is the problem here?

“A list entry has been corrupted.”

Peter
OSR
@OSRDrivers

Peter wrote:

:slight_smile:
And just to add some rattle and hum:

Rakesh wrote:

It seems the problem is just obscured by a c+±constructs you are using.
Isn’t “m_devices” look to be a kind of a wrapper around LIST_ENTRY, SPIN_LOCK and ExInterlocked***List() ?
So then the type of “this” has to somehow contain an instance of LIST_ENTRY. And in turn **::InterlockedInsertHead() should have to properly retrieve the corresponding LIST_ENTRY from the input type.
Is that being proceeded correctly?
If you could publish your underlying sources then please do it so someone would have a chance to be able to note a blunder.

Rakesh wrote:

There is a guess that 32-bit OS doesn’t have such a check, so the problem just exists silently there.

The OP simply needs to debug the problem: Get into the debugger, step through the code, look at the state of the lists before and after the insert attempt, check the way the inserts are being done, and see what’s happening. There’s no magic to be done here.

And posting a whole bunch of code for people on the list to code review really isn’t the most efficient way to find the bug.

As to why 64-bit and not 32-bit, there’s no way to know, and it doesn’t matter the least bit. Because the check’s only in 64-bit, because something different gets corrupted on 32-bit and hasn’t been found, because the code’s different for insert on 64-bit, because the timing is different on the 64-bit system, because the world is round, because it’s Wednesday. It’s entirely irrelevant.

Peter
OSR
@OSRDrivers

Uhu, it’s obvious, rtfm and do things properly. This is the single rule for everything, whatever it’s correct but too hard and boring.

Why not? Is it somehow interfere with a debug session? In turn i’m curious how some things getting broken. Is this a complete OT for ntdev to see how someone get an interlocked list unworking? I’d like to see, as well there would be another chance to solve OP’s problem. Well, while this isn’t a best way but it still is a reasonable way, isn’t it?

I’m confused seeing that. An arch-dependent bug was always for me a sign to check for some specific conditions.

xxxxx@yahoo.co.in wrote:

I also got the faulty source code:

FAULTING_SOURCE_LINE_NUMBER: 38
FAULTING_SOURCE_CODE:
35: m_devices.InterlockedInsertHead(this);
36: m_dorecovery = FALSE;
> 37: }
But I am not getting what is the problem here?

Right, because the problem is not here. The problem is in your
InterlockedInsertHead method. Can you show us that code?

Crashes when moving from 32-bit to 64-bit often happen when a driver
assumes that pointers will fit in a DWORD, or when an ioctl’s structure
has a different size in 32-bit and 64-bit land.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.





Precisely. This is an attitude I don’t appreciate in engineers.

Whenever a new junior engineers joined our group, I asked them “Why do you think programmers like us make such good money?” They’d scratch their heads, and nobody every really had an answer – no problem, it was a rhetorical question. I told them “The reason we make such good money isn’t because we’re outstandingly smart, or have such unusual skills, it’s because we have the tenacity to come to work and deal with trying to find the same bug, day after day, for as many days as it takes to solve the problem. My personal record of longest time working to find a single bug is something like ten straight days of effort.”

I truly believe this. And that’s why I tend not to much appreciate posts with no information, and no indication that the poster’s done any homework, that ask US to discover what’s wrong with THEIR code. If the OP’s not willing to do some significant work to figure it out, I figure why should I?

You, Mr. kt133a, are obviously much more patient on this topic. Which is a good attribute.

And it is well known the Mr. Roberts is an viable candidate for sainthood, based solely on his participation in this forum. His Acta Sancti are well known here.

Peter
OSR
@OSRDrivers

One pretty rare reason for obscure crashes is that the build may not always recompile the affected files when you change a structure definition. Then different files use different structure/class layout.

Thanks for reply to all.

The issue was in destructor. The destructor was not released the pointer. ( I don’t want to explain here because you are already expert).

@Peter:

In this world everything has a reason. without reason nothing will happen in this universe.
If you want to know anything, I will give you the answer. I have also answer why world is round, why today is Wednesday and everything is relevant.

As I just wanted to save my time from debugging to find the solution that’s why I put this question thinking some expert people are here but as I have noticed that some people think there are only smart person in this world.
I also got the reason why crash happen in 64 bit not in 32 bit.

Regards,
Raku

Everything has a cause, and every cause has an effect.

Correlation does not imply causation. And every correlation is not relevant. Implying causation from correlation is a common fallacy. One that you are likely trapped by here.

Yes, that much is evident.

In my experience personal effort tends to yield the greatest gains. When you encounter roadblocks after the application of significant personal effort, THAT is when you tend to learn the most from asking the help of others.

Peter
OSR
@OSRDrivers

On 6/19/2014 12:39 PM, xxxxx@osr.com wrote:

And not every correlation is relevant.

> Thanks for reply to all.

The issue was in destructor. The destructor was not released the pointer.
( I don’t want to explain here because you are already expert).

I’m not sure what you meant to say here. I am interpreting it as “the
destructor failed to release the block of memory referenced by the
pointer”. Of course, this would be a programming error if the class
actually had responsibility for managing that storage, and it would be an
error to release the storage if the class was *not* responsible for
managing that storage. The solution is to copy the data if the class can
work with a copy of the data, thus making the class responsible for the
storage management, or use a reference-counted template class to define
the data if the data class is responsible. Note that just because I’m a
C++ expert (I was a C++ MVP for 15 years), I am not able to use psychic
vibrations to understand what you have done.

@Peter:

In this world everything has a reason. without reason nothing will happen
in this universe.
If you want to know anything, I will give you the answer. I have also
answer why world is round, why today is Wednesday and everything is
relevant.

If the world were deterministic, what you say is true, but Gödel, Post,
Turing, Planck, Schrödinger, and a bunch of other troublemakers back in
the 1930s demonstrated that (a) mathematical systems are incomplete, and
(b) physical system are nondeterministic. In the case of operating
systems, they have all the charm of pure mathematical models coupled with
physical models. So, for example, knowing precisely which one of the
billions of bits is causing unexpected behavior is difficult, and if a
constraint equation can be written such that if it evaluates to “true” the
code will run correctly, and if it evaluates to “false”, the code will
fail, in which case you must evaluate all relevant state at every point in
the code to ensure the required preconditions are satisfied for the
subsequent code to execute correctly. Of course, writing these constraint
equations generally requires that the mathematical system be complete, and
also that verifying these constraint equations not change the timing.
Another one of those troublemakers, Heisenberg, had something to say about
this.

As Peter pointed out, correlation is not causation. And the inherent
nondeterminism of highly parallel systems means that inferring the
*correct* correlation is extremely challenging, and then you have to
verify that this correlation is also causality. So your cheerfully naïve
assertion about causes and consequences, charming though it may be, does
not hold up when analyzing real systems. Which is why it is
all-but-impossible to debug a concurrent system into correctness; if the
correctness under concurrency is not part of the initial design, you can’t
retrofit it.

By the way, the world is not “round”, because that is a two-dimensional
concept. In three dimensions, it would be spherical, which it is not; it
is an oblate spheroid. It is Wednesday because all Christian nations
honor the Norse god, Woden. And whether or not I make a typo in this
message is irrelevant as a cause of any of your problems.

“Not all things that can be counted, count; and not all things that count
can be counted” [attributed to Albert Einstein, found on the
www.adafruit.com Web site]
joe

As I just wanted to save my time from debugging to find the solution
that’s why I put this question thinking some expert people are here but as
I have noticed that some people think there are only smart person in this
world.
I also got the reason why crash happen in 64 bit not in 32 bit.

Regards,
Raku


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> I also got the faulty source code:

FAULTING_SOURCE_LINE_NUMBER: 38
FAULTING_SOURCE_CODE:
35: m_devices.InterlockedInsertHead(this);
36: m_dorecovery = FALSE;
> 37: }

But I am not getting what is the problem here?

Neither am I. Posting code fragments like the one above wastes time and
Internet bandwidth. What is the declaration of m_devices? What is the
declaration of ‘this’?
joe


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer