I am trying to read a reg property called "ParentIdPrefix".

I open the key with the following:
HKEY hkey = SetupDiOpenDevRegKey(info,
devdata,

DICS_FLAG_GLOBAL,
0,
DIREG_DEV,
KEY_READ);

I check the status of that call and the key was indeed opened.
Then I want to read my value from there.

Status = RegQueryValueEx( hkey,
"ParentIdPrefix",
NULL,
&RegistryValueType,
(PUCHAR)Buffer,
&BufferLength );

When I check the Status it is a 2 (file not found). However, when I call
FormatMessage
to get some info I get the command completed successfully.

What am I screwing up here?

~Mike

Mike Pulice wrote:
The key question is how this value gets into the registry. If you have
an AddReg section in the [xxx.hw] section of your INF file, HKR means
the key that you're opening with the code you posted. That's the Device
Parameters subkey of the hardware key in 2K++ and the hardware key
itself in Me--. You open the same key in kernel mode by calling
IoOpenDeviceRegistryKey with the PLUGPLAY_REGKEY_DEVICE parameter.

The "2" means that the value isn't found. Your subsequent call to
FormatMessage must be using an updated value of GetLastError() if it
reports success (my guess, anyway).

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com

"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:3FCE9D51.2E140F46@oneysoft.com...
Thank you Walter. Thats exactly the problem.
So I need to be one up from where I am. I was
trying to use SetupDiGetDeviceRegistryProperty.
However, there is no SPDRP for ParentIdPrefix.

Though, I am not out of the woods yet I really appreciate
your response. At least I can move on from this road block.

~mike

the ParentIdPrefix value is used internally by pnp only. you
MUST not depend on it.

this is true of EVERY registry value in that same key, even ones
whose values appear to correspond to the properties retrieved
by SetupDiGetDeviceRegistryProperty SPDRP_ properties.

these values (and the entire structure of the pnp-specific parts
of the registry) are an internal implementation detail of the pnp
manager, and are subject to change. always use the documented
APIs to retrieve info about devices.

what specifically are you trying to do? there is probably a
legitimate way to get the info you need.

for example, if you need to retrieve information about a device's
parent, use APIs like CM_Get_Parent, etc.

Obtaining the Parent of a Device in the Device Tree:
http://msdn.microsoft.com/library/en...upapi_0wyv.asp

hope this helps,
jim.

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


"Mike Pulice" <badvox@verizon.net> wrote in message
news:OQyHOJhuDHA.3532@TK2MSFTNGP11.phx.gbl...

Actually Jim that does help. However, I read that MS advises not to use
the CM_ library anymore. In fact I think thats in Walter Oney's 2nd Ed
of his book.

Anyway, I have a driver from a Vendor that I must support (Management ya
know).
Problem is the function driver (child) of the bus driver (parent composite
driver)
does not do any PnP notifications. I do get interface notifications from
the parent though.
In which case I can get my expected VID and PID and I know its my device.
Problem is I don't know anything about the function driver (child) instance
that will then load
as a result of this. The upper driver has a COM name resource that I need.

No matter how I slice this its a hack and I am just trying to do it the
right
way which is becoming clear that the right way is impossible with this
driver.

Can you tell me how to get management not to use this sample driver that
doesn't play nice? :-)

~mike


"Jim Cavalaris [MS]" <jamesca@online.microsoft.com> wrote in message
news:3fd139ae$1@news.microsoft.com...

it is advised not to use the CM APIs for routines whose
functionality has been superceded by the SetupDi routines,
but there are just a small handful of CM APIs that are
still supported because they have no SetupDi equivalent
(the SetupDi routines were designed mostly for use
during device installation, so you may have to revert back
to the CM APIs for direct low-level device management).

yeah, i know, it's hard to tell which routines those are.
the easy way is to check which CM APIs are documented.

documentation exists for the CM APIs that are still supported,
while the ones that have been superceded indicate you should
"Use device installation functions instead".

PnP Configuration Manager Functions:
http://msdn.microsoft.com/library/en...mgrfn_88oi.asp

