BIOS vs Pilote vs Windows : Qui contrôle votre matériel (et comment le tester)

Un modèle mental opérationnel : qui possède quoi, quand

Considérez le contrôle matériel comme une course de relais avec trois coureurs et un nombre surprenant de bâtons lâchés :

• BIOS/UEFI (firmware de plateforme) : met sous tension le système, énumère les périphériques, applique les politiques de plateforme (initialisation mémoire, paramètres de lien PCIe, tables ACPI), puis se met principalement en retrait.
• Firmware du périphérique (à l’intérieur du SSD/NIC/HBA/GPU) : implémente le comportement propre au périphérique : gestion des files, récupération d’erreurs, throttling thermique, cache, négociation de lien et parfois un sens de l’humour.
• Pilotes : traduisent les requêtes de l’OS en opérations matérielles ; implémentent la gestion d’alimentation, la gestion des interruptions, la configuration du DMA, l’intégration de l’ordonnancement I/O, les offloads et les optimisations spécifiques au périphérique. Les pilotes sont souvent l’endroit où la performance se gagne ou se perd.
• Windows (noyau + sous-systèmes stockage/réseau) : décide de la politique : ordonnancement, gestion mémoire, comportement de la pile I/O, plans d’alimentation, posture de sécurité et ce que signifie « sain ».

Alors qui « contrôle » le matériel ? La couche qui prend la décision à ce moment-là :

• Au démarrage : le BIOS/UEFI tient le volant. Il prépare la scène. Il décide aussi ce que Windows est autorisé à croire sur le matériel via ACPI et l’énumération des périphériques.
• Après le démarrage : Windows et les pilotes conduisent la plupart du temps. Le firmware agit toujours comme les réflexes du périphérique : throttling thermique, collecte de déchets en arrière-plan, réinitialisations de lien, temporisations internes.
• Sous stress/échec : le firmware devient souvent le véritable chef. Si un contrôleur commence une récupération d’erreur ou des réinitialisations, l’OS ne peut que réagir.

Lorsque vous déboguez, vous ne demandez pas « qui est coupable ? » Vous demandez :

1. Quelle couche prend la décision qui correspond à mon symptôme ?
2. Quelles preuves puis-je collecter en 5 minutes pour le prouver ?
3. Quel changement est réversible et sûr ?

Une citation pour rester honnête. C’est une idée paraphrasée de John Allspaw (opérations/fiabilité) : idée paraphrasée — « Vous ne réparez pas la fiabilité en blâmant ; vous la réparez en apprenant comment le système se comporte réellement. »

Blague n°1 : Si vous pensez que votre serveur « a simplement décidé » de fonctionner en PCIe x1, félicitations — vous venez de rencontrer la moins drôle des aventures à choix multiples.

Contexte historique & faits intéressants (ce qui mord plus tard)

Ce ne sont pas des anecdotes pour le quiz. Ce sont des faits qui expliquent pourquoi les choses fonctionnent ainsi. Ceux qui éclairent des classes entières de défaillances.

1. Le BIOS n’a pas été conçu pour le matériel d’aujourd’hui. Le BIOS classique remonte à l’ère PC ; l’UEFI est apparu pour gérer le boot moderne, les disques plus gros et des services pré-OS plus riches.
2. ACPI est le contrat. Windows se base largement sur les tables ACPI fournies par le firmware pour comprendre les états d’alimentation, la topologie des périphériques et les fonctionnalités plateforme. Un ACPI défectueux peut ressembler à un « bug Windows » pendant des années.
3. Les Option ROM faisaient la loi. Historiquement, les contrôleurs de stockage et réseau livraient des extensions BIOS (Option ROM) qui géraient l’initialisation des périphériques au démarrage. Les pilotes UEFI ont remplacé beaucoup de cela, mais des comportements hérités hantent encore les chemins de démarrage.
4. NVMe est « simple » par conception. NVMe a réduit les couches comparé à SATA/AHCI, mais a aussi rendu l’interaction pilote/firmware plus visible : files, interruptions et états d’alimentation comptent immédiatement.
5. La modération d’interruption est ancienne, mais toujours mal comprise. Les NIC coalescent les interruptions depuis des décennies. C’est excellent pour le débit, terrible pour les charges sensibles à la latence, et souvent réglé dans les pilotes — parfois « à votre avantage ».
6. Storport a remplacé d’anciens modèles de stockage Windows pour la performance. Les mini-ports de stockage haute performance reposent sur Storport ; c’est pourquoi les pilotes HBA/RAID/NVMe se comportent différemment du stockage « simple ».
7. La gestion d’alimentation Windows est devenue plus agressive au fil du temps. Les C-states CPU, ASPM PCIe, politiques d’inactivité des périphériques et le modern standby ont changé les hypothèses par défaut. Pratique pour les laptops ; parfois épicé pour les serveurs.
8. Secure Boot et la signature des pilotes ont changé la donne. Vous ne pouvez plus charger impunément des pilotes noyau douteux. C’est bien — jusqu’à ce que vous testiez un hotfix fournisseur à 2 h du matin.

