In order to track down what is happening in my driver (a mini-filter) when it is unloaded then reloaded, I am considering storing some statistics and a note of what has happened in memory so that it can be picked up and used in dump analysis - should something go wrong. Of course, if I simply allocate non-paged pool, verifier will barf when the driver unloads leaving the memory allocated. Really I’d like a simple way to find it, and for the next load of my driver to be able to update it too. Anyone got good ideas about the mechanism I could use? Writing another driver just to provide this facility seems like overkill!
I wondered about using the registry, but this seems somewhat heavyweight. What about using ZwCreateSection to create a pagefile-backed section? I could simply reference the memory to store a data structure or two, although I’d have to be careful to do it at passive level as being paged, it could take a page fault I presume.
The underlying problem is that although I already have excellent tracing (proper WPP based), I need to get to the bottom of obscure and rare issues seen when the driver is unloaded - generally on a customer system where tracing has not been enabled. Preserving some statistics and a sort of mini-trace on key events would, I believe, help me track down the problematic code.
Any wisdom from those of you who have worked full-time in this area for many years would be appreciated!
Why not have a simple legacy driver loaded in the system to which you
write the statistics and events ?
I did something like that years ago as a tracing driver to synchronise
trace from multiple kernel and user mode sources. All your mini-filter
has to do on startup is open the named device and use IRPs or exposed
interface functions to write data. Let the other driver manage the
storing and manipulation of the data, ideally you want to make as few
changes as possible to mini-filter or you start to lose focus on what
the mini-filter is designed to do.
If the trace driver keeps data in memory rather than a file, just write
a simple user-mode app to recover the data.
Mark.
On 24/11/2011 14:21, xxxxx@bhead.co.uk wrote:
In order to track down what is happening in my driver (a mini-filter) when it is unloaded then reloaded, I am considering storing some statistics and a note of what has happened in memory so that it can be picked up and used in dump analysis - should something go wrong. Of course, if I simply allocate non-paged pool, verifier will barf when the driver unloads leaving the memory allocated. Really I’d like a simple way to find it, and for the next load of my driver to be able to update it too. Anyone got good ideas about the mechanism I could use? Writing another driver just to provide this facility seems like overkill!
I wondered about using the registry, but this seems somewhat heavyweight. What about using ZwCreateSection to create a pagefile-backed section? I could simply reference the memory to store a data structure or two, although I’d have to be careful to do it at passive level as being paged, it could take a page fault I presume.
The underlying problem is that although I already have excellent tracing (proper WPP based), I need to get to the bottom of obscure and rare issues seen when the driver is unloaded - generally on a customer system where tracing has not been enabled. Preserving some statistics and a sort of mini-trace on key events would, I believe, help me track down the problematic code.
Any wisdom from those of you who have worked full-time in this area for many years would be appreciated!
As Mark says it can be another driver, it can also be the registry. If
you keep it in a volatile key it stays in memory only and will not exist
across boots. Personally, I don’t consider the registry to be
heavyweight for this type of stuff, even if you don’t make the key
volatile.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Mark S. Edwards” wrote in message
news:xxxxx@ntfsd:
> Why not have a simple legacy driver loaded in the system to which you
> write the statistics and events ?
>
> I did something like that years ago as a tracing driver to synchronise
> trace from multiple kernel and user mode sources. All your mini-filter
> has to do on startup is open the named device and use IRPs or exposed
> interface functions to write data. Let the other driver manage the
> storing and manipulation of the data, ideally you want to make as few
> changes as possible to mini-filter or you start to lose focus on what
> the mini-filter is designed to do.
>
> If the trace driver keeps data in memory rather than a file, just write
> a simple user-mode app to recover the data.
>
> Mark.
>
>
> On 24/11/2011 14:21, xxxxx@bhead.co.uk wrote:
> > In order to track down what is happening in my driver (a mini-filter) when it is unloaded then reloaded, I am considering storing some statistics and a note of what has happened in memory so that it can be picked up and used in dump analysis - should something go wrong. Of course, if I simply allocate non-paged pool, verifier will barf when the driver unloads leaving the memory allocated. Really I’d like a simple way to find it, and for the next load of my driver to be able to update it too. Anyone got good ideas about the mechanism I could use? Writing another driver just to provide this facility seems like overkill!
> >
> > I wondered about using the registry, but this seems somewhat heavyweight. What about using ZwCreateSection to create a pagefile-backed section? I could simply reference the memory to store a data structure or two, although I’d have to be careful to do it at passive level as being paged, it could take a page fault I presume.
> >
> > The underlying problem is that although I already have excellent tracing (proper WPP based), I need to get to the bottom of obscure and rare issues seen when the driver is unloaded - generally on a customer system where tracing has not been enabled. Preserving some statistics and a sort of mini-trace on key events would, I believe, help me track down the problematic code.
> >
> > Any wisdom from those of you who have worked full-time in this area for many years would be appreciated!
> >
> > - John
> >
> >
Mark, I agree with you in principle, but I know my manager would have fits if I told him I was going to knock up another driver to provide more tracing for the main one!
Don, I didn’t know that about volatile keys in the registry. Presumably you can find these and display the values using the windbg !reg extension - is that correct? Will the data be present in all mini-dumps?
Thanks!
John
The volatile keys act just like regular keys but are not saved to disk.
I doubt they are in the mini-dumps. For volatile keys look at
ZwCreateKey REG_OPTION_VOLATILE. Note that if a key is volatile all
subkeys must be volatile.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@bhead.co.uk” wrote in message
news:xxxxx@ntfsd:
> Mark, I agree with you in principle, but I know my manager would have fits if I told him I was going to knock up another driver to provide more tracing for the main one!
>
> Don, I didn’t know that about volatile keys in the registry. Presumably you can find these and display the values using the windbg !reg extension - is that correct? Will the data be present in all mini-dumps?
>
> Thanks!
> John
> Don, I didn’t know that about volatile keys in the registry.
Memory-only keys which are not persistent across boots.
HKLM\HARDWARE is one. Built by the boot loader on each boot, contains things like the ACPI table.
Used (as volatile) by the kernel.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
You can specify a callback to save your info to crash dump.
KeRegisterBugCheckReasonCallback()
– pa
wrote in message news:xxxxx@ntfsd…
> In order to track down what is happening in my driver (a mini-filter) when
> it is unloaded then reloaded, I am considering storing some statistics and
> a note of what has happened in memory so that it can be picked up and used
> in dump analysis - should something go wrong. Of course, if I simply
> allocate non-paged pool, verifier will barf when the driver unloads
> leaving the memory allocated. Really I’d like a simple way to find it, and
> for the next load of my driver to be able to update it too. Anyone got
> good ideas about the mechanism I could use? Writing another driver just to
> provide this facility seems like overkill!
>
> I wondered about using the registry, but this seems somewhat heavyweight.
> What about using ZwCreateSection to create a pagefile-backed section? I
> could simply reference the memory to store a data structure or two,
> although I’d have to be careful to do it at passive level as being paged,
> it could take a page fault I presume.
>
> The underlying problem is that although I already have excellent tracing
> (proper WPP based), I need to get to the bottom of obscure and rare issues
> seen when the driver is unloaded - generally on a customer system where
> tracing has not been enabled. Preserving some statistics and a sort of
> mini-trace on key events would, I believe, help me track down the
> problematic code.
>
> Any wisdom from those of you who have worked full-time in this area for
> many years would be appreciated!
>
> - John
>
I realize the WDM DDIs make the Registry SEEM like it’s heavyweight, but but the fact is it isn’t heavyweight for this at all. In fact, storage of persistent stuff like this is exactly what the registry is FOR.
This is a debug thing… Why reinvent the wheel?
Peter
OSR