AMD RX 7600: dxgkio_query_adapter_info Ioctl failed -22 persists across driver cleanup, WSL 2.6-2.9, kernel 6.6-6.18, HVCI off, IOMMU on (Win11 IoT Enterprise LTSC 26100.9168)

[miguel184ls]

Environment

• Windows: Microsoft Windows 11 IoT Enterprise LTSC, build 10.0.26100.9168
• GPU: AMD Radeon RX 7600
• GPU driver: 32.0.31041.1004 (2026-08-17) — confirmed as the only AMD driver package left in the driver store (removed 4 stale older versions from 2023-2026, no change to the bug)
• WSL versions tried: 2.7.14.0 (kernel 6.18.33.2), 2.9.12.0 (kernel 6.18.40.1, includes the dxgkrnl memory-leak fix), and a clean reinstall of 2.6.2.0 (kernel 6.6.87.2, Oct 2025) — identical failure on all three
• ROCm 7.2.4 installed in WSL (Ubuntu 22.04), including librocdxg.so.1.2.2 (meets the >=7.1 requirement) and the generic /usr/lib/wsl/lib/libdxcore.so dependency — both present and correct

Symptom

On every WSL boot, before any user-space code runs:

[    0.328612] hv_vmbus: registering driver dxgkrnl
[    1.514588] misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22
[    1.519442] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.519853] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.520225] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.520741] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2

Consequences:

• rocminfo → WSL environment detected. / hsa_init Failed, possibly no supported GPU devices
• torch.cuda.is_available() → False (no exception, silent)
• /sys/class/kfd/kfd/topology/nodes does not exist

History / why this is likely a regression, not a config issue

This exact machine successfully ran multiple hours-long LoRA fine-tuning jobs (transformers + peft + bitsandbytes, ROCm 7.2) on this same RX 7600 through WSL2 for about a week. The failure appeared with no crash, no BSOD, no Windows Event Viewer entry of any kind (checked System log for the full 48h window around when it broke, all Levels Critical/Error/Warning — completely empty of anything GPU/driver/dxg related), right after the last training job finished, before the next one could be launched. A full Windows reboot did not fix it (this was persistent from the first reboot attempt).

Troubleshooting already done (all with reboots in between, none changed the outcome)

1. Plain Windows reboot.
2. wsl --update --pre-release → kernel 6.18.33.2 → 6.18.40.1 (includes "fix for a memory leak in dxgkrnl"). No change.
3. Cleaned the DriverStore of 4 stale AMD graphics driver package versions (2023-08-2026-07), leaving only the current 2026-08-17 build. No change.
4. Disabled Hypervisor-Enforced Code Integrity / Memory Integrity via HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity\Enabled=0 + reboot (confirmed HVCI no longer in SecurityServicesRunning afterwards; Credential Guard/VBS itself still active). No change.
5. Full clean reinstall of WSL: wsl --uninstall, confirmed the Appx package was fully removed, installed Microsoft.WSL_2.6.2.0_x64_ARM64.msixbundle (Oct 2025) from scratch → kernel 6.6.87.2, a completely different kernel major line. No change (existing Ubuntu-22.04 distro registration survived the platform uninstall/reinstall).
6. Enabled IOMMU/SR-IOV/Above 4G Decoding in BIOS (previously "Auto") + reboot. No change — and per dmesg, WSL2 doesn't appear to expose host IOMMU groups to the guest at all (/sys/kernel/iommu_groups/ empty), so this was likely not a relevant variable for GPU-PV specifically, only ruled out for completeness.
7. Verified no Group Policy is configured for SOFTWARE\Policies\Microsoft\Windows\Sandbox (AllowVGPU) or GraphicsDrivers/DeviceGuard under Policies — none exist, so nothing is being blocked by local policy.
8. Confirmed via Microsoft Learn's WindowsSandbox Policy CSP documentation that "IoT Enterprise / IoT Enterprise LTSC" is an officially supported edition for the AllowVGPU capability, so this isn't an edition/licensing exclusion either.

None of the above made any difference — the failure signature (Ioctl failed: -22 on dxgkio_is_feature_enabled and dxgkio_query_adapter_info, at ~1.5s into WSL2 kernel boot) is byte-for-byte identical before and after every attempted fix.

Attached

