Slashdot Mirror
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."
This is officially the first /. post I don't understand.
At all.
Damn..
What compiler?
What is crashing? The compiler? The command prompt?
What are you doing when it crashes?
Does this happen with other compilers? Other programs?
I have been pwned because my
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
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.
Let's see... you have unexpected protection faults, you're running on antique hardware, and when you try the same code on a different machine, it works fine.
That sounds exactly like the symptoms of hardware which has exceeded its MTBF.
Tarsnap: Online backups for the truly paranoid
Parent is right.e =utf-8&q=%22Unexpected+Interrupt+0D%22&btnG=Google +Search
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?
I'm sorry sir, but Slashdot does not support that software, please call your OEM for further help.
You have a "200MHz Pentium II" and are getting unexplained errors. Perhaps I missed something, but the first Pentium II was 233MHz.
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.
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?
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-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.
Kid-proof tablet..
Do you have an intel Nic? replace it. I found most BSOD to be from Intel nics. In linux they work fine, but in NT they just die at random.
hmm... for fun I enjoy launching DDoS attacks against 127.87.42.5
I don't know if this will directly address your problem, but I found it helpful once for diagnosing a bad FPU. There's lots of good tidbits talking about bad hardware and its symptoms.
Check technet.microsoft.com it's the first place to look regarding windows
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.
I'm not sure I understand what you're saying. And I'm not sure of your ASM proficiency level, so I'll go into some details that may be redundant to you. And I think you might have said you resolved the problem, so I dunno if this matters anyway.
According to http://swatch.binary.com.tw/delphi-ti/19057.html, 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.
From 80386 Programmer's Reference Manual.
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.