@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

Hello all,

Version 9.0.9136 of the testsign Windows PV drivers has been released.

This release provides multiple driver bug fixes.

To download XenClean, click here. The installer downloads also includes a copy of XenClean and XenBootFix. Remember to carefully read XenClean docs before use.

Note:

• Always download the latest XenClean/XenBootFix from https://github.com/xcp-ng/win-pv-drivers/releases!
• You don't need testsign mode to run XenClean/XenBootFix!

Before Installing

Thank you for testing our Windows PV drivers. Please carefully read the instructions below.

• This driver release is for testing purposes only. Not for production use!
• Not compatible with the "Manage Citrix PV drivers via Windows Update" option. You must disable this option before installing.
• Make backups/snapshots before installing!
• (Only for installing drivers, not for XenClean or XenBootFix) The drivers in this package are testsigned and require enabling testsigning mode. Disable Secure Boot, then run the included script testsign/install.ps1 as Administrator to configure Windows and install the necessary signer certificates. Your VM will reboot automatically.

Changes since 9.0.9108

• NEW: Windows upgrades with Windows PV drivers installed are now experimentally supported.
• NEW: Using the drivers with Windows PE is now experimentally supported (except Xenvif/Xennet).
• NEW: Support TimeSyncMode option to disable automatic Xen-based time sync (for AD domain environments).
• Fixes: Safer and more robust driver activation process.
• Fixes: Fix several network unplug issues.
• Fixes: Compatibility with NVMe device passthrough.
• Fixes: Better compatibility with RealTimeIsUniversal setting.
• Fixes: Better storage migration compatibility.
• Fixes: Fix XenClean in Safe Mode.
• Other minor fixes to all drivers.

Changes since 8.2.2-beta

• IMPORTANT: Security fix for XSA-468 (CVE-2025-27462, CVE-2025-27463, CVE-2025-27464). Check the XCP-ng docs or blog announcement for more details.

• This release is based on upstream 9.1-series drivers, which includes the PV Mouse/Keyboard driver and PV Console Driver. You can access the PV console with the following command from a XCP-ng host:

xl console -t pv <vmname>

• New installer with clean uninstallation and multiple install/uninstall safety checks.
• New XenClean utility for cleanly removing XCP-ng and Citrix drivers.
• Numerous driver stability fixes.
• Volume Shadow Service Provider is no longer included. (XCP-ng 8.1 and newer no longer support quiescent snapshots)
• Check out the new Rust-based Xen Guest Agent included in our package! We're looking to bring back even more features to the agent.
• Older Windows versions are no longer supported. The driver requires at a minimum Windows 10 1607 or Windows Server 2016.

Help / Community Support

If you encounter installation/uninstallation errors, please try again with one of the following commands:

For installing:
msiexec.exe /i XenDrivers-x64.msi /log install.log

For uninstalling:
msiexec.exe /x XenDrivers-x64.msi /log uninstall.log

Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.

Additionally, please report any errors or BSOD you encounter during testing of this release. Your feedback is very appreciated.

• Discussion: https://xcp-ng.org/forum (preferred)
• Issue Tracker: https://github.com/xcp-ng/xcp/issues
• IRC: #xcp-ng and #xcp-ng-dev on irc.freenode.net

kernel-4.18.0-553.71.1.0.1.el8_10 (OL8) and kernel-5.14.0-570.37.1.0.1.el9_6 (OL9) do not contain the fix. kernel-6.12.0-55.29.1.0.1.el10_0 (OL10) does.

Fix committed upstream.

@dnikola Intel, Family 6 Model 183, that's a 14th gen desktop chip right? 16 cores and Z690 gives me pause, there's the instability issue that this generation has esp. with unlocked chips. Do you run any overclocking? (beware of some gaming BIOSes that overclock by default)

@jiri.hadamek Yes, it's a driver bug. I'll plan for a fix.

If the host is really old I'd also check Windows 11 version 24H2 supported Intel processors

@markr I did a test install with en-us_windows_11_business_editions_version_24h2_updated_july_2025_x64_dvd_d32522f0.iso which went to OOBE with no issues. If you have a new Intel CPU, does doing https://docs.xcp-ng.org/troubleshooting/windows-pv-tools/#windows-bug-check-0x3b-system_service_exception-on-systems-with-newer-intel-cpus help?

