Prev: DPInst ignoring /sa flag?
Next: How to show media/cable disconnected
From: grant_holler on 14 Jul 2006 17:50
I've experienced a similar problem in that SetupCopyOEMInf() returns
TRUE indicating that the operation was succeesful, but i reality the
oem files are not created in %systemroot%inf. This looks like a bug in
vista which they hopefully will fix in the next up issue. I would wait
for the fix from msft if you can because I believe we're using the
setup API correctly.

grant


chris.aseltine(a)gmail.com wrote:
> I've encountered the following problem on Vista Beta 2 (build 5365).
>
> When trying to uninstall a driver package from the DriverStore
> directory with DriverPackageUninstall, the operation seems to fail if
> the OEMxx.INF file that was associated with the driver is no longer
> present in C:\WINDOWS\INF, as the files in that folder under the
> DriverStore hierarchy are not deleted.. However, the function still
> returns ERROR_SUCCESS.
>
> Further, another attempt to install the drivers with (for example)
> SetupCopyOEMInf() seems to succeed, and the function returns the path
> to an OEMxx.INF file, but upon checking the Windows\INF directory, that
> file doesn't exist -- so no device can be installed. Once the system
> gets to this point, the user is stuck because he can't uninstall the
> old drivers and can't install any new ones.
>
> We've tested on XP and this behavior does not seem to be present. When
> calling the uninstall function, the driver message callback merely
> omits the line about removing the OEMxx.INF file, but otherwise
> proceeds normally.
>
> My call to DriverPackageUninstall() looks like this:
>
> DriverPackageUninstall("C:\\Windows\\System32\\DriverStore\\FileRepository\\netmon-mplus.inf_72fe0f75",
> DRIVER_PACKAGE_SILENT | DRIVER_PACKAGE_FORCE, 0, &needReboot);
>
> This generates the following lines in the SetupApi log:
>
> -----------
>
> >>> [SetupCopyOEMInf - C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\Netmon-MPlus.inf]
> >>> Section start 2006/07/13 15:41:05.200
> cmd: "F:\Difx.exe"
> inf: Driver Store location:
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\netmon-mplus.inf
> inf: Published Inf Path: C:\Windows\INF\oem13.inf
> inf: OEM source media location:
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75
> <<< Section end 2006/07/13 15:41:05.325
> <<< [Exit status(0x00000000)]
>
>
> >>> [SetupUninstallOEMInf - oem13.inf]
> >>> Section start 2006/07/13 15:41:05.325
> cmd: "F:\Difx.exe"
> <<< Section end 2006/07/13 15:41:05.325
> <<< [Exit status(0x00000002)]
>
> ---------
>
> Now, (based on this example), if I go and create a bogus copy of
> oem13.inf in C:\Windows\Inf, and then call the function again, the
> uninstall works -- the DriverStore copy is removed, and the SetupApi
> log now shows this:
>
> ---------
>
> >>> [SetupCopyOEMInf - C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\Netmon-MPlus.inf]
> >>> Section start 2006/07/13 15:42:00.175
> cmd: "F:\Difx.exe"
> inf: Driver Store location:
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\netmon-mplus.inf
> inf: Published Inf Path: C:\Windows\INF\oem13.inf
> inf: OEM source media location:
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75
> <<< Section end 2006/07/13 15:42:00.378
> <<< [Exit status(0x00000000)]
>
>
> >>> [SetupUninstallOEMInf - oem13.inf]
> >>> Section start 2006/07/13 15:42:00.378
> cmd: "F:\Difx.exe"
> inf: Driver Store location:
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\netmon-mplus.inf
> dvi: {Client Side Delete Driver Package:
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\netmon-mplus.inf}
> sto: Removing driver package from the driver store.
> sto: DriverStoreDeleteDriverPackage:
> sto: Inf Path =
> C:\Windows\System32\DriverStore\FileRepository\netmon-mplus.inf_72fe0f75\netmon-mplus.inf
> sto: Flags = 0
> sto: DriverStoreDeleteDriverPackage successfully removed the
> package fromo the driver store.
> dvi: {Client Side Delete Driver Package - exit(0x00000000)}
> inf: Uninstalling catalog: C:\Windows\INF\oem13.CAT
> <<< Section end 2006/07/13 15:42:10.331
> <<< [Exit status(0x00000000)]
>
> ---------
>
> Note the call to "DriverStoreDeleteDriverPackage" (this looks like an
> export from drvstore.dll -- can I call this myself manually, if I knew
> the prototype?)
>
> Any thoughts would be appreciated.
>
> -Chris

From: chris.aseltine on 15 Jul 2006 00:12
grant_holler(a)yahoo.com wrote:

> I've experienced a similar problem in that SetupCopyOEMInf() returns
> TRUE indicating that the operation was succeesful, but i reality the
> oem files are not created in %systemroot%inf. This looks like a bug in
> vista which they hopefully will fix in the next up issue. I would wait
> for the fix from msft if you can because I believe we're using the
> setup API correctly.

Yep -- in fact, as a workaround, I call SetupCopyOEMInf() to get what
it claims is the destination oemxx.inf filename (and yes, it returns
TRUE even when nothing is copied) -- then once I have the filename, I
go ahead and recreate a blank copy of it, and then call DIFX
again....which usually works. Sometimes it leaves behind PNF or SYS
files though.

I'd have to agree this is buggy behavior as compared to 2K/XP. Wish
someone from MSFT would weigh in.

From: peterwie on 17 Jul 2006 13:33
I reported it to the driver store folks and they're going to try and
reproduce it in house so they can see what's causing it. Of course that's
no guarantee that it will be fixed, or that someone won't come back and
explain in detail how this is actually the best part of the driver store,
but at least someone's looking at it :)

-p

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<chris.aseltine(a)gmail.com> wrote in message
news:1152936745.874097.117400(a)s13g2000cwa.googlegroups.com...
> grant_holler(a)yahoo.com wrote:
>
>> I've experienced a similar problem in that SetupCopyOEMInf() returns
>> TRUE indicating that the operation was succeesful, but i reality the
>> oem files are not created in %systemroot%inf. This looks like a bug in
>> vista which they hopefully will fix in the next up issue. I would wait
>> for the fix from msft if you can because I believe we're using the
>> setup API correctly.
>
> Yep -- in fact, as a workaround, I call SetupCopyOEMInf() to get what
> it claims is the destination oemxx.inf filename (and yes, it returns
> TRUE even when nothing is copied) -- then once I have the filename, I
> go ahead and recreate a blank copy of it, and then call DIFX
> again....which usually works. Sometimes it leaves behind PNF or SYS
> files though.
>
> I'd have to agree this is buggy behavior as compared to 2K/XP. Wish
> someone from MSFT would weigh in.
>

From: chris.aseltine on 18 Jul 2006 11:43
peterwie(a)online.microsoft.com wrote:

> I reported it to the driver store folks and they're going to try and
> reproduce it in house so they can see what's causing it. Of course that's
> no guarantee that it will be fixed, or that someone won't come back and
> explain in detail how this is actually the best part of the driver store,
> but at least someone's looking at it :)

Thanks -- appreciate it. You may want to ask them about the other
issue that was reported where SetupCopyOEMINF() returns TRUE even
though the OEMxx.INF file is never created -- it seems like a related
problem.

 | 
Pages: 1
Prev: DPInst ignoring /sa flag?
Next: How to show media/cable disconnected