Override kernel exception handler?

In postin
http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.development.device.drivers&mid=74822b53-9342-4101-bbb8-b0daf2afc25b&sloc=en-us
I learned that __try/__except and such can only catch a subset of all
exceptions that may occur in a kernel driver. Unless we write perfect code,
this will eventually come back and bite us.

Is it at all possible - probably not advisable though - to override the
kernel exception handler? I'd write some exception information to the disk,
then reboot.

Unless there is a supported way of replacing the default exception handler,
would I gain anything by replacing KeBugCheck or KeTrap in memory, by a
call/jump to my own exception handler?

I realize this may seem far-fetched...


Any input appreciated,

/ Hannes.

Maxim
Mon Apr 25 12:28:05 CDT 2005

You cannot. MmAccessFault does not raise the access violation exception on
some faults, it BSODs instead.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Hannes" <hannes.news@nospam.nospam> wrote in message
news:A902B6BE-5912-45D5-B56B-0382A824C3C9@microsoft.com...
> In posting
>
http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.development.device.drivers&mid=74822b53-9342-4101-bbb8-b0daf2afc25b&sloc=en-us
> I learned that __try/__except and such can only catch a subset of all
> exceptions that may occur in a kernel driver. Unless we write perfect code,
> this will eventually come back and bite us.
>
> Is it at all possible - probably not advisable though - to override the
> kernel exception handler? I'd write some exception information to the disk,
> then reboot.
>
> Unless there is a supported way of replacing the default exception handler,
> would I gain anything by replacing KeBugCheck or KeTrap in memory, by a
> call/jump to my own exception handler?
>
> I realize this may seem far-fetched...
>
>
> Any input appreciated,
>
> / Hannes.

pavel_a
Tue Apr 26 14:00:03 CDT 2005

Yes this is far-fetched.
You can install a crash dump handler that allows you to add your data to
crash dump,
and there is something in the windbg SDK to retrieve this data.

--PA

"Hannes" wrote:
> In posting
> http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.development.device.drivers&mid=74822b53-9342-4101-bbb8-b0daf2afc25b&sloc=en-us
> I learned that __try/__except and such can only catch a subset of all
> exceptions that may occur in a kernel driver. Unless we write perfect code,
> this will eventually come back and bite us.
>
> Is it at all possible - probably not advisable though - to override the
> kernel exception handler? I'd write some exception information to the disk,
> then reboot.
>
> Unless there is a supported way of replacing the default exception handler,
> would I gain anything by replacing KeBugCheck or KeTrap in memory, by a
> call/jump to my own exception handler?
>
> I realize this may seem far-fetched...
>
>
> Any input appreciated,
>
> / Hannes.

James
Wed Apr 27 17:24:41 CDT 2005

Replacing that component is not supported.

Can you say what is your actual objective? What is it you want to write to
disk, and what purpose would that serve?

--
James Antognini
Windows DDK Support


This posting is provided "AS IS" with no warranties, and confers no rights.



"Hannes" <hannes.news@nospam.nospam> wrote in message
news:A902B6BE-5912-45D5-B56B-0382A824C3C9@microsoft.com...
> In posting
> http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.development.device.drivers&mid=74822b53-9342-4101-bbb8-b0daf2afc25b&sloc=en-us
> I learned that __try/__except and such can only catch a subset of all
> exceptions that may occur in a kernel driver. Unless we write perfect
> code,
> this will eventually come back and bite us.
>
> Is it at all possible - probably not advisable though - to override the
> kernel exception handler? I'd write some exception information to the
> disk,
> then reboot.
>
> Unless there is a supported way of replacing the default exception
> handler,
> would I gain anything by replacing KeBugCheck or KeTrap in memory, by a
> call/jump to my own exception handler?
>
> I realize this may seem far-fetched...
>
>
> Any input appreciated,
>
> / Hannes.

hannes
Wed Apr 27 17:29:15 CDT 2005

Is there a way to write or install a 'crash dump handler' to catch more
exceptions that __try/__except would catch?

/ Hannes.

hannes
Wed Apr 27 22:42:01 CDT 2005

Sure! Part of of product, running entirely on Windows, is a kernel driver.
When we - God forbid - encounter a driver crash in the field, we need crash
dump information to be able to resolve the issue for our customer(s).

For specific reasons, our machines are running without swap file, so
Windows' internal exception handler is not capable of creating a dump file.

We have written our own kernel exception handler that, when invoked,
assembles as much information as possible into a minidump file, which is
readable by WinDbg.

