Votre serveur Windows Server 2012 R2 redémarre sans prévenir avec un BSOD mentionnant NETIO.SYS ? Voici un guide opérationnel, concret et vérifiable pour diagnostiquer, stabiliser et corriger ces redémarrages aléatoires, avec commandes et check‑lists prêtes à l’emploi.
Vue d’ensemble du problème
Vous observez des arrêts brutaux et redémarrages aléatoires (par exemple, trois coupures en onze jours). Les mini‑dumps indiquent NETIO.SYS comme module fautif. NETIO.SYS est un composant du noyau Windows chargé de la pile réseau (NDIS, filtres, offloads, pare‑feu, etc.). Quand il plante, la cause première est souvent un pilote tiers ou une fonctionnalité avancée de la carte réseau qui interagit mal avec la pile réseau.
Symptômes typiques et ce qu’ils révèlent
| Symptôme / Indice | Interprétation probable | Que vérifier d’abord |
|---|---|---|
| BSOD avec NETIO.SYS dans le mini‑dump | Conflit pilote réseau, filtre NDIS, offload agressif | Version du pilote NIC, filtres antivirus/IDS, offloads (LSO/RSS/VMQ) |
| Événements Kernel‑Power 41 et BugCheck 1001 | Arrêt inattendu après BSOD | Journaux Système et minidumps (C:\Windows\Minidump) |
| Crashs sous forte charge réseau (sauvegarde, réplication, VM) | Fonctions avancées NIC (RSS/VMQ/LSO), firmware obsolète | Mises à jour NIC/BIOS/firmware, désactivation temporaire des offloads |
| Installation récente d’un antivirus/agent EDR/VPN | Filtre réseau tiers instable | Mise à jour ou retrait du filtre, test A/B avec filtre désactivé |
| Erreurs disque (ID 7/51/153) ou mémoire suspects | Entrées/sorties dégradées provoquant des délais noyau | chkdsk, outils constructeur disque, test RAM approfondi |
Plan d’action rapide
Si le serveur est en production, commencez par un plan d’action minimal (faible risque, fort impact) puis validez :
- Appliquez les mises à jour Windows disponibles (y compris ESU le cas échéant) et redémarrez en fenêtre de maintenance.
- Mettez à jour le pilote de la carte réseau et, si possible, le firmware NIC et le BIOS.
- Désactivez temporairement les fonctions réseau avancées (RSS/LSO/VMQ) pour tester la stabilité.
- Contrôlez les filtres réseau tiers (antivirus/EDR/VPN) : mise à jour ou retrait temporaire du module de filtrage.
- Surveillez les événements 41/1001 et l’absence de nouveaux dumps pendant au moins 72 h.
Réponse & solutions proposées
Voici la séquence recommandée, à exécuter dans l’ordre.
| Étape | Objectif | Commande / Action | Détails clés |
|---|---|---|---|
| 1 | Vérifier l’intégrité système | sfc /scannow | Répare automatiquement les fichiers système corrompus. |
| 2 | Examiner et restaurer l’image Windows | DISM /Online /Cleanup-Image /CheckHealth → /ScanHealth → /RestoreHealth | Détecte et corrige des corruptions plus profondes dans l’image du système. |
| 3 | Mettre à jour le pilote réseau | Gestionnaire de périphériques → Adaptateurs réseau → clic droit → Mettre à jour | Choisir la recherche automatique ou installer manuellement la version constructeur validée. |
| 4 | Réinstaller le pilote réseau | Gestionnaire de périphériques → Désinstaller → redémarrer | Windows pose un pilote générique ; tester, puis remettre le pilote constructeur à jour. |
| 5 | Vérifier le journal d’événements | eventvwr.msc → Journaux Windows / Système | Rechercher Kernel‑Power 41, BugCheck 1001, avertissements NDIS/NDProxy juste avant l’arrêt. |
| 6 | Mettre à jour le firmware/NIC et le BIOS | Outils / paquets du fabricant | Un microcode/firmware obsolète est une cause classique d’incompatibilités réseau. |
| 7 | Installer les correctifs Windows récents | Windows Update / WSUS | Les correctifs de pile réseau publiés après 2012 R2 ont réduit les BSOD liés à NETIO.SYS. |
| 8 | Contrôler les logiciels tiers | Antivirus, pare‑feu, NIDS | Désactiver ou mettre à jour les filtres réseau tiers susceptibles d’intercepter le trafic. |
Détails d’exécution et commandes utiles
Intégrité système : SFC et DISM
Exécutez en invite admin :
sfc /scannow
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
Interprétez le résultat : si SFC a réparé des fichiers, redémarrez et vérifiez la stabilité avant de poursuivre.
État et options de la pile TCP
netsh int tcp show global
Gardez un cliché avant tout changement. Sur 2012 R2, l’équilibre par défaut convient, mais certaines optimisations historiques peuvent poser problème avec des pilotes NIC anciens.
Mise à jour / réinstallation du pilote réseau
Vérifiez la version et la date des pilotes réseau installés :
Get-NetAdapter | Format-List Name, InterfaceDescription, DriverInformation
Après mise à jour, redémarrez. Si les crashs persistent, désinstallez le pilote depuis le Gestionnaire de périphériques (avec suppression du package si proposé), redémarrez pour charger un pilote générique, testez, puis réinstallez le pilote constructeur certifié.
Désactivation ciblée des fonctions réseau avancées
Pour lever le doute sur un offload défaillant, désactivez temporairement :
# RSS (Receive Side Scaling)
Disable-NetAdapterRss -Name "*"
# Large Send Offload (IPv4/IPv6)
Disable-NetAdapterLso -Name "*" -IPv4 -IPv6
# Checksum Offload
Disable-NetAdapterChecksumOffload -Name "*"
# VMQ (utile si Hyper‑V et NIC 1 GbE)
Set-NetAdapterVmq -Name "*" -Enabled $false Si la stabilité revient, réactivez les options une par une pour identifier le coupable, puis laissez la configuration la plus stable en production.
Inspection des filtres réseau tiers
Listez les composants réseau (dont filtres NDIS) :
netcfg -s n
Les agents antivirus/EDR, IDS/NIDS, VPN et solutions de capture peuvent insérer des pilotes de filtrage. Mettez‑les à jour, désactivez temporairement le module de filtrage, ou planifiez un test sans l’agent pour confirmer.
Analyse des mini‑dumps
Utilisez WinDbg (ou WhoCrashed pour un aperçu) :
# Ouvrir un dump
windbg -z C:\Windows\Minidump\<dump.dmp>
# Simplifier la configuration des symboles
.symfix
.reload
# Analyse
!analyze -v
# Inventaire des modules chargés autour du crash
lm
# Option : regarder la pile en remontant vers un pilote tiers
kv Dans !analyze -v, repérez : MODULE_NAME, IMAGE_NAME (NETIO.SYS), et surtout si un pilote tiers apparaît juste avant l’appel fautif. Les codes de bugcheck fréquents associés à NETIO.SYS sont 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL, 0x3B SYSTEM_SERVICE_EXCEPTION, 0x1E KMODE_EXCEPTION_NOT_HANDLED ou 0x50 PAGE_FAULT_IN_NONPAGED_AREA. Ces codes orientent vers un défaut de pilote ou de mémoire.
Vérifier journaux et fiabilité
Outils essentiels :
- Observateur d’événements (
eventvwr.msc) → Journaux Windows / Système. Filtrez sur 41 et 1001, inspectez NDIS, Tcpip, NetBT, e1iexpress/ixgbe/… selon votre NIC. - Moniteur de fiabilité (
perfmon /rel) pour une frise chronologique claire des défaillances. - Commande rapide :
wevtutil qe System /q:"*[System[(EventID=41 or EventID=1001)]]" /f:text /c:10
Tests mémoire et stockage
Même si NETIO.SYS est en cause, une mémoire instable ou un stockage dégradé peut amplifier le problème :
# Planifier un test mémoire (au prochain reboot)
mdsched.exe
# Vérifier et réparer le disque système (prévoir redémarrage)
chkdsk C: /f /r </code></pre>
<p>Complétez avec l’outil constructeur du disque pour détecter des secteurs instables et un firmware disque obsolète.</p>
<h3>Mettre à jour le firmware NIC et le BIOS</h3>
<p>Sur des serveurs physiques, un firmware NIC/UEFI ancien est un facteur aggravant. Appliquez la dernière révision validée par le constructeur (pack de firmware, iLO/iDRAC/IMM, etc.). Sur VM, vérifiez les <em>Integration Services</em> et la version des <em>VM Tools</em> selon l’hyperviseur.</p>
<h3>Correctifs Windows et support étendu</h3>
<p>Windows Server 2012 R2 est en fin de support classique ; assurez‑vous d’avoir appliqué <em>tous</em> les correctifs encore proposés (WSUS, ESU/Arc si éligible). Les mises à jour cumulatives historiques incluent des correctifs de la pile réseau qui réduisent les BSOD liés à <code>NETIO.SYS</code>.</p>
<h3>Driver Verifier : à manier avec précaution</h3>
<p>Si le coupable n’est pas identifié, <strong>Driver Verifier</strong> peut forcer la mise en défaut d’un pilote tiers instable :</p>
<pre><code>verifier.exe /standard /driver <NomPiloteSuspect.sys>
</code></pre>
<p>Conseils : activez‑le uniquement en fenêtre de maintenance, sur une courte période, et <em>jamais</em> sans sauvegarde/point de restauration ; il peut dégrader les performances et provoquer des BSOD plus fréquents (c’est attendu).</p>
<h2>Procédures spécifiques selon le rôle du serveur</h2>
<h3>Serveur Hyper‑V</h3>
<ul>
<li>Désactivez <strong>VMQ</strong> si vos NIC sont 1 GbE ; conservez‑le sur 10/25/40 GbE :</li>
</ul>
<pre><code>Set-NetAdapterVmq -Name "*" -Enabled $false
</code></pre>
<ul>
<li>Vérifiez <em>SR‑IOV</em> et <em>vRSS</em> selon la génération de vos pilotes et VM.</li>
</ul>
<h3>Serveur de fichiers / sauvegarde</h3>
<ul>
<li>Testez avec <strong>LSO</strong>, <strong>RSS</strong> désactivés durant une fenêtre de sauvegarde.</li>
<li>Surveillez le taux d’erreurs NIC (paquets abandonnés / corrections).</li>
</ul>
<h3>Serveur applicatif avec agent de sécurité</h3>
<ul>
<li>Mettez l’agent à la dernière version, sinon désactivez le module de filtrage réseau pour un test contrôlé.</li>
<li>Ajoutez des exclusions réseau/chemins recommandés par l’éditeur.</li>
</ul>
<h2>Checklist de diagnostic et de stabilisation</h2>
<ul>
<li>Avant : notez la dernière heure de redémarrage (<code>systeminfo</code> ou <code>Get-CimInstance Win32_OperatingSystem</code>).</li>
<li>Appliquez SFC/DISM, mettez à jour NIC/firmware/BIOS, puis redémarrez.</li>
<li>Désactivez temporairement RSS/LSO/VMQ et comparez.</li>
<li>Examinez minidumps avec <code>!analyze -v</code>, repérez un pilote tiers.</li>
<li>Testez sans filtre réseau tiers (antivirus/EDR/VPN) — en environnement maîtrisé.</li>
<li>Validez 72 h sans BSOD, puis réactivez progressivement les fonctions nécessaires.</li>
<li>Documentez la configuration stable (versions pilotes, offloads actifs, correctifs).</li>
</ul>
<h2>Indicateurs de succès</h2>
<table>
<thead>
<tr>
<th>Indicateur</th>
<th>Cible</th>
<th>Comment mesurer</th>
</tr>
</thead>
<tbody>
<tr>
<td>Absence de BugCheck 1001</td>
<td>0 événement en 7 à 30 jours</td>
<td>Observateur d’événements, Moniteur de fiabilité</td>
</tr>
<tr>
<td>Uptime serveur</td>
<td>> 30 jours</td>
<td><code>Get-CimInstance Win32_OperatingSystem</code></td>
</tr>
<tr>
<td>Stabilité des sauvegardes/replications</td>
<td>100 % réussies</td>
<td>Rapports sauvegarde, journaux applicatifs</td>
</tr>
</tbody>
</table>
<h2>Conseils supplémentaires</h2>
<ul>
<li><strong>Analyser le mini‑dump</strong> : valider que <code>NETIO.SYS</code> est bien en tête de pile et identifier un pilote tiers juste avant l’appel.</li>
<li><strong>Tester la mémoire et le stockage</strong> : vous avez passé l’outil mémoire ; complétez par <code>chkdsk /f /r</code> et un utilitaire constructeur disque.</li>
<li><strong>Désactiver brièvement les fonctions réseau avancées</strong> : RSS, LSO, VMQ — si la stabilité revient, réactivez‑les de façon sélective.</li>
<li><strong>Plan de continuité</strong> : pour un serveur critique, prévoyez basculement/cluster afin de réduire l’impact business pendant les tests.</li>
</ul>
<h2>Foire aux questions</h2>
<p><strong>Le problème vient‑il forcément de Windows ?</strong><br>
Pas forcément. <code>NETIO.SYS</code> est le lieu du crash, pas nécessairement la cause. Les responsables sont souvent des <em>pilotes tiers</em> ou un <em>firmware NIC</em> ancien.</p>
<p><strong>Puis‑je laisser RSS/LSO/VMQ désactivés en permanence ?</strong><br>
Oui si c’est la configuration la plus stable et que l’impact performance reste acceptable pour votre charge. Sur des liens > 10 Gb/s, préférez corriger le pilote/firmware pour conserver ces optimisations.</p>
<p><strong>Faut‑il désinstaller l’antivirus ?</strong><br>
Non par défaut. Ciblez le <em>module réseau</em> (filtre) : mise à jour, désactivation temporaire, ou reconfiguration. Maintenez la protection en couches (analyse à l’accès, exclusions raisonnables).</p>
<p><strong>Dois‑je activer Driver Verifier en production ?</strong><br>
Seulement en fenêtre de maintenance, durée limitée, et avec sauvegarde complète. Son but est de <em>provoquer</em> un crash explicite du pilote instable pour l’identifier.</p>
<h2>Exemples de scripts d’observation</h2>
<p>Extraire rapidement les 20 derniers événements critique/erreur réseau et bugcheck :</p>
<pre><code>$ids = 41, 1001, 10400, 10401, 10402
Get-WinEvent -LogName System | Where-Object { $ids -contains $_.Id } | Select-Object TimeCreated, Id, ProviderName, Message | Format-List
</code></pre>
<p>Lister les propriétés avancées NIC pour comparer les serveurs jumeaux :</p>
<pre><code>Get-NetAdapter | ForEach-Object {
$name = $_.Name
Get-NetAdapterAdvancedProperty -Name $name | Select-Object @{n="Adapter";e={$name}}, DisplayName, DisplayValue
}
</code></pre>
<h2>Procédure de retour arrière</h2>
<p>Si une mise à jour aggrave la situation :</p>
<ol>
<li>Démarrez en <em>Mode sans échec</em> avec réseau, puis restaurez l’ancien pilote via <em>Gestionnaire de périphériques</em>.</li>
<li>Réactivez la configuration précédente des offloads :
<pre><code>Enable-NetAdapterRss -Name "*"
Enable-NetAdapterLso -Name "*" -IPv4 -IPv6
Enable-NetAdapterChecksumOffload -Name "*"
Set-NetAdapterVmq -Name "*" -Enabled $true
Revenez au correctif Windows antérieur si nécessaire (dans un créneau contrôlé et avec sauvegarde).
Validation finale et documentation
- Conservez captures de version (pilote, firmware, BIOS, build Windows).
- Enregistrez la configuration réseau stable (offloads activés/désactivés, RSS queues, VMQ, jumbo frames le cas échéant).
- Planifiez un post‑mortem court : cause probable, correctif appliqué, leçons apprises, actions préventives (maintien des versions, fenêtres de patch régulières).
Conclusion
La plupart des redémarrages NETIO.SYS sur Windows Server 2012 R2 se résolvent par une mise à jour ou une réinstallation propre du pilote réseau couplée à l’application des correctifs Windows encore disponibles. Ajoutez à cela un contrôle des filtres réseau tiers et une désactivation temporaire des offloads pour isoler l’origine : vous obtiendrez une plateforme stable et prédictible.