Hi there,
I am implementing crash dump feature of my Storport Virtual Miniport (SVM) driver. http://msdn.microsoft.com/en-us/library/ff552471(v=VS.85).aspx tells me that I have to support SRB_FUNCTION_DUMP_POINTERS SRB. http://msdn.microsoft.com/en-us/library/ff562247.aspx gives me some comments about how to set MINIPORT_DUMP_POINTERS structure. Some field such as AccessRanges will be set by Storport driver and must not be changed in Storport Miniport driver. But the fact is that all these fields are zero or NULL when my Storport Virtual Miniport driver gets it from SRB->DataBuffer and system doesn’t call any function of my Storport Virtual Miniport driver after it’s crashed. I’ve tried in Windows 2003 with hotfix to support SVM and windows 7, both get the same result.
Any doc I would supposed to read first?
Thanks
Wayne
Sorry for my fault.
Set a proper driver name in MINIPORT_DUMP_POINTERS, my storport virtual miniport driver is called for crash dump. I cannot believe system use the name to determine which driver to use to crash dump.
Thanks
Wayne
From: Wayne Gong
Sent: Thursday, April 01, 2010 4:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] crash dump of Storport Virtual Miniport
Hi there,
I am implementing crash dump feature of my Storport Virtual Miniport (SVM) driver. http://msdn.microsoft.com/en-us/library/ff552471(v=VS.85).aspx tells me that I have to support SRB_FUNCTION_DUMP_POINTERS SRB. http://msdn.microsoft.com/en-us/library/ff562247.aspx gives me some comments about how to set MINIPORT_DUMP_POINTERS structure. Some field such as AccessRanges will be set by Storport driver and must not be changed in Storport Miniport driver. But the fact is that all these fields are zero or NULL when my Storport Virtual Miniport driver gets it from SRB->DataBuffer and system doesn’t call any function of my Storport Virtual Miniport driver after it’s crashed. I’ve tried in Windows 2003 with hotfix to support SVM and windows 7, both get the same result.
Any doc I would supposed to read first?
Thanks
Wayne
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
It loads the image. by name.
Mark Roddy
On Wed, Apr 7, 2010 at 2:48 AM, Wayne Gong wrote:
> Sorry for my fault.
>
> Set a proper driver name in MINIPORT_DUMP_POINTERS, my storport virtual
> miniport driver is called for crash dump. I cannot believe system use the
> name to determine which driver to use to crash dump.
>
>
>
> Thanks
>
> Wayne
>
>
>
> From: Wayne Gong
> Sent: Thursday, April 01, 2010 4:47 PM
>
> To: Windows System Software Devs Interest List
> Subject: [ntdev] crash dump of Storport Virtual Miniport
>
>
>
> Hi there,
>
>
>
> I am implementing crash dump feature of my Storport Virtual Miniport (SVM)
> driver. http://msdn.microsoft.com/en-us/library/ff552471(v=VS.85).aspxtells me that I have to support SRB_FUNCTION_DUMP_POINTERS SRB.
> http://msdn.microsoft.com/en-us/library/ff562247.aspx gives me some
> comments about how to set MINIPORT_DUMP_POINTERS structure. Some field such
> as AccessRanges will be set by Storport driver and must not be changed in
> Storport Miniport driver. But the fact is that all these fields are zero or
> NULL when my Storport Virtual Miniport driver gets it from SRB->DataBuffer
> and system doesn?t call any function of my Storport Virtual Miniport driver
> after it?s crashed. I?ve tried in Windows 2003 with hotfix to support SVM
> and windows 7, both get the same result.
>
>
>
> Any doc I would supposed to read first?
>
>
>
> Thanks
>
> Wayne
>
>
> —
> 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
>
As Mr. Roddy pointed out… it does just that.
Why is this surprising? What would you WANT it to use? The “load by name” approach allows ultimate flexibility for the very specific goals of the dump stack. It also allows loading of various filter drivers to support full volume encryption and the like.
It’s actually quite a good approach when you think about it. At least I think so.
Peter
OSR
> Why is this surprising? What would you WANT it to use? The “load by name” approach allows ultimate flexibility for the very specific goals of the dump stack. It also allows loading of various filter drivers to support full volume encryption and the like.
It’s actually quite a good approach when you think about it. At least I think so.
In this case, I agree with you.
Wayne
The question still remains as to how a virtual driver could establish communications with a bus driver at high irql… Has anyone written a virtual storport miniport that relies on a bus to complete it’s I/Os?
I know of such a model that was done as an experimental implementation.
The storport queried the bus driver for a device interface, then stored
the interface away in the dump pointers (IIRC in the
MappedRegisterBase). Then used the pointer call the interfaces. The
driver never shipped, and I was hired to create a different solution in
the same area because of changing needs.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@oracle.com [mailto:xxxxx@oracle.com]
Posted At: Thursday, April 08, 2010 3:59 PM
Posted To: ntdev
Conversation: crash dump of Storport Virtual Miniport
Subject: RE: crash dump of Storport Virtual Miniport
The question still remains as to how a virtual driver could establish
communications with a bus driver at high irql… Has anyone written a
virtual
storport miniport that relies on a bus to complete it’s I/Os?
__________ Information from ESET Smart Security, version of virus
signature
database 5011 (20100408) __________
The message was checked by ESET Smart Security.
http://www.eset.com
Yes, definitely, for crash dumps via a high speed fabric bus.
Jan
The question still remains as to how a virtual driver could establish
communications with a bus driver at high irql… Has anyone written a
virtual storport miniport that relies on a bus to complete it’s I/Os?
It’s hard, Steve. You have to avoid making any calls to the bus driver
which are stateful and any calls to any kernel API. In general, this
implies separate code paths in the bus driver which only get used at crash
time. Certainly it can’t involve sending any IRPs or waiting on any
objects.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> The question still remains as to how a virtual driver could establish
> communications with a bus driver at high irql… Has anyone written a
> virtual storport miniport that relies on a bus to complete it’s I/Os?
>
I think I see, so we would stash away the pointer that the disk driver originally obtained for the bus interface and get that to the dump disk through the dump pointers, but we may want to create special functions in the interface specifically for dumping that do nothing that couldn’t be done at high IRQL.
Thanks for the help all, much appreciated!
> The storport queried the bus driver for a device interface, then stored the interface away in the dump pointers (IIRC in the MappedRegisterBase).
Then used the pointer call the interfaces.
Don, do you mean store the interface in PMINIPORT_DUMP_POINTERS-> MiniportPrivateDumpData? I’ve tried that but didn’t get interface pointer from PPORT_CONFIGURATION_INFORMATION->Reserved as WDK document says.
WDK document says we should set PMINIPORT_DUMP_POINTERS-> MappedRegisterBase to zero (http://msdn.microsoft.com/en-us/library/ff562247.aspx)
All routines in my interface needed for crash dump can work under HIGH_LEVEL because my SCSI miniport driver uses them to dump kernel. My SCSI miniport driver use ScsiPortGetDeviceBase to get the interface from bus driver. But it fails in Storport Virtual Miniport driver as no access range is valid for a virtual device (PPORT_CONFIGURATION_INFORMATION->VirtualDevice = TRUE).
Thanks
Wayne
> It’s hard, Steve. You have to avoid making any calls to the bus driver which are stateful and any calls to any kernel API. In general, this implies separate code paths in the bus driver which only get used at crash time. Certainly it can’t involve sending any IRPs or waiting on any objects.
Actually we are working on Windows Para-virtual driver for Oracle VM (Xen base). We need the bus driver to deal with some memory operations and notify Xen backend drivers, won’t send any IRP or wait any object. These operations can work fine for my SCSI miniport driver. I believe they also can work for Storport Virtual Miniport driver if I can find a way to get that interface from bus driver.
Thanks
Wayne
Well, it depends on what you mean here. Since you wrote the virtual miniport and you wrote the bus driver there is nothing that prevents you having the virtual driver explicitly know about routines in the bus driver. So when a crash occurs, the virtual miniport can call directly into your bus driver to do the I/O at high irql. While I haven’t explicitly done it with storport, I have done it with something else.
–Mark Cariddi
OSR, Open Systems Resources, Inc.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@oracle.com
Sent: Thursday, April 08, 2010 3:59 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] crash dump of Storport Virtual Miniport
The question still remains as to how a virtual driver could establish communications with a bus driver at high irql… Has anyone written a virtual storport miniport that relies on a bus to complete it’s I/Os?
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
Hi all,
Need some help to understand.
While handling SRB_DUMP_POINTERS, we set the driver name in
the PMINIPORT_DUMP_POINTERS structure sent by the SRB. What wud the driver name be?
if it is the vminiport driver name, then how will the os know that the bus driver also has to be loaded during a crash?
Thanks
Vijay
You can’t tell it more than one name. You need to have the bus driver
have a clean separate path for crash dump, using little or none of the
data used for regular operation.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Posted At: Wednesday, April 14, 2010 10:03 AM
Posted To: ntdev
Conversation: crash dump of Storport Virtual Miniport
Subject: RE: crash dump of Storport Virtual Miniport
Hi all,
Need some help to understand.
While handling SRB_DUMP_POINTERS, we set the driver name in the
PMINIPORT_DUMP_POINTERS structure sent by the SRB. What wud the driver
name
be?
if it is the vminiport driver name, then how will the os know that the
bus
driver also has to be loaded during a crash?
Thanks
Vijay
__________ Information from ESET Smart Security, version of virus
signature
database 5028 (20100414) __________
The message was checked by ESET Smart Security.
http://www.eset.com
You use your miniport name. as for your bus driver, it will not be reloaded, but it is in memory (i.e. you were using it before the crash). Therefore your miniport has to have a way to get addresses of routines in your bus driver that it can call to do the dump. One way to do this is to store the data as a driver extension and when your miniport loads it can get the driver extension and get the information from that.
–Mark Cariddi
OSR, Open Systems Resources, Inc…
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, April 14, 2010 10:03 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] crash dump of Storport Virtual Miniport
Hi all,
Need some help to understand.
While handling SRB_DUMP_POINTERS, we set the driver name in
the PMINIPORT_DUMP_POINTERS structure sent by the SRB. What wud the driver name be?
if it is the vminiport driver name, then how will the os know that the bus driver also has to be loaded during a crash?
Thanks
Vijay
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
If the bus driver is the one responsible for a BSOD, then would the dump path routines of the bus driver still be accessible?
Yes the dump path routines will still be accessible. Windows does not
do anything to restrict access to drivers, its dump approach is to have
an independent set of drivers for the dump, but an independent set of
routines in an existing driver is valid also.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@yahoo.com [mailto:xxxxx@yahoo.com]
Posted At: Wednesday, April 14, 2010 11:01 AM
Posted To: ntdev
Conversation: crash dump of Storport Virtual Miniport
Subject: RE: crash dump of Storport Virtual Miniport
If the bus driver is the one responsible for a BSOD, then would the
dump path
routines of the bus driver still be accessible?
__________ Information from ESET Smart Security, version of virus
signature
database 5028 (20100414) __________
The message was checked by ESET Smart Security.
http://www.eset.com
Thanks for that info, Don and Mark.
Regards
Vijay
Mark Cariddi wrote:
Therefore your miniport has to have a way to get addresses of routines in your bus driver that it can call to do the dump. One way to do this is to store the data as a driver extension and when your miniport loads it can get the driver extension and get the information from that.
How can I do that in my storport virtual miniport driver? Will the
driver extension be changed when it’s reloaded to dump kernel?
Thanks
Wayne