Part of that information is "loaded modules". For WinDbg to be able to load
the symbols for these modules, the minidump must contain checksum & timestamp
information about all loaded modules. This information is stored in the PE
header, which appears near the beginning of the module's memory block.


Unfortunately, a small number of modules are not readable, our exception
handler crashes when trying to read any address in their memory range.

If we *knew* what modules we would not be able to read, we could safely
avoid these, and at least get information from the other modules.

This is why I'm asking if there is any way to determine if a certain module
will be accessible or not - before we go ahead and crash trying to access it.


/ Hannes.

"James Antognini [MSFT]" wrote:
> Replacing that component is not supported.
>
> Can you say what is your actual objective? What is it you want to write to
> disk, and what purpose would that serve?

Maxim
Thu Apr 28 11:10:01 CDT 2005

> For specific reasons, our machines are running without swap file, so

Run some of them with swap file for a while, catch the bug and fix the driver.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

James
Thu Apr 28 13:30:27 CDT 2005

The inability to get a dump without a pagefile is a recognized problem, and
I believe this will be addressed in a future OS.

For now, overriding the kernel exception handler is a very fragile solution.
You can expect it will break sooner or later. If you're doing that in your
own lab, OK. But if it goes elsewhere, you are taking a chance. I personally
would try to get a repro set up, attach a kernel debugger, run the repro and
debug that way.

--
James Antognini
Windows DDK Support


This posting is provided "AS IS" with no warranties, and confers no rights.



"Hannes" <hannes.news@nospam.nospam> wrote in message
news:F1E7EF51-10FB-4425-8B97-C4BCA9198F73@microsoft.com...
> Sure! Part of of product, running entirely on Windows, is a kernel driver.
> When we - God forbid - encounter a driver crash in the field, we need
> crash
> dump information to be able to resolve the issue for our customer(s).
>
> For specific reasons, our machines are running without swap file, so
> Windows' internal exception handler is not capable of creating a dump
> file.
>
> We have written our own kernel exception handler that, when invoked,
> assembles as much information as possible into a minidump file, which is
> readable by WinDbg.
>
> Part of that information is "loaded modules". For WinDbg to be able to
> load
> the symbols for these modules, the minidump must contain checksum &
> timestamp
> information about all loaded modules. This information is stored in the PE
> header, which appears near the beginning of the module's memory block.
>
>
> Unfortunately, a small number of modules are not readable, our exception
> handler crashes when trying to read any address in their memory range.
>
> If we *knew* what modules we would not be able to read, we could safely
> avoid these, and at least get information from the other modules.
>
> This is why I'm asking if there is any way to determine if a certain
> module
> will be accessible or not - before we go ahead and crash trying to access
> it.
>
>
> / Hannes.
>
> "James Antognini [MSFT]" wrote:
>> Replacing that component is not supported.
>>
>> Can you say what is your actual objective? What is it you want to write
>> to
>> disk, and what purpose would that serve?
>

hannes
Thu Apr 28 14:14:07 CDT 2005

There is no such thing as perfect testing, I'm afraid, and our customers WILL
see crashes that we can't reproduce.

/ Hannes.

"Maxim S. Shatskih" wrote:

> > For specific reasons, our machines are running without swap file, so
>
> Run some of them with swap file for a while, catch the bug and fix the driver.

Maxim
Thu Apr 28 16:59:04 CDT 2005

I don't think so. Probably you have 1 - only 1 - driver bug, which causes
this. So, you have good chances.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Hannes" <hannes.news@nospam.nospam> wrote in message
news:D4131E10-323E-49AB-98C6-106D498A74EA@microsoft.com...
> There is no such thing as perfect testing, I'm afraid, and our customers WILL
> see crashes that we can't reproduce.
>
> / Hannes.
>
> "Maxim S. Shatskih" wrote:
>
> > > For specific reasons, our machines are running without swap file, so
> >
> > Run some of them with swap file for a while, catch the bug and fix the
driver.
>

hannes
Fri Apr 29 18:42:04 CDT 2005

I appreciate your optimism and belief in me :-)

Unfortunately, our driver has grown to about 24,000 lines of code, and it is
still growing. A large portion of our product is moving into this
driver....so we expect crashes in various areas, especially as we introduce
new features.


Thanks for your comments! I guess the outcome here is, that without a swap
file, we will only be catch certain crashes, through our try/except blocks.


/ Hannes.