Hi All,
We have written a virtual storminiport driver.Now we are looking for to add a support for crash dump.I have gone through the DDK documentation and few google pages.I could not get a better understanding of it.If some one has did this,can you provoide a pointer to some good documentations or can you please take your time to mention the what all are the steps invloled into it.
Thanks in advance…
Let me add some description :
BTW ,our virtual miniport driver will be enumerated by virtual bus driver.Miniport driver doent communicate with hardware directly.It will be through the virtual bus driver.It means that even during the crash dump,bus driver should be loaded ,followed by miniport driver.
>communicate with hardware directly.It will be through the virtual bus driver.It means that even during
the crash dump,bus driver should be loaded ,followed by miniport driver.
The crash dump path is very much limited.
Surely the crash dump path cannot load anything.
Also, it cannot allocate memory. It is executed on HIGH_LEVEL. It cannot accept interrupts. And so on.
The only support Windows provides to you is the 2phase protocol of crash dump drivers.
On phase 1 in the init path, you respond to some “get dump pointers” IOCTL, returning the DMA common buffer and the hardware register addresses for the dump path. The OS saves this information, and load the second instance of your driver just to do dumps. The DriverEntry of this second instance is not called after load.
On phase 2 when the actual dump occurs, the OS calls DriverEntry of the second dump instance, passing there the information gathered at phase 1. The driver is expected to quickly program the hardware according to this data (yes, the same hardware instance) and then execute writes, using polling instead of interrupts.
Everything is undocumented, surely, and, surely, everything was reworked in Vista.
I remember there was some disk encryption open source code (TrueCrypt?) which can be studied as the sample of pre-Vista (at least) crash dump filter.
SCSIPORT+DISKDUMP implement all of this for miniports, so, just the second instance of the miniport is loaded and then activated (using usual HwFindAdapter+HwInitialize) and used during the dump.
I think STORPORT also does this, but this requires the second instance of the miniport to be loaded and not initialized till the dump will occur.
So, you have the task of a) determining whether this miniport instance is a dump instance and b) running some quick simplified procedure of hardware accesses for the dump path, bypassing the bus driver at all.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Be aware that crash dump support for virtual storport’s varies with the
OS. It was not available for Windows Server 2003, IIRC it was not
available for the first instances of Vista and 2008 but was available
for Win7 and 2008 R2.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@rediffmail.com” wrote in message
news:xxxxx@ntdev:
> Hi All,
>
> We have written a virtual storminiport driver.Now we are looking for to add a support for crash dump.I have gone through the DDK documentation and few google pages.I could not get a better understanding of it.If some one has did this,can you provoide a pointer to some good documentations or can you please take your time to mention the what all are the steps invloled into it.
>
> Thanks in advance…
>
> communicate with hardware directly.It will be through the virtual
bus
> driver.It means that even during
> the crash dump,bus driver should be loaded ,followed by miniport
driver.The crash dump path is very much limited.
Surely the crash dump path cannot load anything.
Also, it cannot allocate memory. It is executed on HIGH_LEVEL. It
cannot
accept interrupts. And so on.The only support Windows provides to you is the 2phase protocol of
crash dump
drivers.On phase 1 in the init path, you respond to some “get dump pointers”
IOCTL,
returning the DMA common buffer and the hardware register addresses
for the
dump path. The OS saves this information, and load the second instance
of your
driver just to do dumps. The DriverEntry of this second instance is
not
called after load.On phase 2 when the actual dump occurs, the OS calls DriverEntry of
the second
dump instance, passing there the information gathered at phase 1. The
driver
is expected to quickly program the hardware according to this data
(yes, the
same hardware instance) and then execute writes, using polling instead
of
interrupts.Everything is undocumented, surely, and, surely, everything was
reworked in
Vista.I remember there was some disk encryption open source code
(TrueCrypt?) which
can be studied as the sample of pre-Vista (at least) crash dump
filter.SCSIPORT+DISKDUMP implement all of this for miniports, so, just the
second
instance of the miniport is loaded and then activated (using usual
HwFindAdapter+HwInitialize) and used during the dump.I think STORPORT also does this, but this requires the second instance
of the
miniport to be loaded and not initialized till the dump will occur.So, you have the task of a) determining whether this miniport instance
is a
dump instance and b) running some quick simplified procedure of
hardware
accesses for the dump path, bypassing the bus driver at all.
Maxim,
While your attention is on the subject, I’ve only done this for scsiport
but do you know if the crash and hiber setups are similar for storport
in the way that they are similar for scsiport? I hope to write a
storport driver shortly as I’ve heard rumour that scsiport might not be
supported in future OS’s… (still works fine in 7/2008R2 though!).
Thanks
James
Maxim,Don,James …thanks for your reply.Currently,our concern is that virtual miniport is having couple of threads which perform read/write asynchronously i.e. startio delegate the work to threads.later,threads complete the request.So,Miniport driver is having threads and event mechanisim ,
other synchronization constructs.As you said,during the crash dump code path executes at the HIGH_LEVEL,how shall i accomplish all the above stuff.
>
Maxim,Don,James …thanks for your reply.Currently,our concern is that
virtual
miniport is having couple of threads which perform read/write
asynchronously
i.e. startio delegate the work to threads.later,threads complete the
request.So,Miniport driver is having threads and event mechanisim ,
other synchronization constructs.As you said,during the crash dump
code path
executes at the HIGH_LEVEL,how shall i accomplish all the above stuff.
Can you describe what sort of things the threads are doing? What is your
underlying storage? If it’s network based then I guess you need to hope
that the underlying NDIS stack supports running at HIGH_LEVEL. If it’s
something else then the more info you can give the more likely you are
going to get a useful answer.
The premise of crash dump mode is that the system has broken and in
theory nothing can be relied on so only the minimum amount of activity
should happen. A punt is taken that the crash dump driver is intact, and
that the PCI (or whatever) bus is in good enough shape to talk to your
device. Windows calls your driver to reset the hardware to a known state
and then gives you write requests to write out all the memory (depending
on what your dump settings are).
James
James thanks for your reply…as i mentioned in the post,virtual bus driver will be enumerated by controller.Basically,controller does resource mapping and other stuff…pass it to VMiniport…Miniport is having threads which do async IOs.Now my questions are:
Thanks,
>
James thanks for your reply…as i mentioned in the post,virtual bus
driver
will be enumerated by controller.Basically,controller does resource
mapping
and other stuff…pass it to VMiniport…Miniport is having threads
which do
async IOs.Now my questions are:
I’m not an expert by any means, but based on what I know about storport
and IRQL’s under windows…
- Since,IO will be done by threads,how to use thread and wait events
for
crash dump.Is it possible to use it.?
No
2.Can we do other stuff out of HwStartIo context during the crash
dump.
No
3.Controller is the one who enumerates the miniport driver,while crash
dump
,does system automatically load the controller or we need to do
someother
stuff ?
Crash dump assumes the hardware is already set up, everything is mapped,
it just calls you again with the same resources and stuff.
My question to you is why on earth are you doing things this way? You
must have a reason but unless you give a few hints about why you have
deviated so wildly from the blessed path you are just going to leave
people scrathing their heads. My guesses are:
James