Control snapshot and D3D12 GPU-based validation

Read-only snapshot at 2026-09-16 18:51:22–30 Vienna. PID 46776 was the existing standalone D3D11Control.exe, started by the parent task at 18:49:51. No test was started or stopped by this inspection.

• Both nvspcap64.dll 11.0.9.251 and nvppex.dll 32.0.16.1692 were loaded, exactly matching the versions observed in Unity's GeometryBaseline process. D3D11, DXGI and NVIDIA user-mode driver versions also matched. No UnityPlayer was loaded. Presence is not evidence of active overlay behavior or a causal fault.
• One NVIDIA SMI query reported device-wide GPU utilization 22%, memory-controller utilization 2%, VRAM 726/8188 MiB, temperature 57°C, power 16.85 W, P0. These are not process-exclusive GPU utilization values.
• Windows process CPU counter was 4% (the PerfProc counter, not normalized across 32 logical CPUs); lifetime CPU 6.609 s; working set 47,628,288 bytes; private bytes 56,434,688. Detailed module inventory and query data are in d3d11-control-module-load-snapshot.json.

Microsoft's GBV overview says the validation can detect uninitialized/incompatible descriptors and samplers, descriptors referencing deleted resources, descriptor-heap indexing beyond bounds, incompatible resource states, and resource-state promotion/decay problems. It instruments shaders and adds GPU commands/dispatches. COPY command lists are emulated using COMPUTE command lists, which changes the hardware work path. This can substantially slow execution; Microsoft suggests smaller workloads for practical debugging. Messages arrive after GPU execution completes and can be asynchronous with CPU validation. Results may identify shader locations, draws, queues, command lists and PSOs.

Enablement API: enable before device creation. Changing enablement on an existing device itself causes device removal; it is not a runtime toggle for an active player.

Shader patch modes: default unguarded validation still executes erroneous shader instructions. Guarded validation skips them and can avoid some crashes. No-patching/state-tracking-only modes reduce coverage; no-patching can also produce misleading state reports. These are API controls, not assumptions about Unity's exact selected mode.

Message settings expose a maximum stored message count. Validation flags can disable state tracking at reduced cost, while retaining descriptor checks; such reduced coverage must not be treated as full validation.

Interpretation for the proposed bounded run: GBV is a diagnostic instrumentation run, not a representative performance/stability acceptance run. A crash/reset without a GBV message does not exonerate application/engine resource usage: execution may not reach the error-report completion point, and validation has finite scope. A slowdown or fixture loading timeout may be caused by instrumentation. Preserve actual activation/log evidence and distinguish an emitted validation finding from a plain device reset. These last implications are inferences from the documented execution and reporting behavior, not a diagnosis of the present failure.