Qué es el formato DCH de Windows y para qué sirve

Inicio » Hardware » Qué es el formato DCH de Windows y para qué sirve

Si has tenido que instalar o actualizar drivers en Windows, seguramente te habrás topado con el misterioso término DCH, sobre todo en gráficas Nvidia, Radeon o en la propia documentación de Microsoft. A simple vista parece un nombre más, pero detrás hay un cambio bastante profundo en cómo Windows gestiona los controladores y sus aplicaciones asociadas.

En las siguientes líneas vamos a ver qué es exactamente el formato DCH de Windows, por qué Microsoft lo ha impulsado, en qué se diferencia de los controladores “estándar”, qué implicaciones tiene en el día a día (por ejemplo, al elegir drivers Nvidia o Radeon), y también aclararemos un detalle curioso: la extensión DCH como formato de archivo antiguo y como tipo de esquema DipTrace, que no tiene nada que ver con los drivers modernos pero suele salir en las búsquedas.

Qué significa DCH en los controladores de Windows

Cuando hablamos de drivers DCH en Windows 10 y Windows 11, nos referimos a una forma específica de empaquetar los controladores que Microsoft exige para su ecosistema moderno. DCH son las siglas de Declarative (D), Componentized (C) y Hardware Support App (H), tres principios que marcan cómo debe estar construido el paquete para considerarse compatible con el modelo de controlador universal de Windows.

Un controlador DCH no es solo un archivo .sys con un instalador bonito, sino un conjunto estructurado formado por: un paquete de controlador base, componentes opcionales y, de manera opcional, una aplicación de soporte de hardware (HSA) que se publica a través de la Microsoft Store o se preinstala por el OEM.

El objetivo de Microsoft con este formato es que los controladores funcionen igual en todas las ediciones modernas de Windows (especialmente en las basadas en UWP), que sean más fáciles de mantener, más seguros y menos dependientes de apaños específicos para cada fabricante o modelo concreto.

Principios de diseño: Declarative, Componentized y Hardware Support App

Los drivers DCH se rigen por tres principios de diseño clave que marcan una diferencia importante frente a los controladores heredados.

Declarativo (D)
En los controladores DCH, la instalación debe hacerse solo mediante directivas INF declarativas. Esto significa que:

• No se permiten coinstaladores (pequeños ejecutables que antes se lanzaban durante la instalación para hacer tareas personalizadas).
• No se admite el registro de DLL mediante funciones como RegisterDll dentro del INF.
• La lógica de instalación se describe con reglas claras y comprobables, en lugar de meter código arbitrario que el sistema no puede auditar bien.

Para comprobar que un INF cumple el modelo declarativo, Microsoft proporciona la herramienta InfVerif, que permite validar el archivo usando, por ejemplo, el comando infverif /k, imprescindible si quieres que el paquete sea aceptado como universal.

Componentizado (C)
El segundo pilar es que el controlador esté modularizado. En la práctica esto implica que:

• El paquete base contiene solo la funcionalidad esencial del dispositivo y el código compartido.
• Las personalizaciones específicas de OEM, región o modelo se colocan en paquetes de componentes opcionales o en INF de extensión.
• El driver base puede desplegarse y actualizarse de forma independiente, sin tocar las capas opcionales.

Esta separación es clave para que, por ejemplo, un fabricante de hardware (IHV) como “Fabrikam” pueda certificar una sola vez el controlador base para un chip concreto y luego distintos OEM (Dell, HP, Lenovo, etc.) añadan sus capas de personalización sin romper el núcleo.

Hardware Support App (H)
El tercer componente es la Hardware Support App (HSA), la aplicación que acompaña al dispositivo cuando hace falta una interfaz de usuario avanzada (panel de control, utilidades, configuración, etc.). Las reglas son:

• Cualquier interfaz gráfica asociada al driver debe ser una HSA o venir preinstalada por el OEM.
• La HSA debe ser una app UWP o Desktop Bridge empaquetada como MSIX.
• Su distribución y actualizaciones se hacen exclusivamente a través de Microsoft Store (o preinstalada en fábrica), lo que facilita parches rápidos sin cambiar el controlador base.

Esta filosofía se ve muy claro con Nvidia y su Panel de Control en versión DCH, que ya no se incluye como parte del instalador clásico, sino que se descarga desde la Store.

El papel de UWP y la “U” que completa el modelo DCHU

En muchas guías de Microsoft y de fabricantes de hardware se habla no solo de DCH, sino del término DCHU. Esa letra extra hace referencia a la “U” de Universal API Compliance, que completa el modelo de controlador universal de Windows.

La idea es que los binarios de los drivers universales únicamente utilicen APIs y DDIs presentes en Windows 10 y posteriores. Esto evita que el controlador dependa de bibliotecas antiguas o de componentes no estándar, reduciendo incompatibilidades y errores extraños cuando el sistema se actualiza.

Con este enfoque, Microsoft se asegura de que el mismo paquete pueda ejecutarse en diferentes variantes de Windows (ediciones de escritorio, sistemas ligeros basados en UWP, etc.), siempre que compartan el mismo conjunto de interfaces soportadas.

Gracias a este enfoque unificado:

• Los desarrolladores tienen un marco más predecible y menos dependiente de hacks heredados.
• Los usuarios se benefician de mayor estabilidad y ciclos de actualización más limpios.
• Las aplicaciones asociadas (como paneles de control) son más fáciles de portar y mantener.

Cómo se estructura un paquete de controlador compatible con DCH

Un driver compatible con DCH no es un único fichero INF suelto, sino un conjunto de piezas bien separadas que colaboran entre sí. Normalmente se distinguen cuatro grandes elementos.

1. Paquete de controlador base
Es el corazón del sistema: contiene toda la funcionalidad básica del dispositivo y el código que comparten todas las variantes. Suele ser desarrollado por el IHV (fabricante de hardware), que luego pasa este paquete a diferentes OEM para que lo integren.

2. Paquetes de componentes opcionales
En lugar de inflar el núcleo con cada personalización, se añaden componentes separados que pueden incluir:

• Ajustes específicos para ciertos modelos u OEM.
• Software adicional heredado necesario solo en algunos escenarios.
• Configuraciones avanzadas que no forman parte del mínimo necesario.

Estos componentes pueden desplegarse y actualizarse independientemente del paquete base, lo que simplifica muchísimo la gestión a largo plazo.

3. INF de extensión
El archivo INF base define la instalación general, pero se pueden crear INF de extensión que añaden o modifican comportamiento para casos concretos. Es la forma recomendada de:

• Sobre-escribir valores de registro del driver base para cierto OEM.
• Incorporar componentes adicionales (por ejemplo, creaciones de dispositivos secundarios virtuales).
• Encapsular personalizaciones de “marca” sin tocar el núcleo.

El sistema procesa siempre las extensiones después del INF base, por lo que es posible actualizar el núcleo y que Windows rehaga automáticamente las extensiones sobre la nueva versión.

4. Hardware Support App (HSA)
Cuando el dispositivo requiere una experiencia de usuario más rica (por ejemplo, un panel de control con ajustes avanzados), se vincula una HSA. Un ejemplo típico sería:

• Crear una app UWP que exponga capacidades personalizadas del dispositivo.
• Asociarla mediante propiedades de interfaz en el driver (por ejemplo, usando DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities).
• Distribuirla por Microsoft Store o preinstalarla con DISM en las imágenes OEM.

Buenas prácticas técnicas al desarrollar drivers DCH

Para los desarrolladores de drivers, Microsoft marca una serie de recomendaciones muy concretas para no salirse de las reglas DCH y, de paso, simplificar pruebas y mantenimiento.

Uso de Visual Studio y WDK con plataforma “Universal”
Si se utiliza el Windows Driver Kit (WDK) junto con la versión reciente de Visual Studio, se recomienda configurar la plataforma objetivo del proyecto de controlador como “Universal”. Con esto, el propio entorno:

• Añade automáticamente las bibliotecas correctas para drivers universales.
• Ejecuta verificaciones como InfVerif y ApiValidator durante la compilación.
• Reduce el riesgo de introducir APIs no permitidas en el paquete.

