Skip to main content
El driver de AMD que escribía en tu SSD mientras no hacías nada

This content is currently only available in Spanish. English translation is on the roadmap — in the meantime, here's the original.

3 min read

El driver de AMD que escribía en tu SSD mientras no hacías nada

Unos 55 GB al día. Esa es la cifra que midió un usuario en un PC parado, sin juegos abiertos, solo con el driver de una Radeon instalado. El culpable era atieclxx.exe, el módulo de eventos externos de AMD, que según el análisis publicado se copiaba a sí mismo cada segundo desde la carpeta del driver a una ruta dentro del perfil de sistema de Windows.

AMD lo confirmó para las versiones 26.10.x de Adrenalin y el 12 de noviembre publicó la 26.11.1, que corrige dos cosas: las escrituras excesivas en la unidad del sistema en reposo (en Radeon RX 7000 y posteriores) y las escrituras extra al mover o redimensionar ventanas.

Lo que se sabe y lo que no

Las cifras bailan. Hay usuarios que reportan entre 0,3 y 1,5 MB/s en reposo, alguno habla de 5 MB/s, y la medición más citada da unos 662 KB/s de copia, de los que Process Monitor veía llegar al disco algo menos de medio mega por segundo. Son mediciones de terceros, no datos de AMD, y nadie ha demostrado desgaste real de NAND por esto.

Tampoco está claro qué pasa con las tarjetas anteriores. La corrección de reposo habla solo de RX 7000 en adelante, y hay quien sigue viendo el problema en una RX 6950 XT o en tarjetas Polaris y Vega con el driver nuevo. Hay incluso un parche comunitario en GitHub para quien no quiera esperar.

Mi lectura: el SSD es lo de menos

Me vais a perdonar, pero creo que con este fallo se ha exagerado la parte del "te mata el SSD". Hagamos cuentas: un SSD de 1 TB con 600 TBW de resistencia aguantaría unos 30 años a 55 GB diarios. En un disco pequeño y barato la cosa cambia, pero tampoco es un apocalipsis de un mes.

Lo que de verdad me molesta es otra cosa. Este arreglo sale como driver opcional, sin firma WHQL. Eso significa que no llega por Windows Update y que, en un parque de equipos gestionado, nadie lo va a instalar salvo que alguien lea las notas y lo empuje a mano. Desde el lado de soporte, donde lo normal es estandarizar en el driver recomendado y no tocarlo, esto deja un fallo confirmado vivo durante semanas en muchos equipos. Y encima el propio driver avisa de que en Windows 10 puede desactivar Smart Access Memory tras instalarlo. Arreglas una cosa y vigilas otra.

Entiendo el argumento de AMD: un driver opcional sale antes y los WHQL necesitan validación. Es razonable para mejoras de rendimiento en juegos. Para un servicio en segundo plano que escribe sin parar en el disco del sistema, yo lo trataría como un parche de seguridad y no como una novedad para entusiastas.

Qué miraría yo

No tengo una Radeon a mano y no lo he medido en mi máquina, así que no voy a vender una receta. Si tienes una RX 7000 o posterior con 26.10.x, lo sensato parece pasar a 26.11.1. Si usaste el parche comunitario o desactivaste el servicio de eventos externos, conviene deshacerlo antes, que es lo que recomiendan las propias guías. Y si tu tarjeta es más antigua, el Monitor de recursos de Windows te dice en la pestaña de disco qué proceso escribe y cuánto.

La parte que me llevo para mi homelab es más general: casi nunca miro qué escribe en disco un sistema que está "sin hacer nada". Lo asumo. Y este caso demuestra que un componente del fabricante puede pasar meses haciendo ruido sin que nadie lo vea hasta que alguien abre Process Monitor por curiosidad.

¿Cuántos de nosotros sabríamos decir ahora mismo cuántos GB escribe nuestro equipo en un día de reposo?

Fuentes

David González Lombraña

Apuntes, laboratorio y proyectos de IA, Linux y redes.