Unable to install guest tools v0.1.262

[Taomyn]

Describe the bug
On a test machine running guest tools v0.1.248, I am unable to install, it fails and rolls back

To Reproduce
Run installer from: virtio-win-0.1.262-1/virtio-win-guest-tools.exe

Expected behavior
Clean installation

Host:

• Disto: Proxmox 8.2.4
• Kernel version: Linux 6.8.8-4-pve
• QEMU version: 9.0

Guest:

• Windows version: Server 2022
• virtio-win version: 0.1.248->262

Additional context

Same happens with same version .MSI installer

Virtio-win-guest-tools_20240806094248_000_virtio_win_gt_x64.msi.log

Virtio-win-guest-tools_20240806094248.log

setupapi.dev.log

[vrozenfe]

@Taomyn
Let me check it.
Thanks.
Vadim.

[mac-linux-free]

same on my side...thank you

[wsycqyz]

PVE7.4,Windows11 Guest
virtio-win version: 0.1.248->262 also see the issue.

[alexus-m]

Hello!
The same issue with update 0.1.248->262 and for clean install of 0.1.262
Guest OS: Windows 10 Enterprise 2021 LTSC
Both
./virtio-win-0.1.262/virtio-win-gt-x64.msi
./virtio-win-0.1.262/virtio-win-guest-tools.exe
rolled back.
Log record is attached.
virtio-win-0.1.262.failed.txt

[HurinSteadfast]

As alexus-m points out. The same error occurs even on a clean, new VM with no prior virtio-win presence (other than the storage driver being installed during the Windows setup process).

[vrozenfe]

thanks a lot.
can you please give a try to the new build available at https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-2/

Sorry for any inconvenience. The virtio-win installed is under some reconstruction. So please let us know
if you see any regressions or other problems.

Cheers,
Vadim.

[tuxmaster5000]

Yes, 0.1.262-2 will fix the error message, but now no drivers will be installed.

[vrozenfe]

@tuxmaster5000

Strange. Can you please post setupapi.dev.log file?

Thanks,
Vadim.

[tuxmaster5000]

@vrozenfe where can I found it?
And for the virtscsi driver I have to update it manual, because the installer will install the version from 2023.

[vrozenfe]

@tuxmaster5000
it can be found under c:\Windows\INF directory
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries

Can yo tell me if that vioscsi driver is operating on the system or data volume?
Thanks,
Vadim.

[tuxmaster5000]

Hi @vrozenfe the vioscsi driver is used for the OS volume.
After looking for the other drivers, also the video driver was not replaced. After install it was an release from 2019. After manual update from the iso, it was from 2020. (The QXL OD one)
Here are the log:

[tuxmaster5000]

