Memory Exception Number
Liou, Jaw-Wu (EXCHANGE:MPK:4B13)
Our application running on NT 3.51 crashed with a Dr. Watson log, in the
log, a memory exception number "c000001e" was reported. Where can I find
more information about this exception? Following is part of the Dr.
Watson log:
Application exception occurred:
App: (pid=485)
When: 6/4/1999 @ 1:37:19.889
Exception number: c000001e
Thanks for the help! Please send response to jwl...@nortelnetworks.com
or post on the group.
Felix Kasza [MVP]
From ntstatus.h (comes with the DDK):
//
// MessageId: STATUS_INVALID_LOCK_SEQUENCE
//
// MessageText:
//
// {Invalid Lock Sequence}
// An attempt was made to execute an invalid lock sequence.
//
#define STATUS_INVALID_LOCK_SEQUENCE ((NTSTATUS)0xC000001EL)
Can you post some of the offending code?
--
Cheers,
Felix.
If you post a reply, kindly refrain from emailing it, too.
Note to spammers: fel...@mvps.org is my real email address.
No anti-spam address here. Just one comment: IN YOUR FACE!
Liou, Jaw-Wu (EXCHANGE:MPK:4B13)
***********************************
State Dump for Thread Id 0x1ee
eax=01530098 ebx=0000002f ecx=0153f358 edx=01530000 esi=0153f18c
edi=0153f280
eip=00429231 esp=01a1bc0c ebp=01a1c2b3 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00000202
function: <nosymbols>
00429230 4d dec ebp
FAULT ->00429231 f0e969a2ffff lock jmp 004234a0
00429237 cc int 3
**************************************************
Notice, the fault happened at the instruction "lock" which is consistent
to your finding. After checking Intel's Pentium Processor Develop's
Manual, "The LOCK prefix causes the LOCK# signal of the Pentium
processor to be asserted during the execution of the instruction that
follows it".
The source code is like this:
child_class::child_class() NOTE: this is the copy constructor
of the child_class
:parent_class()
{
...
}
Notice the copy constructor starts at "00429230", and "004234a0" is the
starting address of the constructor of the parent_class, i.e. the
application crashed when the copy constructor of the child_class try to
initialize the parent_class. But I don't think this is a application
code problem because this copy constructor is used al the time. Also,
another netter email me a link to an MSDN Online article that seems to
suggest it is a hardware error. Here is the link:
http://msdn.microsoft.com/library/sdkdoc/cifs/cifs5_5rn4.htm
He also suggested to take a look at winerror.h which describe how
interpret the number. I think ntstatus.h just build on top of this
header file.
Raymond Chen
Clearly your EIP went into the weeds, possibly due to...
1. using a destroyed object (jumping through a freed vtbl) or
2. overwriting a buffer, or
3. using an uninitialized pointer variable.
--
(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.)
Felix Kasza [MVP]
> Notice the copy constructor starts at "00429230", and "004234a0" is the
> starting address of the constructor of the parent_class, i.e. the
> application crashed when the copy constructor of the child_class try to
> initialize the parent_class.
Raymond already gave you the short answer.
The long answer is, 429230h _cannot_ be the entry point for any
function, ctor or otherwise: "dec ebp" would point EBP at an unaligned
address, when in reality it must use the same alignment as ESP.
Either someone jumped into the middle of an instruction, or someone
overwrote code (which is quite hard to do accidentally). The former
seems more probable, especially as it could also happen by stomping on
the retaddress in some stackframe -- overflowing buffers are a classic
example.
Liou, Jaw-Wu (EXCHANGE:MPK:4B13)
One of the colleague pointed me to the winerror.h under /MSDEV/include which
show a format for deciphering the error code, it looks like this:
Severity|C|R|Facility|Code
and according to this format, c000001e becomes: Severity = Error, C = 0, R =
0, Facility = 0 (FACILITY_NULL), Code = 30 (ERROR_READ_FAULT)
Is this a different way of saying the same thing you and Raymond talked about?
Because, he further send me a link to an MSDN Online article which seems to
suggest this is a haedware problem.
You have to forgive me, since I don't have much experiences ventured into NT
world yet, I still don't understand you longer version. Are you suggesting the
most possible cause is memory corruption in the application? Following things
are what we gethered from our customer support (BTW, this happened at our
customer site and for sure they will not let us play with their servers, i.e.
try to reproduce the probelm):
1). So far, this only happen once (knock on wood).
2) It happened during application startup.
3) The map file indicates it happened at the copy constructor of a class
attempting to inntialize its parent class.
I've borrowed Intel's Pentium Processor Develop's Manual from another group
(our group "only" do application development in VC++, :+)!!), in the page
describe the "lock" instruction, it suggested 1) sone kind of assertion will
be done before the execution of next instruction, in this casse "jmp xxx", 2)
JMP shouldn't be used with lock and the page gave a list of instructions that
can be used with lock, e.g. BTS, BTR, XCHG. Am I on a wrong track?
Thanks for your help!
Felix Kasza [MVP]
> One of the colleague pointed me to the winerror.h under /MSDEV/include which
> show a format for deciphering the error code, it looks like this:
Winerror.h is nice, but _exception_ codes bubbling up from lower layers
are NTSTATUS values (which also follow the winerror convention). No
matter.
> Because, he further send me a link to an MSDN Online article which seems to
> suggest this is a haedware problem.
It may be, but unless your machine is round the bend, the possibility
seems remote to me. For every confirmed hardware problem affecting code
execution (as opposed to killing the machine outright), I see myriad
logic errors.
> Are you suggesting the most possible cause is memory corruption
> in the application?
Yes. It is evident that either your code changed without warning while
loaded; or that something caused a jump to the wrong address (in the
middle of an instruction -- one of the leftover bytes would be the
"lock" you see); or that the compiler generated faulty code in the first
place.
My money is on the second cause. Since regular jump instructions are
located in code pages, to which you do not, one hopes, write (you'd need
to change their protection beforehand), it is unlikely that one of those
changed. The most common mechanisms which store code addresses in
writable memory are subroutine calls (the return address is on the
stack) and function pointers (the target address is wherever you want it
to be). Since it is quite easy to stomp on the stack by overflowing a
stack-allocated buffer, by not checking where you write through a
pointer pointing into the stack, and so on, this would be one of the
first possibilities I'd check.
> 1). So far, this only happen once (knock on wood).
In that case, and given my assumptions above, forget about reproducing
the problem. Concentrate on argument validation and algorithm
verification -- review, review, review.
> 3) The map file indicates it happened at the copy constructor of a class
> attempting to inntialize its parent class.
NO NO NO. Forget this. The address you saw was already the _wrong_
target, in my considered opinion. What you need to find is the
instruction that _caused_ the jump to that address, and the reason why
the target of that instruction was invalid.
> in the page describe the "lock" instruction [...]
And forget that, too. I am normally the anal-retentive type who says
that anyone trying to use a debugger should first learn fundamentals of
assembly language for his CPU and call/arg-passing/return mechanisms for
his compiler, but in this case, looking at the "lock" is wrong. I'll bet
a day of my time that the "lock" is an artifact. Consider:
00400000 add eax, 12345678h
If you jump to address 00400001, the CPU sees the bytes "78 56 34 12".
Dr. Watson will try to disassemble this and show you things that aren't
really there. Recognizing that kind of artifact is one of the most
important things to learn for successful debugging.