Limites de contrôle : BIOS/UEFI vs firmware vs pilotes vs Windows

Ce que le BIOS/UEFI contrôle réellement

Le BIOS/UEFI contrôle la plateforme. Il n’« exécute » pas vos périphériques en état stable, mais il décide des conditions initiales :

• Topologie PCIe et entraînement du lien (largeur de voie, vitesse négociée, paramètres de bifurcation).
• Initialisation et timings mémoire (et si vos DIMM tournent à la vitesse annoncée ou en « mode sûr »).
• Fonctionnalités CPU et options de virtualisation (VT-x/VT-d, activation SR-IOV dans le firmware, comportement IOMMU exposé à l’OS).
• Politiques d’alimentation et thermiques (limites de type PL1/PL2, courbes de ventilateurs, « mode silencieux » qui rend les serveurs discrètement lents).
• Ordre de démarrage, Secure Boot, TPM, démarrage mesuré.
• Tables ACPI que Windows lit comme une bible.

Le BIOS/UEFI fournit aussi des hooks microcode et des éléments de gestion plateforme. Mais si vous déboguez une chute de débit à midi un mercredi, le BIOS n’est pas en train de boucler pour déplacer vos paquets.

Ce que contrôle le firmware du périphérique (et ce qu’il n’ira pas demander)

Le firmware à l’intérieur du périphérique est l’endroit où « le comportement matériel » vit réellement :

• Récupération d’erreur et nouvelles tentatives : temporisations, aborts, réinitialisations de lien, remappage de mauvais blocs.
• Throttling thermique : les SSD et GPU le font ; certains NIC aussi ; l’OS l’apprend après coup.
• Ordonnancement interne : couches de traduction NAND, comportement de soumission/complétion NVMe, politiques de cache de contrôleur RAID.
• Travail en arrière-plan : garbage collection, wear leveling, lectures de patrol, scrubs.

Les bugs de firmware sont particuliers car ils produisent des symptômes qui ressemblent à des problèmes de pilotes, et des correctifs qui ressemblent à des rituels : « Mettre à jour le firmware, redémarrer, et le fantôme disparaît. » Parfois c’est exactement ça.

Ce que contrôlent les pilotes (votre cause racine la plus fréquente)

Les pilotes se trouvent à la frontière où l’intention devient réalité :

• Stratégie de gestion des interruptions : basées sur la ligne vs MSI/MSI-X, affinité CPU, modération/coalescence.
• Mapping DMA : comment les tampons sont verrouillés et mappés, ce qui interagit avec les réglages IOMMU.
• Gestion d’alimentation : inactivité du périphérique, états d’alimentation du lien, selective suspend.
• Offloads : RSS/RSC/LSO sur les NIC ; profondeur de file et comportement du cache d’écriture sur le stockage.
• Surface de bugs : un bug de pilote peut bloquer le système ou « simplement » plafonner la performance à 30 % sans erreurs.

Les pilotes décident aussi de la télémétrie disponible. Si un pilote masque les détails, Windows ne peut pas diagnostiquer ce qu’il ne voit pas.

Ce que contrôle Windows (politique et orchestration)

Windows est l’ordonnanceur, l’arbitre et parfois celui qui déplace les poteaux de but :

• Ordonnancement CPU et placement des threads.
• Gestion mémoire, y compris le comportement du cache de page qui peut faire mentir les benchmarks de stockage.
• Politique de la pile I/O : files de stockage, comportement du système de fichiers, mise en cache, barrières d’écriture.
• Sécurité : HVCI/Memory Integrity, Credential Guard, VBS — cela peut modifier les caractéristiques de performance.
• Plans d’alimentation et politiques d’alimentation des périphériques.

Windows héberge aussi les journaux d’événements. Si vous ne les lisez pas, vous déboguez à l’aveugle.

Méthode de diagnostic rapide (vérifications 1re/2e/3e)

Ceci est la « j’ai 15 minutes avant que l’appel incident empire » méthode. L’objectif n’est pas la vérité parfaite. L’objectif est d’identifier la couche du goulot avec une forte confiance et une perturbation minimale.

Premier : confirmer que le symptôme est réel et local

• Est-ce une seule machine ou plusieurs ? Une seule machine pointe vers « matériel, pilote ou configuration locale ». Plusieurs machines indiquent « mise à jour Windows, politique, changement de charge ou dépendance partagée ».
• Est-ce une seule classe de périphérique ? Stockage seulement ? Réseau seulement ? GPU seulement ? Ne généralisez pas. Classez.
• Pouvez-vous reproduire avec un test simple ? Un test de lecture disque unique, un test réseau de type iperf sur une seule NIC (Windows a des outils), un stress CPU simple.

Second : mapper le goulot vers un sous-système

• Stockage : latence disque élevée, longueurs de file, réinitialisations ou temporisations du contrôleur.
• Réseau : pertes, retransmissions, CPU élevé dans les interruptions/DPC, ou négociation de lien faible.
• CPU/alimentation : fréquence bloquée basse, comportement anormal des C-states, limites thermiques.
• PCIe : largeur/vitesse du lien dégradée, erreurs AER, périphérique instable.

Troisième : décider quelle couche inspecter en premier

1. Politique/configuration Windows (rapide à vérifier, réversible) : plan d’alimentation, fonctionnalités VBS, politique de cache d’écriture, versions de pilotes.
2. Comportement du pilote (moyen) : interruptions, offloads, profondeur de files, réinitialisations storport, événements miniport.
3. Firmware/BIOS/UEFI (plus lent, plus risqué) : bifurcation PCIe, basculement SR-IOV, ASPM, mises à jour BIOS, firmware des périphériques.

Règle : si vous ne pouvez pas expliquer comment un réglage BIOS affecte votre symptôme, ne le touchez pas pendant un incident. Ce n’est pas de la discipline ; c’est de la survie.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’utilise réellement. Chacune inclut : la commande, ce que signifie la sortie, et quelle décision prendre.

Tâche 1 : Identifier la version du BIOS/UEFI et la date du firmware

cr0x@server:~$ wmic bios get smbiosbiosversion, releasedate
ReleaseDate                SMBIOSBIOSVersion
20231108000000.000000+000  2.1.7

Signification : Vous regardez la version du firmware de plateforme et la date de publication. Un firmware ancien ne signifie pas automatiquement « mauvais », mais indique souvent « cas connus ».

Décision : Si vous voyez des problèmes connus dans votre environnement (rétrogradation du lien PCIe, réinitialisations NVMe), planifiez une mise à jour BIOS contrôlée. Pas pendant l’incident.

Tâche 2 : Confirmer la build Windows et le niveau de correctifs

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"Hotfix(s)"
OS Name:                   Microsoft Windows Server 2022 Standard
OS Version:                10.0.20348 N/A Build 20348
Hotfix(s):                 5 Hotfix(s) Installed.

Signification : Le numéro de build compte ; le comportement du noyau/stockage change avec les mises à jour cumulatives.

Décision : Si la régression correspond au déploiement d’un correctif, segmentez le parc par anneau de mise à jour et comparez les performances avant d’accuser le « matériel ».

Tâche 3 : Voir quels pilotes sont réellement chargés (pas ce que vous pensez installé)

cr0x@server:~$ driverquery /v /fo table | findstr /I "stor nvme iastor mlx e1d"
stornvme.sys     ...   Microsoft Corporation   ...
storport.sys     ...   Microsoft Corporation   ...
mlx5.sys         ...   Mellanox Technologies   ...
e1d68x64.sys     ...   Intel Corporation       ...

Signification : Le pilote chargé est la vérité. Les captures d’écran du Gestionnaire de périphériques sont des impressions.

Décision : Si vous attendiez un pilote NVMe fournisseur mais voyez stornvme.sys, vos hypothèses de tuning sont fausses. Ajustez en conséquence.

Tâche 4 : Inspecter les erreurs du contrôleur de stockage dans le journal Système

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129 or EventID=153 or EventID=157)]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-StorPort
  Event ID: 129
  ...
  Description: Reset to device, \Device\RaidPort0, was issued.

Signification : L’Event ID 129 est un timeout/réinitialisation Storport. Ce n’est pas « l’application est lente ». C’est la pile de stockage qui hurle.

Décision : Si 129/153/157 apparaissent autour de pics de latence, arrêtez d’ajuster le cache Windows et commencez à investiguer le pilote/firmware et la couche physique (câbles/backplane/PCIe).