WslLogs-2026-09-20_17-37-00.zip — full output of collect-wsl-logs.ps1 (default WSL profile), including a WPR trace (logs.etl) captured across a wsl --shutdown + fresh boot + rocminfo repro cycle.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[miguel184ls]

WslLogs-2026-09-20_17-37-00.zip

Environment

• Windows: Microsoft Windows 11 IoT Enterprise LTSC, build 10.0.26100.9168
• GPU: AMD Radeon RX 7600
• GPU driver: 32.0.31041.1004 (2026-08-17) — confirmed as the only AMD driver package left in the driver store (removed 4 stale older versions from 2023-2026, no change to the bug)
• WSL versions tried: 2.7.14.0 (kernel 6.18.33.2), 2.9.12.0 (kernel 6.18.40.1, includes the dxgkrnl memory-leak fix), and a clean reinstall of 2.6.2.0 (kernel 6.6.87.2, Oct 2025) — identical failure on all three
• ROCm 7.2.4 installed in WSL (Ubuntu 22.04), including librocdxg.so.1.2.2 (meets the >=7.1 requirement) and the generic /usr/lib/wsl/lib/libdxcore.so dependency — both present and correct

Symptom

On every WSL boot, before any user-space code runs:

[    0.328612] hv_vmbus: registering driver dxgkrnl
[    1.514588] misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22
[    1.519442] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.519853] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.520225] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.520741] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2

Consequences:

• rocminfo → WSL environment detected. / hsa_init Failed, possibly no supported GPU devices
• torch.cuda.is_available() → False (no exception, silent)
• /sys/class/kfd/kfd/topology/nodes does not exist

History / why this is likely a regression, not a config issue

This exact machine successfully ran multiple hours-long LoRA fine-tuning jobs (transformers + peft + bitsandbytes, ROCm 7.2) on this same RX 7600 through WSL2 for about a week. The failure appeared with no crash, no BSOD, no Windows Event Viewer entry of any kind (checked System log for the full 48h window around when it broke, all Levels Critical/Error/Warning — completely empty of anything GPU/driver/dxg related), right after the last training job finished, before the next one could be launched. A full Windows reboot did not fix it (this was persistent from the first reboot attempt).

Troubleshooting already done (all with reboots in between, none changed the outcome)

1. Plain Windows reboot.
2. wsl --update --pre-release → kernel 6.18.33.2 → 6.18.40.1 (includes "fix for a memory leak in dxgkrnl"). No change.
3. Cleaned the DriverStore of 4 stale AMD graphics driver package versions (2023-08-2026-07), leaving only the current 2026-08-17 build. No change.
4. Disabled Hypervisor-Enforced Code Integrity / Memory Integrity via HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity\Enabled=0 + reboot (confirmed HVCI no longer in SecurityServicesRunning afterwards; Credential Guard/VBS itself still active). No change.
5. Full clean reinstall of WSL: wsl --uninstall, confirmed the Appx package was fully removed, installed Microsoft.WSL_2.6.2.0_x64_ARM64.msixbundle (Oct 2025) from scratch → kernel 6.6.87.2, a completely different kernel major line. No change (existing Ubuntu-22.04 distro registration survived the platform uninstall/reinstall).
6. Enabled IOMMU/SR-IOV/Above 4G Decoding in BIOS (previously "Auto") + reboot. No change — and per dmesg, WSL2 doesn't appear to expose host IOMMU groups to the guest at all (/sys/kernel/iommu_groups/ empty), so this was likely not a relevant variable for GPU-PV specifically, only ruled out for completeness.
7. Verified no Group Policy is configured for SOFTWARE\Policies\Microsoft\Windows\Sandbox (AllowVGPU) or GraphicsDrivers/DeviceGuard under Policies — none exist, so nothing is being blocked by local policy.
8. Confirmed via Microsoft Learn's WindowsSandbox Policy CSP documentation that "IoT Enterprise / IoT Enterprise LTSC" is an officially supported edition for the AllowVGPU capability, so this isn't an edition/licensing exclusion either.

None of the above made any difference — the failure signature (Ioctl failed: -22 on dxgkio_is_feature_enabled and dxgkio_query_adapter_info, at ~1.5s into WSL2 kernel boot) is byte-for-byte identical before and after every attempted fix.

Attached

WslLogs-2026-09-20_17-37-00.zip — full output of collect-wsl-logs.ps1 (default WSL profile), including a WPR trace (logs.etl) captured across a wsl --shutdown + fresh boot + rocminfo repro cycle.

WslLogs-2026-09-20_17-37-00.zip

[github-actions]

No logs.etl found in the archive. Make sure that you ran collect-wsl-logs.ps1 as administrator and that the logs.etl file is in the archive.

Diagnostic information

appxpackage.txt not found
optional-components.txt not found
No logs.etl found in archive.
Error while parsing the logs. See action page for details

[miguel184ls]

Diagnósticos solicitados

wsl --version:

Versión de WSL: 2.7.14.0
Versión de kernel: 6.18.33.2-2
Versión de WSLg: 1.0.73.2
Versión de MSRDC: 1.2.7214
Versión de Direct3D: 1.611.1-8152851
Versión de DXCore: 10.0.26100.1-240331-1435.ge-release
Versión de Windows: 10.0.26100.9168

wsl --status:

Distribución predeterminada: Ubuntu-22.04
Versión predeterminada: 1

winver / versión de Windows:

Windows 10 IoT Enterprise LTSC 2024 (edición real: Windows 11 IoT Enterprise LTSC)
OsBuildNumber: 26100
OsHardwareAbstractionLayer: 10.0.26100.1

dxdiag (sección Display Devices relevante):

Card name: AMD Radeon RX 7600
Chip type: AMD Radeon Graphics Processor (0x7480)
Device Status: 0180200A [DN_DRIVER_LOADED|DN_STARTED|DN_DISABLEABLE|DN_NT_ENUMERATOR|DN_NT_DRIVER]
Device Problem Code: No Problem
Driver Version: 32.0.31041.1004
DDI Version: 12
Adapter Attributes: HARDWARE_TYPE_GPU,D3D11_GRAPHICS,D3D12_GRAPHICS,D3D12_CORE_COMPUTE,D3D12_GENERIC_ML,D3D12_GENERIC_MEDIA
Feature Levels: 12_2,12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1,1_0_CORE
Driver Model: WDDM 3.2
Hardware Scheduling: DriverSupportState:Stable Enabled:False

Es decir: Windows considera la GPU completamente sana y funcional en modo nativo (WDDM 3.2, DDI 12, sin ningún problema reportado).

Get-CimInstance Win32_VideoController:

Name          : AMD Radeon RX 7600
DriverVersion : 32.0.31041.1004
DriverDate    : 17/08/2026
Status        : OK
PNPDeviceID   : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&179ABF18&0&00000019

Get-PnpDevice -Class Display:

Status : OK
Class  : Display
FriendlyName : AMD Radeon RX 7600
InstanceId   : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&179ABF18&0&00000019
Present      : True

(Además existen 3 entradas "fantasma" de hardware retirado — una RX 7600 antigua con otro InstanceId y una NVIDIA Tesla P40 — de un cambio de GPU anterior en esta máquina, todas con Present=False, no deberían influir.)

dmesg | grep -iE "dxg|drm|hsa":

[    0.362900] ACPI: bus type drm_connector registered
[    0.387481] hv_vmbus: registering driver dxgkrnl
[    1.627158] misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22
[    1.631826] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.632294] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.632798] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.633356] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2

/dev/dxg sí existe como nodo de dispositivo (crw-rw-rw- 1 root root 10, 258), pero la negociación falla igualmente.

Última versión conocida que SÍ funcionaba (driver AMD / WSL / ROCm): exactamente las mismas que las actuales — 32.0.31041.1004 / WSL 2.7.14.0 (kernel 6.18.33.2) / ROCm 7.2.4. No hubo ninguna actualización de driver, de WSL ni de ROCm entre el último entrenamiento que funcionó y el momento en que dejó de funcionar. Verificado también contra el registro de eventos de Windows (canal System, 48h alrededor del corte): cero eventos de instalación/reconfiguración de driver de pantalla.

Prueba de desactivar/reactivar el adaptador: hecha ahora mismo (Disable-PnpDevice + Enable-PnpDevice sobre la instancia PCI activa). El adaptador vuelve a Status=OK, Present=True correctamente, pero no restaura el acceso desde WSL — mismo error exacto (Ioctl failed: -22) inmediatamente después.

Enfoques que hemos probado (todos sin éxito, ninguno cambió el síntoma ni un byte)

1. Reinicio completo de Windows.
2. Actualización del kernel de WSL (6.18.33.2 → 6.18.40.1, que incluye un fix real de dxgkrnl para una fuga de memoria).
3. Limpieza completa del almacén de drivers: eliminadas 4 versiones antiguas de AMD (2023-2026), dejando solo la actual.
4. Desactivación de Hypervisor-Enforced Code Integrity / Memory Integrity (HVCI) vía registro + reinicio.
5. Reinstalación completa de la plataforma WSL desde cero a una versión de octubre de 2025 (2.6.2.0, kernel 6.6.87.2 — familia de kernel completamente distinta). Mismo error exacto.
6. Prueba con una distro Linux completamente distinta (Debian, instalación limpia, nunca tocada antes) bajo WSL2: mismo error exacto, descarta que sea algo específico de Ubuntu.
7. Activación de IOMMU/SR-IOV/Above 4G Decoding en la BIOS (estaban en "Auto").
8. Verificado que no hay ninguna directiva de grupo local bloqueando vGPU (SOFTWARE\Policies\Microsoft\Windows\Sandbox, GraphicsDrivers/DeviceGuard bajo Policies: todas vacías).
9. Verificado contra la matriz oficial de compatibilidad de AMD (rocm.docs.amd.com, ROCm 7.2.1): la RX 7600 base no aparece en la lista (sí la RX 7700 en adelante) — pero el registro UserModeDriverNameWsl está correctamente configurado para esta GPU exacta (apunta a amdxc64.so en el paquete del driver instalado), y el INF del driver incluye el componente AMDWIN (el que da soporte WSL) para el modelo "Navi33" (el chip de la RX 7600) exactamente igual que para los modelos oficialmente soportados — es decir, toda la configuración estática está bien puesta, no hay ninguna exclusión visible a nivel de instalación/registro.
10. Probado HSA_OVERRIDE_GFX_VERSION=11.0.0 (truco estándar de la comunidad ROCm para GPUs no oficialmente soportadas de arquitectura hermana): sin efecto, coherente con que el fallo ocurre antes de que ROCm llegue a cargar.
11. Desactivar/reactivar el adaptador de pantalla (esta ronda): sin efecto.

Por qué creemos que SÍ es compatible técnicamente

Esta misma GPU, con este mismo driver, en esta misma instalación de WSL, entrenó con éxito varios modelos LoRA reales durante más de una semana (varias fases de un curriculum de fine-tuning, horas de cómputo GPU sostenido cada vez, confirmado con métricas de pérdida de validación bajando de forma consistente — no fue una casualidad de un solo test). El fallo apareció de un momento a otro, sin ninguna actualización de driver, de Windows o de WSL de por medio, y sin dejar ningún rastro de error en el sistema (sin crash dumps, sin eventos de Device Manager, sin BSOD). Esto no encaja con "nunca fue compatible" — encaja con "dejó de estar permitido".

Sospecha: Controlled Feature Rollout

Dado que (a) no hay ningún cambio de software local detectable, (b) no hay ningún evento de error registrado en ningún sitio, y (c) funcionaba de forma sostenida y ahora no funciona en absoluto, sospechamos que el soporte de GPU-PV para esta combinación de hardware podría estar controlado por un mecanismo de Controlled Feature Rollout de Microsoft (activación/desactivación remota de funciones por máquina, sin actualización de build visible). No tenemos forma de confirmar ni descartar esto desde el lado del cliente — no existe ningún comando que liste qué flags de CFR están activos en un equipo — pero es la única explicación que encaja con la totalidad de la evidencia recogida sin contradicciones.

[miguel184ls]

Requested diagnostics

wsl --version:

WSL version: 2.7.14.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.7214
Direct3D version: 1.611.1-8152851
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.9168

wsl --status:

Default Distribution: Ubuntu-22.04
Default Version: 1

winver / Windows version:

Windows 10 IoT Enterprise LTSC 2024 (actual edition: Windows 11 IoT Enterprise LTSC)
OsBuildNumber: 26100
OsHardwareAbstractionLayer: 10.0.26100.1

dxdiag (relevant Display Devices section):

