Com testar drivers: guia completa per a controladors de PC i embeguts

Saber com testar drivers marca la diferència entre un sistema estable i un ple de penjolls, pantalles blaves o dispositius que funcionen quan volen. És igual que estiguem parlant d'un controlador de Windows, d'un driver per a una GPU o d'una capa HAL per a un microcontrolador com l'ATmega328P: si no es prova bé, tard o d'hora fallarà en el pitjor moment possible.

El problema és que, encara que es parla molt de proves unitàries i testing automàtic, quan entrem al terreny dels controladors i del codi molt proper al maquinari la cosa es complica. Aquí entren en joc eines específiques (com Driver Verifier o el WDK a Windows), bones pràctiques durant el desenvolupament, entorns de prova dedicats i, al món embegut, simuladors i plaques de test per no jugar-nos-la amb el maquinari real.

Què és un driver i per què és tan crític provar-ho bé

Un driver o controlador és un petit programa que actua de traductor entre el sistema operatiu (o el microprogramari principal en un microcontrolador) i un dispositiu físic: targeta gràfica, targeta de so, xarxa, sensors, memòria, busos, etc. Sense aquest pont, el sistema ni tan sols sabria que el dispositiu existeix, o no podria utilitzar totes les seves capacitats.

En un PC amb Windows, gairebé tots els components que veus al Administrador de dispositius depenen de drivers: GPU, àudio, xarxa (Ethernet/WiFi), USB, chipset, BIOS/UEFI, teclat i ratolí, webcam, impressores… En un microcontrolador, aquest paper ho fan les capes HAL (Hardware Abstraction Layer) i els drivers de cada perifèric: SPI, I2C, UART, ADC, timers, PWM, sensors concrets, etc.

Si aquests controladors estan mal implementats o defectuosos, podem tenir símptomes molt variats: des d'una simple pèrdua de rendiment fins a bloquejos totals de l'equip, apagats espontanis, artefactes gràfics, errades en imprimir, desconnexions de xarxa, àudio que es talla o s'escolta distorsionat, o al món embegut, lectures aleatòries, perifèrics que deixen de respondre o penges que obliguen a reiniciar el micro.

Per això, més que a gairebé qualsevol altra part del programari, testejar a consciència els drivers és obligatori si volem fiabilitat, estabilitat i rendiment. A més, els errors en aquesta capa solen ser dels més cars de corregir un cop el producte està en mans de l'usuari, així que interessa detectar-los com més aviat millor.

Quan començar a provar un driver: estratègia general de testing

La millor manera d'assegurar un bon resultat final és començar les proves des de molt aviat al cicle de desenvolupament. Quan tinguis clars els requisits del controlador (què ha de fer, quins errors ha de manejar, latències acceptables, límits de dades, etc.) convé anar dissenyant casos de prova en paral·lel al propi codi.

L'experiència (i molts estudis) demostren que com més aviat es detecten els defectes, menys costa arreglar-los i menys impacte tenen. Un bug en el disseny o en una API del teu HAL, descobert quan ja hi ha mitja aplicació a sobre, és un marró; si es detecta quan amb prou feines hi ha unes línies de codi, és un simple ajustament de disseny.

En el context de drivers, se sol parlar de tres moments clau per provar:

• Fase primerenca de desenvolupament: proves unitàries i funcionals de les funcions bàsiques del controlador, validant l'API, els paràmetres, el maneig d'errors i els casos límit.
• Fase dintegració i solució de problemes: quan el driver ja es fa servir en un sistema real (PC, placa amb microcontrolador, entorn de producció simulat) i es depuren penges, bloquejos i comportaments erràtics.
• Proves prèvies a desplegament/certificació: test d'estrès, compatibilitat, rendiment i, en el cas de Windows, execució de bateries de proves com les del WDK o el Kit de certificació de maquinari.

Un error molt freqüent és limitar-se a “funciona a la meva placa en imprimir per UART” i donar el driver per bo. Aquesta comprovació ràpida va bé com a primera validació, però per a funcions complexes o drivers HAL complets es queda extremadament curta; cal anar molt més enllà: casos límit, entrades errònies, errors de maquinari simulats, interrupcions encadenades, canvis de freqüència, etc.

Mètodes generals per testar drivers (PC i sistemes encastats)

Tot i que les eines canvien segons si treballes a Windows o microcontroladors, les idees de testing són molt semblants. Convé combinar diverses capes de prova:

