Hi,
I have seen some window prompts once system reboots after crash (BSOD). It
seems OS knows whether current reboot is because of some crash or normal
reboot. Could you please let me know if from application level or kernel
level we can get same information? Actually my intension is to identify
1.) Is the crash is because of my driver (without debugging.) If so then
next time onwards I will not load my driver, until new driver has been
installed.
2.) Can I register some function(user/kernel level) or register some
callback so that before crash OS will notify my driver that system is about
to crash?
Note: My driver is a mirror driver.
Please let me know in case you need any other information.
Maybe this could be helpful “KeRegisterBugCheckCallback”
http://msdn.microsoft.com/en-us/library/ff566401(VS.85).aspx
But there is not much you can do in the callback it executes at HIGH_LEVEL.
I don’t think that you can determine who caused the crash after the
system has rebooted without analyzing the dump file.
Cheers
/Faik
On Tue, Dec 21, 2010 at 11:55 AM, Sarbojit Sarkar wrote:
> Hi,
> ??I have seen some window prompts once system reboots after crash (BSOD). It
> seems OS knows whether current reboot is because of some crash or normal
> reboot. Could you please let me know if ?from application level or kernel
> level we can get same information? Actually my intension is to identify
> 1.) Is the crash is because of my driver (without debugging.) If so then
> next time onwards I will not load my driver, until new driver has been
> installed.
> 2.) Can I register some function(user/kernel level) or register some
> callback so that before crash OS will notify my driver that system is about
> to crash?
> Note: My driver is a mirror driver.
> Please let me know in case you need any other information.
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
You can register for bugcheck callbacks as noted above, but how is
that going to help you decide if your driver was at fault? However
that is different from knowing if this boot was preceded by a system
crash. The OS does not share that information with other kernel
components. You can of course also register for shutdown notification
and you can implement your own scheme that uses, for example, the
registry to record a normal shutdown state.
You could implement a ‘no normal shutdown since my driver was
installed means my driver is causing the problem’ policy. I think that
is making a lot of assumptions.
Mark Roddy
On Tue, Dec 21, 2010 at 5:55 AM, Sarbojit Sarkar wrote:
> Hi,
> ??I have seen some window prompts once system reboots after crash (BSOD). It
> seems OS knows whether current reboot is because of some crash or normal
> reboot. Could you please let me know if ?from application level or kernel
> level we can get same information? Actually my intension is to identify
> 1.) Is the crash is because of my driver (without debugging.) If so then
> next time onwards I will not load my driver, until new driver has been
> installed.
> 2.) Can I register some function(user/kernel level) or register some
> callback so that before crash OS will notify my driver that system is about
> to crash?
> Note: My driver is a mirror driver.
> Please let me know in case you need any other information.
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
You can register for bugcheck callbacks as noted above, but how is
that going to help you decide if your driver was at fault? However
that is different from knowing if this boot was preceded by a system
crash. The OS does not share that information with other kernel
components. You can of course also register for shutdown notification
and you can implement your own scheme that uses, for example, the
registry to record a normal shutdown state.
You could implement a ‘no normal shutdown since my driver was
installed means my driver is causing the problem’ policy. I think that
is making a lot of assumptions.
Almost sounds easier just to fix the bugs that caused the crash in the
first place 
A trick like this might be useful if your driver did some undocumented
things and could be a bit sensitive to other stuff running on the system
(eg antivirus), but it still seems like detecting a crash and disabling
is spending your resources in the wrong place.
James
Thanks for all responses.
Thats true, by only checking crash I can’t make out whether my driver is at
fault. Since my application can run without driver also so I just wanted to
isolate which is exactly causing the issue.
/sarbojit
On Wed, Dec 22, 2010 at 1:45 AM, James Harper > wrote:
> >
> > You can register for bugcheck callbacks as noted above, but how is
> > that going to help you decide if your driver was at fault? However
> > that is different from knowing if this boot was preceded by a system
> > crash. The OS does not share that information with other kernel
> > components. You can of course also register for shutdown notification
> > and you can implement your own scheme that uses, for example, the
> > registry to record a normal shutdown state.
> >
> > You could implement a ‘no normal shutdown since my driver was
> > installed means my driver is causing the problem’ policy. I think that
> > is making a lot of assumptions.
> >
>
> Almost sounds easier just to fix the bugs that caused the crash in the
> first place
>
> A trick like this might be useful if your driver did some undocumented
> things and could be a bit sensitive to other stuff running on the system
> (eg antivirus), but it still seems like detecting a crash and disabling
> is spending your resources in the wrong place.
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
There are very few bugcheck codes where you can directly infer that your driver was at fault. You want as little code as possible to run in the bugcheck callback because if you fault again, you double or triple fault and and immediately reboot without the dump file being written, making the problem worse. keep the driver simple
d
Thanks D, for your response, I will keep in mind.
Well Some where I have read we can check minidup file modified date/time at
application level to decide whether system has just recovered from crash. Is
it possible?
/sarbojit
On Wed, Dec 22, 2010 at 12:54 PM, wrote:
> There are very few bugcheck codes where you can directly infer that your
> driver was at fault. You want as little code as possible to run in the
> bugcheck callback because if you fault again, you double or triple fault and
> and immediately reboot without the dump file being written, making the
> problem worse. keep the driver simple
>
> d
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Just scan the event log.
Mark Roddy
On Wed, Dec 22, 2010 at 2:33 AM, Sarbojit Sarkar wrote:
> Thanks D, for your response, I will keep in mind.
> Well Some where I have read we can check minidup file modified date/time at
> application level to decide whether system has just recovered from crash. Is
> it possible?
>
> /sarbojit
> On Wed, Dec 22, 2010 at 12:54 PM, wrote:
>>
>> There are very few bugcheck codes where you can directly infer that your
>> driver was at fault. You want as little code as possible to run in the
>> bugcheck callback because if you fault again, you double or triple fault and
>> and immediately reboot without the dump file being written, making the
>> problem worse. keep the driver simple
>>
>> d
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer