Contact & help
Reproducible tests start with a cleanly documented test environment. For Windows systems, stating “Windows 11” in a bug report is usually not enough. Build version, firmware mode, security features, graphics driver and hardware can all influence whether a bug occurs and whether it can be reproduced on a second device. This guide shows how to capture the key technical data of a Windows test device using only built-in tools – with no extra diagnostic software.
What information belongs in the documentation of a Windows test device?
For many QA and support scenarios, six groups of information are especially relevant: operating system and build, processor and memory, firmware mode, TPM status, Secure Boot status, and graphics and driver data. Depending on the application, screen resolution, available storage capacity, language, time zone and installed runtime components should be added as well.
The point is not to collect as much data as possible. The goal is a small, consistent system fingerprint that is captured the same way for every test device. This makes it much faster to spot differences between a working environment and a faulty one.
1. Capture the Windows version and build with winver
Press Windows key + R, type winver and confirm. The window shows the installed Windows version and the operating system build. Both values should be included in a bug report.
The edition alone is too imprecise. Two devices can both run Windows 11 but have different builds or patch levels. Behaviour that appears after an update can therefore only be investigated meaningfully if the build is documented.
Even so, always note the edition too. Whether a test device runs Windows 11 Home, Windows 11 Pro or Windows 11 Enterprise determines whether features such as BitLocker, Group Policy or Hyper-V are even available – and therefore also affects test behaviour.
2. Read out the key system data with msinfo32
Open the command msinfo32 via Windows key + R. System Information bundles many details that are useful for testing and troubleshooting. Especially relevant are:
- Operating system name and version
- System manufacturer and system model
- System type
- Processor
- Installed physical memory
- BIOS version and date
- BIOS mode
- Status of “Secure Boot”
For reproducible QA processes, it is worth keeping these fields in a fixed template. That way you avoid bug reports where one tester documents the BIOS version and another only notes the Windows edition.
3. Check UEFI and Secure Boot
In msinfo32, the BIOS Mode field shows whether the device booted in UEFI mode or in an older legacy mode. The Secure Boot State field shows whether Secure Boot is active. Microsoft lists UEFI and Secure Boot capability as part of the Windows 11 system requirements.
This information is useful for troubleshooting even when the application under test does not use Secure Boot directly. Differences in firmware configuration and security state can explain why installation, driver or device behaviour differs between two otherwise similarly equipped machines.
Do not change firmware settings for a single test without understanding the consequences. If a change is necessary, document the state before and after the adjustment and follow the instructions from the device or mainboard manufacturer.
4. Check the TPM version with tpm.msc
Press Windows key + R, type tpm.msc and open the TPM Management console. If the Trusted Platform Module is available and ready for use, you will find manufacturer information and the specification version there. TPM 2.0 is a minimum requirement for Windows 11.
If Windows does not show a compatible TPM, that does not necessarily mean the hardware is missing. Microsoft notes that TPM can be disabled in the UEFI firmware on some devices. Depending on the platform, it may appear under names such as Intel PTT or AMD fTPM.
For test documentation, three values are usually enough: TPM present: yes/no, specification version and status. Sensitive key or identity data does not belong in a normal bug report.
5. Document DirectX and the graphics driver with dxdiag
Open the command dxdiag via Windows key + R. The DirectX Diagnostic Tool shows, alongside system data, information about the graphics unit and driver. The Display tab shows, among other things, the GPU name, driver version, driver date, DirectX support and display mode.
This information is especially important for rendering issues, crashes involving hardware acceleration, problems with multiple monitors, or differences between virtual and physical test machines. Microsoft names a DirectX 12-compatible graphics unit with a WDDM 2.0 driver as a minimum requirement for Windows 11.
6. Record CPU, RAM and system type consistently
You can also find the processor, installed RAM and system type in msinfo32 or under Settings → System → About. When recording the CPU, note the exact model name rather than just “Intel” or “AMD”. For memory, the installed capacity is sufficient unless you are investigating a memory-related problem.
For performance or load tests, you should additionally record whether other resource-intensive processes are running in parallel. A test result without context on hardware utilisation can easily be misinterpreted.
7. Check free storage space
A device can meet the formal Windows requirements and still have too little free storage for an update, temporary test data or a larger application. When documenting installation and update failures, therefore, record not only the drive size but also the free space available before the test.
According to Microsoft, Windows 11 requires a storage device of at least 64 GB. For reproducible application tests, however, the actually available free space is the more meaningful figure.
Recommended system fingerprint for bug reports
A compact template might look like this, for example:
OS: Windows 11 [Edition]
Version/Build: [winver]
Device model: [msinfo32]
CPU: [exact model]
RAM: [GB]
BIOS mode: UEFI/Legacy
Secure Boot: On/Off/Not supported
TPM: present, version [x.x]
GPU: [model]
Graphics driver: [version + date]
DirectX/WDDM: [dxdiag]
Display: [resolution / scaling]
Free storage: [GB]
Test timestamp: [date/time]When comparing two machines, the same template should be used for both systems. This makes differences immediately visible, without developers having to search through several screenshots.
What data should not go into public bug reports?
System diagnostics can contain information that is not necessary for the technical analysis. Do not publish serial numbers, product keys, account data, device identifiers, private network data or other personal or confidential information. Review exported diagnostic reports before sharing them.
In companies, internal policies for logs and telemetry data apply in addition. A good system fingerprint contains only the data that contributes to reproducing the bug.
Why this documentation improves reproducibility
A bug that only appears on a single test device is not automatically random. The environment often differs in one detail: a different Windows build, a different graphics driver, a different firmware configuration, less free storage, or different hardware. If these differences are captured in a structured way, “it works on my machine” can be turned into a testable hypothesis.
This method is especially valuable for regression testing. Save the system fingerprint together with the test run. If the result changes after a Windows, firmware or driver update, it becomes traceable which environment variable changed between the runs.
Conclusion
Robust Windows test documentation does not require extensive third-party tools. With winver, msinfo32, tpm.msc and dxdiag, the key system characteristics can be captured consistently. What matters is not the amount of data but a repeatable template used identically on all test devices.
