Detecting process crash in driver

Hello everyone,

I am researching on the subject, what is the best way to catch process crash in driver. There are API functions like PsSetCreateProcessNotifyRoutine to register callback to be notified that the process is started or stopped, does something simular exists for process crash?

If not, what will be the best solution? One of the idea which comes into my mind is seting windows hook in all process (linking with user32.dll) using dll and setting unhandled exception filter which will ioctl my driver when crash occures.

Please don’t judge my ideas strongly, I am just researching :slight_smile:

Thx

http://pages.cs.wisc.edu/~swift/papers.html with some ideas for windows
implementation.
Ms driver verifier is already sandboxing device drivers ?
J.

wrote in message news:xxxxx@ntdev…
> Hello everyone,
>
> I am researching on the subject, what is the best way to catch process
> crash in driver. There are API functions like
> PsSetCreateProcessNotifyRoutine to register callback to be notified that
> the process is started or stopped, does something simular exists for
> process crash?
>
> If not, what will be the best solution? One of the idea which comes into
> my mind is seting windows hook in all process (linking with user32.dll)
> using dll and setting unhandled exception filter which will ioctl my
> driver when crash occures.
>
> Please don’t judge my ideas strongly, I am just researching :slight_smile:
>
> Thx
>
>

Hello jchristatos,

Thank you for answer. I was looking into article “Using Computer to Diagnose Computer Problems” pointed by your link and unfortunately, these are just non-precise ideas :slight_smile:

I need to discuss something more specific :slight_smile:

For example, one can register some application to act like debugger which get’s called when process crash, or one can read wer or drwatson logs and fetch process crash information. But these solutions do not sound reliable for me.

In fact, the only reliable solution I see is keeping your dll within the process and setting unhanded exception filter. I just want to know disadvantages of this solution.

Also, maybe, when the process crashes, there is something in PEB despite exit code which might be interesting so I can try to read it?

Thanks

you don’t want to inject your DLL inot the process and set an unhandled exception filter. handling unhandled exceptions in the process is a recipe for disaster and is highly unreliable. this is why WER (an out of proc handler) was created, much more reliable.

d

Doron,

WER stands for slightly different purpose - to make a dump of the crashing process, that’s why it is outproc. At the same time, as far as I understand, the principle is similar - once unhanded exception is detected (because process had no unhandled exception handlers and the system handler was invoked) - WER is making a dump.

I don’t need actually to make dump, all I want to know, if process crashed or not. Giving the fact, that WER is detecting process crash in simular way I am lost why you say “handling unhandled exceptions in the process is a recipe for disaster and is highly unreliable”

Thx

If you are going to inject a DLL, perhaps you can use just the fact that the
process exit callback of your DLL has been called.
In this callback, inform your driver (or whatever). If you receive process
exit notification before notofication from your dll, assume the process
crashed, or killed. Will this work?

–pa

Dll injection is not the route to take here. Windows has a well
defined mechanism that has been in place for over a decade and has
been used for many other programs for similar purposes. What you want
to write is a first chance exception handler. In Windows terms,
you’re writting a debugger. That is how Dr Watson, WER, Visual studio
all work. The very first product I worked on was Norton CrashGuard
Deluxe. In the CrashGuard component, we caught *and fixed* user-mode
crashes. This was back when MS Office and most Windows apps were
quite unstable compared to today. Office’s bugginess contributed
significantly to our sales.

Implementation-wise, you are writing a simplified debugger that logs
the crash. This is all user mode stuff and so is really off topic
here. It isn’t done much nowdays. Unfortunately, even the latest WER
is useless here because they don’t let you install a system-wide
snapin to just get notified of an unhandled exception - the app itself
must install a handler each time it runs. Might as well try/catch all
your threads, then, this does little for you, only helps with worker
threads spun off on your behalf. Docs read as though this might work,
but it doesn’t.

There is a very old MSDN article on writing your own debugger. Its
circa 1992 or 95 or so, but the info is still accurate as this hasn’t
changed much. You’ll just want to lookup all the new debug help,
stack walk, psapi’s and such that have been added since then to help
with the “mundane” and very hard tasks of capturing state, walking the
stack, etc. Debuggers are so much easier to write nowdays.

On 2/1/11, xxxxx@microsoft.com wrote:
> you don’t want to inject your DLL inot the process and set an unhandled
> exception filter. handling unhandled exceptions in the process is a recipe
> for disaster and is highly unreliable. this is why WER (an out of proc
> handler) was created, much more reliable.
>
> 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
>


Sent from my mobile device