GH reject the log file :( also zipped :(

[tuxmaster5000]

Now :) Rename and Zip
setupapi.zip

[alexus-m]

thanks a lot. can you please give a try to the new build available at https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-2/

Fresh complete installation of virtio-win-0.1.262-2 via virtio-win-guest-tools.exe on new Win10 VM successfully done.

[Taomyn]

I tried the .exe installer to upgrade from .248 on Windows Server 2022, it still fails. The setupapi.dev.log file did not have any new entries, but I have attached the installer logs.

Virtio-win-guest-tools_20240807112709_000_virtio_win_gt_x64.msi.log
Virtio-win-guest-tools_20240807112709.log

Also:

Not useful when notepad.exe is not installed, perhaps it could use file associations when attempting to open the log?

[myssv]

thanks a lot. can you please give a try to the new build available at https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-2/

Fresh complete installation of virtio-win-0.1.262-2 via virtio-win-guest-tools.exe on new Win10 VM successfully done.

Also not for me:

Virtio-win-guest-tools_20240807121657.log

[vrozenfe]

Guys, can I ask you to try running the MSI in verbose mode and upload the resulting log files
It can be done by running the following command from elevated command prompt:
"msiexec /i virtio-win-gt-x64(x86).msi /l*v install.log"

The qemu command lines are also welcome.

Sorry again for the troubles.
Vadim.

[Taomyn]

Guys, can I ask you to try running the MSI in verbose mode and upload the resulting log files It can be done by running the following command from elevated command prompt: "msiexec /i virtio-win-gt-x64(x86).msi /l*v install.log"

Here you go. Not sure about the qemu command you want as I am running my VMs on Proxmox.

install-262.log

[iq2luc]

Same issue on Windows 11 Pro (Microsoft Windows [Version 10.0.22631.2428]) guest and Archlinux (kernel 6.10.3 / qemu 9.0.2) host. Still not working with the latest virtio-win-0.1.262-2 (from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-2).

Also tried to uninstall old version (0.1.248) first (Windows add / remove programs):

• Trying to uninstall "Virtio-win-driver-installer" does nothing (no error, just blink for a second and closes without removing the package from the system).

• Trying to uninstall "Virtio-win-guest-tools" gives an error and a log file (see below).
  
  Virtio-win-guest-tools_20240807135450.log

Installing the new version (0.1.262-2) I get the following error and log file:

Virtio-win-guest-tools_20240807140345.log

Thank you,
L.

P.S.: See the next post for a detailed installation log.

[iq2luc]

Attached a detailed (verbose) log for the installation process:
verbose-logging-install-0-1-262.log

[santiagobiali]

Using "virtio-win-0.1.262-2":

DIFXAPP: ERROR 0x2 encountered while opening persistent-info key for component '{824217E9-568A-403A-82E1-408171BDB05B}'
DIFXAPP: UninstallDriverPackages failed with error 0x2

"msiexec /i virtio-win-gt-x64.msi /l*v install.log"
virtio-win-gt-x64_20240807081429.log

Virtio-win-guest-tools_20240807075518.log

Host:

• Disto: Proxmox 8.2.4
• Kernel version: Linux 6.8.8-4-pve
• QEMU version: 9.0

Guest:

• Windows version: Server 2022 with latest cumulative update (08/2024)
• virtio-win version: 0.1.240->262

[alexus-m]

can you please give a try to the new build available at https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-2/

Successfully updated including drivers
0.1.248->262
on
Windows 10 Pro for Workstations 22H2

[myssv]

msiexec /i virtio-win-gt-x64(x86).msi /l*v install.log

install.log

[DmDS]

install262-2.log

[iq2luc]

Clean install on Windows 11 guest works OK for me using https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-2 (failed when using https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.262-1).

Updating from 0.1.248 fails with both (as mentioned in the posts above).

[myssv]

From my point of view it is not an error with the new version.

I also got an error trying to uninstall the 0.1.248.

uninstall.log

[iq2luc]

From my point of view it is not an error with the new version.

I second that, it certainly looks so (at least for 0.1.262-2).

[Taomyn]

I'm so confident because there are several servers (servers that work not in fresh lab but in production for years) just in front of me.

Ah yes, the same systems that didn't pick up the issue before I did - they must be so reliable. Also seems you haven't actually read this issue thread as well, having provided zero information towards its diagnosis.

[matveevandrey]

Ok, let's come back to an issue.
On one of my problem servers (2022) there is only single record at mentioned above registry records:

P.S. do u mind to provide me correct registry records - to update mine and check?

[thany]

@vrozenfe

Unfortunately it is extremely hard to investigate and fix such kind of problems without a reproducer.

This got me thinking now. Instead of saying you can't reproduce it, which is fair enough in its own right, why don't you tell us what you actually need in order to reproduce it?

No disrespect, but people have been posting all kinds of logs, but without much indication that they have been helpful or not. Perhaps if you let us know what exactly you need (and where/how to get whatever it is you need), people can start posting those things in a more organised way, which I'm sure is a lot more helpful that the seemingly random bits of logs and screenshots being posted currently. (Although some, I'm sure, have been helpful so far, and so I'm not trying to undermine those)

[vrozenfe]

@thany

Ideally, it would be extremely helpful if you or anyone else can create such reproducer and share the VM image the qemu command line with me. So I will be able to investigate the problem running the VM locally on my setup.

Thanks,
Vadim.

[Directox01]

Ideally, it would be extremely helpful if you or anyone else can create such reproducer and share the VM image the qemu command line with me. So I will be able to investigate the problem running the VM locally on my setup.

Hello! Is there any way I can contact you? I'm ready to give you admin access to a test VM where you can check it.

[vrozenfe]

@Directox01
Thank you.
Please ping me on vrozenfe_at_redhat_dot_com

Best,
Vadim.

[Directox01]

Done, let me know if you didn't receive my message.

[Directox01]

Before bothering you today, I tried to install it on my VM and re-test it. Unfortunately old test VM's I had removed. And now whatever I try I don't get the same bug. The only thing I remember from my previous VM's is I was using virtio-win-0.1.262-2/ but even with the latest version I had the same issue. I was running kernel 6.8 then and now kernel 6.11 but even after rollback to 6.8 I still couldn't find the issue. I think I have tried everything....

[Directox01]

Ok, finally I found it.

The issue comes when you add virtio iso to cdrom using Sata instead of IDE.

Add cdrom using Sata => install driver => update using newer version or uninstall simply.

[Directox01]

I apologize for the mistake the issue wasn't been from SATA as well but SCSI! Can you guys, please confirm if everyone here tried at least once install the iso using SCSI?

[xiagao]

Ok, finally I found it.

The issue comes when you add virtio iso to cdrom using Sata instead of IDE.

Add cdrom using Sata => install driver => update using newer version or uninstall simply.

Hello @Directox01, I also use ahci for cdrom, but I couldn't reproduce this issue. Could you please give your qemu-kvm command line for reference? Thanks.
My info qtree:
```
dev: ich9-ahci, id ""
addr = 1f.2
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = true
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
x-pcie-ari-nextfn-1 = false
class SATA controller, addr 00:1f.2, pci id 8086:2922 (sub 1af4:1100)
bar 4: i/o at 0x7040 [0x705f]
bar 5: mem at 0x82140000 [0x82140fff]
bus: ide.5
type IDE
bus: ide.4
type IDE
bus: ide.3
type IDE
bus: ide.2
type IDE
dev: ide-cd, id "virtio"
drive = "drive_virtio"
backend_defaults = "auto"
logical_block_size = 512 (512 B)
physical_block_size = 512 (512 B)
min_io_size = 0 (0 B)
opt_io_size = 0 (0 B)
discard_granularity = 512 (512 B)
write-cache = "on"
share-rw = false
account-invalid = "auto"
account-failed = "auto"
rerror = "auto"
werror = "auto"
ver = "2.5+"
wwn = 0 (0x0)
serial = "QM00005"
model = ""
unit = 0 (0x0)
win2k-install-hack = false

[xiagao]

I apologize for the mistake the issue wasn't been from SATA as well but SCSI! Can you guys, please confirm if everyone here tried at least once install the iso using SCSI?

okay, I'll have a try.

[xiagao]

@Directox01 Wait, if you use virtio-scsi as the cdrom device, I think you definitely have the chance to hit this issue. Because when you uninstall the installer, the SCSI driver was uninstalled some time, then the installer itself couldn't be accessed except you copy the installer out of the cdrom drive.

[Directox01]

@Directox01 Wait, if you use virtio-scsi as the cdrom device, I think you definitely have the chance to hit this issue. Because when you uninstall the installer, the SCSI driver was uninstalled some time, then the installer itself couldn't be accessed except you copy the installer out of the cdrom drive.

Yes... but u can't still uninstall it :

[Directox01]

When you install the iso using SCSI and then trying to reinstall/repair or upgrade to newer version it install the driver but not completely ( by my knowledge ) from which comes the bug.

[xiagao]

@vrozenfe Could you please have a look at the above information? Thanks.

[vrozenfe]

@xiagao
Sure. Feel free to open a new issue in Jira and assign it to me.
It will be nice to try this scenario on one of our setups and
the downstream iso.
Best,
Vadim.

[xiagao]

@vrozenfe I'm considering whether this is a valid scenario, from my perspective it's not valid to present a cdrom device virtio type .

@ALL hi, I want to ask if you also had this issue with virtio type cdrom device?

[lilydjwg]

I don't know what my cdrom type was (just using -cdrom path/to/iso). I tried with -drive file=/var/lib/libvirt/images/virtio-win.iso,if=ide,format=raw,media=cdrom,read-only=on but it still failed.

[vrozenfe]

@vrozenfe I'm considering whether this is a valid scenario, from my perspective it's not valid to present a cdrom device virtio type .

If I'm not mistaken, Windows should copy msi first from removable media to non-removable before running it. (At least it is how it used to be working in the past). From the other side we need to double check how the combination of the system disk and CDROM attached to the same sort of virtio HBA works in terms of the relevant driver update. Technically, in this case Windows probably will not unload the old storage driver and will keep it running until reboot.

@ALL hi, I want to ask if you also had this issue with virtio type cdrom device?

[vrozenfe]

I don't know what my cdrom type was (just using -cdrom path/to/iso). I tried with -drive file=/var/lib/libvirt/images/virtio-win.iso,if=ide,format=raw,media=cdrom,read-only=on but it still failed.
^^^^^
Should be an IDE controller in this case

[xiagao]

@vrozenfe I'm considering whether this is a valid scenario, from my perspective it's not valid to present a cdrom device virtio type .

If I'm not mistaken, Windows should copy msi first from removable media to non-removable before running it. (At least it is how it used to be working in the past). From the other side we need to double check how the combination of the system disk and CDROM attached to the same sort of virtio HBA works in terms of the relevant driver update. Technically, in this case Windows probably will not unload the old storage driver and will keep it running until reboot.

That makes sense, I'll try with this scenario.

@ALL hi, I want to ask if you also had this issue with virtio type cdrom device?

[xiagao]

I don't know what my cdrom type was (just using -cdrom path/to/iso). I tried with -drive file=/var/lib/libvirt/images/virtio-win.iso,if=ide,format=raw,media=cdrom,read-only=on but it still failed.

Thanks, and could you share your qemu command line and related pkgs/host/guest version? That would be helpful.

[lilydjwg]

The full qemu command arguments used:

  -enable-kvm
  -name "Win10"
  -machine q35
  -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time
  -smp 8,cores=8,threads=1,sockets=1
  -m "$memsize"
  -device virtio-balloon-pci
  -usb -device usb-tablet
  -rtc base=localtime
  -monitor stdio

  -drive file="$HOME"/workspace/kvm/disks/Win10.qcow2,if=virtio,discard=unmap
  -drive file=/var/lib/libvirt/images/virtio-win.iso,if=ide,format=raw,media=cdrom,read-only=on

  -netdev bridge,id=eth0,br=br0
  -device virtio-net,netdev=eth0,mac=XXXXXX

  -vga none -device qxl-vga,vgamem_mb=32

  -display egl-headless,gl=on,rendernode=/dev/dri/renderD128
  -spice unix=on,addr="$spice_sock",disable-ticketing=on

  -device virtio-serial-pci
  -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0
  -chardev spicevmc,id=spicechannel0,name=vdagent

  -audiodev pipewire,id=pw0 -device ich9-intel-hda -device hda-output,audiodev=pw0

Versions:

• Arch Linux recent
• QEMU 9.1.2
• virtio-win 0.1.266.1
• Guest: Windows 10 Pro 22H2 (Simplified Chinese version; internal version 19045.4894; Windows Feature Experience Pack 1000.19060.1000.0). Existing software on it:
  • Virtio-win-guest-tools 0.1.262
  • Virtio-win-driver-installer 0.1.225
  • SPICE Guest Tools 0.141
  • QEMU guest agent 7.4.5

I have setup this virtual machine for quite some time, and installed various updates and third party applications.

[matveevandrey]

@ALL hi, I want to ask if you also had this issue with virtio type cdrom device?

always IDE cdrom in my case

[xiagao]

@vrozenfe Seems that I reproduce the issue.
The steps are installing 0.1-248 version, then update to 0.1-262 version and reboot, after the system was up install 0.1-266 version, then hit the error.

Feel free to access to system that has the issue.
$ remote-viewer vnc://dell-per750-33.lab.eng.pek2.redhat.com:5900 &

[matveevandrey]

@vrozenfe
Any news?

[Taomyn]

I'm still struggling with this even on a clean install of Windows Server 2025 that other than the manual install of the scsi, network and balloon .266 driver during the initial setup, never had the guest tools or even the MSI anywhere near it before.

[xiagao]

I'm still struggling with this even on a clean install of Windows Server 2025 that other than the manual install of the scsi, network and balloon .266 driver during the initial setup, never had the guest tools or even the MSI anywhere near it before.

Sorry to hear that. Seems that you have a stable environment to reproduce it. Unfortunately, I hit this issue randomly. In order to locate the issue better, could you please provide your entire qemu command line, we'll know what devices you use inside guests. And the qemu-kvm version is a plus.

And two questions, what applications do you run in your clean install os? What the language is used on your os?

[Taomyn]

@xiagao I'm using Proxmox v8.3.2 so I hope the VMs config is enough for you

agent: 1
bios: ovmf
boot: order=sata0
cores: 4
cpu: host
efidisk0: cpool-01:vm-110-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: local:iso/virtio-win-0.1.266.iso,media=cdrom,size=707456K
machine: pc-q35-9.0,viommu=virtio
memory: 8192
meta: creation-qemu=9.0.2,ctime=1735032083
name: WIN2K25
net0: virtio=BC:24:11:CF:41:B9,bridge=vmbr0
numa: 0
ostype: win11
sata0: cpool-01:vm-110-disk-1,cache=writeback,discard=on,size=80G
scsihw: virtio-scsi-pci
smbios1: uuid=2534065c-bce7-4b78-aeef-6bf999d2cd8f
sockets: 1
tags: vm;windows
tpmstate0: cpool-01:vm-110-disk-2,size=4M,version=v2.0
vga: virtio,clipboard=vnc
vmgenid: eff09076-f5e1-47cf-b58d-d375d12e156f

I started out with SCSI disks but switched them to SATA hoping it would help, but I also tried IDE - the OS was installed when they were SCSI though.

I don't run any applications in the clean OS other than getting the latest OS updates, I've not gotten that far yet, and it's US-English with English-UK regional settings.

Also, I continued trying things out when I thought to try running the MSI and set all the options to "unavailable" and see what happens. Curiously the "Next" button remained enabled even though I was asking it to basically do nothing, so I hit next and it promptly failed again. I then checked the verbose log I had enabled with the msiexec command and this showed up:

MSI (s) (80:A0) [13:22:11:558]: Executing op: ActionStart(Name=CA_RestoreIPConfig,,)
Action 13:22:11: CA_RestoreIPConfig. 
MSI (s) (80:A0) [13:22:11:558]: Executing op: CustomActionSchedule(Action=CA_RestoreIPConfig,ActionType=7206,Source=Dim wsShell
                Set wsShell = CreateObject("WScript.shell")
                Dim nmFile
                nmFile = Session.Property("CustomActionData")
                Dim fsObj
                Set fsObj = CreateObject("Scripting.FileSystemObject")
                If fsObj.FileExists(nmFile) Then
                    wsShell.run "cmd /c netsh exec " & Chr(34) & nmFile & Chr(34), 1, TRUE
                End If,,CustomActionData=C:\Program Files\Virtio-Win\vionet.cfg)
MSI (s) (80:0C) [13:22:11:560]: Generating random cookie.
MSI (s) (80:0C) [13:22:11:564]: Created Custom Action Server with PID 1704 (0x6A8).
MSI (s) (80:68) [13:22:11:582]: Running as a service.
MSI (s) (80:68) [13:22:11:584]: Hello, I'm your 64bit Elevated Non-remapped custom action server.
MSI (s) (80:14) [13:22:11:586]: Note: 1: 2205 2:  3: Error 
MSI (s) (80:14) [13:22:11:586]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2738 
DEBUG: Error 2738:  Could not access VBScript runtime for custom action 
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738. The arguments are: , , 
MSI (s) (80:14) [13:22:14:465]: Note: 1: 2205 2:  3: Error 
MSI (s) (80:14) [13:22:14:465]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 
MSI (s) (80:14) [13:22:14:465]: Product: Virtio-win-driver-installer -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2738. The arguments are: , , 

Action ended 13:22:14: InstallFinalize. Return value 3.

I'm building a 2025 template and had removed many preinstalled things, one of which included "VBSCRIPT" under "Optional features". Once I reinstalled that the problem went away. I'm curious why if nothing is being installed the installer still feels the need to execute this script.

Now this might not be what's causing this for everyone but it might be something else to look at.