WinXP and "instant reboot" app crashes

Lucky

Lifer
Nov 26, 2000
13,126
1
0
I have a few programs, all similar in code, that have a tendency to randomly lock up my winxp box and either instantly reboot (no warning) or give me a blue screen with the "irq less than equal, beginning memory dump" crap.

Stupid question, :eek: , but is there any third party software that will incercept an application crash and prevent this from happening?
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
If your getting a blue screen, that isn't an application crash, thats the OS going down. An no, you can't intercept and 'fix' it, the system is hosed at the point they decide to blue screen. What programs in particular are you talking about, this sounds 'weird'.

Bill
 

Lucky

Lifer
Nov 26, 2000
13,126
1
0
so what would cause an instant reboot? I thought xp wasnt to allow those...
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
Most likely it's a driver issue, are all of your drivers (especially video) up to date?
Bill
 

Lucky

Lifer
Nov 26, 2000
13,126
1
0
I considered that, but it happens on two machines, one with a gf3ti200 and one with a voodoo 3 3K. The 3K's drivers were automatically installed with XP, the gf3's drivers are updated.
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
Any chance this program installs drivers for some reason? I user mode app can't bring the system down, but a kernel component can. When you see the bluescreen, it should be saying in there somewhere "in xxxxxx.sys". What is the xxxx part of the messsage, that should help track down which driver is doing it.

Bill
 

Lucky

Lifer
Nov 26, 2000
13,126
1
0
hmm...I'll look next time it happens. When it BSOD's it reboots automatically pretty fast so it might be hard, and that doesnt even touch the instant reboots (no warning) that occasionally happen.
 

Sivar

Member
Nov 11, 1999
50
0
66
FYI, IRQL is short for "interrupt request level". This is a number maintained by the NT family of OS's for each CPU, i.e. it is part of NT's view of the CPU state, but it has no actual manifestatation in the hardware state of the CPU. IRQL is in the range 0 through 31 and represents a precedence level for interrupts and interrupt-related processsing.

Each interrupt, in addition to having an IRQ number, has an IRQL assigned to it by the OS. They are not the same number and it is not a one-to-one relationship (many different IRQs are often handled at the same IRQL). IRQLs are also assigned to other sorts of interrupts that have no external "IRQ" manifestation, such as the interprocessor interrupt used on MP systems; CLI is considered equivalent to IRQL 31; IRQL 2 is a software interrupt level used by internal serialization mechanisms and after-the-interrupt processing in drivers. Normal thread execution is at IRQL 0.

The IRQL of an interrupt essentially says "how important is this interrupt?" When an interrupt occurs, the NT interrupt dispatcher compares the interrupt's IRQL (found in a data structure which NT built earlier) with the current IRQL of the processor. Only if the new interrupt is of higher IRQL than what the processor is doing at the moment, is the interrupt service routine for the new interrupt called. Otehrwise the interrupt dispatcher simply notes the fact that the interrupt occurred - and was deferred - and returns to the interrupted code.

Later, when the interrupt code returns to caller, the deferred interrupt's ISR will get called.

it is a little like thread priorities, but ISRs aren't threads, there is no timeslicing among ISRs of equal IRQL, etc.

The stop code IRQL_NOT_LESS_OR_EQUAL means simply this: An unhandled exception, most commonly a memory access violation, like dereferencing a NULL pointer, occurred at IRQL 2 or above. All unhandled exceptoins in kernel mode are fatal errors leading to blue screens. An exception in kernel mode at IRQL 0 or 1 that isn't handled by surrouinding try...except code results in the blue screen KMODE_EXCEPTION_NOT_HANDLED. Exceptions cannot even be attempted to be handled at IRQL 2 or above, so exceptions in that context result in a different bugcheck, IRQL_NOT_LESS_OR_EQUAL, or sometimes DRIVER_IRQL_NOT_LESS_OR_EQUAL.