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?
|