What are the parameters for this illegal instruction stop code?

NTDEV
1

I bumped into this at one of our customers, but I don’t have a MEMORY.DMP
file, so I don’t have much to go on other than the stop codes:
0x0000001E (0xC000001D,0x8001508C,0x8011C012,0xF1A573A0)

Clearly, the 0x0000001E is KMODE_EXCEPTION_NOT_HANDLED, and the 0xC000001D
is STATUS_ILLEGAL_INSTRUCTION. The 0x8001508C is the address where it found
the illegal instruction (_HalpClockInterrupt+0090 in HAL.DLL, which is
actually not on an instruction boundary, though it’s a mystery why code
would end up there).

But what are the last two parameters for? I can’t find any documentation on
what they would mean in the case of a STATUS_ILLEGAL_INSTRUCTION, nor any
pointers with Google. I tried a quick search using SoftICE for a “PUSH
C000001D”, but didn’t find any that then called KeBugCheckEx, so I was
surprised by that (I’ve used that method before to figure out what
parameters really mean).

Those happen to be two locations in NTOSKRNL.EXE and TCPIP.SYS, but is that
just a coincidence, or is it trying to give me a summary of the call stack,
or what?

Thanks for any pointers (and please let us all know where you found the
information for future reference)!

2

Well I glanced at the trap handlers and STATUS_ILLEGAL_INSTRUCTION is a
“zero argument” trap, which I belive to mean that those two extra arguments
are random garbage. (I could spend a little while convincing myself of that
with higher assurance, but I don’t have the time at the moment.)

In either case, it’s pretty clear why you got the exception. You say
yourself that your processor jumped to a location in between instructions.
That will often cause the processor to decode something that doesn’t seem
legal. The question is why you ended up there. I would guess that your
stack got trashed and then you returned from something, either an interrupt
or a simple call. The address that got picked up as the return address
happened to be _HalpClockInterrupt+0090.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Taed Wynnell” wrote in message news:xxxxx@ntdev…
>I bumped into this at one of our customers, but I don’t have a MEMORY.DMP
> file, so I don’t have much to go on other than the stop codes:
> 0x0000001E (0xC000001D,0x8001508C,0x8011C012,0xF1A573A0)
>
> Clearly, the 0x0000001E is KMODE_EXCEPTION_NOT_HANDLED, and the 0xC000001D
> is STATUS_ILLEGAL_INSTRUCTION. The 0x8001508C is the address where it
> found
> the illegal instruction (_HalpClockInterrupt+0090 in HAL.DLL, which is
> actually not on an instruction boundary, though it’s a mystery why code
> would end up there).
>
> But what are the last two parameters for? I can’t find any documentation
> on
> what they would mean in the case of a STATUS_ILLEGAL_INSTRUCTION, nor any
> pointers with Google. I tried a quick search using SoftICE for a “PUSH
> C000001D”, but didn’t find any that then called KeBugCheckEx, so I was
> surprised by that (I’ve used that method before to figure out what
> parameters really mean).
>
> Those happen to be two locations in NTOSKRNL.EXE and TCPIP.SYS, but is
> that
> just a coincidence, or is it trying to give me a summary of the call
> stack,
> or what?
>
> Thanks for any pointers (and please let us all know where you found the
> information for future reference)!
>
>
>

3

> legal. The question is why you ended up there. I would guess that your

stack got trashed and then you returned from something, either an
interrupt
or a simple call. The address that got picked up as the return address
happened to be _HalpClockInterrupt+0090.

Actually the return address may not have been right there. I’ve more than
once had this sort of thing happen where you return to some totally bogus
address, but what is there is NOT an invalid instruction. So you can
continue executing ‘instructions’ for maybe 3-5 instructions or more before
you finally hit an invalid instruction. Worse, you can sometimes even
decode what appears to be a branch of some kind in the sequence, so the
bogus return address *could* have been almost anywhere.

However, the good bet is the bogus return address was either right where you
landed, or within 15 bytes or so in front of that. I would search around
whatever bits of stack you may have for something that looks odd.

Loren

4

xxxxx@lists.osr.com wrote on 09/12/2004 03:40:09 AM:

> legal. The question is why you ended up there. I would guess that
your
> stack got trashed and then you returned from something, either an
interrupt
> or a simple call. The address that got picked up as the return address
> happened to be _HalpClockInterrupt+0090.

Actually the return address may not have been right there. I’ve more
than
once had this sort of thing happen where you return to some totally bogus
address, but what is there is NOT an invalid instruction. So you can
continue executing ‘instructions’ for maybe 3-5 instructions or more
before
you finally hit an invalid instruction. Worse, you can sometimes even
decode what appears to be a branch of some kind in the sequence, so the
bogus return address *could* have been almost anywhere.

However, the good bet is the bogus return address was either right where
you
landed, or within 15 bytes or so in front of that. I would search around
whatever bits of stack you may have for something that looks odd.

Loren

Depending on what the code that is on the stack looks like, I’d also check
for function pointers that have been corrupted (especially function
pointers that may be on the stack!).

Also, I’ve seen the processor run much more than 15 bytes from where it’s
eventually ended up, including doing all sorts of weird and whacky things.
The only cases where I have been able to prove what happens was when I had
in-circuit emulator to trace what was going on, and I had a trace of
several hundred thousand instructions (well, they were mostly zero’s). The
usual cause for it would be jumping off to somewhere completely crazy after
filling the stack with some garbage (wrong arguments to memcpy or memset
will do this very well!).

Text strings with lower-case characters make very good instructions that
confuse the h*ll out of the processor, because the back half of the lower
case ascii table is 7X hex, and that’s a conditional jump (so not only may
it jump at random because it’s not a proper jump, but also because it’s
hard to figure out what result of the condition was…).

I’ve also seen weird crashes after jumping to a NULL function pointer. My
code wasn’t checking if the function pointer was NULL, and NULL happened to
be mapped in, so it was “valid”. It then found a return, but only after
removing X bytes on the stack, which was a different amount than the
function pointer took, so some random number was used as instruction
pointer…

Some of this will of course be trapped by a processor that has No-eXecute /
eXecute Disable bit in the page table, but since most of use don’t have
Athlon64’s or similar, it’s not much point…

–
Mats