IRQL and exception (correction to statement made on locked thread)

> Another obvious problem with C++ exceptions in kernel mode is that they cannot be build

on top of native exception handling. Because at elevated IRQL you cannot get preempted
by an exception handler with a lower interrupt vector (such as a pagefault). Everything
needs to be implemented in software entirely by verification. //Daniel

Sorry, Daniel, but you are totally wrong here. Vector-implied priority applies only to external interrupts (that happen to be maskable, btw) Exceptions cannot be either masked or delayed - they are going to fire straight away, because they are internal to the CPU. In fact, the very idea of exception is based upon the assumption that CPU cannot proceed with executing currently running code until exception gets handled.

BTW, if what you are saying was right you would have no chance to cause page fault at elevated IRQL, in the first place…

Anton Bassov

wrote in message news:xxxxx@ntdev…
> Sorry, Daniel, but you are totally wrong here. Vector-implied priority
> applies only to external interrupts (that happen to be maskable, btw)
> Exceptions cannot be either masked or delayed - they are going to fire
> straight away, because they are internal to the CPU. In fact, the very
> idea of exception is based upon the assumption that CPU cannot proceed
> with executing currently running code until exception gets handled.
>

You are right of course. Apparently I had my common sense exceptions all
masked off when I impulsively wrote that. (Some exceptions like FPU btw can
be masked)

//Daniel

> (Some exceptions like FPU btw can be masked)

Well, as long as CPU is the exception source (this is what I call the exception) they cannot be masked either.
The confusing part here is that exceptions may come from the external sources as well - all exceptions can be delivered through INTR pin, and exception vectors 16-32 can be delivered through the local APIC. However, these are not exceptions - they are already interrupts (btw, maskable ones) if they are delivered this way. In your example of page fault handler, although it can be delivered through INTR pin (and masked), it will be different from the real page fault exception that comes from the CPU - no error code will be pushed on the stack.

Another confusing part is that exceptions, indeed, have a priority to one another if they occur on the instruction boundary - for example, the same instruction can generate both page fault and debug exception, i.e. you cause page fault when TF flag is on. However, this priority is not vector-implied (check Intel Manual Vol 3a for more info)…

Anton Bassov