WSL2: GPU AMD RX 7600 deja de detectarse (dxgkio_query_adapter_info Ioctl failed: -22) tras entrenamiento LoRA prolongado

Question

WSL2: GPU AMD RX 7600 deja de detectarse (dxgkio_query_adapter_info Ioctl failed: -22) tras entrenamiento LoRA prolongado

Miguel SL 20

Servicio: Windows Subsystem for Linux 2 (WSL2), GPU compute con ROCm sobre GPU AMD.

Escenario: Llevaba varios días entrenando modelos (LoRA fine-tuning con PyTorch+ROCm) dentro de WSL2 usando una GPU AMD Radeon RX 7600, sin ningún problema. Tras finalizar un entrenamiento largo, al intentar lanzar el siguiente, WSL2 dejó de detectar la GPU por completo, sin ningún cambio de configuración de por medio.

Resultado: Desde entonces, en cada arranque de WSL, el log del kernel muestra este error nada más iniciar, antes de ejecutar nada:

[    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

Como consecuencia: rocminfo da "hsa_init Failed, possibly no supported GPU devices", y torch.cuda.is_available() devuelve False sin ningún error visible.

Entorno:

Windows 11 IoT Enterprise LTSC, build 10.0.26100.9168
GPU: AMD Radeon RX 7600, driver 32.0.31041.1004 (2026-08-17)
WSL: probado en 2.7.14 (kernel 6.18.33.2), 2.9.12 (kernel 6.18.40.1) y una reinstalación limpia de 2.6.2 (kernel 6.6.87.2) — el fallo es idéntico en las tres
ROCm 7.2.4 en Ubuntu 22.04 dentro de WSL, con librocdxg correctamente instalado

Esfuerzos de solución de problemas: reinicio completo de Windows; actualización del kernel de WSL (incluye un fix de dxgkrnl para una fuga de memoria, sin efecto); limpieza de versiones antiguas del driver AMD en el almacén de controladores (solo queda la actual); desactivación de Memory Integrity (HVCI) vía registro + reinicio; reinstalación completa de WSL desde cero a una versión de octubre de 2025; activación de IOMMU/SR-IOV/Above 4G Decoding en la BIOS (estaban en "Auto"); verificado que no hay ninguna directiva de grupo bloqueando vGPU. Ninguna de estas acciones cambió el resultado. Tampoco hay ningún evento de error/advertencia en el Visor de eventos de Windows relacionado, ni volcados de memoria (crash dumps) de ningún tipo — el fallo no deja rastro de un cuelgue o driver reiniciado.

Pasos reproducibles:

wsl --shutdown
wsl -d Ubuntu-22.04
Dentro de WSL: dmesg | grep dxg → muestra los errores de arriba inmediatamente
rocminfo → falla con "hsa_init Failed"

Materiales auxiliares: tengo capturados los logs oficiales de diagnóstico (collect-wsl-logs.ps1), incluida una traza ETL reproduciendo el fallo, listos para adjuntar. También he reportado esto en GitHub: https://github.com/microsoft/WSL/issues/41654

Windows Subsystem for Linux

0 comentarios

Respuesta aceptada por el autor de la pregunta

0 respuestas adicionales

Su respuesta

Answer 1

Daphne Huynh (WICLOUD CORPORATION) 1,900 Personal externo de Microsoft Moderador

¡Bienvenido a Microsoft Q&A!

Gracias por proporcionar una descripción tan detallada del problema y de los pasos de solución de problemas que ya ha realizado.

Según la información que ha compartido, los errores dxgkio_query_adapter_info: Ioctl failed: -22 se producen durante la inicialización del controlador dxgkrnl de WSL, antes de que se carguen ROCm o PyTorch. Como resultado, el posterior mensaje hsa_init Failed de rocminfo y que torch.cuda.is_available devuelva False parecen ser síntomas posteriores y no la causa principal.

Dado que el error se produce durante la enumeración del adaptador /dev/dxg, es poco probable que reinstalar ROCm dentro de Ubuntu resuelva el problema por sí solo.

Una consideración importante es que la AMD Radeon RX 7600 no aparece actualmente en la matriz de compatibilidad ROCm sobre WSL publicada por AMD. AMD valida combinaciones específicas de GPU compatibles, controladores Radeon Software para WSL, versiones de ROCm, versiones de Ubuntu, kernels de WSL y versiones de frameworks. Debido a que la RX 7600 no está incluida actualmente en esa matriz de compatibilidad, resulta difícil determinar si este comportamiento representa una regresión de WSL, un problema del controlador o una limitación de compatibilidad de la plataforma.

Para ayudar a aislar aún más el problema, recomendaría lo siguiente:

Verifique que Windows siga detectando correctamente la RX 7600 en Administrador de dispositivos y dxdiag, y que esté cargado el controlador de AMD en lugar del Adaptador de pantalla básico de Microsoft.
Dentro de WSL, verifique que la interfaz de la GPU esté disponible: ls -l /dev/dxg

Si /dev/dxg no existe, o si los errores dxgkio_query_adapter_info aparecen inmediatamente durante el inicio, el enfoque debería centrarse en el controlador de pantalla de Windows y la capa de virtualización de GPU de WSL, en lugar de en la propia instalación de ROCm.

Realice una prueba con una configuración ROCm sobre WSL compatible con AMD utilizando exactamente el paquete Radeon Software para-WSL y las versiones de software documentadas por AMD.
Si es posible, intente reproducir el comportamiento en hardware que aparezca explícitamente en la matriz de compatibilidad ROCm sobre WSL de AMD. Esto puede ayudar a determinar si el problema está relacionado con el modelo actual de GPU o con la pila de virtualización de GPU de WSL.
Continúe adjuntando el paquete de diagnósticos y las trazas ETL a su incidencia de GitHub. Además de los registros existentes, considere incluir:

wsl --version
wsl --status
winver
dxdiag /t dxdiag.txt
Get-CimInstance Win32_VideoController
Get-PnpDevice -Class Display
dmesg | grep -iE "dxg|drm|hsa"
La última versión conocida funcional del controlador AMD, la versión de WSL y la versión de ROCm
Si deshabilitar y volver a habilitar el adaptador de pantalla o reinstalar el controlador AMD restaura temporalmente /dev/dxg

Dado que el comportamiento persiste en múltiples versiones de WSL, versiones del kernel e incluso tras una reinstalación limpia de WSL, no parece estar causado por una distribución Ubuntu dañada. En esta etapa, es razonable seguir investigándolo como un posible problema de interoperabilidad entre el controlador de pantalla de Windows y DXG en WSL. Sin embargo, dado que la RX 7600 se encuentra actualmente fuera de la matriz de compatibilidad ROCm sobre WSL documentada por AMD, todavía no hay evidencia suficiente para concluir que se trate de una regresión confirmada del producto WSL.

Como solución alternativa práctica, puede probar con una combinación de GPU y software que figure en la matriz de compatibilidad ROCm sobre WSL de AMD, ejecutar ROCm en una instalación nativa de Linux o evaluar DirectML en WSL si satisface los requisitos de su carga de trabajo.

Referencias: Habilitación de PyTorch con DirectML en WSL | Microsoft Learn

Ejecución de aplicaciones de GUI de Linux con WSL | Microsoft Learn

DirectX 12 para subsistemas de Windows | Microsoft Support

Si esta información le resulta útil, haga clic en Aceptar respuesta.

Gracias por elegir Microsoft Q&A.

Nota: Esta respuesta ha sido traducida mediante una herramienta de traducción. Tenga en cuenta que puede contener errores gramaticales o semánticos. Gracias por su comprensión.

Miguel SL 20 Puntos de reputación

2026-09-21T08:30:25.89+00:00

I have added the data you requested, some additional tests that have been performed, and the suspicion regarding the Controlled Feature Rollout
Daphne Huynh (WICLOUD CORPORATION) 1,900 Puntos de reputación Personal externo de Microsoft Moderador

2026-09-24T02:50:53.2066667+00:00
Thank you for taking the time to provide the additional diagnostics, test results, and observations. I appreciate the thorough troubleshooting you've already performed, as it helps narrow the investigation considerably.

Based on the new information, the evidence continues to suggest that this is not simply a corrupted Ubuntu environment or an issue with the ROCm installation itself. The dxgkio_query_adapter_info: Ioctl failed: -22 messages occur while the WSL dxgkrnl interface is attempting to enumerate the GPU, before ROCm, PyTorch, or the training workload has a chance to initialize. As a result, messages such as hsa_init Failed from rocminfo and torch.cuda.is_available returning False appear to be downstream effects rather than the root cause.

Your observation regarding a possible Controlled Feature Rollout is valuable and worth documenting in the ongoing investigation. At this stage, however, the available logs do not provide enough evidence to confirm or rule out that possibility. Determining whether a rollout-related change is involved would require correlation of the ETL trace and WSL diagnostics with the host's Windows build, servicing state, feature configuration, and GPU virtualization events. The fact that no corresponding Windows event logs or crash dumps were generated does not, by itself, confirm or eliminate that theory.

Given that the behavior reproduces across multiple WSL package versions, kernel versions, and even after a clean WSL reinstallation, additional Ubuntu or ROCm reinstalls are unlikely to provide new insight at this point. The most valuable next step is to continue updating the issue with the diagnostic data you have already collected, including:

A fresh reproduction captured with collect-wsl-logs.ps1 and the associated ETL trace

The exact Windows build and cumulative update revision

wsl --version and wsl --status

dxdiag /t dxdiag.txt

Output from Get-CimInstance Win32_VideoController

Output from Get-PnpDevice -Class Display

Confirmation of whether /dev/dxg exists after WSL starts

Results from dmesg | grep -iE "dxg|drm|hsa"

Any comparison with another system using the same GPU and driver

The last known working combination of Windows, AMD driver, WSL, and ROCm versions, if available

I would also recommend preserving the diagnostic package from the failing state before making any further driver or operating system changes. Those traces may provide the best opportunity for engineering teams to identify what is happening during GPU enumeration and virtualization.

One other point worth keeping in mind is that the Radeon RX 7600 is not currently listed in AMD's published ROCm-over-WSL compatibility matrix. While that does not invalidate your findings, especially given that the configuration previously worked successfully, it does mean the environment falls outside AMD's officially validated combinations. Because of that, the current evidence supports continued investigation, but it is still too early to classify this as a confirmed WSL regression or a confirmed Controlled Feature Rollout issue.

Based on the troubleshooting already completed, I would not recommend any further WSL or ROCm reinstalls unless they are specifically requested by the WSL engineering team for comparison purposes.

Thank you again for the detailed testing and for sharing your findings. The additional data you've provided should be helpful in moving the investigation forward.
Miguel SL 20 Puntos de reputación

2026-09-26T09:24:49.36+00:00

Follow-up with the full requested diagnostic set, captured fresh just now:

1. Fresh reproduction with collect-wsl-logs.ps1 (run elevated) + ETL trace: attached (WslLogs-2026-09-26_11-20-41.tar.gz). Repro used: wsl --shutdown followed by wsl -d Ubuntu-22.04 -- rocminfo, which reliably fails with hsa_init Failed, possibly no supported GPU devices right as WSL cold-boots — same signature as every previous attempt.

2. Windows build / cumulative update revision: 10.0.26100.9168 (24H2)

3. 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 / wsl -l -v:

Default distribution: Ubuntu-22.04

Ubuntu-22.04: State=Stopped, Version=2

4. dxdiag /t dxdiag.txt: attached (dxdiag.txt).

5. Get-CimInstance Win32_VideoController:

Name : AMD Radeon RX 7600

DriverVersion : 32.0.31041.1004

DriverDate : 2026-08-17

AdapterCompatibility : Advanced Micro Devices, Inc.

PNPDeviceID : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&179ABF18&0&00000019

Status : OK

6. Get-PnpDevice -Class Display (full output, including stale entries):

FriendlyName : AMD Radeon RX 7600

Status : Unknown

InstanceId : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&4A0B500&0&00000019

Present : False

FriendlyName : NVIDIA Tesla P40

Status : Unknown

InstanceId : PCI\VEN_10DE&DEV_1B38&SUBSYS_11D910DE&REV_A1\4&1D81E16&0&0019

Present : False

FriendlyName : AMD Radeon RX 7600

Status : Unknown

InstanceId : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\8&E4E3A2A&0&00000000020A

Present : False

FriendlyName : AMD Radeon RX 7600

Status : OK

InstanceId : PCI\VEN_1002&DEV_7480&SUBSYS_E4521DA2&REV_CF\6&179ABF18&0&00000019

Present : True

(The Tesla P40 is an unrelated card no longer physically installed; the other two RX 7600 stale entries are leftovers from earlier driver installs. Only the last entry, Present: True, is the active adapter. Flagging the ghosts in case any leftover PnP registration is relevant — none show as Present, so likely harmless, but wanted to give the raw output as requested rather than only the active device.)

7. /dev/dxg exists after WSL starts: Yes, confirmed present: crw-rw-rw- 1 root root 10, 258.

8. dmesg | grep -iE "dxg|drm|hsa" (fresh capture from this exact repro):

[ 0.331216] ACPI: bus type drm_connector registered

[ 0.355603] hv_vmbus: registering driver dxgkrnl

[ 1.449211] misc dxg: dxgk: dxgkio_is_feature_enabled: Ioctl failed: -22

[ 1.454944] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22

[ 1.455421] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22

[ 1.455991] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22

[ 1.456492] misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -2

Identical signature to every previous capture — fully reproducible, always at ~1.4-1.9s into WSL2 boot, before amdgpu/ROCm ever load.

9. Comparison with another system: Still not available on my end — no second machine with this exact GPU. The offer stands for any community member with an RX 7600 on WSL2 to compare against.

10. Last known working combination: Unchanged from my previous comment — AMD driver 32.0.31041.1004, WSL kernel 6.18.33.2, ROCm 7.2.1, last successful GPU training run 2026-09-19 04:14. No driver/OS change confirmed between then and the break.

Hope the ETL trace from this fresh, timestamped repro gives the engineering team something concrete to inspect at the GPU-PV enumeration layer. Happy to run any further specific diagnostic that would help.
Daphne Huynh (WICLOUD CORPORATION) 1,900 Puntos de reputación Personal externo de Microsoft Moderador

2026-09-28T07:22:07.1566667+00:00
Thank you for taking the time to collect and share the complete diagnostic set. I appreciate the thorough testing and the effort involved in capturing a fresh, timestamped reproduction together with the ETL trace, WSL logs, and system diagnostics. The additional data helps narrow the scope of the issue considerably and provides a much stronger basis for engineering investigation.

Based on the information you have provided, several observations stand out:

Windows continues to detect the active AMD Radeon RX 7600 correctly, and the active adapter reports a healthy status.

/dev/dxg is successfully created inside WSL, which indicates that the DXG device node is present and that the initial GPU virtualization infrastructure is being initialized.

The failure occurs when WSL attempts to query information about the virtualized GPU adapter:

dxgkio_is_feature_enabled: Ioctl failed: -22

dxgkio_query_adapter_info: Ioctl failed: -22

dxgkio_query_adapter_info: Ioctl failed: -2

These messages appear almost immediately after WSL starts, before rocminfo, ROCm, PyTorch, or the training workload begins initialization.

The behavior remains reproducible across multiple WSL versions, multiple kernel versions, and even after a clean WSL reinstallation.

The same hardware, Windows build, AMD driver, WSL configuration, and ROCm environment were previously able to complete GPU training workloads successfully on this system.

Taken together, the additional evidence continues to suggest that the hsa_init Failed message and torch.cuda.is_available returning False are downstream effects rather than the root cause. The GPU virtualization path appears to be present, but adapter enumeration through the DXG interface is not completing successfully.

The stale PnP entries are also unlikely to be the immediate cause. Those entries are reported as Present: False, while the active RX 7600 device is reported as Present: True and Status: OK. However, the ETL trace should provide engineers with a better opportunity to determine whether an unexpected adapter property, capability query response, or host-side driver state is affecting adapter enumeration.

Regarding the possibility of a Controlled Feature Rollout, I agree that it is a reasonable hypothesis to keep in consideration, particularly because the issue appears to have started without a known operating system, WSL, or driver change. That said, the currently available data is not sufficient to confirm whether a rollout-related change occurred or whether it is related to the observed behavior. Establishing that relationship would require analysis of the ETL trace together with the host's servicing and feature configuration state.

At this stage, I would avoid making additional configuration changes, using undocumented feature-control utilities, or modifying virtualization-related settings solely for troubleshooting purposes. Preserving the current failing state is valuable because it ensures the collected traces remain representative of the issue being investigated.

Based on the troubleshooting completed so far, the most useful next steps appear to be:

Preserve the diagnostic package and ETL trace captured from the current failing state.

Attach the latest logs to the existing WSL GitHub issue and clearly identify the timestamp of the recorded reproduction.

Include the last known successful workload timestamp (2026-09-19 04:14) and note that the reported AMD driver version remained 32.0.31041.1004.

If engineering requests additional comparison testing, change only one variable at a time and collect traces before and after the change.

Avoid further WSL or ROCm reinstalls unless specifically requested, as the issue reproduces before those user-space components initialize and has already persisted across clean WSL installations.

One remaining consideration is that the Radeon RX 7600 does not currently appear in AMD's published ROCm-on-WSL compatibility matrix. While that places the configuration outside AMD's officially validated combinations, it does not by itself explain why the same environment previously worked and later stopped enumerating the adapter. The fact that the issue is consistently reproducible and occurs during DXG adapter queries still makes the collected traces valuable for investigation.

At this point, the issue appears sufficiently isolated to the area where WSL, GPU virtualization, and the Windows display driver interact. The ETL trace is likely the most important artifact available, as the reason the host-side adapter query is failing cannot be determined reliably from the Linux dmesg output alone.

Thank you again for the exceptionally thorough testing and documentation.

Given the amount of diagnostic information already collected, I believe continuing the investigation through the existing WSL issue is likely to be more productive than repeating installation-level troubleshooting that has already been ruled out.