Handling 'Unexpected Interrupt 0D' Errors Under NT?

Jersiais asks: "I am trying to get some command line stuff running on NT4 server with Take Control installed on an old 200MH Pentium II (Before anybody throws up, it's the test-it-&-wreck-it machine, not the real thing so there's no actual LAN there). Even on the real thing the compiler under command line has a tendency to blow up at random with 'Unexpected Interrupt 0D'. This only happens on the Pentium II, on the real (Workstation) thing it doesn't. I've found 3 different descriptions of Int 0D, none of which make any sense. Anybody any ideas how to get around it, or get rid of it? The compiler is 32-bit to interpreted intermediate and I have a RP calculator running as a test on the work system already, despite its use of soft interrupt IO."

http://www.google.com/search?hl=en&lr=&ie=

[Anonymous Coward]

http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe =utf-8&q=%22Unexpected+Interrupt+0D%22&btnG=Google +Search [google.com]

Ralph Brown's interrupt list..

[Jon-o]

I know next to nothing on the subject, but when I was tinkering about back in the good ole' DOS days, I came across this list of interrupts: http://www.delorie.com/djgpp/doc/rbinter/

I expect most people have seen it. It lists the following fod 0d:

0D INT 0D C - IRQ5 - FIXED DISK (PC,XT), LPT2 (AT), reserved (PS/2)
0D INT 0D C - IRQ5 - Tandy 1000 60 Hz RAM REFRESH
0D INT 0D - HP 95LX - INFRARED INTERRUPT
0D INT 0D C - CPU-generated (80286+) - GENERAL PROTECTION VIOLATION

Possibly a hardware problem, or bad software

[Anonymous Coward]

Int 0Dh is General Protection Fault, issued by the processor when illegal instructions or memory accesses are encountered. It's likely your compiler is catching GPF's instead of letting them pass on to Windows where you would get the generic "This program has crashed...blah blah" message. The interrupt could be caused by bad software or bad hardware. Gcc randomly crashes with the same interrupt on bad hardware, normally bad memory or processor cache.

Your equipment is probably hosed.

[Eneff]

0D is often hardware.

That's why it works on the other computer.

You have three options.
A. hope it's some sort of HD corruption and it's just windows being stupid. cheapest. Do a full scandisk on it, and see if it's having trouble. if it's not...

B. Replace the memory. Memory gone bad isn't pretty. If *that* doesn't help,

C. Throw it out the window, because you probably have some sort of motherboard or other bugs you just don't want to diagnose.

And thank you for calling Microsoft Technical Support. Do you want the bill on Visa, Mastercard, or Discover?

0D

[adolf]

It's not an NT error, but an Intel one, dating back to the Beginning of Time (or the 6MHz 286, anyway). The same errors are reported in the same way under OS/2, and probably a number of other operating systems - I seem to recall Win95 puking out similar nomenclature during at least one BSOD.

Under OS/2, such screaching halts are known as "traps," instead of blue screens. And since OS/2 users were generally more knowledgable about computers then, than NT users are today, there's a lot of information available to help with fixing it.

According to groups.google.com [google.com]-archived message from 1993, 0D is a General Protection Fault.

GPFs happen all the time with bunky hardware. Try re-seating (or just purchasing new) RAM, CPU, and anything else socketed that you can find.

And if that doesn't work, toss the machine. Or give it away to someone with stubborn enough to fix it. Different boxes of similar ilk are available in the $50 range, these days - no need to spend any absurd amount of time with a diagnosis.

Re:0D

[Spoing]

In general, you're right;

1. Int13 (hex 0D) is an Intel CPU generated error code. (Don't shoot the messenger -- the CPU reports the violation and is very very rarely the reason for the failure.)

2. If the same software works on one machine but does not work on a similar machine it's often not worth the time to find out why it's failing. (Good guess: it's probably faulty hardware -- dammaged or designed broken.)

In addition...

3. Int13 can be caused by faulty hardware or software. Bad software usually wins the coin toss. Since it happens in this case while using a compiler, I'd say software is the likely cause -- the compiler or (hate to say) your source.

4. Only occurs when the processor is in protected mode. Simply stated; you've got no process isolation in an Intel processor's initial mode at boot time, in DOS (not a command prompt) and while in the system BIOS (aka "real" mode).

5. Protected mode enables the Intel MMU (memory management unit) and requires a program (usually the OS) to manage the GDT (general [memory] descriptor table).

6. If improperly managed by the GDT control program, processes can bleed into other areas. A proper response by the OS to violating and attempting to modify/read areas it is not allowed to use is to close the process and flag the error.

7. In quite a few situations, violations (int13 and otherwise) are OK and expected. These violations are used to trigger responses such as virtual memory page swapping and interrupt handling. Anything outside an expected violation may point to hardware failure, software corruption (by an errant program), or

8. Failures that happen on the OS level can only be cought _after_ the violation _as_long_as_ the process does not nuke critical parts of the OS or the GDT. This means that a violation that is announced usually means your system is in a suspect (possibly instable) state.

9. This is why few things should run as extentions to the OS (ring 0) and should be run at the user level (ring 3).

Rant: Video and other hardware drivers should never run at the OS level let alone other programs that are not part of the OS that specifically is designed to manage memory and other core system hardware. Limited and focused use of OS level resources is a necessity -- because if the OS is corrupted, all bets are off including sane int13 handling