[fire_the_hole]

My English is poor.If you cann't make clear what i'm talking about,Please tell me.
for example:
i write a driver who triggers a "int 3" command in DriverEntry function.
If the kd is debugging the windows . Then the windows will break into the kd. otherwise windows will bsod.

If i just edit the int 3 command in the current eip address(eg: eb . 0x90) .then make the system run.(eg: g)It will not bsod.
But this is the most simple example.
When i meet a new driver which will cause the bsod.
How can i stop this?
can i terminate the thread? Is there a simple way to do this?

[Vrtule]

Hello,

generally speaking, attempt to get past BSOD might be dangerous and it makes no sense in most cases. BSOD occurs when a serious problem, that cannot be solved, is deceted. The system is in inconsistent state, hence you cannot trust it will work "normally" when you manage to get past the BSOD.

For example, when a bogus/malicious kernel driver corrupts parts of main kernel module (ntoskrnl.exe) how do you want to repair it? The kernel cannot function normally because its code is damaged. And this is only one scenario. It is possible to "defend" against particular scenarios but not in general case (in every situation). This is my opinion.

I simply do not understand why to do so. If the driver causes BSOD, it is buggy. If I am the author of the driver I should fix the bug and do not try to evade the crash.

There are some exceptions. BSODHook for example. And it does not get past BSOD in 100 % cases.
http://www.matousec.com/projects/bsodhook/

[fire_the_hole]

It is possible to "defend" against particular scenarios but not in general case (in every situation). This is my opinion.

I simply do not understand why to do so. If the driver causes BSOD, it is buggy. If I am the author of the driver I should fix the bug and do not try to evade the crash.

thank you for your help.I agree with you opinion.i just want to against particular scenarios not every case.
kernel mode is new for me.now I frequently compile and run the driver .
in this case. i know it's my module cause the bsod and the reason.i want to "unload it" or do some other thing just to avoid bsod and rebooting.,because they waste a lot time.i want to use the enviroment again without rebooting from bsod.

when i use ollydbg to debug the ring3 program.If i know the program's algorithm and thread context well and i know what i want to do clearly.I can easily change the eip to force the program run from a specify address.it sounds crazy and make no sense.but in that case i know what i'm doing and what i can do.
I believe there must be some way to past bsod in kernelmode . I can't do this because i don't understand the system's mechanism for now.

[EP_X0FF]

Imagine: your driver damaged some system structures and system BSOD's. Now you want to prevent this BSOD (for example by hooking KeBugCheckXX). And what? System already dead in most cases and need restart.

i want to "unload it" or do some other thing just to avoid bsod and rebooting.,because they waste a lot time.i want to use the enviroment again without rebooting from bsod.

Use virtual machine and modern hardware. It takes 3-4 secs to do complete reboot. Or fix your damn driver, isn't it the best solution?

[fire_the_hole]

Imagine: your driver damaged some system structures and system BSOD's. Now you want to prevent this BSOD (for example by hooking KeBugCheckXX). And what? System already dead in most cases and need restart.
Use virtual machine and modern hardware. It takes 3-4 secs to do complete reboot. Or fix your damn driver, isn't it the best solution?

of course i can do it .anyone can do it.
if so i don't need to post this question here.

I just want to do take the whole control of the machine with debuger. for examle,when i get enough information about the debugee. I can figure out a way to stop it from bsod.
for now I know if i want to solve this problem,What i need to is
just get a best understanding of the system's mechanism .When I get it .I can do what i want to do.

If someone else have already got the answer. Please tell me.Thank you.
my email:fire_the_hole@hotmail.com

[Vrtule]

Hello,

when i use ollydbg to debug the ring3 program.If i know the program's algorithm and thread context well and i know what i want to do clearly.I can easily change the eip to force the program run from a specify address.it sounds crazy and make no sense.but in that case i know what i'm doing and what i can do.
I believe there must be some way to past bsod in kernelmode . I can't do this because i don't understand the system's mechanism for now.

well, it seems to me as quite hard to achieve in kernelmode. Reboot will be, in most cases, less time consuming option. If you don''t want to perform the reboot, maybe reverting to latest snapshot would do the job faster.

[xdeadcode]

Hi fire_the_hole,

Well without seeing any code and bugcheck here, it will be hard to help you what exactly causes bsod.
When this 'strange' things happens I would use driver verifier to check if e.g you don't have buffer overflow/overrun or any other 'standard driver developers' problem has occured. M$ invested a lot of $ to eliminate problems that occurs to programmers over and over (and they still invest).

About wasting time.. well If you develop any driver I belive time is not good measure since bsod means something to fix for sure. Additionally as EP_X0FF and Vrtule stated before BSOD means inconsistent system state and if e.g in your driver you has overwritten not your (but system) memory or you done anything that crash system (e.g unlinked system structure) I don't think that it will be good to step to see what will happen later - you can't trust later results (it can be not deterministic). Before you do anything review your code again..

Best regards,

[Vrtule]

Because BSODs are so time consuming for you, you should improve your coding skills and learn more about techniques that help you to find the bugs. I think I never used Driver Verifier (well, this is probably nothing to boast of, however, I never written somethinkg like REALLY complicated driver). But I am trying to follow certain good practices like:

* Unified code style.
* Before I load the driver into kernel, I carefully re-read the source coee I added or modified, and try to act (and think) like the operating system. The re-read is usually quite slow, however, it reduces amount of BSODs.
* I use debug prints in the beginning and in the end of nearly every routine. When a BSOD occurs, I just look into the debug output, and I see where the crash occured, what exactly was going on, what the parameters of routines were etc. I have learnt how the debug prints are powerful during certain school project where other debug possibilities were very weak when working out problems of certain kinds.

Of course, if you get familiar with code verification tools that can be used to drivers ,it will help.

My hardware is not powerful enough to manage reboots in five seconds time. But the reboot gives me time to think about the problem and to read the debug log. Well, it is annoying sometimes. But such emotions should be suppressed during programming. They do nothing right there.

The above is only my personal opinion.

EDIT: You can also read some books about the subject. Even the old ones might be good (for example, the Rootkits: Subverting the Windows Kernel book). They probably won''t teach you the most astonishing tricks but they attempt to show you how the kernel (and drivers) work.