Prev: USB stich influences FireWire throughput
Next: Identifying the cause of Code 12 error
From: RamenWarrior on 18 Jun 2010 12:34
I am adding WMI support to my storport driver and used the sample code in the
DDK iSCSI driver as a foundation. My driver is simply trying to support the
HBA API and does not have any unique data to provide. There is no MOF for my
driver and I am simply using the GUID provided in Windows header files to
describe the data that can be retrieved from my driver.

The first time I executed my code I got a BSOD. After tracing through the
code, I determined that the srb->DataPath was NULL and that pointer was being
used inside scsiwmi.lib while processing the WMI request. I replaced the NULL
with a pointer to a GUID that I support and the code executed without
crashing.

I am not sure why the srb->DataPath would be used for the first WMI request.
I was expecting it to be a simple QueryRegInfo request, trying to identify
the MOF that might be defined in my storport driver.


Does anyone have any ideas about what might be happening?
From: RamenWarrior on 21 Jun 2010 17:57
Someone else reported that they saw srb->DataPath was NULL for the first
request in their storport driver as well. Is it possible this problem is
caused by not having a BMF file included in my .rc file? As I mentioned in
the original post, I have no private data and assumed these definitions were
optional.

"RamenWarrior" wrote:

> I am adding WMI support to my storport driver and used the sample code in the
> DDK iSCSI driver as a foundation. My driver is simply trying to support the
> HBA API and does not have any unique data to provide. There is no MOF for my
> driver and I am simply using the GUID provided in Windows header files to
> describe the data that can be retrieved from my driver.
>
> The first time I executed my code I got a BSOD. After tracing through the
> code, I determined that the srb->DataPath was NULL and that pointer was being
> used inside scsiwmi.lib while processing the WMI request. I replaced the NULL
> with a pointer to a GUID that I support and the code executed without
> crashing.
>
> I am not sure why the srb->DataPath would be used for the first WMI request.
> I was expecting it to be a simple QueryRegInfo request, trying to identify
> the MOF that might be defined in my storport driver.
>
>
> Does anyone have any ideas about what might be happening?
From: James Antognini [MSFT] James Antognini on 20 Jul 2010 21:58
On Win7 at least (where I just tried), it's to be expected that the first WMI
SRB will have pSrb->DataPath = 0. I cannot explain the bugcheck you saw.
Since, as far as I know, a miniport saying it's a WMI provider must always
provide a .mof resource name, your problem may result from not doing so. Do
as I did, create a .mof with a few classes from HBAAPI.mof (I assume that's
what your reference to "HBA API" means) and see if things work.

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

"RamenWarrior" wrote:

> Someone else reported that they saw srb->DataPath was NULL for the first
> request in their storport driver as well. Is it possible this problem is
> caused by not having a BMF file included in my .rc file? As I mentioned in
> the original post, I have no private data and assumed these definitions were
> optional.
>
> "RamenWarrior" wrote:
>
> > I am adding WMI support to my storport driver and used the sample code in the
> > DDK iSCSI driver as a foundation. My driver is simply trying to support the
> > HBA API and does not have any unique data to provide. There is no MOF for my
> > driver and I am simply using the GUID provided in Windows header files to
> > describe the data that can be retrieved from my driver.
> >
> > The first time I executed my code I got a BSOD. After tracing through the
> > code, I determined that the srb->DataPath was NULL and that pointer was being
> > used inside scsiwmi.lib while processing the WMI request. I replaced the NULL
> > with a pointer to a GUID that I support and the code executed without
> > crashing.
> >
> > I am not sure why the srb->DataPath would be used for the first WMI request.
> > I was expecting it to be a simple QueryRegInfo request, trying to identify
> > the MOF that might be defined in my storport driver.
> >
> >
> > Does anyone have any ideas about what might be happening?
From: eagersh on 22 Jul 2010 12:25
On Jun 18, 10:34 am, RamenWarrior <RamenWarr...(a)nospam.nospam> wrote:
> I am adding WMI support to my storport driver and used the sample code in the
> DDK iSCSI driver as a foundation. My driver is simply trying to support the
> HBA API and does not have any unique data to provide. There is no MOF for my
> driver and I am simply using the GUID provided in Windows header files to
> describe the data that can be retrieved from my driver.
>
> The first time I executed my code I got a BSOD. After tracing through the
> code, I determined that the srb->DataPath was NULL and that pointer was being
> used inside scsiwmi.lib while processing the WMI request. I replaced the NULL
> with a pointer to a GUID that I support and the code executed without
> crashing.
>
> I am not sure why the srb->DataPath would be used for the first WMI request.
> I was expecting it to be a simple QueryRegInfo request, trying to identify
> the MOF that might be defined in my storport driver.
>
> Does anyone have any ideas about what might be happening?

Compile and attach as a resource the standard HBA API mof file.
Somebody report similar problem at OSR forum around month ago. A
person who ask the same question tried to implement exact solution -
putting existing GUID to DataPath. After that he got another problem.
I don't remember details but you could make search on OSR archive. He
solved the problem by compiling and attaching HBA API mof file as I
suggest.

Igor Sharovar
 | 
Pages: 1
Prev: USB stich influences FireWire throughput
Next: Identifying the cause of Code 12 error