Tâche 5 : Vérifier la latence disque et la mise en file avec les compteurs de performance

cr0x@server:~$ typeperf "\PhysicalDisk(*)\Avg. Disk sec/Read" "\PhysicalDisk(*)\Avg. Disk sec/Write" "\PhysicalDisk(*)\Current Disk Queue Length" -sc 3
"(PDH-CSV 4.0)","\\server\PhysicalDisk(0 C:)\Avg. Disk sec/Read","\\server\PhysicalDisk(0 C:)\Avg. Disk sec/Write","\\server\PhysicalDisk(0 C:)\Current Disk Queue Length"
"10.000000","0.003412","0.089532","7.000000"
"10.000000","0.002981","0.102114","9.000000"
"10.000000","0.003105","0.095220","8.000000"

Signification : Les lectures vont bien, les écritures sont ~100 ms, la longueur de file est non triviale. C’est généralement du throttling de périphérique/firmware, cache désactivé, pression de barrières d’écriture ou un contrôleur en détresse.

Décision : Si la latence d’écriture est élevée alors que le CPU est inactif, investiguez la politique de cache d’écriture, le cache du contrôleur et les réinitialisations firmware/driver.

Tâche 6 : Confirmer le comportement TRIM/ReTrim (SSDs) et si Windows considère le disque comme SSD

cr0x@server:~$ fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 0
ReFS DisableDeleteNotify = 0

Signification : 0 signifie que TRIM est activé. Si TRIM est désactivé sur des volumes SSD, la performance d’écriture à long terme peut se dégrader.

Décision : Si vous observez un effondrement d’écriture soutenu sur des semaines/mois, vérifiez TRIM et le comportement de GC du firmware du périphérique.

Tâche 7 : Vérifier le plan d’alimentation qui plafonne silencieusement la performance

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Signification : Le mode Balanced peut être acceptable, mais sur certains serveurs il provoque une mise à l’échelle de fréquence et une variabilité de latence qui ressemble à de la « lenteur aléatoire ».

Décision : Pour des serveurs critiques en performance, passez en High performance (après validation des températures) ou réglez explicitement l’état minimum du processeur.

Tâche 8 : Confirmer que la fréquence CPU n’est pas bloquée basse (limite thermique/alimentation)

cr0x@server:~$ wmic cpu get name, currentclockspeed, maxclockspeed
CurrentClockSpeed  MaxClockSpeed  Name
1896               3500           Intel(R) Xeon(R) Silver ...

Signification : Si la fréquence actuelle est loin du maximum sous charge, vous pouvez être limité par l’alimentation, en throttling thermique ou sur une politique d’alimentation agressive.

Décision : Corrélez avec la charge ; si sous charge elle reste basse, vérifiez les limites d’alimentation BIOS, le refroidissement et les paramètres d’alimentation Windows.

Tâche 9 : Vérifier la présence des périphériques PCIe et les codes de problème

cr0x@server:~$ pnputil /enum-devices /problem /class System
Instance ID: PCI\VEN_8086&DEV_2030&SUBSYS_...
Problem: 0000000A (CM_PROB_FAILED_START)

Signification : Les périphériques avec codes de problème ne sont pas « à moitié fonctionnels ». Ils ne fonctionnent pas. Parfois Windows bascule sur des chemins génériques.

Décision : Réparez l’association pilote et les réglages firmware avant d’optimiser. Vous ne pouvez pas optimiser un périphérique qui n’a pas démarré.

Tâche 10 : Inspecter l’état du lien NIC et la vitesse

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name, Status, LinkSpeed, DriverInformation"
Name   Status  LinkSpeed DriverInformation
Ethernet0 Up   1 Gbps    Intel(R) Ethernet Controller X710 ...

Signification : Si vous attendiez 10/25/40/100GbE et que vous êtes à 1Gbps, arrêtez tout. C’est votre goulot.

Décision : Vérifiez la configuration du port du switch, le câblage/transceiver et les propriétés avancées du NIC. N’accusez pas TCP.

Tâche 11 : Vérifier les fonctionnalités d’offload NIC qui aident ou nuisent

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterAdvancedProperty -Name Ethernet0 | Where-Object {$_.DisplayName -match 'RSS|RSC|LSO|Checksum'} | Select-Object DisplayName, DisplayValue"
DisplayName                 DisplayValue
Receive Side Scaling        Enabled
Receive Segment Coalescing  Enabled
Large Send Offload v2 (IPv4) Enabled
IPv4 Checksum Offload       Rx & Tx Enabled

