Windows 11 Reference Machine

Every record in the inventory is read from one machine: a clean Hyper-V virtual machine running one pinned Windows 11 build under one capture profile. A position or a size only means something against that machine, so this page names it, and a capture from anything else is refused until it is recorded here first. What a capture may take from it, facts and never Microsoft's text, images or files, is the rule in the inventory format.

Which build is the reference?

The machine-readable copy is reference.json. ref-vm.ps1 refuses to take or verify clean, and ref-run.ps1 refuses to capture (exit 5), when the guest's edition, version or build differs from it. The values come from ref-vm.ps1 -Verify, which prints ref-vm: ios-win11-ref ok, profile fhd-100 (Windows 11 Professional 26H2 build 26300.9711) when the machine matches.

What is the rule for a new build?

Every captured record carries the build it was read from in capturedFrom, as 26300.9711. A capture from any other build is a new reference: build the machine from the new image (-Rebuild installs it and stops before clean, because the build differs), record the new build in reference.json and on this page, run -Reclean, and only then capture. Records from two builds never share a surface file, and a record is never "updated" to a new build without being captured again.

What is the capture profile?

fhd-100 is the profile every canonical record is captured under:

ref-vm.ps1 -Verify reads every value in this table from inside that session (resolution, monitor count and DPI through a per-monitor DPI-aware process) and fails on any difference; clean is only taken when the same check passes.

Which other profiles exist?

The further profiles are entries of the profile matrix that Capture Matrix, Fixtures and Device Stand-ins owns; their values and their -Verify checks are defined there, not here. The catalogues name two of them now:

• fhd-100-dark: fhd-100 with dark mode for apps and system.
• fhd-150: fhd-100 at 150 percent scaling (144 DPI).

An observation captured under one of them goes in a <surface>/<file>.<profile>.json file, as the inventory format describes.

What is the machine?

Install and setup run unattended. The setup pages are reached with no keyboard input: a watcher inside the guest reports them through Hyper-V key-value exchange, and the host asks the watcher to finish setup when it is time.

How is it built, checked and used?

powershell.exe -File scripts\inventory\ref-vm.ps1 -Rebuild    # install from the ISO: about 12 minutes
powershell.exe -File scripts\inventory\ref-vm.ps1 -Reclean    # clean again from pre-oobe, no reinstall
powershell.exe -File scripts\inventory\ref-vm.ps1 -Verify     # exits 0 when the machine matches this page
powershell.exe -File scripts\inventory\ref-run.ps1 -Proof -Out R:\11\out

ref-run.ps1 takes a new, empty -Out folder for each run, holds the VM for itself, restores clean, checks the build, copies its inputs to C:\ios\in as one zip, runs one command in ref's desktop (an interactive scheduled task under a headless console, so it draws no window of its own), waits for its exit code, copies C:\ios\out back and turns the VM off. Each capture therefore starts from the same desktop. -Proof runs the end-to-end check: it starts Notepad, finds its window through UI Automation and saves a screenshot. pre-oobe exists so first-run setup can be captured again at any time.

The machine and the tools are kept after the inventory is captured, so anything missed can be captured later from the same build.

Which records are not built as captured?

The inventory format defines the four dispositions. These rules say which one a record gets.

• Cloud-tied records are equivalent. Sign-in with a Microsoft account, the Store, cloud file sync, the assistant, the news feed, and the advertising and telemetry consent pages: Impossible OS builds its own version, or excluded with the reason where it has none.
• Absent hardware is equivalent. A surface that no stand-in in the virtual machine and no host can show is written by hand from the nearest captured sibling, with the component library's controls. The sibling is named where the absence is documented.
• Names and places stay. What opens a replaced flow keeps its captured name, place and order as a build record: the Control Panel name and its commands, and the four sign-in method entries.
• Nothing is replaced on judgment. A record is replaced only under a ledger entry that names two captured records which disagree.

Which baseline rows are absent?

A row of a completeness baseline that the reference build lists but no surface shows (a setting gated off in this edition, a verb whose handler is not installed) is documented here, with the build the absence was checked on and the reason, instead of being matched by a captured record. check-inventory.py refuses a row listed here that a record also matches, a row that names nothing, and a row without a build or a reason. An absence checked on another build than the reference build counts nothing until it is checked again and its build updated.