1. Proves unitàries sobre funcions individuals del driver o de l'HAL: validen que cada API fa allò que promet amb entrades normals, límits i paràmetres incorrectes. En embegut se solen fer servir marcs de test adaptats o simuladors que emulen registres i perifèrics.

2. Proves funcionals que exerciten el controlador sencer: per exemple, llegir i escriure en un sensor, enviar paquets per la xarxa, reproduir àudio o inicialitzar una GPU. Aquí ja entra en joc la interacció amb altres capes del sistema (aplicació, sistema operatiu, RTOS).

3. Proves d'estrès i robustesa: es bombardeja el driver amb sol·licituds intensives, combinacions d'esdeveniments, desconnexions i reconnexions del dispositiu, canvis de freqüència del sistema, suspensió/represa, etc., per veure si aguanta sense fuites de memòria, penges ni corrupció de dades.

4. Proves de regressió: cada vegada que modifiquis el controlador, hauries repetir un conjunt estàndard de proves per assegurar que no has trencat res del que ja funcionava. Aquí és on té sentit automatitzar al màxim amb scripts, bancs de proves de maquinari i eines del sistema operatiu.

Al món Windows, moltes d'aquestes tasques es recolzen en eines especialitzades com el Driver Verifier, el WDK, Visual Studio i el Kit de certificació de maquinari. En sistemes embeguts, el més típic és combinar simuladors, plaques de desenvolupament, lògica analògica (oscil·loscopi, analitzador lògic) i petites aplicacions natives que exerciten el driver en diferents escenaris, en comptes de limitar-se a un simple printf per UART.

Driver Verifier a Windows: què és i per a què serveix

A Windows hi ha una eina poc coneguda per l'usuari mitjà però clau per a desenvolupadors i per diagnosticar errors grossos de controladors: Driver Verifier (verifier.exe). És un component del sistema que s'encarrega de vigilar en temps real els controladors de manera kernel i els drivers gràfics, amb l'objectiu de detectar comportaments que podrien desestabilitzar el sistema.

Driver Verifier no comprova si el driver funciona a nivell d'usuari, sinó si respecta estrictament les regles internes del nucli: ús correcte d'IRPs, memòria, sincronització, accés a recursos, compliment de les interfícies DDI, etc. Quan detecta una acció il·legal o perillosa, força una comprovació d'errors (bug check), el que en cristià és una pantalla blava dissenyada per donar-te la màxima informació possible sobre la decisió.

Aquesta eina ve inclosa en la majoria de les versions de Windows des de fa anys, es troba a %WinDir%\System32\Verifier.exe i no cal descarregar res addicional. La gran excepció és Windows 10 S, on no està disponible i convé fer les proves en una edició estàndard de Windows 10.

Driver Verifier és especialment útil durant el desenvolupament de nous controladors o quan intentes caçar una fallada esquiva que només apareix de tant en tant. En activar regles estrictes sobre el teu driver, és més fàcil que el sistema “cridi” just al punt de la infracció, en lloc de deixar que l'error es propagui i causi un pengi misteriós minuts després.

Com iniciar i configurar Driver Verifier al Windows

El primer que has de tenir clar abans de llançar-te a fer servir aquesta eina és que Driver Verifier pot provocar bloquejos i reinicis a l'equip de prova, precisament perquè la seva funció és detectar infraccions greus. Per això, Microsoft insisteix que es faci servir únicament a màquines de test o entorns de depuració, mai a l'equip principal d'un usuari final.

A més, per treure-li tot el suc, és recomanable connectar un depurador de nucli (WinDbg, KD, CDB o NTSD) a l'equip sota prova. Això permet capturar els detalls del bug check en el mateix instant en què passa i analitzar amb ordres com !anàlisi -v quin controlador ha estat el culpable i quina regla ha violat.

Per arrencar Driver Verifier amb la interfície gràfica estàndard, el flux bàsic seria aquest:

1. Obrir un símbol del sistema amb privilegis d'administrador i executar verifier per llançar el Driver Verifier Manager.
2. Escollir “Crear configuració estàndard” (opció per defecte) i fer clic a Següent. Si necessites una mica més fi, pots optar per “Crear configuració personalitzada” i seleccionar manualment les regles que vols habilitar.
3. A la pantalla “Seleccionar quins controladors comprovar”, triar un dels esquemes de selecció disponibles: controladors sense signar, drivers per a versions antigues de Windows, tots els controladors instal·lats o un subconjunt escollit d'una llista.
4. Si seleccioneu l'opció de "Trieu noms de controladors d'una llista", es mostrarà el catàleg de drivers disponibles al sistema i podràs marcar un o diversos en concret.
5. Finalitzar l'assistent i reiniciar l'equip perquè el verificador comenci a actuar sobre els controladors seleccionats en la següent arrencada.

