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."
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe =utf-8&q=%22Unexpected+Interrupt+0D%22&btnG=Google +Search
INT 0D is reserved according to my asm book.
Install just linux. Trying to dual boot 2000 and linux is a pain. Use a compiler like gcc.
Jonahweb.com has stuff.
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 0D is for:
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
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.
yes underclocking is bad too.
...would make an excellent post on Usenet. I hear the kids these days are even able to access it over the web, so if you got this far, you can probably try over there. Of course, you are likely to get the same responses, which will be requests for more information.
I'm a busy man. Stop wasting my time.
It's probably a memory error... page fault or overflow or something similar... I think, based off the similar (borrowed) underpinnings taken from OS/2 for command line, Interrupt 0D errors are the same as OS/2's Trap 0D errors... each are error interrupts, same error code, different way of "naming" them (Trap/Interrupt).
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
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?
Asketh the original poster:
Better question: Why the hell do the editors publish these on the front page?
Not as good of a question: Why the hell don't we just set our preferences to block these from the front page?
Overrated / Underrated : Moderation
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..
I believe the slowest Pentium II ever made was 233MHz. Perhaps the problems you're having are somehow related to the fact that a 200MHz Pentium II never existed...? :)
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
Try your programs/compilers on a machine that uses Registered ECC memory. You'd be surprised how many single bit memory errors can occur, especially when the internal case temp of your 'puter gets high, and also when the memory is getting old (as it clearly is in a 200mhz machine).
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.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
Supermicro makes excellent motherboards. I've never had a single hiccup from any of the ones I've used in the past.
You have to wonder why these idiots can't use google.
Yet they can manage to use a form to submit the "story".
Idiots.
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.
I did and it doesn't apply. That's why I posted it here. It doesn't occur at any specific point where I could guess my software is incompatible and there's no drive access going on. Unless it occurs as a 'normal' feature and NT usually handles it out of the way. It isn't even consistent between different user interfaces. What I was looking for was a way to integrate old command line stuff into NT with a reasonable user interface, which Take Command more or less provides (and to find out what it will do as compared to what it's supposed to do). I have got it through since - sometimes - but I guess it's just a case of do it MuckySoft's way or forget it. There are times when sodding about with setting windows up is not worth the effort compared to a quick dirty command line. But I was hoping it needn't be quite as dirty as what's provided!
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.
cowardly,
-craiger
I think it's a speed thing. It turns up in faster machines too but not as frequently. The compiler was probably designed for a 486 or even 386, windows yes but not NT. On a 486 under DOS it's fine. It isn't my code that's doing it: it's the compiler or its libraries but is shouldn't be executing anything except itself at that point. The weirdness is that lack of consistency. It might go through, it might fail the moment it starts or anywhere between. A soft bug I'd expect to blow up after a specific time and probably as it's working on a particular source library - which it lists to screen as its going. My main concern was to check whether it would work (including run the result since it's an intermediate translating system) with NT. If it won't, it won't. I don't want my home stuff under NT anyway! Truth is, I don't like mysteries and 'General Error' is as bad as 'DOS Error 21' for informativeness.