Hi,
? I have an MF device which at the moment has assigned the same HardwareID.
? The HardwareID is in the form PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr.?
? Each function belongs to a different PCIe base class.
? Both functions are controlled by one driver.
? On some systems, the driver installs properly while on others it does not. Changing the subsystem portion with a new firmware leads to complete installations. Can someone confirm that the identical HardwareID is the root cause for the driver installation failure?
Thank you for your time.
? Calin
On 12-Dec-2011 18:46, Calin Iaru wrote:
Hi,
I have an MF device which at the moment has assigned the same HardwareID.
The HardwareID is in the form PCI\VEN_vvvv&DEV_dddd&SUBSYS_ssssssss&REV_rr.
Each function belongs to a different PCIe base class.
Both functions are controlled by one driver.
On some systems, the driver installs properly while on others it does
not. Changing the subsystem portion with a new firmware leads to
complete installations. Can someone confirm that the identical
HardwareID is the root cause for the driver installation failure?
Thank you for your time.
Calin
How do you change the subsystem: same on both functions or different?
Could you post the setup log from a system where it fails to install
(just the relevant part)? Thanks for helping us help you.
Note that h/w ID for PCI includes VEN,DEV,SUBSYS&REV, or VEN,DEV and
class (CC) parts. An id that includes VEN&DEV but no SUBSYS or CC is
considered as compatible ID and has lower preference.
– pa
>Can someone confirm that the identical HardwareID is the root cause for the driver installation failure?
The short answer is no, it should not be a problem. If you have a system with two devices which have the same Hardware ID Windows uses the same device driver but it creates two different Device
Object. You should look setupapi logs file. They may give you more information on your problem.
Igor Sharovar
Hi Pavel and Igor,
? I will run a few more changes tomorrow before coming back with the logs.
Regards,
? Calin
How do you change the subsystem: same on both functions or different?
Could you post the setup log from a system where it fails to install
(just the relevant part)? Thanks for helping us help you.
Note that h/w ID for PCI includes VEN,DEV,SUBSYS&REV, or VEN,DEV and
class (CC) parts. An id that includes VEN&DEV but no SUBSYS or CC is
considered as compatible ID and has lower preference.
– pa
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
Hi,
? I will give the complete information now. The board exposes 3 functions: function A which is a PCI-to-PCI Bridge, function B and function C. The driver package attempts to install function B and C. Function A is installed by the operating system.
? Judging from SETUPAPI, the PnP manager tries to install function A from the driver package.?I have removed the devnode for function A - the PCI-to-PCI Bridge with the HardwareId?PCI\VEN_DDDD&DEV_EEEE&CC_0604?- and all installs complete. This is not a shipping solution. The inf file contains the HardwareId decorations for function B and C.
[MANUFACTURER.NTamd64]
%MANUFACTURER_ADAPTER_DESC%= ? ? ?MANUFACTURER_DDINSTALL, ? ? PCI\VEN_DDDD&DEV_EEEE&CC_0680 ; function B
%MANUFACTURER_ADAPTER_DESC%= ? ? ?MANUFACTURER_DDINSTALL, ? ? PCI\VEN_DDDD&DEV_EEEE&CC_0880 ; function C
? The objective is to have an inf file that installs function B and C, lets A to be installed by the operating system. Are there INF sections that can accomplish this?
? Thank you for taking the time to answer this question.
Calin
SETUPAPI.DEV.LOG
>> ?[Device Install (UpdateDriverForPlugAndPlayDevices) - PCI\VEN_DDDD&DEV_EEEE&SUBSYS_AAAAAAAA&REV_01]
>> ?Section start 2011/12/13 14:18:48.542
? ? ? cmd: “y:\driverpackage\dpinst.exe” ?/c
? ? ?dvi: Set selected driver complete.
? ? ?dvi: {Build Driver List} 14:18:48.542
? ? ?dvi: ? ? ?Searching for hardware ID(s):
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&dev_EEEE&subsys_AAAAAAAA&rev_01
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&dev_EEEE&subsys_AAAAAAAA
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&dev_EEEE&cc_060400
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&dev_EEEE&cc_0604
? ? ?dvi: ? ? ?Searching for compatible ID(s):
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&dev_EEEE&rev_01
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&dev_EEEE
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&cc_060400
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD&cc_0604
? ? ?dvi: ? ? ? ? ? pci\ven_DDDD
? ? ?dvi: ? ? ? ? ? pci\cc_060400
? ? ?dvi: ? ? ? ? ? pci\cc_0604
? ? ?cpy: ? ? ?Policy is set to make all digital signatures equal.
? ? ?dvi: ? ? ?Processing a single INF: ‘c:\windows\system32\driverstore\filerepository\driver.inf_amd64_neutral_197f0aed1df8bf5e\driver.inf’
? ? ?inf: ? ? ?Opened PNF: ‘c:\windows\system32\driverstore\filerepository\driver.inf_amd64_neutral_197f0aed1df8bf5e\driver.inf’ ([strings])
? ? ?dvi: {Build Driver List - exit(0x00000000)} 14:18:48.557
? ? ?dvi: {DIF_SELECTBESTCOMPATDRV} 14:18:48.557
? ? ?dvi: ? ? ?No class installer for ‘PCI standard PCI-to-PCI bridge’
? ? ?dvi: ? ? ?Using exported function ‘CriticalDeviceCoInstaller’ in module ‘C:\Windows\system32\SysClass.Dll’.
? ? ?dvi: ? ? ?CoInstaller 1 == SysClass.Dll,CriticalDeviceCoInstaller
? ? ?dvi: ? ? ?CoInstaller 1: Enter 14:18:48.557
? ? ?dvi: ? ? ?CoInstaller 1: Exit
? ? ?dvi: ? ? ?Default installer: Enter 14:18:48.557
? ? ?dvi: ? ? ? ? ? {Select Best Driver}
! ? ?dvi: ? ? ? ? ? ? ? ?Selecting driver failed(0xe0000228)
? ? ?dvi: ? ? ? ? ? {Select Best Driver - exit(0xe0000228)}
! ? ?dvi: ? ? ?Default installer: failed!
! ? ?dvi: ? ? ?Error 0xe0000228: There are no compatible drivers for this device.
? ? ?dvi: {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 14:18:48.557
? ? ?dvi: {DIF_DESTROYPRIVATEDATA} 14:18:48.557
? ? ?dvi: ? ? ?CoInstaller 1: Enter 14:18:48.557
? ? ?dvi: ? ? ?CoInstaller 1: Exit
? ? ?dvi: ? ? ?Default installer: Enter 14:18:48.557
? ? ?dvi: ? ? ?Default installer: Exit
? ? ?dvi: {DIF_DESTROYPRIVATEDATA - exit(0xe000020e)} 14:18:48.557
<<< ?Section end 2011/12/13 14:18:48.557
<<< ?[Exit status: SUCCESS]
DPINST.EXE /c
PS y:\driverpackage> .\dpinst.exe /c
INFO: ? Option set: dumping log info to console.
INFO: ? Current working directory: ‘y:\driverpackage’
INFO: ? Running on path ‘y:\driverpackage’
INFO: ? No valid ‘dpinst.xml’ file provided.
INFO: ? Found driver package: ‘y:\driverpackage\driver.inf’.
INFO: ? Preinstalling ‘y:\driverpackage\driver.inf’ …
INFO: ? ENTER: ?DriverPackagePreinstallW
SUCCESS:y:\driverpackage\driver.inf is preinstalled.
INFO: ? RETURN: DriverPackagePreinstallW ?(0x0)
INFO: ? ENTER: ?DriverPackageGetPathW
INFO: ? RETURN: DriverPackageGetPathW ?(0x0)
INFO: ? ENTER: ?DriverPackageInstallW
INFO: ? Installing INF file ‘y:\driverpackage\driver.inf’ (Plug and Play).
INFO: ? Looking for Model Section [MANUFACTURER.NTamd64]…
INFO: ? Installing devices with Id “PCI\VEN_DDDD&DEV_EEEE&SUBSYS_AAAAAAAA&REV_01” using INF “C:\Windows\System32\DriverStore\FileRepository\driver.inf_amd64_neutral_197f0aed1df8bf5e\driver.inf”.
INFO: ? ENTER UpdateDriverForPlugAndPlayDevices…
ERROR: ?RETURN UpdateDriverForPlugAndPlayDevices. (Error code 0x103: No more data is available.)
INFO: ? Installation did not occur because the current driver on the device is the same or better.
INFO: ? No drivers installed. Drivers contained in ‘C:\Windows\System32\DriverStore\FileRepository\driver.inf_amd64_neutral_197f0aed1df8bf5e\driver.inf’ are not better than current one’s.
INFO: ? RETURN: DriverPackageInstallW ?(0x103)
INFO: ? Did not install ‘y:\driverpackage\driver.inf’ because it is not better than the current drivers.
INFO: ? Created entry in Add or Remove Programs for ‘C:\Windows\System32\DriverStore\FileRepository\driver.inf_amd64_neutral_197f0aed1df8bf5e\driver.inf’.
INFO: ? Returning with code 0x100
From: “xxxxx@hotmail.com”
To: Windows System Software Devs Interest List
Sent: Monday, December 12, 2011 8:05 PM
Subject: RE:[ntdev] multifunction device PCIe HardwareId
>Can someone confirm that the identical HardwareID is the root cause for the driver installation failure?
The short answer is no, it should not be a problem. If you have a system with two devices which have the same Hardware ID Windows uses the same device driver but it creates two different Device
Object. You should look setupapi logs file. They may give you more information on your problem.
Igor Sharovar
—
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
I’m confused.
You said the Functions differed by “subsystem”, yet the INF specifies different Class codes … not different subsystems. And those class codes seem unusual, at least to me.
Maybe I’m just slow this morning… I don’t follow the above at all. So, the system boots up and your hardware is present, and the PCI bridge on your device (this is a TRANSPARENT PCI bridge, I assume… a Type 0 header) gets enumerated and claimed by the PCI Bus Driver.
BTW… Are the second and third functions on your device BEHIND this PCI bridge, or is the PCI bridge entirely separate?
So, now you have two device red banged in Device Manager, your second and third functions… right?
And you run your INF, which has no reference at all to your first function, and the setupAPI log says it fails because it can’t install the driver for your first function… and this function already has a perfectly acceptable driver (PCI.SYS) loaded for it??
Can you please explain a bit more specifically?
Peter
OSR
Hi Peter,
? The inf does not ask about SubvendorId. The same inf is used with distinct firmware versions: one that generates distinct SubvendorIDs and one that makes all of them equal.
? The first function is managed by PCI.sys and separate from the other functions.
? The device manager keeps the yellow exclamation marks. This is Windows 7.
? !pci 0x140 shows a ?“HeaderType ? ? 81”. I see that this is not documented in wdm.h.
Regards,
? Calin
From: “xxxxx@osr.com”
To: Windows System Software Devs Interest List
Sent: Tuesday, December 13, 2011 4:20 PM
Subject: RE:[ntdev] multifunction device PCIe HardwareId
I’m confused.
You said the Functions differed by “subsystem”, yet the INF specifies different Class codes … not different subsystems.? And those class codes seem unusual, at least to me.
Maybe I’m just slow this morning… I don’t follow the above at all.? So, the system boots up and your hardware is present, and the PCI bridge on your device (this is a TRANSPARENT PCI bridge, I assume… a Type 0 header) gets enumerated and claimed by the PCI Bus Driver.
BTW… Are the second and third functions on your device BEHIND this PCI bridge, or is the PCI bridge entirely separate?
So, now you have two device red banged in Device Manager, your second and third functions… right?
And you run your INF, which has no reference at all to your first function, and the setupAPI log says it fails because it can’t install the driver for your first function… and this function already has a perfectly acceptable driver (PCI.SYS) loaded for it??
Can you please explain a bit more specifically?
Peter
OSR
—
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
Transparent bridge… Type 1 header. Sorry, bad typo there.
So, you have three functions on your device. One is a transparent PCI bridge. This is being correctly and automagically being handled by the PCI bus driver. You want to load drivers for the other 2 functions. These functions have the same VID and DID, but differ in class code, and you want your INF to load drivers for each, differentiating by Class Code… but this is failing.
Is that correct?
Can you tell me, step by step, how you’ve tried to load the drivers for your device and what you’re seeing in the setupapi logs? For example, have you tried to load the drivers one at a time, manually, via device manager and does it not work?
Peter
OSR
Hi Peter,
? yes, everything you said is accurate.
? There’s one driver that handled function B and C. dpinst.exe or an MSI installer on top of DifxApi fails. The driver does install one at a time from devmgr. Do you still need setupapi?
Regards,
? Calin?
From: “xxxxx@osr.com”
To: Windows System Software Devs Interest List
Sent: Wednesday, December 14, 2011 3:22 PM
Subject: RE:[ntdev] multifunction device PCIe HardwareId
Transparent bridge… Type 1 header.? Sorry, bad typo there.
So, you have three functions on your device.? One is a transparent PCI bridge.? This is being correctly and automagically being handled by the PCI bus driver.? You want to load drivers for the other 2 functions.? These functions have the same VID and DID, but differ in class code, and you want your INF to load drivers for each, differentiating by Class Code… but this is failing.
Is that correct?
Can you tell me, step by step, how you’ve tried to load the drivers for your device and what you’re seeing in the setupapi logs?? For example, have you tried to load the drivers one at a time, manually, via device manager and does it not work?
Peter
OSR
—
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
OK… that’s good. That means the INF “works”…
The problem seems to be (looking back at your setupapi log) that setup seems to be trying to update the driver for the PCI bridge device, and not finding it. This must have something to do with how you’re invoking the INF (from DPINST or whatever… which I’ve never used, personally). Do the three functions on your device all have the same Vendor ID and Device ID??
If so, have you tried invoking DPINST or whatever specifying the VID, DID, and something else to make the the functionyou want to load the driver for unique (such as the classcode)??
If the INF works, the problem has to be the way the INF is being invoked…
Peter
OSR
Hi Peter,
? all 3 functions have the same VID, DID, SSID and REV. All 3 functions have different CC. dpinst and difxapp don’t allow specifying the class code.
? Thank you all for help on this issue.
Calin
From: “xxxxx@osr.com”
To: Windows System Software Devs Interest List
Sent: Wednesday, December 14, 2011 4:30 PM
Subject: RE:[ntdev] multifunction device PCIe HardwareId
OK… that’s good.? That means the INF “works”…
The problem seems to be (looking back at your setupapi log) that setup seems to be trying to update the driver for the PCI bridge device, and not finding it.? This must have something to do with how you’re invoking the INF (from DPINST or whatever… which I’ve never used, personally).? Do the three functions on your device all have the same Vendor ID and Device ID??
If so, have you tried invoking DPINST or whatever specifying the VID, DID, and something else to make the the functionyou want to load the driver for unique (such as the classcode)??
If the INF works, the problem has to be the way the INF is being invoked…
Peter
OSR
—
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
AH! There you go then… that’s the problem.
If the hardware is under your control, I’d recommend making the Vendor System or Vendor Subsystem code specific to each function. This is really what those fields are designed for.
It doesn’t make a lot of sense, from either a PCI or a Windows perspective, to have vastly different devices with the same VID, DID, Subsystem ID, and Subsystem Vendor ID.
Well, at least now you know what the problem is… Glad I could help.
Peter
OSR
Hi Peter and all,
?All the PCI books I have don’t mention MF devices and HardwareId decorations. Can you confirm that the 3 functions break the standard?
Regards,
? Calin
From: “xxxxx@osr.com”
To: Windows System Software Devs Interest List
Sent: Thursday, December 15, 2011 3:38 PM
Subject: RE:[ntdev] multifunction device PCIe HardwareId
AH!? There you go then… that’s the problem.
If the hardware is under your control, I’d recommend making the Vendor System or Vendor Subsystem code specific to each function.? This is really what those fields are designed for.
It doesn’t make a lot of sense, from either a PCI or a Windows perspective, to have vastly different devices with the same VID, DID, Subsystem ID, and Subsystem Vendor ID.
Well, at least now you know what the problem is… Glad I could help.
Peter
OSR
—
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
No. The 3 functions don’t “break the standard.”
They don’t make a lot of sense… they don’t allow you to install drivers the way you want on Windows. But they don’t “break the standard” as far as I know.
I would guess the board was devised by somebody who was not extremely experienced in the development of PCI devices… at least not for Windows.
Peter
OSR
Calin Iaru wrote:
Hi Peter and all,
All the PCI books I have don’t mention MF devices and HardwareId
decorations. Can you confirm that the 3 functions break the standard?
Peter was careful not to say that it violated the standard. It is,
however, a design flaw. Windows uses VID, PID, and SSID to identify a
PCI device and locate its driver INF. Your three devices are identical,
as far as Windows is concerned. All three devices will be assigned to
the same INF. Always.
It is possible to drive your device in this state, but you will have to
use a single INF and driver, and dole out the various subfunctions on
your own based on the CC.
If you really do need three different INFs for these three functions,
then you have no choice. You must change the product ID or the SSID so
the three functions are unique.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.