Lelecció de quins drivers incloure és crucial. Activar el verificador sobre tots els controladors del sistema dóna una cobertura molt àmplia i va bé en escenaris de compatibilitat i d'interacció entre dispositius, però també pot consumir molts recursos, reduir el rendiment global i esgotar mecanismes com el Pool Especial o el seguiment de recursos. Per això, quan estàs centrat en un únic controlador problemàtic, acostuma a ser millor marcar només aquest driver per disposar de la màxima capacitat de detecció i minimitzar efectes col·laterals.

Ús avançat de Driver Verifier i consola d'ordres

Si ja tens certa experiència o vols automatitzar sessions de prova, pots controlar Driver Verifier des de la línia d'ordres sense passar per la GUI. El format bàsic permet activar perfils complets sobre un o diversos drivers amb ordres molt simples.

Per exemple, per habilitar la configuració estàndard sobre un controlador concret anomenat myDriver.sys només cal llançar:

verifier /standard /driver myDriver.sys

Un cop acabada una campanya de proves, el normal és desactivar el verificador i tornar el sistema a un estat normal. Això es fa amb:

verifier /reset

Després d'executar aquesta ordre, convé reiniciar l'equip perquè la configuració deixi d'estar activa del tot. Si el que vols és simplement veure l'estat actual del verificador i els controladors sota vigilància, pots fer servir:

verifier /query

o bé, si vols comprovar quines regles estan habilitades i amb quins paràmetres, recórrer a:

verifier /querysettings

Aquestes mateixes funcions estan disponibles des de l'administrador gràfic del verificador, on trobareu opcions com “Eliminar configuració existent”, “Mostrar informació sobre els controladors comprovats actualment” o “Mostrar la configuració existent”. Depèn de si prefereixes una interfície més visual o et manegues millor amb scripts i consoles.

Depurar errors detectats per Driver Verifier

Quan Driver Verifier detecta una infracció, no es limita a escriure un avís en un log: força un bug check per aturar immediatament el sistema. Encara que pugui resultar agressiu, és l'única manera de capturar el context exacte de la fallada abans que el sistema segueixi corrent i el problema es dilueixi o carregui dades corruptes.

La comprovació derrors més habitual associada a aquesta eina és Comprovació d’errors 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, que indica que el verificador ha detectat una violació de regles en un controlador. Hi ha altres codis freqüents segons el tipus d'infracció (interbloquejos, ús incorrecte de memòria paginable/no paginable, etc.), però aquest és el que veureu més sovint en sessions de prova intensiva.

Després del bug check, en connectar un depurador de kernel a l'equip de proves, Windows invocarà el debugger i mostrarà un diagnòstic inicial. El primer que hauríeu de fer en una nova sessió és executar l'ordre d'extensió:

!analyze -v

El modificador -v proporciona informació més detallada sobre l'error: pila de trucades, mòdul sospitós, paràmetres del bug check i, en el cas de les regles de compliment DDI, el RuleID afectat. Aquests identificadors solen tenir la forma 0x200nn i us indiquen exactament quina norma ha violat el vostre controlador.

A més de !analyze, hi ha altres extensions de depuració molt útils quan estàs treballant amb Driver Verifier:

• !verifier: mostra estadístiques recopilades pel verificador sobre els controladors sota vigilància. Pots consultar !verifier -? per veure totes les opcions disponibles.
• !deadlock: presenta informació sobre interbloquejos i objectes monitoritzats per la funció de detecció de deadlocks del verificador, ideal per a problemes de sincronització i bloquejos mutus.
• !iovirp : ensenya detalls sobre un IRP (I/O Request Packet) monitoritzat per la comprovació d'E/S, cosa que ajuda a rastrejar el camí d'una petició entre els diferents controladors de la pila.

Combinant aquestes extensions amb les dades del bug check, pots localitzar amb precisió la part del codi del driver que ha comès la infracció, en lloc de perseguir símptomes difusos com ara penjaments aleatoris o corrupció de memòria sense context.

WDK, Visual Studio i proves de drivers a Windows

