Missinf file while WinUsb driver installation

[Peter]

I have create a inf file for WINUSB, create the cat file and try to install
winusb on my win7 64bit system. And only get an error message that a file is
missing.
If I check in device manager I can see winusb.sys, WDFCoInstaller and
WinUSBCoInstaller with the right version under "driver details".
Installation error is 00000002 System can not find a file.
How can I find out which file is missing ?
I took more or les themicrosoft example for the WINUSB inf file.

[mpv]

Hi,

Post by Peter
I have create a inf file for WINUSB, create the cat file and try to install
winusb on my win7 64bit system. And only get an error message that a file is
missing.
If I check in device manager I can see winusb.sys, WDFCoInstaller and
WinUSBCoInstaller with the right version under "driver details".
Installation error is 00000002 System can not find a file.
How can I find out which file is missing ?
I took more or les themicrosoft example for the WINUSB inf file.

There is a bug in the 64 bit part of the Microsoft sample WinUSB inf file

The section header [SourceDisksFiles.NTamd64] should read
[SourceDisksFiles.amd64]

Regards, Matt

[Mike [MSFT]]

You can check the %windir%\inf\setupapi.dev.log file for more information
about where the failure occurred.

About the platform decoration, NTamd64 should be correct according to MSDN:
http://msdn.microsoft.com/en-us/library/ff540206(v=VS.85).aspx

-Mike

Post by mpv
Hi,

Post by Peter
I have create a inf file for WINUSB, create the cat file and try to install
winusb on my win7 64bit system. And only get an error message that a file is
missing.
If I check in device manager I can see winusb.sys, WDFCoInstaller and
WinUSBCoInstaller with the right version under "driver details".
Installation error is 00000002 System can not find a file.
How can I find out which file is missing ?
I took more or les themicrosoft example for the WINUSB inf file.

There is a bug in the 64 bit part of the Microsoft sample WinUSB inf file
The section header [SourceDisksFiles.NTamd64] should read
[SourceDisksFiles.amd64]
Regards, Matt

[mpv]

Hi,

Post by Mike [MSFT]
About the platform decoration, NTamd64 should be correct according to
MSDN: http://msdn.microsoft.com/en-us/library/ff540206(v=VS.85).aspx

I just downloaded a new version of WinUsb_HowTo.docx (from March 9, 2010)
and it has been corrected.

For some reason, the Manufacturer section has .NTamd64 as extension, but the
SourceDisksFiles section has just .amd64, which probably must match the
subdirectory name in SourceDisksNames.
This used to be .NTamd64 as well, and DPInst then could not find the correct
files, resulting in the Error 2 in the log.

I was bitten by this in 2008 (and reported it). Glad it has been fixed.
Maybe Peter is still using the old document.

Regards, Matt

[Mike [MSFT]]

Ah, I see here:
http://msdn.microsoft.com/en-us/library/ff547478(v=VS.85).aspx

"Be aware that, unlike other sections such as a DDInstall section, the
platform extensions for a SourceDisksNames section are not .ntx86, .ntia64,
or .ntamd64. For example, to specify a source disk names section for an
x86-based system, use a SourceDisksNames.x86 section, not a
SourceDisksNames.ntx86 section. Similarly, use a SourceDisksNames.ia64
section to specify an Itanium-based system and a SourceDisksNames.amd64
section to specify an x64-based system."

Apparently the platform decoration for SourceDiskNames/SourceDiskFiles is
not consistent, and so just .amd64 is correct there.

-Mike

Post by mpv
Hi,

Post by Mike [MSFT]
About the platform decoration, NTamd64 should be correct according to
MSDN: http://msdn.microsoft.com/en-us/library/ff540206(v=VS.85).aspx

I just downloaded a new version of WinUsb_HowTo.docx (from March 9, 2010)
and it has been corrected.
For some reason, the Manufacturer section has .NTamd64 as extension, but
the SourceDisksFiles section has just .amd64, which probably must match
the subdirectory name in SourceDisksNames.
This used to be .NTamd64 as well, and DPInst then could not find the
correct files, resulting in the Error 2 in the log.
I was bitten by this in 2008 (and reported it). Glad it has been fixed.
Maybe Peter is still using the old document.
Regards, Matt