@jiri.hadamek The drivers don't like that value being a REG_QWORD. Try using REG_DWORD instead.

@deefdragon Your XAPI is also lagging behind (25.6.0-1.5 vs latest 25.6.0-1.9). Could you update your pool?

@deefdragon How about host Xen and XAPI versions? I'm on the bleeding edge, so this may have been fixed somewhere already.

# unbuffer yum list installed | grep xen\\\|xapi
mellanox-mlnxen.x86_64            5.9_0.5.5.0-2.1.xcpng8.3    @xcp:main/$releasever
python2-xapi-storage.x86_64       24.19.2-1.10.xcpng8.3       @xcp-ng-testing
xapi-core.x86_64                  25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-nbd.x86_64                   25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-rrd2csv.x86_64               25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-storage-script.x86_64        25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-tests.x86_64                 25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-xe.x86_64                    25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xcp-ng-xapi-plugins.noarch        1.12.0-1.xcpng8.3           @xcp-ng-testing
xen-crashdump-analyser.x86_64     2.6.1-1.xcpng8.3            @xcp:main/$releasever
xen-dom0-libs.x86_64              4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-dom0-tools.x86_64             4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-hypervisor.x86_64             4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-libs.x86_64                   4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-tools.x86_64                  4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xengt-userspace.noarch            4.0.0-1.xcpng8.3            @xcp:main/$releasever
xenopsd.x86_64                    25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xenopsd-cli.x86_64                25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xenopsd-xc.x86_64                 25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xenserver-dracut.noarch           10-2.xcpng8.3               @xcp:main/$releasever
xenserver-hwdata.noarch           20240411-1.xcpng8.3         @xcp:main/$releasever
xenserver-status-report.noarch    2.0.11-1.xcpng8.3           @xcp-ng-ci

@deefdragon All three values match for me with XCP-ng 8.3, Ubuntu 24.04 guests and kernel 6.8:

$ sudo cat /sys/devices/virtual/dmi/id/product_serial
adc9b6ba-d187-0844-13a6-5f1dc155bf6e
$ sudo cat /sys/devices/virtual/dmi/id/product_uuid
adc9b6ba-d187-0844-13a6-5f1dc155bf6e
$ sudo cat /sys/hypervisor/uuid
adc9b6ba-d187-0844-13a6-5f1dc155bf6e

From your Github issue, it looks like a confusion in byte order between the System UUID (6a87cb0f-ca4c-ffa5-3ca2-fc398fb25eac) and the XCP-ng VM UUID (0fcb876a-4cca-a5ff-3ca2-fc398fb25eac).

I'd check the guest kernel version first.

@flakpyro It's most likely a bug in the Citrix agent.

@McHenry Yes, that's the cause of your issue.

@McHenry That's your Dom0 partition, which stores the XCP-ng operating system. Don't store the ISOs there (which your local ISO SR is doing), you should mount an ISO SR using NFS instead.

/var/log shouldn't be an issue as it's in a separate partition. (I misread the df output)

@McHenry /dev/md127p1 (the root partition) looks pretty full. Do you store anything big in there (ISOs...)?

@McHenry Do they work if you turn off Secure Boot? There's a procedure to enable Secure Boot, see https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/ .

Do you have space left on your Dom0 disk?

@McHenry Do you have any relevant host logs in /var/log/xensource.log and /var/log/daemon.log (look for xen_platform_log)?

Updated with working procedure. (tl;dr XenClean should fix this)

@bberndt Okay, I managed to reproduce your situation. I think it's because the "driver via Windows Update" option was enabled after installing the XS drivers, which caused the drivers to lock onto the non-C000 device and prevent updates from coming in.

Normally, XenClean should be able to fix the situation. But if you want to fix things manually, or if things still don't work (C000 is still not active), here's a procedure that should fix the problem:

1. Take a snapshot/backup/etc.
2. Keep a note of static IP addresses (if you have any; there's a chance those will be lost). You can also use our script here: https://github.com/xcp-ng/win-pv-drivers/blob/xcp-ng-9.1/XenDriverUtils/Copy-XenVifSettings.ps1
3. Reboot in safe mode and disable the non-C000 device.
4. Reboot back to normal mode; it'll ask you to reboot a few more times.
5. The C000 device should now be active and you should be able to get driver updates again.
6. (Optional) You can now enable and manually update the non-C000 device (Browse my computer - Let me pick).