Separar lógica dependiente de plataforma en INF de extensión
Si el archivo INF actual hace acciones de configuración personalizadas que varían según la plataforma, la recomendación es mover esa lógica a una extensión INF. De esta forma:

• El controlador base se mantiene limpio y genérico.
• Las extensiones pueden actualizarse de forma independiente cuando cambian los requisitos de una plataforma u OEM concreto.

Instalar servicios y software desde INF de manera declarativa
En el contexto DCH, incluso la instalación de servicios Win32 asociados al dispositivo debe definirse declarativamente en el INF, por ejemplo usando directivas como AddService para crear servicios, especificar tipo, modo de inicio, binario y triggers de arranque.

De forma similar, si existe software heredado adicional que debe instalarse (por ejemplo, una herramienta GUI que solo funciona en ediciones de escritorio), se puede empaquetar en un componente separado y declararlo con AddSoftware, manteniendo el núcleo libre de dependencias específicas.

Ejecución desde el Driver Store (dirid 13)
Otra recomendación importante es configurar los destinos de copia de archivos usando el dirid 13, es decir, el almacén de controladores de Windows (driver store). Esto:

• Facilita que el sistema cargue los binarios desde una ubicación única y controlada.
• Mejora la estabilidad durante actualizaciones de drivers.
• Simplifica la gestión y desinstalación a medio y largo plazo.

DCH vs controladores estándar en Nvidia y otros fabricantes

Donde más se oye hablar de DCH a nivel usuario es con drivers de tarjetas gráficas. Nvidia, por ejemplo, ofrece y diferencia claramente drivers estándar y DCH para Windows.

Tipos de driver Nvidia: Game Ready vs Studio
Antes incluso de elegir entre estándar o DCH, Nvidia te hace escoger el “tipo de descarga”:

• Game Ready Driver (GRD): centrado en lanzar soporte y optimizaciones el mismo día que salen nuevos juegos o actualizaciones importantes. Es el que se actualiza más a menudo y prioriza el rendimiento y compatibilidad con títulos recientes.
• Studio Driver (SD): pensado para creadores de contenido y profesionales que usan aplicaciones de diseño, edición de vídeo, 3D, etc. Aquí el foco está mucho más en la estabilidad y certificaciones con software profesional, y no tanto en tener el último parche para el último lanzamiento.

Estos dos sabores no dependen directamente de ser estándar o DCH, pero suelen combinarse con esa otra elección.

Tipo de controlador de Windows: estándar vs DCH
En la web de Nvidia aparece la opción de “Tipo de controlador de Windows: Estándar o DCH”. A nivel de funcionalidad bruta de la GPU, la diferencia es mínima o nula: rinden prácticamente igual y dan acceso a las mismas tecnologías básicas.

La diferencia está en el modelo de integración con Windows:

• El driver estándar sigue el enfoque clásico, instalando el panel de control y otros componentes “a la antigua” dentro del mismo paquete.
• El driver DCH sigue el modelo moderno: el driver se instala como paquete DCH y el Panel de control de Nvidia llega como app de Microsoft Store (HSA), descargable y actualizable por separado.

Algo importante: no se puede instalar un paquete DCH sobre un sistema que ya usa un driver estándar (y viceversa) sin limpiar antes. Para cambiar de uno a otro, lo habitual es usar DDU (Display Driver Uninstaller) u otras herramientas de desinstalación limpia, o bien dejar que la propia instalación de Nvidia se encargue de hacer el cambio según la situación.

¿Qué tipo de driver Nvidia conviene instalar?
En equipos modernos, especialmente si vienes de una instalación limpia de Windows 10 u 11, el propio sistema tiende a instalar drivers DCH de Nvidia automáticamente desde Windows Update. Muchos usuarios se preguntan si tiene sentido desconectar la red durante la instalación del sistema para evitarlo y luego instalar manualmente un driver estándar desde un pendrive.

En la práctica real:

