Installing Windows 11 on Xen

The following is a guide to install a Windows 11 guest on Xen for use with DRAKVUF. The Xen, LibVMI and DRAKVUF setup itself is unchanged and is described on https://drakvuf.com, this page only covers what is different for Windows 11 compared to the Windows 7 and Windows 10 instructions found there. The steps below have been verified with Windows 11 21H2, 22H2, 23H2, 24H2, 25H2 and the 26H1 Insider build on Xen 4.21 with a Debian 13 dom0.

---

Domain configuration

Windows 11 installs and runs fine as a regular HVM domain booting with SeaBIOS, no UEFI, Secure Boot or TPM is required once the installer checks are bypassed as described in the next section. Create a disk of at least 64GB and use the following template (tune it as needed):

arch = 'x86_64'
name = "windows11"
maxmem = 4096
memory = 4096
vcpus = 2
maxvcpus = 2
builder = "hvm"
boot = "dc"
hap = 1
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "destroy"
vnc = 1
vnclisten = "0.0.0.0"
vga = "stdvga"
usb = 1
usbdevice = "tablet"
viridian = 0
altp2m = 2
shadow_memory = 32
vif = [ 'type=ioemu,model=e1000,bridge=xenbr0' ]
disk = [ 'phy:/dev/vg/windows11,hda,w', 'file:/path/to/your/windows11.iso,hdc:cdrom,r' ]

Compared to the Windows 7 template a few things are worth pointing out:

• 4GB of RAM and 2 vCPUs are the minimum the Windows 11 installer accepts. Give it more if you can, the installation is noticeably slower than Windows 10 with the minimum.
• on_reboot = "restart" is needed during the installation as Windows Setup reboots the domain several times. You can switch it back to destroy afterwards.
• The guest was tested with viridian = 0. Windows 11 boots and installs with the Hyper-V enlightenments enabled as well, but all the DRAKVUF testing referenced on this page was done without them.

Installing Windows

Windows Setup checks for TPM 2.0, Secure Boot and a supported CPU before it lets you install and stops with "This PC can't run Windows 11" on a Xen HVM domain. Since 22H2 the out-of-box experience (OOBE) at the end of the installation also insists on an internet connection and a Microsoft account, and Microsoft keeps removing the interactive workarounds for that (oobe\bypassnro, ms-cxh:localonly) from newer builds. The reliable way around both is an unattended installation, which is also how the builds listed at the top of this page were installed:

1. Download autounattend-windows11.xml, adjust the account name and password at the end of the file if you want, and wrap it into an ISO image. The file selects the edition by image name (Windows 11 Pro); the 21H2 installation media still calls its images Windows 10 Pro, so adjust the name for that one (wimlib-imagex info sources/install.wim lists them).

genisoimage -o /path/to/autounattend.iso -J -r -V unattend /path/to/folder/containing/autounattend.xml

The file in the ISO must be named autounattend.xml. 2. Attach it to the domain as a second CD-ROM in the domain config:

disk = [ 'phy:/dev/vg/windows11,hda,w', 'file:/path/to/your/windows11.iso,hdc:cdrom,r', 'file:/path/to/autounattend.iso,hdd:cdrom,r' ]

3. Create the domain. Setup picks the answer file up on its own, wipes the disk, installs the Pro edition and reboots into the desktop with a local administrator account and auto-logon enabled, no interaction needed. With the 2 vCPUs and 4GB of the template above the whole installation takes about 75 minutes (two reboots, the first one after roughly 55 minutes), noticeably less with more resources.

The answer file does three things that matter for Xen. It sets the LabConfig registry values that disable the hardware checks before Setup runs them, it hides the network and Microsoft account screens of the OOBE and creates a local account instead, and it disables the Windows Update service at first logon. The last one is worth keeping even if you change everything else: a freshly installed Windows 11 guest downloads updates and reboots on its own in the first hours, which looks like a crash from DRAKVUF's perspective.

If you prefer to install by hand, the hardware checks can be disabled from the installer itself. On the first Setup screen press Shift+F10 to open a command prompt and run the following, then continue the installation as usual and pick "I don't have a product key":

reg add HKLM\SYSTEM\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassCPUCheck /t REG_DWORD /d 1 /f

Whether you can then get past the OOBE network screen without a Microsoft account depends on the build of your installation media, so the unattended route is recommended.

Generating the JSON profile

The JSON profile is created the same way as for Windows 7 and 10. Get the PDB GUID and filename of the kernel with vmi-win-guid while the domain is running:

$ sudo vmi-win-guid name windows11
Windows Kernel found @ 0x...
	PDB GUID: e6426a07c26e66f8eb8594621a7b273b1
	Kernel filename: ntkrnlmp.pdb

Then generate the profile with pdbconv.py and add the LibVMI config entry as described on drakvuf.com:

cd /tmp
python3 ~/drakvuf/volatility3/volatility3/framework/symbols/windows/pdbconv.py --guid e6426a07c26e66f8eb8594621a7b273b1 -p ntkrnlmp.pdb -o windows11.json
sudo mv windows11.json /root

For reference, these are the kernels and PDB GUIDs of the installation media used for this page, which is what vmi-win-guid reports right after the installation (any cumulative update changes them, so regenerate the profile after updating the guest):

Build	Kernel	PDB GUID
21H2 (22000)	10.0.22000.318	32c1a669d5ffefd41091f636cfdb6e991
22H2 (22621)	10.0.22621.382	ee6818ebc82f1f08ba8ebb2fd12196c01
23H2 (22631)	10.0.22621.2428	cf32de2e4a334c7c06fb63fcb6fafb5c1
24H2 (26100)	10.0.26100.1742	953a8de880b0818c32da2dec1d79c2d91
25H2 (26200)	10.0.26100.6584	e6426a07c26e66f8eb8594621a7b273b1
26H1 Insider (28000)	10.0.28000.1340	2aa0cf6279496ee75596000966386c6e1

If you would rather get the GUID from the disk with tools/pdbguid.py, note that on 24H2 and later media ntoskrnl.exe is often stored with Windows system compression (CompactOS), which ntfs-3g cannot read ("unsupported reparse tag"). Using vmi-win-guid on the running domain avoids the problem.

Notes

• Every Windows 11 build has its own kernel, so a profile is only valid for the exact build it was generated from. Generate a new one after a feature update.
• A plain vmi-process-list windows11 without the JSON profile does not work on Windows 11 with LibVMI versions that do not decode the encoded KdDebuggerDataBlock (the fast KDBG scan cannot find it). Always pass the profile.
• Attaching to the domain while it is still in the boot loader can make LibVMI scan the whole guest memory for several minutes before it gives up. Start DRAKVUF once the guest has reached the login screen, the attach then takes well under a second.