Hi,

I'm writing a disk filter driver. I need to call IoGetDeviceProperty()
for property DevicePropertyClassGuid. The function is called in driver's
AddDevice() routine, but the call failed with the error 0xC0000034
(STATUS_OBJECT_NAME_NOT_FOUND).

Here is the code for this call:
NTSTATUS
AddDevice(
IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT PhysicalDeviceObject
)
{
/*
some code here
*/

{
GUID guidBusType = {0};
ULONG length = 0;
status = IoGetDeviceProperty(
PhysicalDeviceObject,
DevicePropertyBusTypeGuid,
sizeof(guidBusType),
&guidBusType,
&length
);

if (status != STATUS_SUCCESS) {
DbgPrint("Device %x, requiredLength %d, status %x.\n",
PhysicalDeviceObject, length, status);
}
else {
DbgPrint("Device %x, BusTypeGuid %08x-%04x-%04x-"
"%02x%02x-%02x%02x%02x%02x%02x%02x\n",
PhysicalDeviceObject,
guidBusType.Data1,
guidBusType.Data2,
guidBusType.Data3,
guidBusType.Data4[0], guidBusType.Data4[1],
guidBusType.Data4[2], guidBusType.Data4[3],
guidBusType.Data4[4], guidBusType.Data4[5],
guidBusType.Data4[6], guidBusType.Data4[7]);
}
}

/*
some code here
*/
}

This piece of code has been tested in toaster driver (included in DDK)
and it works. But it doesn't work in my disk filter driver.

I cannot understand why the call failed with the error code
STATUS_OBJECT_NAME_NOT_FOUND. According to the DDK, the API
IoGetDeviceProperty() usually returns the error STATUS_BUFFER_TOO_SMALL,
STATUS_INVALID_PARAMETER_2, or STATUS_INVALID_DEVICE_REQUEST.

And in the description of IRP_MN_QUERY_BUS_INFORMATION, DDK says "Bus
drivers should handle this request for their child devices (PDOs). " and
"Drivers must not send this IRP. Call IoGetDeviceProperty to get
information about the bus to which a device is attached.".

So, like toaster bus driver(busenum.sys) does, this call should not fail
if all the paramters are correct. Even it fails, it should not fail with
the error 0xC0000034.

In my test, the bus driver of disk device are either Microsoft SCSIPORT
or Microsoft ISCSIPORT driver, I didn't test with MS STORPORT driver.

Could someone help me figure out why the call fails in storage stack and
how I can work around the problem?

Thanks !

is your PDO a PDO created by disk.sys that was actually reported to the
system? or was it a PDO that partmgr enumerated instead?

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"wenhua" <wenhua@discussions.microsoft.com> wrote in message
news:32CAD5F2-D4FD-41DA-BAB7-11E3A67D2E3D@microsoft.com...

The PDO is either created by scsiport.sys(SCSIPORT) or iscsiprt.sys(ISCSI
PORT), my driver is a multi-path IO driver under disk.sys.

"Doron Holan [MS]" wrote:

Just before your driver calls IoGetDeviceProperty, set a break point on the
following two functions and see which one returns an error:

bp nt!IopOpenRegistryKeyEx

bp nt!IopGetRegistryValue

When you hit the breakpoint of IopOpenRegistryKeyEx, get the stack trace and
dump the third parameter with dS command. That will show the key it's trying
to open.

When you hit the breakpoint of IopGetRegistryValue, dump the second param
with du command. That will show the value it's trying to open.

I'm sure one of these calls is failing. Then inspect the registry to see
what it's looking for is really there.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

Well, it doesn't work.

In my filter driver, I set 2 breakpoints just before calling
IoGetDeviceProperty().
The breakpoint on nt!IopOpenRegistryKeyEx was never hit. When the breakpoint
on nt!IopGetRegistryValue() was enabled after calling IoGetDeviceProperty(),
it
was hit, running du command on second parameter gave me a "" string.

In my DSM driver for MPIO, in DsmInquireDevice(), I added the same code. this
time, the breakpoint on nt!IopOpenRegistryKeyEx can be hit, running dS command
on third parameter gave me a Device Instance Id like
SCSI\Disk&Ven_VendorId&Prod_ProductId&Rev_00001&2a fd7d61&0&000 under the
key HKLM\SYSTEM\CURRENTCONTROLSET\ENUM

I checked the registry in second case, everything looks ok, I don't know
what could
be wrong.

When I debug into IoGetDeviceProperty(), I found it's the routine
nt!PpBusTypeGuidGet returning the error 0xC0000034.

Any way, in my both test cases, IoGetDeviceProperty() always failed with error
0xC0000034.

Any suggestions?


"Eliyas Yakub [MSFT]" wrote:

Aha! it seems to me that the bus driver didn't provide any bus type
information to pnp manager in the first place. When the device is
enumerated, the pnp manager sends IRP_MN_QUEYR_BUS_INFORMATION to the PDO to
get that information.

typedef struct _PNP_BUS_INFORMATION {
GUID BusTypeGuid;
INTERFACE_TYPE LegacyBusType;
ULONG BusNumber;
} PNP_BUS_INFORMATION, *PPNP_BUS_INFORMATION;

I'm pretty sure that's the problem in your case but you can verify that by
setting a breakpoint in the bus driver pnp dispatch handler and checking the
information provided by the bus driver. So there is nothing you can do about
this problem.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

Yes, you're right. If the bus driver doesn't handle
IRP_MN_QUERY_BUS_INFORMATION,
IoGetDeviceProperties() will fail with error 0xC0000034.

But if you check DDK, in the description of IRP_MN_QUERY_BUS_INFORMATION, DDK
said "Bus drivers should handle this request for their child devices (PDOs).
Function and
filter drivers do not handle this IRP." .

The bus drivers I'm using are scsiport.sys, storport.sys, iscsiprt.sys . All
are part of
Windows operating system, all from Microsoft.

By publishing DDK, I think Microsoft is telling the developers what should
be done, what
should not be done. But Microsoft itself doesn't follow the rule !!!

Actually, the idea to call IoGetDeviceProperties() to get bus information is
from another
Microsoft developer.

Because the bus drivers are from Microsoft, there is nothing I can do for
this problem.


"Eliyas Yakub [MSFT]" wrote:

Try enumerator name instead of bus type GUID as a fallback.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"wenhua" <wenhua@discussions.microsoft.com> wrote in message
news:75C6BEC9-074D-4DAD-9518-28F6F476AC72@microsoft.com...

In article <eOlwG4TvEHA.1260@TK2MSFTNGP12.phx.gbl>, maxim@storagecraft.com
says...
For scsi targets that is going to be SCSI, which is not very helpful. For the
adapters that is going to be PCI or ROOT, which also is not very helpful.

IOCTL_SCSI_GET_CAPABILITIES can get you a STORAGE_ADAPTER_DESCRIPTOR which
includes a STORAGE_BUS_TYPE field. This *might* tell you what kind of adapter
you are dealing with. Unfortunately quite a few miniports claim to be scsi even
when they are not. Also some adapters return values not defined in the current
sdk (like iscsi.)

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com