Trying to componentize USB2 Card: PNP install not working.

[steves]

Hello all,

I am trying to componentize a D-Link DFB-A5 USB hub. I imported the
INF into Component desinger, and ended up with the following elements:

Component: D-Link DFB-AV USB 2.0 PCI Adapter
Files:
OUSB2.INF (Target=%17%)
ousb2hub.sys (Target = %10%\SYSTEM32\DRIVERS)
ousbehci.sys (Target = %10%\SYSTEM32\DRIVERS)

Resources:
Nec PCI to USB Enhanced Host Controller Type: Service Data
PnPID(819):"PCI\Ven_1033&DEV_00E0&SUBSYS_F1021186"

The files are all present in the correct locations in the pre FBA
image:
C:\Windows\INF\OUSB2.INF
C:\Windows\System32\Drivers\ousb2hub.sys
C:\Windows\System32\Drivers\ousb2hub.sys

However, when the system boots up after FBA is all finished
I receive an error Window Titled "Files Needed" with the
message: "The file 'OUSBEHCI.SYS' on the EHCI Driver Installation Disk
Is Needed", Copy File From ((C:\Windows))

At this point, the files have been moved into the C:\Windows\LastGood
folder!!!

If I browse over to them and install them, then everything is AOK.

What have I done Wrong?

 

[KM]

steves,

Any chance for you to share the \windows\SetupApi.log with us? (use OE and attach the file when post)
Basically, it should tell you (us) what was the reason why the files were moved to the LastGood.
E.g., they are not signed or vice versa but the signature file was not provided (don't see a *.cat file in the list of files you
mentioned).

 

[KM]

Steve,

I am glad you found such easy fix..
I think I had some explanation about the bug. Although I suspect it is in a different place of the INF file.

The DelFiles section usually used to delete the files left from previous OS installations (obviously, does not really apply to most
PXe deployment scenarios).
Microsoft documentation does not recommend having a file listed in CoyFiles and DelFiles sections. If a file is listed in both a
CopyFiles-referenced and a DelFiles-referenced section, and the file is currently present on the system with a valid signature, the
operating system might optimize away the copy operation but perform the delete operation:
http://msdn.microsoft.com/library/d..._77765e82-5415-450b-9a64-f505849c2786.xml.asp

However, if you take a look at Mcirosoft's INF files, you will notices that many (if not all) of them do not follow this rule (the
recommendation). However, they usually don't mention the DelFiles sections in DestinationDirs section and, therefore, the
DefaultDestDir is applied to those. Usually the DefaultDestDir is set to %11% which is \windows\system32 on NT/XP. Thus, Microsoft
INF files will delete the "old" driver binaries under \windows\system32, but not under \windows\system32\drivers.

In your INF file, however, no DefaultDestDir specified but explicitly set:
OEHCI.DelFiles.Ext = 10,SYSTEM32\DRIVERS
This is, I believe, why you saw the issue.

Easy fix may be just commenting out that line of the INF file.

--
Regards,
KM, BSquare Corp.

Hi KM, thanks..

I appreciate your prompt hint, but I have been working on some other
projects for the last week or so. A description of the solution is given
below, and for completeness I have attached a text file containing snippets
of the SETUPAPI section, and the relevant INF file sections.

C:\WINDOWS\SETUPAPI.LOG contained an error message stating:

Copy target "C:\WINDOWS\SYSTEM32\DRIVERS\ousbehci.sys" is also a Delete
target, forcing COPYFLG_NODECOMP.

A previous line of the setupapi.log specifies the 'Actual Install Section'
(of C:\Windows\INF\ousb2.inf) as [OEHCI.NT] INF.

C:\WINDOWS\INF\OUSB2.INF contained the sections below. I commented out the
delete files lines, and the problem appears to be fixed

[OEHCI.NT]
CopyFiles=OEHCI.Files.Ext
DelFiles=OEHCI.DelFiles.Ext
AddReg=OEHCI.AddReg.NT

[OEHCI.Files.Ext]
ousbehci.sys
ousb2hub.sys

[OEHCI.DelFiles.Ext]
; ousbehci.sys,,,1 <----- COMMENTED THESE LINES OUT, PROBLEM
FIXED
; ousb2hub.sys,,,1 <------COMMENTED THESE LINES OUT, PROBLEM
FIXED
nusbd.sys,,,1

If I understand correctly, this is a bug in the inf... Why would an inf
need to delete the same files it is installing? My speculation is that the
INF developer was doing repeated installs, and needed to delete old .sys
file versions to force an update of the device driver.

moving forward,

Steve