Més enllà de Driver Verifier, l'ecosistema de Windows compta amb tot un conjunt d'eines específiques per a desenvolupament i testing de controladors, integrades principalment al Windows Driver Kit (WDK) i les seves extensions per a Visual Studio.

El WDK afegeix a Visual Studio una interfície de proves de drivers que permet compilar, implementar, instal·lar i executar proves sobre un controlador en un equip remot de la xarxa. En comptes de caminar copiant binaris a mà o instal·lant manualment cada build, pots automatitzar gran part del cicle: compilar, desplegar a la màquina de proves, arrencar el driver i executar una bateria de tests predefinits.

Aquest entorn inclou a més una col·lecció de proves estàndard per a controladors de dispositius, que cobreixen des del funcionament bàsic fins a característiques concretes exigides pel sistema operatiu. Si aquestes proves es passen de forma consistent, tens força garanties que el teu driver respecta les especificacions de Windows.

De cara a treure el controlador al públic o distribuir-lo en equips de producció, entra en joc el Kit de certificació de maquinari (HCK) i el programa de certificació de Windows. Executar aquestes bateries de test és gairebé obligatori si voleu el segell oficial de compatibilitat, ja que es comproven aspectes d'estabilitat, rendiment, consum i compliment de normes de seguretat.

El WDK també proporciona eines i binaris de prova pensats per a línia de comandes, que fan més fàcil l'execució de proves fonamentals del dispositiu des de scripts o processos automatitzats. Això es fa servir molt en laboratoris de validació on es repeteixen centenars d'execucions canviant maquinari, versions de SO i configuracions.

Com comprovar i actualitzar drivers en un PC amb Windows

Per a l'usuari general (i també per a molts desenvolupadors quan es posen el barret de “sysadmin”), tan important com testejar és saber quins drivers estan instal·lats, la versió i si necessiten una actualització. El primer pas sol ser fer una ullada al Administrador de dispositius.

Des del menú Inici podeu cercar “Administrador de dispositius” i obrir-lo. A l'arbre de maquinari trobaràs tots els components detectats i, si hi ha problemes, veuràs un icona d'advertència groc sobre el dispositiu conflictiu. Des d'allà pots:

• entrar a Propietats → pestanya Controlador per veure la versió i la data del driver.
• Actualitzar el controlador perquè Windows busqui versions noves de forma automàtica (encara que aquest mètode sol quedar curt amb GPUs i maquinari avançat).
• Deshabilitar o desinstal·lar el component si dóna molts problemes, permetent que el sistema el reinstal·li des de zero al següent reinici.

En el cas concret de la targeta gràfica, l'Administrador de dispositius us permet veure quin GPU tens (a l'apartat “Adaptadors de pantalla”) i quina versió de driver fa servir. Si en lloc del fabricant (Nvidia, AMD, Intel) apareix Microsoft, és molt probable que estiguis usant un controlador de pantalla genèric, amb pitjors prestacions i sense accés a totes les funcions avançades.

Per això, a GPUs modernes gairebé sempre convé instal·lar el programari oficial del fabricant: per exemple, GeForce Experience per a Nvidia, Adrenalin per a AMD o les eines d'Intel. Aquestes solucions no només us avisaran de noves versions de drivers, sinó que aporten funcions extra, perfils de joc, optimització automàtica de gràfics, etc. Si no vols els afegits, en molts casos pots triar una instal·lació de “només driver”.

Una altra via integrada al sistema és Windows Update. Des de Configuració → Actualització i seguretat (al Windows 10) o Configuració → Windows Update → Opcions avançades → Actualitzacions opcionals (al Windows 11) pots revisar si n'hi ha controladors nous disponibles. A la secció d'actualitzacions de drivers veureu una llista de controladors que el sistema ofereix instal·lar de forma opcional.

Instal·lació manual, sense Internet i amb eines de tercers

Windows inclou molts drivers genèrics que permeten que el sistema arrenqui i funcioni sense connexió, però no sempre són els òptims. En equips sense Internet o amb maquinari molt específic, podeu tocar recórrer a altres tàctiques com exportar drivers amb DISM i portar-los a l'equip fora de línia.

Una opció clàssica és fer servir paquets de drivers sense connexió com DriverPack o similars. Aquestes eines es descarreguen des d'un PC amb Internet, es copien en un USB i, un cop a l'equip desconnectat, analitzen el maquinari i instal·len els controladors necessaris des del seu propi dipòsit. Són especialment útils després d'una instal·lació neta de Windows en un ordinador vell o sense accés permanent a la xarxa.