Card name: AMD Radeon RX 7600
Chip type: AMD Radeon Graphics Processor (0x7480)
Device Status: 0180200A [DN_DRIVER_LOADED|DN_STARTED|DN_DISABLEABLE|DN_NT_ENUMERATOR|DN_NT_DRIVER]
Device Problem Code: No Problem
Driver Version: 32.0.31041.1004
DDI Version: 12
Adapter Attributes: HARDWARE_TYPE_GPU,D3D11_GRAPHICS,D3D12_GRAPHICS,D3D12_CORE_COMPUTE,D3D12_GENERIC_ML,D3D12_GENERIC_MEDIA
Feature Levels: 12_2,12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1,1_0_CORE
Driver Model: WDDM 3.2
Hardware Scheduling: DriverSupportState:Stable Enabled:False

In other words: Windows considers the GPU fully healthy and functional in native mode (WDDM 3.2, DDI 12, no reported problem).

Get-CimInstance Win32_VideoController:

Name          : AMD Radeon RX 7600
DriverVersion : 32.0.31041.1004
DriverDate    : 08/17/2026
Status        : OK
PNPDeviceID   : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&179ABF18&0&00000019

Get-PnpDevice -Class Display:

Status : OK
Class  : Display
FriendlyName : AMD Radeon RX 7600
InstanceId   : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&179ABF18&0&00000019
Present      : True

(There are also 3 "ghost" entries from previously removed hardware — an older RX 7600 instance and an NVIDIA Tesla P40 — from an earlier GPU swap on this machine, all with Present=False; these shouldn't be relevant.)

dmesg | grep -iE "dxg|drm|hsa":

[    0.362900] ACPI: bus type drm_connector registered
[    0.387481] hv_vmbus: registering driver dxgkrnl
[    1.627158] misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22
[    1.631826] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.632294] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.632798] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22
[    1.633356] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2

/dev/dxg does exist as a device node (crw-rw-rw- 1 root root 10, 258), but the negotiation fails regardless.

Last known-working versions (AMD driver / WSL / ROCm): exactly the same as the current ones — 32.0.31041.1004 / WSL 2.7.14.0 (kernel 6.18.33.2) / ROCm 7.2.4. There was no driver, WSL, or ROCm update between the last successful training run and the moment it stopped working. Also verified against the Windows Event Log (System channel, 48h window around the cutover): zero display-driver install/reconfiguration events.

Disable/re-enable adapter test: just performed (Disable-PnpDevice + Enable-PnpDevice on the active PCI instance). The adapter returns to Status=OK, Present=True correctly, but this does not restore WSL access — same exact error (Ioctl failed: -22) immediately afterward.

Approaches we've already tried (none changed the symptom at all)