generally, the CM APIs that are still supported are the device
tree traversal routines (CM_Get_Parent, CM_Get_Sibling, etc.),
those related to device resources (CM_Get_First_Log_Conf, etc.),
CM_Get_DevNode_Status, CM_Request_Device_Eject, and
the routines to help move between setupapi SP_DEVINFO_DATA
and CM DEVINST handles (CM_Locate_DevNode, CM_Get_Device_ID).

here's the story:
the SetupDi routines are layered on top of the CM APIs, and
introduce the concept of allowing other components to
interact with device installation and management (class
installers, co-installers). when you install or manage
devices (enable, disable, etc.) with the correspinding SetupDi
routines, those components are called to potentially perform
additional work for the action. if you use the CM APIs to
perfrom these actions directly, you bypass those components,
and can potentially leave the device in an inconsistent state.
that's why the CM APIs that have SetupDi equivalents should


now, re: your parent/child problem... are you saying that the
child device is the one that registers the COM port name?
ideally, this device would register a device interface for
the COM port device interface class (GUID_DEVINTERFACE_COMPORT),
but it sounds like that is not the case here.

if the parent provides an interface on which you can receive
notification, you can translate that device interface to find
the parent device that registered it, and then enumerate the
chilren of that device to find the right child.

when you a device interface arrival event, create an empty
device info set:

SetupDiCreateDeviceInfoList:
http://msdn.microsoft.com/library/en...-rtns_2iya.asp

add the device interface (using the dbcc_name path as the DevicePath):

SetupDiOpenDeviceInterface:
http://msdn.microsoft.com/library/en...-rtns_49v6.asp

this will return a SP_DEVICE_INTERFACE_DATA representing the
device interface in the set.

use SetupDiGetDeviceInterfaceDetail to retrieve a SP_DEVINFO_DATA
that corresponds to the device the interface is registered for.

SetupDiGetDeviceInterfaceDetail:
http://msdn.microsoft.com/library/en...-rtns_6ar6.asp

the SP_DEVINFO_DATA structure contains a DevInst field that is
a dnDevInst DEVINST handle that you can use with the CM APIs,
such as CM_Get_Child.

SP_DEVINFO_DATA:
http://msdn.microsoft.com/library/en...truct_7nqq.asp

CM_Get_Child:
http://msdn.microsoft.com/library/en...mgrfn_7zea.asp

to get all children, call CM_Get_Sibling on each child.

CM_Get_Sibling:
http://msdn.microsoft.com/library/en...mgrfn_5hbm.asp

to go back and get a SetupDi SP_DEVINFO_DATA for a particular
DEVINST, retieve the device instance id of the DEVINST using:

CM_Get_Device_ID:
http://msdn.microsoft.com/library/en...mgrfn_00vm.asp

and add it to an existing SetupDi HDEVINFO device info list
by name, using:

SetupDiOpenDeviceInfo:
http://msdn.microsoft.com/library/en...-rtns_8n02.asp

you can retrieve the multi-sz list of Hardware IDs and Compatible IDs
for a device using SetupDiGetDeviceRegistryProperty, for the
SPDRP_HARDWAREID, and SPDRP_COMPATIBLEIDS properties. that may help
you find the right child:

SetupDiGetDeviceRegistryProperty:
http://msdn.microsoft.com/library/en...-rtns_4x2q.asp

i'm assuming that you could get the COM port name from the
"PortName" registry value in the child device's pnp hardware
key, as described by:

Registry Settings for a Plug and Play COM Port:
http://msdn.microsoft.com/library/en...seovr_4unb.asp

this is the key that is opened using:

SetupDiOpenDevRegKey, DIREG_DEV:
http://msdn.microsoft.com/library/en...-rtns_8g36.asp

hope this helps,
jim.

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


"Mike Pulice" <badvox@verizon.net> wrote in message
news:%23Ed3wGavDHA.3224@tk2msftngp13.phx.gbl...

Damn. That is some explanation Jim. Actually that helps alot.

I know it sounds like a miserable mess thats because it is.
Because a few people got used to using this sample driver
before the real one was finished we have to continue to support
even though its apain in the neck. Supporting one is hard enough
but supporting two with differing PnP behavior really sucks.

Just as you explained I do get the parents PnP notifications
so I will give this a shot. Thanks I really appreciate it.

~mike



"Jim Cavalaris [MS]" <jamesca@online.microsoft.com> wrote in message
news:3fd517c2$1@news.microsoft.com...
p