Handling 'Unexpected Interrupt 0D' Errors Under NT? 59
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= (Score:1, Informative)
Re:http://www.google.com/search?hl=en&lr=& (Score:2)
http://www.google.com/search?hl=en&lr=&ie=UTF-8&o
It's right there. Again, this doesn't belong in Ask Slashdot. It belongs on usenet, in one of the asm groups. Alternately, just use google, it's right there. Blargh. Why don't people do basic research before posting an ask slashdot?
Re:http://www.google.com/search?hl=en&lr=& (Score:1)
Re:http://www.google.com/search?hl=en&lr=& (Score:2)
According to http://swatch.binary.com.tw/delphi-ti/19057.html [binary.com.tw], found with Google,
Interrupt 0d is the general protection exception and is generated by any protection violation that does not generate some other exception. See the above question for a more complete description of the problem. Common causes of this problem are network boards and certain hard disk controllers.
Interrupts can be either software generated, or hardware generated. Assuming this is a hardware generated interrupt, it's set when the processor receives an IRQ (Interrupt ReQuest). In this case, the processor recieved an IRQ for int 15. From the article, we get that IRQ 15 is our old friend, General Protection. Here, General Protection is (most likely) protecting us from bad hardware. If you trace through your code, or set AfxMessageBox() calls in your code in key places, you should be able to trace where the fault occurs. (AfxMessageBox() does block the thread until you hit OK, BTW.) At this point you should have figured out where the fault gets flagged, and from here you diagnose exactly which hardware is bad.
If you haven't figured out the problem this way, generate checksums of the file, both on the faulty hardware, and the good hardware, to see if it wasn't changed due to a faulty HDD. If the checksums look OK, then test your memory. If that tests OK, then you may be looking at a faulty CPU. Check to see how hot the CPU gets, that may be what's generating the error.
Or it may be something else entirely. Debugging flakey hardware in software is often quite tricky. I've thrown out MoBos before after diagnosing that something on the MoBo was broken, but never knowing exactly what it was. And I'll do it again. Oftentimes, diagnosing hardware isn't worth the headache.
Re:http://www.google.com/search?hl=en&lr=& (Score:1)
Reserved (Score:1, Redundant)
Finally.. (Score:5, Funny)
This is officially the first /. post I don't understand.
At all.
Damn..
Re:Finally.. (Score:1)
First things first (Score:5, Insightful)
What is crashing? The compiler? The command prompt?
What are you doing when it crashes?
Does this happen with other compilers? Other programs?
Ralph Brown's interrupt list.. (Score:5, Informative)
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
Re:Ralph Brown's interrupt list.. (Score:2)
Re:Ralph Brown's interrupt list.. (Score:1)
Re:Ralph Brown's interrupt list.. (Score:2, Troll)
Int 0D (Score:1)
IRQ5 of 8259 (reserved for hard disk XT)
The 8259 is the onboard interrupt controler, so basically an interrupt on IRQ5 is occuring and windows doesn't know what to do with it, cause something is wrong.
Check technet.microsoft.com it's the first place to look regarding windows
Re:Int 0D (Score:2)
I didn't think Microsoft's technet was that out of date.
The XT, for you youngsters out there, was when they added a whopping big 20 meg hard drive to the pc. It's before Intel made the 80286.
With the AT (80286) they added a second interrupt controller, accessable by 16-bit cards and moved the hard disk interrupt to IRQ14 (primary) and IRQ15 (secondary) IDE controllers. IRQ5 now standard for lpt2 but somewhat avoided because of conflict with hardware interrupt 0Dh on 80286+, the famous General Protection Violation.
Check google.com when you actually need useful information.
Re:Int 0D (Score:1)
Re:Int 0D (Score:2)
General Protection Exception
All protection violations that do not cause another exception cause a general protection exception. This includes (but is not limited to):
1. Exceeding segment limit when using CS, DS, ES, FS, or GS
2. Exceeding segment limit when referencing a descriptior table
3. Transferring control to a segment that is not executable
4. Writing into a read-only data segment or into a code segment
5. Reading from an execute-only segment
6. Loading the SS register with a read-only descriptor
7. Loading SS, DS, ES, FS, or GS with the descriptor of a system segment
8. Loading DS, ES, FS, or GS with the descriptor of an executable segment that is not also readable
9. Loading SS with the descriptor of an executable segment
10. Accessing memory via DS, ES, FS, or GS when the segment register contains a null selector
11. Switching to a busy task
12. Violating privilege rules
13. Loading CR0 with PG=1 and PE=0
14. Interrupt or exception via trap or interrupt gate from V86 mode to privilege level other than zero.
15. Exceeding the instruction length limit of 15 bytes (this can occur only if redundant prefex are placed before an instruction)
Basically, the machine code is trying to do something highly illegal. How it got there and why are a different matter.
Flaky memory is always a suspect.
Computed jumps based on leftover garbage (uninitialized variable) are another fun way to encounter the problem. Random code/data usually crashes eventually.
It is possible that it's just catching an attempted write to protected storage.
The Intel 386+ actually does have a very good hardware protection mechanism, which unless sombody managed a port of Multics, is effectively unused and subverted from protected segments to a nice flat space where anybody can do anything to everything.
Possibly a hardware problem, or bad software (Score:3, Informative)
Crappy hardware (Score:4, Insightful)
That sounds exactly like the symptoms of hardware which has exceeded its MTBF.
Re:Crappy hardware (Score:1)
Unsupported Software (Score:2, Funny)
What the hell... (Score:2)
Maybe the problem is that you don't know what you're doing.
Either that or I'm a half-drunk asshole. Either answer wouldn't surprise me.
Re:What the hell... (Score:5, Funny)
Get with the program, people...
Re:What the hell... (Score:1)
Re:What the hell... (Score:1)
180MHz Pentium Pro, not Pentium II
This guy might have a Pentium MMX 200, hell he could have a K6-450, it doesn't seem like he knows what he's talking about.
Not so much an "interrupt" in the "normal" sense (Score:1, Insightful)
It's cause usually by the application. A look at WinNT error docs that should come with their older compilers, should turn it up, or a look at OS/2's Trap Explanation help file (or whatever it's called).
- Rob
www.WebBinaries.com
Your equipment is probably hosed. (Score:3, Informative)
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?
Re:Your equipment is probably hosed. (Score:1)
Linux can't do much with a bad HD, memory, or MB either.
nice troll, man.
Re:Your equipment is probably hosed. (Score:2)
The parent post reminds me of this classic scene(shoot me if I got the band name wrong)
Beavis: Winger sucks!
Butthead: Dude, That's not Winger
Beavis: I know, I just felt like saying that.
0D (Score:5, Informative)
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 (Score:3, Informative)
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
Re:0D (Score:2)
Re:0D (Score:1)
Re:0D (Score:2)
Another frequent reason is memory offsets. A slight difference on similar hardware (or with different drivers or software) may allow one system to 'work' (it's corrupting or accessing it's own address space -- BAD), or 'fail' (you get an int13 or other error -- actually a good thing; you are told something is wrong).
This is not an exhaustive list. Happy hunting...
200 MHz Pentium II? (Score:1)
Intel NIC? (Score:2)
general protection fault = possible memory errors? (Score:1)
If you do not have such hardware available, try just swapping out the RAM in that machine for new memory and see if the problem goes away.
BTW I picked up a new SuperMicro DLI motherboard (dual P3) w/ ServerWorks chipset and ECC memory mandatory from ebay for $58 bucks.
Particularly on a software development machine, having ECC memory can prevent you from chasing odd bugs that are seemly random (at least ones that would be due to memory errors).
Or maybe we're both crazy.
Signal 11 FAQ (Score:2)