WinPE as a stateless harness for Windows driver testing and fuzzing - bednars.me

Recently, I analyzed two specific engineering problems in the field of low-level automation. The first one is the orchestration of CI/CD environments for Windows systems, where creating reproducible, deterministic conditions for end-to-end (E2E) tests is incredibly expensive and inefficient. Suppose you manage a repository for a Kernel-Mode Driver Framework (KMDF) kernel driver: how do you deploy fully automated E2E tests?<br>The classic approach based on full Windows runners is a massive resource burden. The environment is non-deterministic, lacks idempotency, and the boot time from scratch (the so-called cold start) drastically extends the feedback loop in the pipeline.<br>The second problem is a twin issue but concerns a different stage of the software lifecycle: dynamic fuzzing of a KMDF driver and immediate capture of kernel exceptions (bugcheck / BSOD). Here, the barriers are identical: memory overhead, slow restoration of machine state from a snapshot, and a lack of operating system predictability.<br>Both of these problems stem from the same root cause. A standard Windows installation carries significant resource overhead from graphical components, background services, and telemetry. For automated testing, this user-mode layer is unnecessary; we only need a minimalist environment running the NT kernel.<br>The solution is Windows PE (Windows Preinstallation Environment). It is an official, stripped-down environment distributed with every Windows ISO image. It runs entirely in RAM, requires as little as 512 MB of memory, and lacks support for DirectX, the PowerShell subsystem, or the standard graphical shell (Explorer). Booting by default with NT AUTHORITY\\SYSTEM privileges makes it an ideal test harness for both of these tasks.<br>The following analysis focuses on the low-level mechanisms of WinPE, as well as BCD and QEMU modifications that allow transforming this system into an ultra-fast, idempotent testing environment.<br>Reconnaissance and boot configuration automation<br>The WinPE environment boots from a WIM (Windows Image) file, which the bootloader mounts as a RAM disk under the virtual drive letter X:. The entire process is controlled by the BCD (Boot Configuration Data) store. To make the virtual machine spin up in a matter of milliseconds, aggressive boot optimizations must be deployed using the bcdedit tool:<br>bcdedit /set {default} bootstatuspolicy ignoreallfailures<br>bcdedit /set {default} recoveryenabled no<br>bcdedit /set {bootmgr} timeout 0 ignoreallfailures – a critical flag for CI/CD systems. It ignores improper shutdown errors, preventing a blocking welcome screen from appearing.<br>recoveryenabled no – completely cuts off automatic system repair attempts, which would end up in a crash loop anyway in a diskless environment.<br>When testing digitally unsigned KMDF drivers, enabling test mode is the primary requirement. While many legacy guides suggest nointegritychecks yes, this flag has been ignored by the x64 bootloader since Windows Vista/7. Instead, the main lever to disable Virtualization-Based Security (VBS) and Hypervisor-Protected Code Integrity (HVCI) is hypervisorlaunchtype off. To disable these kernel-level protections:<br>bcdedit /set {default} testsigning yes<br>bcdedit /set {default} hypervisorlaunchtype off<br>bcdedit /set {default} isolatedcontext no Here, testsigning yes permits loading unsigned drivers, hypervisorlaunchtype off disables VBS/HVCI at the hypervisor level, and isolatedcontext no disables isolated user-mode contexts (like Credential Guard and Isolated User Mode). Together, they prevent the hypervisor from blocking unverified code and allow direct manipulation of kernel structures during fuzzing.<br>Hardware topology architecture in QEMU<br>Emulating the environment for kernel debugging stability requires a precise choice of chipset. When virtualizing with QEMU, the default, modern q35 profile implements the PCIe (PCI Express) bus along with its full, complex topology (Root Complex, root ports).<br>For the simplified, built-in network drivers present in WinPE, navigating the PCIe tree can be problematic. The older pc (i440FX) machine profile, which provides a flat, classic PCI bus (bus 0), is significantly more predictable. Device addressing here is trivial, eliminating resource allocation errors at the HAL (Hardware Abstraction Layer) level.<br># Recommended, stable base QEMU configuration for Windows (WHPX)<br># with a specific CPU model selected instead of 'host' (WHPX has issues with 'host')<br># and Hyper-V enlightenments removed by default, so they do not break KDNET:<br>qemu-system-x86_64.exe -M pc -accel whpx -cpu Skylake-Client-IBRS -m 1024 -vga none -nographic ... Network debugging via KDNET<br>The KDNET mechanism enables kernel debugging over the UDP protocol. It operates completely independently of the system network stack (NDIS), working directly at the hardware controller level.<br>In a minimalist environment, KDNET does...