The test environment for this problem is a dual processr with 1/2 gig of RAM
and nearly a terabyte of Seagate SATA/PATA harddiscs under test and booting
from a Promise ATA controller. The OS is XP SP2/RC2. The drivers are written
using Compuwares DriverWorks with the bus driver based on the “vscsi”
example, and uses the KPhysicalDevice and KBus classes for PDO/FDO creation,
enumeration , and management of child drivers.
Once the bus driver has created it’s FDO in AddDevice, it starts the thread
that invalidates the bus to produce one PDO each for the child drivers, ala
vscsi. Thus far, having stepped through this numerous times this appears to
be working properly. The new DOs are indeed created and the calls to
IRP_MN_QUERY_Xxxx IOCTLs handled properly. QUERY_ID generates proper strings
and returns them in IoStatus->Information with Status set to STATUS_SUCCESS.
The QUERY_RESOURCES IRPs are simply completed with Status unchanged.
Once I’m at the desktop on a boot, the AddDeviceWizard does not run. When I
look at the Device Manager I see the parent driver and class has been
created and the bus driver is functionioning properly. However, there is an
Unknown device and it has ChildA and ChildB defined under it. When I then
attempt to install/update either child, it is moved under the proper driver
in Device Manager, but is yellow banged, telling me the driver failed
because of Code 9, “The controlling firmware is reporting the resources for
the device incorrectly.” These child drivers have no resources.
–
Gary G. Little
Seagate Technologies, LLC
as so often happens, shortly after I posted this I found the problem.
It seems ti’s more of an environmental than driver/code problem. I had been
installing and uninstalling the drivers for quite some time on that test
partition. As soon as I tried to install the suite on a fresh OS that had
never seen my driver suite installed … it worked. Crap! I hesitated to
Ghost the partition back to a fresh OS install because I have utilities and
tools installed which I use to test the driver. I have many times tiptoed
through the registry to “clean” it and consistently purged the oem files
from the INF directory, but there is a “sourdough” something that pollutes
an OS over a period of time requiring a fresh start.
That’s the wonderful world of driver writing folks! 
–
Gary G. Little
Seagate Technologies, LLC
“Gary G. Little” wrote in message news:…
> The test environment for this problem is a dual processr with 1/2 gig of
RAM
> and nearly a terabyte of Seagate SATA/PATA harddiscs under test and
booting
> from a Promise ATA controller. The OS is XP SP2/RC2. The drivers are
written
> using Compuwares DriverWorks with the bus driver based on the “vscsi”
> example, and uses the KPhysicalDevice and KBus classes for PDO/FDO
creation,
> enumeration , and management of child drivers.
>
> Once the bus driver has created it’s FDO in AddDevice, it starts the
thread
> that invalidates the bus to produce one PDO each for the child drivers,
ala
> vscsi. Thus far, having stepped through this numerous times this appears
to
> be working properly. The new DOs are indeed created and the calls to
> IRP_MN_QUERY_Xxxx IOCTLs handled properly. QUERY_ID generates proper
strings
> and returns them in IoStatus->Information with Status set to
STATUS_SUCCESS.
> The QUERY_RESOURCES IRPs are simply completed with Status unchanged.
>
> Once I’m at the desktop on a boot, the AddDeviceWizard does not run. When
I
> look at the Device Manager I see the parent driver and class has been
> created and the bus driver is functionioning properly. However, there is
an
> Unknown device and it has ChildA and ChildB defined under it. When I then
> attempt to install/update either child, it is moved under the proper
driver
> in Device Manager, but is yellow banged, telling me the driver failed
> because of Code 9, “The controlling firmware is reporting the resources
for
> the device incorrectly.” These child drivers have no resources.
>
> –
> Gary G. Little
> Seagate Technologies, LLC
>
>