Remember that “interrupt” comes asynchronously from outside the CPU, and
“exception” comes synchronously from the instruction execution engine.
While it is true that ISRs run at elevated IRQL, that’s because the
interrupt system is dealing with this. So, from a driver perspective, all
ISRs run at elevated IRQL level, > DISPATCH_LEVEL, and that is absolutely
true. But exception handlers, although they use (and share) the mechanism
of gates and dispatching, you have to think of them as basically unrelated
concepts. The Intel instruction manual, for every instruction, tells what
exceptions it can raise. Some exceptions (such as page fault) can only be
raised in certain modes (virtual memory enabled). So when you talk about
ISRs in the context of a driver development group, the standard answer is
“All ISRs run at DIRQL > DISPATCH_LEVEL”, because in the context of
external devices, this is true. As a programmer, unless you are writing
an operating system, you will never see these exceptions or have to worry
about handling them. So while innate curiosity is valuable, you have to
be willing to understand that generic responses to generic questions are
not going to cover ISRs that handle exceptions.
I’ve written several operating system-like components that had to respond
to address errors, divide-by-zero, alignment, and similar errors. It’s
really hairy when you have to respond to stack overflow errors.
Page-faults are complex, but generally formulaic solutions are provided by
the computer vendor. A misaligned stack was a seriously bizarre problem
on a machine that insisted that pointers be aligned on pointer-sized
boundaries, because the exception handler couldn’t be transferred to,
since the push of the IP took an alignment fault. We ultimately solved
this one with a wire-cutter, and clipped the lead to the low-order bit of
the register and soldering a jumper to lock it to 0. Then the new model
came out, and it was all done in microcode, and you ain’t seen nothin’
until you’ve seen a piece of hardware that monitors the CPU board and
“hooks” access to low-level registers by the microcode! (They were called
“procmod” boards).
joe
Okay. Atleast in case of handling page fault the page fault handler(ISR)
should run at an IRQL < DISPATCH_LEVEL in the context of the thread that
resulted in page fault for what Windows Internals says to hold true. If it
runs at an IRQL >= DISPATCH_LEVEL, it can’t wait for the synchronous IO to
complete. Synchronous handling of page fault also makes sense as it is a
fault type exception so the instruction that caused the exception would
re-execute expecting that the fault handler or ISR would have fixed the
problem (page fault handler would have adjusted the eip to the back to the
same instruction before returning i suppose). While it’s okay to say that
in general it’s safer to assume that the ISRs run at a DIRQL level but in
this case it doesn’t seem to hold true. Device interrupts handler run at
DIRQL level but that might not be the case with other system registered
exception handlers. Am I thinking on the right lines?
On Thu, Sep 20, 2012 at 8:25 PM, wrote:
>
>> If you’re asking this just for curiosity, there is no fixed answer, and
>> the answer won’t be of any use.
>>
>> If you’re learning to write drivers, you don’t want to know every little
>> detail of kernel itself. What you need to know are constraints and
>> limitations what you can do in your ISR, DPC, etc. You don’t need to
>> care
>> about trap handlers, etc.
>>
>> If you’re writing an ISR, you only needs to know it runs in arbitrary
>> thread context on elevated IRQL >DISPATCH_LEVEL, and you cannot use
>> regular
>> spinlocks, and any other synchronization objects, other than interrupt
>> spinlocks. You cannot access any pageable memory. You can queue a DPC
>> from
>> there.
>>
>> If you’re writing a DPC, you need to know you cannot wait on synch
>> objects. You can use spinlocks. You can signal events.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer