I have hooked the pagefault handler to learn more about the system internals and watch when and how page faults are triggered. The PF handler is really simple and always calls the original one in the end. Everything works fine so far.
But now I want to debug my PF handler. I execute “KdBreakPoint()” under several conditions, which are:
one particular process is executed (some particular CR3 value)
the faulting instruction is in usermode
the faulting address is in < 0x80000000
The breakpoint itself and the debugging works fine, but when I come back to usermode the particular process crashes. I have found out that this is due to the fact. that the FS register becomes ZERO after the IRET from nt!KiExceptionExit. I have read in the Intel Specs that any register is zeroed on return from an interrupt, when it has a DPL that does not match.
Is this the normal behavior and caused through the “int 3” which is issued by KdBreakPoint while being in the PF handler? Is there any other way to debug the PF handler? Or will this always produce problems, especially when return to ring 0 ?
Could you post the code for your page fault handler?
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@cwse.de
Sent: Friday, August 20, 2010 11:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Page Fault Handler and Breakpoints
Hi,
I have hooked the pagefault handler to learn more about the system internals
and watch when and how page faults are triggered. The PF handler is really
simple and always calls the original one in the end. Everything works fine
so far.
But now I want to debug my PF handler. I execute “KdBreakPoint()” under
several conditions, which are:
one particular process is executed (some particular CR3 value)
the faulting instruction is in usermode
the faulting address is in < 0x80000000
The breakpoint itself and the debugging works fine, but when I come back to
usermode the particular process crashes. I have found out that this is due
to the fact. that the FS register becomes ZERO after the IRET from
nt!KiExceptionExit. I have read in the Intel Specs that any register is
zeroed on return from an interrupt, when it has a DPL that does not match.
Is this the normal behavior and caused through the “int 3” which is issued
by KdBreakPoint while being in the PF handler? Is there any other way to
debug the PF handler? Or will this always produce problems, especially when
return to ring 0 ?
> umm, of course I meant "I have read in the Intel Specs that any **SEGMENT** register is zeroed
on return from an interrupt, when it has a > DPL that does not match. "
This one looks even more intriguing - UM code is unable to proceed upon the return from interrupt because
CS got zeroed behind the scenes so that CPU cannot fetch instructions any more…
Why don’t you want to actually READ Intel Developer’s Manual (particularly everything about INT n and IRET in
Volume 2 and Chapters 3 to 6 inclusive in Volume 3A) before making statements like that???
I am sorry that I did describe it so confusing. I did read the Intel Specs, and Vol3A says for RET on 4-30:
“6. (If the return requires a privilege level change.) Checks the contents of the DS,
ES, FS, and GS segment registers. If any of these registers refer to segments
whose DPL is less than the new CPL (excluding conforming code segments), the
segment register is loaded with a null segment selector”
and for IRET on 5-18:
“To return from an exception- or interrupt-handler procedure, the handler must use
the IRET (or IRETD) instruction. The IRET instruction is similar to the RET instruction execpt… (other stuff)”
So I concluded that it is normal, that the CPU zeros out the FS on return from ring0 code through a IRET to ring3 code, if the FS still contains a selector with DPL0. I even do not find it so intriguing that the CPU will not allow ring3 code to use segment selectors with DPL0 which were left there by accident.
Nevertheless, my question is not about zeroing segment registers, but about the possibilities to use breakpoints inside interrupt handlers. In fact, I see that the FS is zeroed on IRET.
wrote in message news:xxxxx@ntdev… > Hi, > > I have hooked the pagefault handler to learn more about the system > internals and watch when and how page faults are triggered. The PF handler > is really simple and always calls the original one in the end. Everything > works fine so far. > > But now I want to debug my PF handler. I execute “KdBreakPoint()” under > several conditions, which are: > - one particular process is executed (some particular CR3 value) > - the faulting instruction is in usermode > - the faulting address is in < 0x80000000 > > The breakpoint itself and the debugging works fine, but when I come back > to usermode the particular process crashes. I have found out that this is > due to the fact. that the FS register becomes ZERO after the IRET from > nt!KiExceptionExit. I have read in the Intel Specs that any register is > zeroed on return from an interrupt, when it has a DPL that does not match. > > Is this the normal behavior and caused through the “int 3” which is issued > by KdBreakPoint while being in the PF handler? Is there any other way to > debug the PF handler? Or will this always produce problems, especially > when return to ring 0 ? > > Cheers and Thanks for your help > Carsten
Int3 causes an exception by itself, so if you have int3 inside PF handler, things may became too curly.
And congratulations for learning one important thing about Windows internals: hooking is harder than it seems. – pa