1. Full Windows restart.
2. WSL kernel update (6.18.33.2 → 6.18.40.1, which includes an actual dxgkrnl memory-leak fix).
3. Full driver-store cleanup: removed 4 older AMD driver package versions (2023-2026), leaving only the current one.
4. Disabled Hypervisor-Enforced Code Integrity / Memory Integrity (HVCI) via registry + reboot.
5. Full clean reinstall of the WSL platform itself, rolled back to an October 2025 release (2.6.2.0, kernel 6.6.87.2 — a completely different kernel line). Same exact error.
6. Tested with a completely different Linux distro (Debian, clean install, never touched before) under WSL2: same exact error, ruling out anything Ubuntu-specific.
7. Enabled IOMMU/SR-IOV/Above 4G Decoding in the BIOS (previously set to "Auto").
8. Verified no local Group Policy is blocking vGPU (SOFTWARE\Policies\Microsoft\Windows\Sandbox, GraphicsDrivers/DeviceGuard under Policies: all empty).
9. Checked against AMD's official ROCm-on-WSL compatibility matrix (rocm.docs.amd.com, ROCm 7.2.1): the base RX 7600 is not listed (RX 7700 and up are) — however, the UserModeDriverNameWsl registry value is correctly set for this exact GPU (points to amdxc64.so in the installed driver package), and the driver's INF includes the AMDWIN component (the one providing WSL support) for the "Navi33" model section (the RX 7600's chip) exactly the same way it does for officially supported models — i.e., all static configuration is correctly in place, with no visible exclusion at the install/registry level.
10. Tried HSA_OVERRIDE_GFX_VERSION=11.0.0 (the standard ROCm-community trick for unsupported GPUs of a sibling architecture): no effect, consistent with the failure happening before ROCm even loads.
11. Disable/re-enable the display adapter (this round): no effect.

Why we believe this is technically compatible

This exact GPU, with this exact driver, on this exact WSL installation, successfully trained several real LoRA models over more than a week (multiple stages of a fine-tuning curriculum, hours of sustained GPU compute each time, confirmed by validation loss dropping consistently — not a one-off fluke). The failure appeared suddenly, with no driver, Windows, or WSL update in between, and without leaving any error trace anywhere on the system (no crash dumps, no Device Manager events, no BSOD). This doesn't fit "never compatible" — it fits "stopped being allowed."

Suspicion: Controlled Feature Rollout

Given that (a) there is no detectable local software change, (b) there is no error event logged anywhere, and (c) it worked consistently and now doesn't work at all, we suspect GPU-PV support for this hardware combination might be gated by a Microsoft Controlled Feature Rollout mechanism (remote per-machine feature enable/disable, with no visible build update). We have no way to confirm or rule this out from the client side — there is no command that lists which CFR flags are active on a machine — but it is the only explanation that fits all the collected evidence without contradiction.

[miguel184ls]

Additional investigation: Windows Feature Management Store (Controlled Feature Rollout / Known Issue Rollback)

Since the driver never changed between "working" and "broken" (same 32.0.31041.1004 verified both times, zero display-driver events in the Event Log around the cutover), we went looking for a remote/silent-toggle mechanism that wouldn't leave any local trace of a driver or OS update.

Confirmed this mechanism is real and active on this machine: HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides (the same registry area used by tools like ViVeTool) currently holds 1135 individually-controlled feature flags on this system.

Method: since Windows doesn't expose per-key last-write time through any standard cmdlet, we called RegQueryInfoKey (advapi32.dll) via a small P/Invoke script to pull the LastWriteTime of every Overrides\<priority-bucket>\<feature-id> subkey, then sorted by date. Out of 1135 flags (2749 counting all priority buckets), the vast majority fall into two simultaneous bulk-write events (345 entries at 2026-09-01 22:23:43, 267 entries at 2026-09-04 17:06:10 — almost certainly routine cumulative-update servicing, not individually meaningful).

Exactly 8 flags were touched individually, each with a unique timestamp, not part of either bulk write:

ID	Modified	EnabledState
320056463	2026-09-05 08:51:59	1 (Disabled)
2742522511	2026-09-11 19:33:03	1
1398682766	2026-09-11 19:33:03	1
3783113870	2026-09-12 08:09:50	1
2599657614	2026-09-12 16:48:57	1
2341184143	2026-09-16 01:23:09	1
1545886350	2026-09-18 03:37:10	1
549554317	2026-09-20 08:01:16	1

The last successful GPU training run finished 2026-09-19 04:14, and the failure was discovered that same morning shortly after — so 1545886350 (18-Sep, <24h before) was our best-fit candidate, and 549554317 (20-Sep) is actually after the failure was already occurring, making it a poor cause candidate (kept in testing anyway for completeness).

Testing done (all reversible, original values recorded before every change, reverted immediately after each negative result):

• 1545886350 alone, EnabledState 1→2, full reboot, retested: no change.
• 2341184143 alone, EnabledState 1→2, full reboot, retested: no change.
• All 8 together, EnabledState 1→2 (Enabled), full reboot, retested: no change.
• All 8 together, EnabledState 1→0 (Default/no override, in case the override's creation — not a flip — was itself the regression), full reboot, retested: no change.
• All 8 reverted to their original EnabledState=1 afterward; system confirmed back to its exact prior state.

Conclusion: none of the 8 individually-timestamped feature overrides we could identify from the client side reproduce or fix the issue in any of the 3 possible states. This doesn't rule out a Controlled Feature Rollout / Known Issue Rollback mechanism as the actual cause (it remains the only theory that fits "worked for a week, then stopped, with zero local software/driver change and zero error trace anywhere") — but if it is the cause, the responsible flag is either buried in one of the two ~300-entry bulk-update clusters (not practically isolable from the client), or the gating mechanism doesn't touch this local Feature Store at all (e.g., a server-side allow/block-list with no local footprint). This is the practical limit of what we can determine without visibility into Microsoft's/AMD's own telemetry or rollout systems.