Re: Hardware ids and device ids... (more...)

NTDEV
1

Thanks for the help on HardwareIds. Almost there… :wink:

Now I’m at a loss for understanding why I have added content in the
hardware id path. devcon reports:

VBUS\TEST_DEV_10\4&306CFD90&0&10
Name: Vbus virtual ethernet id = 10
Hardware IDs:
VBUS\test_dev_10
VBUS\TEST_DEV_11\4&306CFD90&0&11
Name: Vbus virtual ethernet id = 11
Hardware IDs:
VBUS\test_dev_11
2 matching device(s) found.

What is “4&306CFD90&0&10” all about? Interesting that the last two
digits are “10” and “11”, which are the InstanceIds I assign. But I do
not understand why my path was modified. I’d like to know.

I create my ids with the following:

DECLARE_CONST_UNICODE_STRING(deviceLocation, L"VBUS\");
DECLARE_UNICODE_STRING_SIZE(type, VBUS_MAX_DEVTYPE_LEN*2);
DECLARE_UNICODE_STRING_SIZE(hwid, VBUS_MAX_DEVTYPE_LEN*2);

/*
* Set DeviceType
*/
WdfDeviceInitSetDeviceType(init, FILE_DEVICE_NETWORK);

RtlInitAnsiString(&atype, d->type);
RtlAnsiStringToUnicodeString(&type, &atype, FALSE);
RtlUnicodeStringCat(&hwid, &deviceLocation);
RtlUnicodeStringCat(&hwid, &type);

/*
* Provide DeviceID, HardwareIDs and InstanceId
*/
rc = WdfPdoInitAssignDeviceID(init, &hwid);
if (!NT_SUCCESS(rc))
return rc;

rc = WdfPdoInitAddHardwareID(init, &hwid);
if (!NT_SUCCESS(rc))
return rc;

RtlUnicodeStringPrintf(&type, L"%d", d->id);
rc = WdfPdoInitAssignInstanceID(init, &type);
if (!NT_SUCCESS(rc))
return rc;

Am I missing something?

THanks,
-PWM

2

> VBUS\TEST_DEV_10\4&306CFD90&0&10
This is the device instance path. It is composed of the hw id (first 2 parts) you reported plus another id. If you report that your device as unique in the system, that 3rd part is the device instance id as is . since it is not unique, the system unique’ified it for you

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Friday, December 04, 2009 9:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Hardware ids and device ids… (more…)

Thanks for the help on HardwareIds. Almost there… :wink:

Now I’m at a loss for understanding why I have added content in the
hardware id path. devcon reports:

VBUS\TEST_DEV_10\4&306CFD90&0&10
Name: Vbus virtual ethernet id = 10
Hardware IDs:
VBUS\test_dev_10
VBUS\TEST_DEV_11\4&306CFD90&0&11
Name: Vbus virtual ethernet id = 11
Hardware IDs:
VBUS\test_dev_11
2 matching device(s) found.

What is “4&306CFD90&0&10” all about? Interesting that the last two
digits are “10” and “11”, which are the InstanceIds I assign. But I do
not understand why my path was modified. I’d like to know.

I create my ids with the following:

DECLARE_CONST_UNICODE_STRING(deviceLocation, L"VBUS\");
DECLARE_UNICODE_STRING_SIZE(type, VBUS_MAX_DEVTYPE_LEN*2);
DECLARE_UNICODE_STRING_SIZE(hwid, VBUS_MAX_DEVTYPE_LEN*2);

/*
* Set DeviceType
*/
WdfDeviceInitSetDeviceType(init, FILE_DEVICE_NETWORK);

RtlInitAnsiString(&atype, d->type);
RtlAnsiStringToUnicodeString(&type, &atype, FALSE);
RtlUnicodeStringCat(&hwid, &deviceLocation);
RtlUnicodeStringCat(&hwid, &type);

/*
* Provide DeviceID, HardwareIDs and InstanceId
*/
rc = WdfPdoInitAssignDeviceID(init, &hwid);
if (!NT_SUCCESS(rc))
return rc;

rc = WdfPdoInitAddHardwareID(init, &hwid);
if (!NT_SUCCESS(rc))
return rc;

RtlUnicodeStringPrintf(&type, L"%d", d->id);
rc = WdfPdoInitAssignInstanceID(init, &type);
if (!NT_SUCCESS(rc))
return rc;

Am I missing something?

THanks,
-PWM

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

On Fri, 2009-12-04 at 21:09 +0000, Doron Holan wrote:

> VBUS\TEST_DEV_10\4&306CFD90&0&10
This is the device instance path. It is composed of the hw id (first 2 parts) you reported plus another id. If you report that your device as unique in the system, that 3rd part is the device instance id as is . since it is not unique, the system unique’ified it for you

d

Thx. How do I “report it as unique in the system”?

(I had assumed the unique deviceid was sufficient)

-PWM

4

Peter W. Morreale wrote:

On Fri, 2009-12-04 at 21:09 +0000, Doron Holan wrote:

>> VBUS\TEST_DEV_10\4&306CFD90&0&10
>>
> This is the device instance path. It is composed of the hw id (first 2 parts) you reported plus another id. If you report that your device as unique in the system, that 3rd part is the device instance id as is . since it is not unique, the system unique’ified it for you
>

Thx. How do I “report it as unique in the system”?

Why do you care? The hardware ID is still VBUS\TEST_DEV_10, and that’s
what it will look for in the INF files. That instance path is just used
to build a registry key.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

On Fri, 2009-12-04 at 14:43 -0800, Tim Roberts wrote:

Peter W. Morreale wrote:
> On Fri, 2009-12-04 at 21:09 +0000, Doron Holan wrote:
>
>>> VBUS\TEST_DEV_10\4&306CFD90&0&10
>>>
>> This is the device instance path. It is composed of the hw id (first 2 parts) you reported plus another id. If you report that your device as unique in the system, that 3rd part is the device instance id as is . since it is not unique, the system unique’ified it for you
>>
>
> Thx. How do I “report it as unique in the system”?
>

Why do you care? The hardware ID is still VBUS\TEST_DEV_10, and that’s
what it will look for in the INF files. That instance path is just used
to build a registry key.

Generally I care quite a bit if an interface takes my data and mangles
in some undocumented way. It leaves me wondering whether I did
something wrong, something I may pay for later.

Doron’s explanation leaves me wondering why, when setting two devices to
the same hardware id, I get identical ‘uniquified’ strings EXCEPT for
the last two characters. Which are the deviceids, which is what I
specified.

So I’m wondering why Windows decided to ‘uniquify’ that portion of the
string by merely pre-pending identical characters on the deviceid. How
is that more unique? If its a question of adding characters to the
deviceid, I’d rather do that. I’ll test that and see.

Judging from the responses, it apparently doesn’t matter to the system.

Thanks,
-PWM

6

The 3rd part of the ID is something you cannot and should not control. The device instance path is an opaque string really. The fact that you can identify its pieces is not the point. You are doing the right thing as you posted in your code, accept that and move on.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Friday, December 04, 2009 3:54 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Hardware ids and device ids… (more…)

On Fri, 2009-12-04 at 14:43 -0800, Tim Roberts wrote:

Peter W. Morreale wrote:
> On Fri, 2009-12-04 at 21:09 +0000, Doron Holan wrote:
>
>>> VBUS\TEST_DEV_10\4&306CFD90&0&10
>>>
>> This is the device instance path. It is composed of the hw id
>> (first 2 parts) you reported plus another id. If you report that
>> your device as unique in the system, that 3rd part is the device
>> instance id as is . since it is not unique, the system unique’ified
>> it for you
>>
>
> Thx. How do I “report it as unique in the system”?
>

Why do you care? The hardware ID is still VBUS\TEST_DEV_10, and
that’s what it will look for in the INF files. That instance path is
just used to build a registry key.

Generally I care quite a bit if an interface takes my data and mangles in some undocumented way. It leaves me wondering whether I did
something wrong, something I may pay for later.

Doron’s explanation leaves me wondering why, when setting two devices to the same hardware id, I get identical ‘uniquified’ strings EXCEPT for the last two characters. Which are the deviceids, which is what I specified.

So I’m wondering why Windows decided to ‘uniquify’ that portion of the string by merely pre-pending identical characters on the deviceid. How
is that more unique? If its a question of adding characters to the
deviceid, I’d rather do that. I’ll test that and see.

Judging from the responses, it apparently doesn’t matter to the system.

Thanks,
-PWM

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Excellent. Now I understand.

Thx
-PWM
-----Original Message-----
From: Doron Holan
To: Windows System Software Devs Interest List

Sent: 12/4/2009 5:02:11 PM
Subject: RE: [ntdev] Hardware ids and device ids… (more…)

The 3rd part of the ID is something you cannot and should not control. The device instance path is an opaque string really. The fact that you can identify its pieces is not the point. You are doing the right thing as you posted in your code, accept that and move on.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter W. Morreale
Sent: Friday, December 04, 2009 3:54 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Hardware ids and device ids… (more…)

On Fri, 2009-12-04 at 14:43 -0800, Tim Roberts wrote:
> Peter W. Morreale wrote:
> > On Fri, 2009-12-04 at 21:09 +0000, Doron Holan wrote:
> >
> >>> VBUS\TEST_DEV_10\4&306CFD90&0&10
> >>>
> >> This is the device instance path. It is composed of the hw id
> >> (first 2 parts) you reported plus another id. If you report that
> >> your device as unique in the system, that 3rd part is the device
> >> instance id as is . since it is not unique, the system unique’ified
> >> it for you
> >>
> >
> > Thx. How do I “report it as unique in the system”?
> >
>
> Why do you care? The hardware ID is still VBUS\TEST_DEV_10, and
> that’s what it will look for in the INF files. That instance path is
> just used to build a registry key.
>

Generally I care quite a bit if an interface takes my data and mangles in some undocumented way. It leaves me wondering whether I did
something wrong, something I may pay for later.

Doron’s explanation leaves me wondering why, when setting two devices to the same hardware id, I get identical ‘uniquified’ strings EXCEPT for the last two characters. Which are the deviceids, which is what I specified.

So I’m wondering why Windows decided to ‘uniquify’ that portion of the string by merely pre-pending identical characters on the deviceid. How
is that more unique? If its a question of adding characters to the
deviceid, I’d rather do that. I’ll test that and see.

Judging from the responses, it apparently doesn’t matter to the system.

Thanks,
-PWM

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

I’d like to suggest that you use some string other than “VBUS” as that’s
about the most likely string I can think of to collide with somebody else’s
virtual bus.

–
Jake Oshins
Hyper-V I/O Architect (Author of a virtual bus driver which uses “VMBUS” as
its enumerator string.)
Windows Kernel Group

This post implies no warranties and confers no rights.

“Peter W. Morreale” wrote in message
news:xxxxx@ntdev…
> On Fri, 2009-12-04 at 21:09 +0000, Doron Holan wrote:
>> > VBUS\TEST_DEV_10\4&306CFD90&0&10
>> This is the device instance path. It is composed of the hw id (first 2
>> parts) you reported plus another id. If you report that your device as
>> unique in the system, that 3rd part is the device instance id as is .
>> since it is not unique, the system unique’ified it for you
>>
>> d
>
> Thx. How do I “report it as unique in the system”?
>
> (I had assumed the unique deviceid was sufficient)
>
> -PWM
>
>
>