Això sí, cal anar amb compte: molts programes d'aquest tipus inclouen programari addicional no desitjat durant la instal·lació, per la qual cosa convé fer servir sempre els modes avançats o “experts” i desmarcar qualsevol casella que no sigui exclusivament de drivers. També és bona idea crear un punt de restauració de sistema abans de fer canvis massius.

Una altra via més controlada és instal·lar manualment el driver: descarregues l'arxiu des de la pàgina oficial del fabricant, descomprimeixes si cal i, des de l'Administrador de dispositius, tries “Actualitzar controlador” → “Cerca programari de controlador a l'equip” i apuntes al fitxer .inf corresponent. Si el controlador és compatible, Windows ho acceptarà i ho registrarà; si no, veuràs un error d'incompatibilitat o de signatura.

Pel que fa a programes de tercers per detectar i actualitzar controladors, hi ha tota una fauna: des d'eines oficials com Intel Driver & Support fins a utilitats d'escaneig com Snappy Driver Installer, SlimDrivers, DriverPack, Device Doctor, DriverMax, etc. Algunes tenen versió gratuïta, altres de pagament, i moltes han tingut en el passat problemes de adware o bloatware, així que cal anar amb compte i descarregar sempre des dels seus webs oficials. Per a aquestes tasques convé recórrer a programes específics d'instal·lació i fer-los servir de forma selectiva.

La recomanació general de molts tècnics experimentats és no confiar cegament en paquets que “ho actualitzen tot de cop”, sinó utilitzar-los, en tot cas, per identificar drivers faltants o desfasats i després instal·lar-los de manera selectiva, preferiblement des de les fonts oficials del maquinari.

Drivers en microcontroladors i HAL: com provar-los de manera eficaç

Al món dels sistemes embeguts, provar drivers té les seves pròpies peculiaritats. Un exemple típic és el d'un desenvolupador que està creant drivers per a sensors o capes HAL en un ATmega328P i l'estratègia de test actual del qual consisteix a cridar funcions com get_temperature() i enviar el resultat per UART per veure si “sembla raonable”.

Aquest enfocament és bon punt de partida, però es queda molt curt quan el codi comença a complicar-se: interrupcions concurrents, múltiples perifèrics actuant alhora, modes destalvi denergia, canvis dinàmics de freqüència, etc. Per anar més enllà, en embegut se solen combinar diverses tècniques:

Simuladors i emuladors: moltes plataformes ofereixen simuladors que permeten emular registres i perifèrics del microcontrolador, de manera que pots escriure proves unitàries sobre el teu HAL sense haver de flaixar la placa constantment. No cobreixen el 100% de casos, però sí que ajuden a detectar errors lògics i d'API.

Plaques de prova dedicades: tenir un o diversos “mòduls de laboratori” amb sensors, actuadors i busos ben accessibles (pins exposats, connectors clars, punts de mesura) facilita muntar bancs de prova repetibles. Res de cables volant a l'atzar cada cop que vulguis comprovar alguna cosa.

Instrumentació maquinari: utilitzar oscil·loscopis, analitzadors lògics o fins i tot simples LEDs de debug permet veure si les línies de comunicació (SPI, I2C, UART) i els senyals de control es comporten com haurien de baixar, no només a nivell de “m'arriba un nombre més o menys correcte”.

Proves automatitzades amb scripts: igual que en un PC pots fer servir scripts per llançar test sobre un driver, en embegut pots escriure petites aplicacions hoste que exercitin el teu HAL en bucle i envien resultats a un PC, on es validen contra valors esperats. Això et permet repetir la mateixa bateria de proves cada cop que canvies el codi.

En tot cas, la idea clau és la mateixa que a Windows: no quedar-te que “compila i sembla anar bé una vegada”, sinó dissenyar escenaris de prova sistemàtics, amb entrades variades, errors simulats (fallida de sensor, desconnexió de bus, temps de resposta anòmals) i una automatització suficient perquè puguis repetir els tests sense patir.

En definitiva, dominar com testar drivers -ja sigui a Windows amb eines com Driver Verifier, WDK i l'Administrador de dispositius, o en sistemes embeguts amb simuladors i bancs de prova- és el que separa un sistema robust i professional d'un que falla quan més ho necessites; dedicar temps a dissenyar bones proves, fer servir les utilitats adequades i evitar dreceres perilloses amb eines de tercers és una inversió que s'amortitza sola en estabilitat, rendiment i en menys mals de cap en producció.