Signification : Les offloads peuvent réduire le CPU et augmenter le débit, mais ajouter de la latence ou déclencher des cas limites pilote/firmware.

Décision : Si vous avez des pics de latence ou des retransmissions étranges, testez la bascule d’une fonctionnalité à la fois avec un plan de rollback.

Tâche 12 : Rechercher la pression DPC/ISR (goulot classique du pilote)

cr0x@server:~$ typeperf "\Processor(_Total)\% DPC Time" "\Processor(_Total)\% Interrupt Time" -sc 5
"(PDH-CSV 4.0)","\\server\Processor(_Total)\% DPC Time","\\server\Processor(_Total)\% Interrupt Time"
"1.000000","12.482931","6.193847"
"1.000000","14.110332","7.003218"
"1.000000","11.802104","6.552190"
"1.000000","13.224987","6.990114"
"1.000000","12.901443","6.401008"

Signification : Un temps DPC/interruption élevé signifie généralement qu’un pilote impose au CPU trop de travail « d’interruption », privant les threads normaux. Les pilotes réseau et stockage sont des coupables fréquents.

Décision : Si DPC/Interrupt sont constamment élevés sous charge modérée, concentrez-vous sur les versions de pilotes NIC/stockage, la modération des interruptions, la configuration RSS et le firmware.

Tâche 13 : Confirmer le statut VBS/HVCI (fonctionnalités de sécurité qui peuvent modifier la performance)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

Signification : Une sortie non vide indique des services de sécurité (comme Credential Guard et/ou HVCI). Ce n’est pas « mauvais », mais c’est une variable à prendre en compte.

Décision : Si la performance a régressé après un durcissement, testez en environnement contrôlé avec et sans ces fonctionnalités. Ne devinez pas.

Tâche 14 : Vérifier la politique de cache d’écriture du stockage (bouton dangereux, à traiter avec précaution)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, IsWriteCacheEnabled"
FriendlyName        MediaType  BusType IsWriteCacheEnabled
NVMeDisk0           SSD        NVMe    True
SATADisk1           HDD        SATA    False

Signification : Si le cache d’écriture est désactivé sur un périphérique que vous attendez rapide, la latence d’écriture sera mauvaise. S’il est activé sans protection contre la perte d’alimentation, vous pouvez être rapide et faux.

Décision : Changez le cache d’écriture seulement si vous comprenez les exigences de durabilité et la protection contre la perte d’alimentation du matériel. Sinon, vous sacrifiez l’intégrité des données pour la performance.

Tâche 15 : Valider les réinitialisations de périphérique et les erreurs PCIe dans les journaux d’événements

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  ...
  Description: A corrected hardware error has occurred.

Signification : Les erreurs WHEA corrigées indiquent souvent des problèmes de lien PCIe, du matériel marginal ou des problèmes d’intégrité du signal. « Corrigé » coûte toujours en performance et peut annoncer des pannes non corrigées.

Décision : Si WHEA 17/19 corrèle avec des baisses de performance, inspectez l’emboîtement PCIe, le backplane, les risers, les réglages PCIe BIOS et le firmware des périphériques. Ce n’est pas un bug applicatif.

Blague n°2 : La seule chose plus optimiste que « ça va probablement » est « c’est probablement le DNS ».

Trois mini-récits d’entreprise depuis le terrain

1) Incident causé par une fausse hypothèse : « Le BIOS configure la vitesse du NIC, non ? »

Une entreprise de taille moyenne a déployé une nouvelle baie d’hôtes Windows Server pour un service interne sensible à la latence. Le plan de déploiement était propre : matériel identique, profil BIOS identique, installation OS automatisée, puis un test de fumée rapide. Le test de fumée a passé—CPU, mémoire, disque semblaient normaux.

Puis le trafic de production est arrivé. La latence a doublé. Le débit s’est aplati. Les graphiques ressemblaient à un goulot CPU classique, sauf que l’utilisation CPU était étrangement faible. Les gens ont fait ce qu’ils font : ils ont argumenté en rond sur si c’était « l’appli ».

L’hypothèse était que le BIOS « configure le NIC » et donc le NIC devait être bon. Une vérification rapide avec Get-NetAdapter a tout brisé : les NICs avaient négocié à 1Gbps au lieu de la vitesse attendue supérieure. Le profil BIOS était hors sujet ; la négociation de lien se fait entre le NIC et le switch. Certains ports étaient forcés sur une vitesse/duplex inattendue à cause d’un template de switch hérité.

