Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Internals & Software Drivers | 7 February 2022 | Live, Online |
Kernel Debugging | 21 March 2022 | Live, Online |
Developing Minifilters | 23 May 2022 | Live, Online |
Writing WDF Drivers | 12 September 2022 | Live, Online |
Comments
> definitely, there is not hardware problem..
Page fault during handling zero-divide fault - for instance.
Max
>definitely, there is not hardware problem..
The Intel processor manual (system programming guide) has the authoritative
answer. In general, anytime you get a fault when trying to process a fault,
you get a double fault. Some faults can be handled sequentially, so don't
give a double fault. Some double fault examples::
1) say your page fault hander is paged out, oops where does the next
instruction come from when you get the first fault, the double fault handler
2) say some silly person set's your kernel flat code segment size to 0
(oops, that segment descriptor memory wasn't a DMA buffer?), you get a
segment limit fault, but oops again, the segment limit handler uses the
same flat code segment, plan B is the processor starts praying your double
fault vector points to some other code segment or a task gate
3) say your cruising along in kernel mode, and you enter that kernel
function with a few too many locals, oops, kernel stack fault, no problem,
the stack overflow handler will just extends our stack (I wish), double
oops as there is no place to push the faulting cs:eip (unless the stack
fault hander uses a task gate), the processor really is hoping the OS
designer used a task gate for the double fault handler, as it will get a
shiny new stack to report the double fault on (the screen reads "Dear user,
we forgot to use a task gate for the stack fault handler, fortunately we
did remember to use one on the double fault handler, to print this handy
message, preventing the dreaded Will Robinson error. - The OS folks).
You can also get a triple fault, which puts the processor into shutdown
mode. An external hardware signal (like reset) is needed to get the
processor out of shutdown. An example of a triple fault, say example 3
above doesn't use a task gate for the double fault handler, when the
processor tries to enter the double fault handler, on the overflowed kernel
stack it can't, so enters shutdown.
Double fault handling is basically a last ditch effort to prevent processor
shutdown (which will require external intervention to exit from). It means
all the "normal" fault handling has failed.
- Jan
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Girish Desai
> Sent: Monday, April 03, 2000 5:22 PM
> To: NT Developers Interest List
> Subject: [ntdev] various causes of double faults?
>
>
> Hi all,
>
> What are various causes of double faults?
> definitely, there is not hardware problem..
>
> Many Thanks..
> GR
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>