Help to evaluate the system crash resistance method
- From: "darkside" <zlfeng@xxxxxxxxxxx>
- Date: Mon, 16 Jan 2006 23:12:22 +0800
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
- Prev by Date: Unidriver QueryInterface function
- Next by Date: Re: Help to evaluate the system crash resistance method
- Previous by thread: Unidriver QueryInterface function
- Next by thread: Re: Help to evaluate the system crash resistance method
- Index(es):
Relevant Pages
|