La correction fut ennuyeuse : corriger la configuration des ports du switch, vérifier les transceivers, et confirmer la vitesse de lien sur chaque hôte lors de la mise en service. La leçon n’était pas « équipe réseau en tort ». C’était : le BIOS ne possède pas la négociation de lien. Le pilote rapporte ce que le PHY a négocié, et Windows utilise cette réalité.

Après, ils ont ajouté une validation pré-production : si la vitesse de lien n’est pas celle attendue, on ne déploie pas. Cette vérification a évité une récidive quand la rack suivante est arrivée avec un lot différent de transceivers.

2) Optimisation qui a mal tourné : « Activez tous les offloads, c’est de la performance gratuite »

Une autre organisation avait un pipeline d’ingestion de fichiers Windows « trop consommateur CPU ». Quelqu’un, voulant bien faire, a activé une suite d’offloads NIC sur le parc : large send, coalescence de réception, checksum offloads et quelques améliorations spécifiques fournisseur. L’utilisation CPU a chuté. Tout le monde a célébré. Un ticket a été clos avec un commentaire satisfait et sans plan de mesure de suivi.

Deux semaines plus tard, incident : blocages intermittents et retransmissions, mais seulement sous certains profils de trafic. La supervision montrait des pics périodiques de temps DPC et de latence réseau. Le stockage semblait correct. Les logs applicatifs étaient bruyants mais peu utiles.

La cause racine était une interaction entre une version de pilote spécifique et un offload particulier sous un profil de paquets donné. Ce n’était pas un échec bruyant ; c’était une dégradation. Windows n’était pas « responsable », mais Windows était la scène où l’échec se produisait : pression DPC, traitement retardé et timeouts plus hauts dans la pile.

La correction n’a pas été « désactiver tout pour toujours ». La correction a été : figer les versions de pilote, tester les réglages d’offload sous charge représentative, et déployer progressivement. Ils ont fini par laisser la plupart des offloads activés mais désactiver le problématique, plus planifier une mise à jour pilote/firmware en fenêtre de maintenance.

La morale : les boutons de performance sont comme les épices. Un peu, c’est génial. Vider le bocal et vous regrettez.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Snapshots de baseline avant et après »

Une grande entreprise exécutait des hôtes Windows avec un mix de stockage NVMe et RAID. Ils avaient une pratique qui paraissait douloureusement bureaucratique : chaque changement de plateforme exigeait la capture d’un bundle de baseline — inventaire des pilotes, compteurs perf clés et un court test I/O synthétique. C’était automatisé et stocké avec le ticket de changement.

Un trimestre, un ensemble d’hôtes a commencé à voir des réinitialisations sporadiques Storport (Event ID 129) et des pics de latence d’écriture. La première réaction a été de blâmer la mise à jour cumulative Windows la plus récente. Cette théorie était émotionnellement satisfaisante et techniquement plausible.

Les snapshots baseline ont raccourci le débat. La comparaison « avant » et « après » sur les hôtes affectés montrait : la build Windows était identique entre machines saines et malades, mais la révision du firmware NVMe différait. Un fournisseur avait expédié un nouveau firmware dans un rafraîchissement de chaîne d’approvisionnement, et il se comportait différemment sous pression d’écriture soutenue.

Grâce aux preuves, ils n’ont pas eu à deviner. Ils ont segmenté le parc par révision firmware, confirmé la corrélation, et planifié une remédiation firmware ciblée. En attendant, ils ont ajusté le placement de charge pour réduire la pression sur les nœuds affectés.

La pratique ennuyeuse — baseline consistantes — n’a pas seulement fait gagner du temps. Elle a évité le rollback d’un patch de sécurité qui n’était pas responsable.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le disque est lent » pendant les benchmarks, mais les applis vont bien

Symptôme : Les benchmarks synthétiques disque montrent des résultats incohérents ; les charges réelles ne sont pas manifestement impactées.

Cause racine : Cache du système de fichiers et comportement write-back ; le benchmark mesure la RAM ou le flush de cache, pas le périphérique.

