Bug 708930

*** Bug 700118 has been marked as a duplicate of this bug. ***

Created attachment 501995 [details]
sosreport of the host

Created attachment 501996 [details]
Logs for setupapi.app and setupapi.dev

Reproduced with a win7-32 image using the steps in bug description.
virtio-win: virtio-win-1.2.0-1.el6.noarch

Sure, Amit!

The problem's description:
Installing balloon with path x:\balloon\win7 ( original bugzilla bug https://bugzilla.redhat.com/show_bug.cgi?id=700118#c31 ),
because UI from Device Manager in Windows 7 allow to do that opposite to XP, where only full path allowed driver installation .

I try to install the last virtio-win-1.2.0 package on Windows 7 32 bit VM, and receive the same behaviour:
Drvinst.exe show dialog box with message:
"Windows found driver software for your device but encountered an error while attempting to install it".
I tried to installed it from x:\virtio-win-1.2.0\balloon path and it has in it next paths:
2k3\amd64
2k3\x86
2k8\amd64
2k8\x86
w7\amd64
w7\x86
xp\amd64
xp\x86

In setupapi.dev.log possible to see that drvinst.exe try to install the driver from 2k3\amd64.
2k3 chosen because it's the least alphabetically. When I change it to ws2k3, drvinst.exe choose 2k8 directory,
and after changing that to ws2k8, it choose w7 one.

Here drvinst.exe choose amd64 directory and changes of the name ( like x86 to i386 cor rect name and amd64 to i486 incorrect name ) didn't help.
As I saw with ProcessMonitor ( included FileMon functionallity in Windows7 version) drvinst.exe enumerate all the directories, but choose i486 any case.
I found that it happen because inf file in w7\i486(originall amd64) directory have next line in the [Version]
section
DriverVer=03/30/2011,52.61.101.58000

and inf file in w7\i386(originall x86) directory have next line in the [Version]
section
DriverVer=03/30/2011,51.61.101.58000

So it choose amd64 because newer (bigger) driver version.

So our signed package have two problems:
1)Wrong version : both inf for win7 have to be 61.61.101.58000
BTW that versions are the same for other 2k3, 2k8 directories too where both ( x86 and amd64 )
have to be : for 2k3 - 52.61.101.58000, for 2k8 - 60.61.101.58000
2)Under w7\x86 directory exist oditional x86 directory with netkvm in it.

I have to have signed version of balloon drivers if I change inf file because drvinst.exe doesn't
want to install changed drivers because PCI standard controller driver signed by MSFT opposite to our signature, so next experiments I did on serial driver for win7.

In both amd64  and x86 inf files the line is the same and have 61.61.101.58000 version.
In this case drvinst try to install amd64 driver and failed, but if I change dir name to from amd64 to xamd64 , drvinst.exe goes to x86 directory and install correct driver.

That mean that NTx86 and NTamd64 decorations are important only on the next installation stage
where files copied to the system and not on the first stage where all directories enumerated to find the latest driver version and correct signatures.

All that bring me to conclusion that possible it's impossible to use partial path when drvinst.exe called, but full path only.

The bug is result of the specific behaviour of the Windows Installer ( drvinst.exe ), but we can't open the ticket in MSFT,
because of the statement there that, there's no user interaction support in modern OSes
http://msdn.microsoft.com/en-us/library/ff553973%28v=VS.85%29.aspx.

Possible to stand that choosing the path, due to the article is, is UI error in Device Manager, and especially possibility to choose partial path and not full path only, as it was in XP and before.

Vadim, please close that bug, as not a bug but defined by MSFT behaviour.

Best,
Arkady

Hello IBM,
From reading the last update. This would appear to be not a bug. This is MSFT behaviour. 

The statement of that bug, I believe is a type to mean this bug.

Thank You
Joe Kachuck

Closing, as it cannot be solved as is.
The other option is to provide an EXE file that will install the correct driver, but since it is a completely different workflow on the user end, it does not solve the exact same problem.