🔒 Locked

What does Illegal Instruction mean?

Started by VanillaSnake21 Jun 25, 2007 at 1:59 AM 1 replies 31.8k views

Original Post

Jun 25, 2007 at 1:59 AM

Hi, something weird keeps happening to my asm application, first off its a 16 bit app, running under WindXP, made with masm and a 16 bit link.exe. It seems to be throwing C:\WINDOWS\system32\cmd.exe The NTVDM CPU has encountered an illegal instruction. CS:0f18 IP:00ef OP:63 6f 6e 64 2e Choose 'Close' to terminate the application. but this error comes up whenever it feels like it, so for example I can assemble the application, and it runs fine, but then I add a few spaces to the source file to change it a little and save, then rebuild, and it shows me that error, I can't seem to pinpoint where it's coming from since it stops showing up for a while then it comes back. Does anyone know what this might means, illegal instruction? And what might be causing it? Thanks

Evil Steve

Jun 25, 2007 at 3:17 AM

Illegal instruction means that there's a byte in the assembled file which doesn't represent a valid CPU instruction. E.g. 0x90 is NOP, but 0xff probably doesn't map to a valid instruction.

When the CPU comes to a byte it can't understand, it throws an illegal instruction exception.

It's usualyl caused by using a broken function pointer to vtable in C/C++ source, or if you're writing in assembly, it could be that you're jumping to an invalid offset, or the assembler is creating broken output.

The Instruction Pointer (IP) tells you what instruction the CPU was on when the exception occurred, which is IP:00ef in your code - although I really don't know how to translate that to an instruction (I've never done 16-bit ASM).

VanillaSnake21

Jun 25, 2007 at 6:23 PM

Quote:
Original post by Evil Steve
Illegal instruction means that there's a byte in the assembled file which doesn't represent a valid CPU instruction. E.g. 0x90 is NOP, but 0xff probably doesn't map to a valid instruction.

When the CPU comes to a byte it can't understand, it throws an illegal instruction exception.

It's usualyl caused by using a broken function pointer to vtable in C/C++ source, or if you're writing in assembly, it could be that you're jumping to an invalid offset, or the assembler is creating broken output.

The Instruction Pointer (IP) tells you what instruction the CPU was on when the exception occurred, which is IP:00ef in your code - although I really don't know how to translate that to an instruction (I've never done 16-bit ASM).

Thanks, I could run the code through CodeView, and check out where the IP is 00EF,
to find the faulty line. =D

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.