• No hay una ventaja clara de rendimiento o estabilidad entre estándar y DCH para la mayoría de usuarios.
• DCH está alineado con la dirección que marca Microsoft (controladores universales, apps de soporte desde la Store, etc.), por lo que es la opción más “de futuro”.
• El Panel de Control desde la Store funciona de forma muy similar al heredado, y salvo casos puntuales, no supone una pérdida de opciones importantes.

Por todo ello, si no tienes una razón muy específica para mantenerte en el modelo antiguo, lo más sensato es dejar que GeForce Experience o la web oficial te proporcionen el driver DCH adecuado para tu sistema, sin bloquear la instalación automática de Windows.

Controladores DCH en Radeon y otros OEM

El enfoque DCH no es exclusivo de Nvidia. Otros fabricantes, como AMD con sus Radeon o los propios OEM (Dell, HP, etc.), ofrecen paquetes marcados como compatibles con este modelo.

Por ejemplo, en portales de soporte de fabricantes como Dell puedes encontrar “controladores DCH de Radeon Desktop” pensados para ciertos equipos (como sobremesas Alienware). Las dudas típicas son:

• Si son más estables que los clásicos.
• Si traen menos funciones por ser más “universales”.
• Si se pueden usar en cualquier tarjeta o están bloqueados para ese OEM.

En términos generales:

• Los drivers DCH no son necesariamente más limitados; el recorte viene solo si el fabricante decide no incluir ciertas funciones en su build concreta.
• Los paquetes que ofrece un OEM concreto suelen estar adaptados y firmados para sus equipos específicos, así que no son automáticamente “universales” para cualquier tarjeta RDNA o similar.
• Lo habitual es que el chipset gráfico sea el mismo, pero el paquete OEM incluya componentes de personalización (por ejemplo, integraciones con software preinstalado del fabricante).

Si buscas el máximo control y las últimas versiones, normalmente conviene descargar los drivers directamente del fabricante del chip (AMD, Nvidia), salvo que el OEM recomiende explícitamente usar su versión por motivos de compatibilidad.

La otra cara de DCH: formato de archivo antiguo y esquemas DipTrace

Al buscar información sobre “formato DCH” también salen referencias que no tienen nada que ver con los controladores modernos de Windows, pero que comparten la misma extensión.

Archivos DCH de DraftChoice (formato de planos CAD)
Hubo un tiempo en el que la extensión .DCH identificaba los archivos nativos del programa DraftChoice, una aplicación de CAD para DOS y más tarde para Windows. Este software permitía crear planos técnicos y dibujos de diseño con hasta 16 capas, con un rendimiento muy alto para la época y un consumo de recursos bastante modesto.

DraftChoice trabajaba con varios formatos clásicos como PCX, WPG, HPGL, PIC y su propio formato DCH. El desarrollo se abandonó alrededor de 2005 y se llegó a ofrecer gratuitamente en su web, pero hoy en día es un software totalmente descontinuado.

Archivos DCH en DipTrace (esquemas electrónicos)
La extensión DCH también puede referirse a archivos de esquemas de DipTrace, usados en el diseño de circuitos electrónicos. En este contexto, los problemas más frecuentes al abrir un archivo .DCH son bastante mundanos:

• No tener DipTrace instalado en el sistema, por lo que Windows muestra el típico mensaje de “no se puede abrir este tipo de archivo”.
• Tener una versión antigua de DipTrace que no entiende un archivo creado con una versión más reciente.
• Errores de instalación, asociaciones rotas en el registro, archivos dañados o afectados por malware.

En estos casos, la solución pasa por instalar o actualizar DipTrace, verificar el archivo (por ejemplo, comprobando sus propiedades y la versión con la que se generó) y revisar que el registro de Windows no tenga asociaciones corruptas.

Es importante no mezclar estos usos de la extensión .DCH con el formato DCH de drivers de Windows, porque son conceptos completamente distintos que solo coinciden en el nombre.

Cuando Windows, Microsoft o fabricantes de gráficas hablan de “formato DCH”, no se refieren a un simple cambio de nombre, sino a un modelo de controlador más modular, declarativo y preparado para el ecosistema UWP, que además convive con otros usos históricos de la extensión DCH en el mundo del software y los formatos de archivo.