Windows 11 Endpoint Health & Network Verification

Key finding

Plug and Play checks identified multiple virtual-device installation errors, including a representative Code 28 finding. Investigation showed the available QEMU firmware configuration driver did not include ARM64 support.

Decision

Do not force-install the incompatible QEMU firmware configuration driver. Record the device finding, keep it under observation, and continue validating the endpoint because core Windows, network, DNS, HTTPS and guest-service functions remained operational.

Verified outcome

Windows 11 Pro 24H2 was confirmed, and Windows Update reported the endpoint was up to date. The endpoint received valid DHCP configuration, gateway and external connectivity tests passed with 0% packet loss, DNS resolution succeeded, TCP/443 connectivity to microsoft.com succeeded, and the installed QEMU/Spice guest services were running.

Queried operating-system information using Get-ComputerInfo.

Before attempting to install a driver for ACPI\QEMU0002, the Windows architecture was verified as ARM64.

The mounted UTM Guest Tools media contained a qemufwcfg.inf candidate driver. The INF file was inspected directly and was found to declare support for NTx86 and NTAMD64, but no NTARM64 section.

Because the workstation is running ARM64 Windows, the candidate driver was not manually installed.

Existing guest integration was then checked. UTM Guest Tools 0.1.271, QEMU Guest Agent and ARM64 Spice webdavd were installed, while QEMU Guest Agent, SPICE webdav proxy and SPICE VDAgent services were all running.

No current impact has been observed to Windows startup, DHCP, IP connectivity, DNS resolution, HTTPS connectivity or the tested guest-integration services.

The Code 28 virtual-device findings are therefore being documented and assessed rather than forcing an incompatible remediation solely to remove a warning.

A separate UTM startup issue occurred before the Windows health-check session after the UTM application had previously been closed. The virtual machine initially reported that another process could be using its EFI variables file.

The VM was subsequently recovered and started normally. This incident is better suited to a separate Support Case because it represents a specific fault and recovery scenario rather than the planned endpoint-health verification itself.

Windows 11 Pro

Version

24H2

OS Build

26100.9168

Architecture

ARM64

Unexpected values should therefore be cross-checked using other reliable sources before reaching a conclusion.

The device-health investigation demonstrated that an Error status should not automatically be interpreted as failed hardware.

The initial query showed 33 errors, but examining Instance IDs revealed a repeated pattern of virtual ACPI devices rather than 33 unrelated hardware failures.

I learned to use pnputil and PnP device properties to investigate Windows Device Manager problem codes rather than immediately uninstalling or updating devices.

I also learned that finding a driver file does not mean that the driver is appropriate for the system.

Before installing the candidate qemufwcfg driver, I verified that Windows was ARM64 and inspected the INF file itself.

The available INF declared x86 and AMD64 support but did not declare ARM64 support, so I did not force the installation.

This demonstrated the importance of checking operating-system architecture and driver compatibility before remediation.

Finally, I learned that technical troubleshooting should consider actual service impact.

Although several virtual devices currently report Code 28, Windows boots successfully, the tested network services work and the main UTM/QEMU/SPICE guest services are running.

The safest decision at this stage is therefore to document the finding and continue investigating only where there is evidence that remediation is required, rather than making changes simply to remove an error indicator.