Re: Help to evaluate the system crash resistance method
- From: "darkside" <zlfeng@xxxxxxxxxxx>
- Date: Mon, 16 Jan 2006 23:25:25 +0800
I don't know what's your mean of "such as moving it into its own address
space"(moving which into whose address space?), can you explain why?
Regarding to the system state, I think the processor should reserve most of
them if not all, it is a standard kernel exception handling mechnism, the
processor and OS know which things they should keep in mind...
"Don Burn" <burn@xxxxxxxxxxxxxxxx> wrote in message
news:ew7A9$qGGHA.312@xxxxxxxxxxxxxxxxxxxxxxx
> As some one who has worked in the fault tolerant part of the computer
> industry, the problem is a lot harder than you imagine. I know of a
> number
> of companies working on potential solutions (I am a founder of one them),
> but you are not going to see discussions here of their technology, you
> won't
> get that without an NDA.
>
> What I can say is you either have to wrap a layer of protection around the
> whole driver (such as moving it into its own address space) or provide a
> way
> to capture enough system state to go back before the crash and do
> something
> to avert it. Neither of these is a small task such as tweaking an IDT
> member, and neither can easily be explained in a newsgroup.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> "darkside" <zlfeng@xxxxxxxxxxx> wrote in message
> news:u53hE9qGGHA.1100@xxxxxxxxxxxxxxxxxxxxxxx
>> Hi,
>>
>> I just thought a approach to hold system crash caused by those tiny SW
>> problems, please kindly help to evaluate:
>>
>> 1. Hacking the IDT, replace those exception vector like memory
>> violation,divided by zero with our handling logic.
>>
>> 2. At our handling logic, if the IRQL is above dispatch, transfer the
>> control to original OS handler, which will show blue screen at last; but
>> if not, use KeDelayExecutionThreadexction() to hold the problem thread
>> for a while, then kernel will re-schedule to other threads.In this case,
>> system still alive instead of going to blue screen.
>>
>> I've been dedicated to fixing kernel bugs for several years, feel very
>> pity to see many times the system dead just because of a tiny driver
>> problem. Would think to develop a kernel piece that can help this...It
>> NOT targets for helping all the system crash cases - I'm aware of many
>> crash cases are so severe that it is no use even if you can hold it for a
>> while, it targets for those SW problems like DBZ, memory violate
>> etc...each of them has a seperate item at IDT which can be selectively
>> replaced.
>>
>> My questions here are:
>> 1. Is there any formal way for us to get the IDT address and selectively
>> replace some of IDT items?
>> 2. How long can the KeDelayExecutionThreadexction() hold the problem
>> thread in practice?
>> 3. Will the overall mechnism work when driver code raises a kernel crash?
>>
>> Thank you!
>>
>> TR
>>
>
>
.
- Follow-Ups:
- Re: Help to evaluate the system crash resistance method
- From: Don Burn
- Re: Help to evaluate the system crash resistance method
- References:
- Help to evaluate the system crash resistance method
- From: darkside
- Re: Help to evaluate the system crash resistance method
- From: Don Burn
- Help to evaluate the system crash resistance method
- Prev by Date: Re: Help to evaluate the system crash resistance method
- Next by Date: Re: Help to evaluate the system crash resistance method
- Previous by thread: Re: Help to evaluate the system crash resistance method
- Next by thread: Re: Help to evaluate the system crash resistance method
- Index(es):
Relevant Pages
|