Correctif : Utilisez une méthodologie de test cohérente ; regardez Avg. Disk sec/* et la mise en file, et exécutez des tests qui contournent le cache quand approprié (ou au moins videz entre les runs). Comparez avec les compteurs perf, pas seulement MB/s.

2) Débit réseau plafonné exactement à 1Gbps (ou 10Gbps) sur du matériel « plus rapide »

Symptôme : Le débit atteint un plafond dur ; le CPU est bas ; pas d’erreurs.

Cause racine : Négociation de lien ou profil de port switch incorrect ; câble/transceiver incorrect ; parfois mode forcé du NIC.

Correctif : Vérifiez la vitesse de lien via Get-NetAdapter ; validez la configuration du switch et la couche physique ; évitez de penser « c’est forcément Windows ».

3) Sauts I/O aléatoires avec réinitialisations Storport

Symptôme : Event ID 129 en rafales ; pics de latence ; parfois des « blocages » temporaires.

Cause racine : Temporisations du pilote de stockage, récupération d’erreur firmware, problèmes de signal PCIe, ou cache de contrôleur en difficulté.

Correctif : Corrélez les journaux d’événements avec la latence ; mettez à jour pilote et firmware de façon contrôlée ; inspectez câblage/backplane/riser ; vérifiez les erreurs WHEA corrigées.

4) Performance régressée après un « durcissement de sécurité »

Symptôme : Suralimentation CPU ; latence I/O plus variable ; parfois plus de changements de contexte.

Cause racine : VBS/HVCI/Device Guard modifient le comportement du noyau et les contraintes d’exécution des pilotes ; certains pilotes performent moins bien sous ces contraintes.

Correctif : Mesurez avec et sans fonctionnalités en staging ; mettez à jour les pilotes certifiés pour cette posture de sécurité ; ne désactivez pas la sécurité en production comme première option.

5) CPU semble sous-utilisé mais le système est « lent »

Symptôme : Faible pourcentage CPU, temps de réponse élevé, saccades intermittentes.

Cause racine : Temps DPC/interruption élevé ; tempêtes d’interruptions pilotes ; RSS mal configuré ; interruptions stockage collées sur un seul cœur.

Correctif : Vérifiez % DPC Time et % Interrupt Time ; mettez à jour/ajustez pilotes NIC/stockage ; configurez RSS ; ajustez la modération des interruptions prudemment.

6) NVMe « disque rapide » qui performe comme du SATA

Symptôme : IOPS/débit inférieur attendu ; latence élevée sous charge.

Cause racine : Lien PCIe entraîné en mode bas (x1, Gen1/Gen2) ; throttling thermique ; problèmes d’états d’alimentation.

Correctif : Vérifiez les erreurs WHEA ; contrôlez les réglages PCIe BIOS ; validez le refroidissement ; confirmez le pilote ; validez la performance soutenue plutôt que les courtes rafales.

7) « Le cache du contrôleur RAID le rend rapide » puis frayeur de perte de données

Symptôme : Excellente performance d’écriture jusqu’à un événement d’alimentation ; la récupération prend une éternité ; corruption potentielle.

Cause racine : Cache write-back activé sans protection batterie/flash ; l’OS suppose une durabilité qui n’était pas garantie.

Correctif : Assurez-vous de la présence et de la santé de la protection du cache ; alignez la politique de cache Windows avec les capacités du contrôleur ; ne sacrifiez pas la cohérence des données pour la vitesse sans accord.

Listes de contrôle / plan pas-à-pas

Checklist A : Avant de toucher aux réglages BIOS/UEFI

1. Capturer la version BIOS actuelle (wmic bios) et exporter la configuration BIOS si l’outil du fournisseur le permet.
2. Enregistrer la build Windows et l’inventaire des pilotes (systeminfo, driverquery).
3. Collecter des échantillons de journaux d’événements : Storport, WHEA, et fournisseurs de périphériques pertinents.
4. Exécuter une baseline courte : compteurs latence disque, compteurs DPC/Interrupt, vitesse de lien NIC.
5. Définir le rollback : comment revenir aux paramètres BIOS, comment récupérer si le système ne démarre pas.

Checklist B : Plan de changement pilote contrôlé (la manière sensée)

1. Identifier le pilote chargé et sa version (driverquery /v).
2. Changer un composant à la fois (pilote NIC ou pilote stockage, pas les deux).
3. Déployer sur un petit canari avec une charge représentative.
4. Mesurer : débit, latence, temps DPC/Interrupt, journaux d’événements.
5. Promouvoir progressivement ; garder un package pilote connu bon prêt pour un rollback.

Checklist C : Isolation du goulot stockage en 30 minutes

1. Vérifier les réinitialisations/temporisations Storport (Event 129/153/157).
2. Mesurer Avg. Disk sec/Read, Avg. Disk sec/Write, longueur de file.
3. Vérifier l’état du cache d’écriture (Get-PhysicalDisk) et confirmer les hypothèses de durabilité.
4. Rechercher des erreurs WHEA corrigées aux mêmes moments.
5. Si mismatch firmware/driver entre hôtes, segmenter et comparer.

Checklist D : Isolation du goulot réseau en 30 minutes

1. Confirmer la vitesse de lien négociée (Get-NetAdapter).
2. Mesurer le temps DPC/Interrupt ; corréler avec les baisses de débit.
3. Revoir les réglages d’offload ; comparer avec un hôte connu bon.
4. Vérifier les réinitialisations pilote ou avertissements dans le journal Système.
5. Escalader vers la couche physique (switch/transceivers/câblage) si le lien est incorrect.

FAQ

1) Le BIOS contrôle-t-il ma performance de stockage après le démarrage ?

Généralement pas directement. Le BIOS fixe les conditions initiales (lien PCIe, ACPI, mode contrôleur). Après le démarrage, le pilote de stockage + le firmware du périphérique dominent le comportement.

2) Si je mets à jour un pilote, dois-je aussi mettre à jour le firmware ?

Pas toujours, mais vous devriez considérer pilote et firmware comme un duo pour les périphériques critiques (NIC, HBA, NVMe). Beaucoup de « bugs de pilote » sont en fait des interactions firmware.

3) Pourquoi je vois Event Storport 129 alors que les disques semblent sains ?

Parce que « sain » au sens SMART peut quand même inclure des temporisations et des réinitialisations. L’Event 129 concerne des temporisations I/O et la récupération, qui peuvent survenir avec des liens PCIe marginaux, des blocages firmware ou des problèmes pilotes.

4) Le pilote inbox Microsoft est-il mauvais ?

Non. Les pilotes inbox sont souvent stables et solides. Mais les pilotes fournisseur peuvent exposer du tuning, des offloads ou de la télémétrie dont vous avez besoin. Utilisez le pilote qui correspond à vos besoins et testez-le.

5) Les paramètres d’alimentation Windows peuvent-ils vraiment impacter la performance serveur ?

Oui. Les plans d’alimentation et les politiques d’inactivité des périphériques influencent la fréquence CPU et parfois les états PCIe. Si vous avez besoin d’une latence prévisible, validez explicitement votre configuration d’alimentation.

6) Comment savoir si je suis limité par les interruptions ?

Vérifiez % DPC Time et % Interrupt Time avec typeperf. S’ils sont élevés et corrèlent avec des problèmes de débit ou de latence, un pilote est souvent le goulot.

7) Pourquoi la performance diffère-t-elle entre des serveurs « identiques » ?

Parce qu’ils sont rarement identiques : révisions firmware différentes, versions pilotes différentes, câblage de slot PCIe différent, valeurs BIOS par défaut différentes, ports switch différents ou environnements thermiques différents.

8) Dois-je changer les réglages BIOS pendant un incident ?

Seulement si vous pouvez expliquer la chaîne causale et avez un plan de rollback. Sinon, collectez des preuves d’abord et planifiez les changements firmware en fenêtre de maintenance.

9) Comment éviter d’être trompé par le cache dans les tests disque ?

Surveillez les compteurs de latence et la mise en file, pas seulement le débit. Utilisez des tailles de test cohérentes et répétez les runs. Considérez les résultats « trop beaux pour être vrais » comme suspects jusqu’à preuve du contraire.

Prochaines étapes à réaliser cette semaine

Cessez de traiter « BIOS vs pilote vs Windows » comme un débat philosophique. C’est un problème de frontières de contrôle. Les équipes les plus rapides gagnent en prouvant quelle couche possède le symptôme, puis en faisant un changement réversible à la fois.

1. Automatisez un bundle baseline : version BIOS, build Windows, pilotes chargés, vitesse lien NIC, compteurs perf clés et extraits de journaux d’événements.
2. Ajoutez deux contrôles de mise en service pour chaque nouvel hôte : vitesse de lien NIC attendue et absence d’inondation d’erreurs WHEA corrigées.
3. Construisez une matrice pilote/firmware pour les périphériques critiques et figez les versions. « Latest » n’est pas une stratégie ; c’est de l’espoir.
4. Exercez la méthode de diagnostic rapide sur un système sain pour ne pas apprendre les commandes pendant un incident.

Si vous ne faites rien d’autre : faites de l’inventaire des pilotes chargés et des vérifications de journaux d’événements votre réflexe de première réponse. La plupart des « mystères matériels » deviennent très ordinaires quand vous regardez ce qui se passe réellement.