IRQL = 0xFF mystery IV

OSR_Community_User · February 10, 2005, 6:24am

Dear All:

The mystery has been partially resolved. Only partially.

Upon DriverEntry, interrupts are enabled. The following code, though,
disables interrupts on this particular machine under XP Home SP2.

=============
// Interrupts enabled here. (Determined programmatically.)

{ __try { __asm int 1 } __except(EXCEPTION_EXECUTE_HANDLER) {}}

// Interrupts disabled here. (Crash dump confirms interrupt flag (IF) is 0)

Does this make any sense at all?

Ralph Shnelvar

OSR_Community_User · February 10, 2005, 7:09am

It looks like the “single step” trap functionality is broken in that
version of XP.

You could try to analyze it, but I would write it down as a “it’s broken,
let’s not use it” feature. I’m not sure why you would want to have a INT 1
in there anyways. But it does explain why it works when you have a debugger
attached, since the debugger would take over the usage of INT 1 and cause a
different route through the interrupt handler to be taken. Try using an INT
0 instead and see if that’s broken too (that’s simulating a divide by zero
trap, and you could of course write some code that generates a divide by
zero instead, but you have to fool around with the code a bit to make the
compiler accept it, but still end up with a divide by zero). Not to be
confused with the INTO opcode, which is “Interrupt if the overflow flag is
set”.

–
Mats

xxxxx@lists.osr.com wrote on 02/10/2005 11:27:29 AM:

Dear All:

The mystery has been partially resolved. Only partially.

Upon DriverEntry, interrupts are enabled. The following code, though,
disables interrupts on this particular machine under XP Home SP2.

=============
// Interrupts enabled here. (Determined programmatically.)

{ __try { __asm int 1 } __except(EXCEPTION_EXECUTE_HANDLER) {}}

// Interrupts disabled here. (Crash dump confirms interrupt flag (IF) is

=============

Does this make any sense at all?

Ralph Shnelvar

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000CAAE

OSR_Community_User · February 10, 2005, 7:19am

Personally, I’ve never used this “int 1” trick (I always use
DbgBreakPoint which invokes “int 3”) so I’ve never bothered to walk the
code. But since I’ve now seen this a couple of times in the past two
weeks, I went and looked - and the two paths are surprisingly VERY
different. I can see enabling and disabling interrupts in this routine,
but I must admit there is sufficient complexity in this code path that I
can’t say I know interrupts will be enabled when this execution is
finished.

I *can* say that it does not use the standard exception handling scheme

which is used by KiTrap03 (reporting back STATUS_BREAKPOINT as the
exception). So, my suspicion is that this is some interesting
interaction in the implementation of structured exception handling and
this particular kernel trap function.

Try replacing your “_asm int 1” with “DbgBreakPoint()” and see if this
changes its behavior.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Thursday, February 10, 2005 6:27 AM
To: ntdev redirect
Subject: [ntdev] IRQL = 0xFF mystery IV