Windows 11 ARM64: 3D guest tools leave vdservice absent; registering it restores clipboard (5.0.5 beta) #7937

Describe the issue

On a Windows 11 ARM64 VM using UTM 5.0.5 beta and the 3D guest tools, host-to-guest clipboard sharing did not work despite Clipboard Sharing being enabled. The Windows browser's Paste action was disabled after copying text on the Mac.

Diagnosis inside elevated Windows PowerShell showed that the vdservice service was absent, even though both ARM64 agent executables were installed. Registering and starting that service restored clipboard transfer immediately, without reinstalling Windows, rebooting, or changing the accelerated display device.

Configuration

• UTM Version: 5.0.5 beta (124), downloaded from the official UTM release
• macOS Version: 27.0 (26A428)
• Mac Chip: Apple M1 Max; 32 GB host RAM
• Guest: Windows 11 ARM64, installed from Microsoft's ISO (26H2 / 26300.9457)
• Backend: QEMU ARM64 virt, HVF virtualization
• VM: 16 GB RAM, 8 vCPUs, UEFI and TPM
• Display: virtio-ramfb-gl, experimental DirectX 12 / D3DMetal support
• Guest tools: utm-guest-tools-3d.iso, 0.1.273
• Clipboard Sharing: enabled

Observed sequence and reproducibility limits

1. Install Windows 11 ARM64 and the 3D UTM guest tools.
2. During the final part of guest-tools installation, the VM display showed “Display output is not active.” The user reported that rebooting and a full Windows reinstall did not resolve that display symptom.
3. Rosetta was subsequently installed on the Mac and the VM restarted; the Windows display recovered. DirectX 12 feature levels were visible in dxdiag.
4. Clipboard transfer still failed with Clipboard Sharing enabled.
5. Inspect installed services and agent files; vdservice is absent, while its executable is present.
6. Register and start the service using the workaround below; copying text in Mac TextEdit with Command+C and pasting into guest PowerShell with Ctrl+V then works.

The absent service and successful repair were directly verified. We did not perform another clean installation with installer logging enabled. An interrupted installation is a possible explanation, but the exact cause of the missing registration is unknown. This report concerns that incomplete guest-tools state and its silent clipboard failure, rather than claiming a deterministically reproduced installer defect.

Diagnostic evidence

PS> get-service vdservice
Cannot find any service with service name 'vdservice'.

PS> get-service *spice*
Running  spice-webdavd  Spice webdav proxy

C:\Program Files (x86)\UTM Guest Tools\ARM64\
vdagent.exe    415744 bytes
vdservice.exe  173056 bytes

Verified workaround

Run in elevated PowerShell:

New-Service vdservice -BinaryPathName '"C:\Program Files (x86)\UTM Guest Tools\ARM64\vdservice.exe"' -StartupType Automatic -DisplayName 'SPICE VDAgent'
Start-Service vdservice
Get-Service vdservice

The final command reported Running. A real Mac-to-Windows clipboard transfer of the test text utm clipboard test 123 then succeeded. The display remained virtio-ramfb-gl throughout the repair.

Expected behavior

Guest-tools installation should register and start the SPICE VDAgent service, or clearly report failure. Repair/re-running installation should recover a state in which the executable is installed but the service is absent.

Related report

#7681 describes clipboard failure with the agent running on UTM 4.7.5 and GL display backends. This case differs: the service was absent, and clipboard transfer worked on virtio-ramfb-gl after service registration in 5.0.5.

Crash/debug log and VM configuration

No UTM/QEMU process crash was established. Installer logs and QEMU debug logs from the original failure were not captured, and the guest has already been repaired. The relevant VM settings are listed above; no VM disk image or unsanitized host paths are included.