Écran bleu tcpip.sys : les solutions

Un écran bleu qui désigne tcpip.sys vient presque toujours d’un autre module que lui : le pilote de la carte réseau, un VPN, ou un filtre installé par une suite de sécurité. Le fichier tcpip.sys est le pilote TCP/IP de Windows, et il se contente le plus souvent de tomber avec le composant qui lui passe une mauvaise adresse mémoire.

Points clés

• Le code d’arrêt associé est en général DRIVER_IRQL_NOT_LESS_OR_EQUAL, valeur 0x000000D1.
• Ce code signifie qu’un pilote en mode noyau a tenté d’accéder à de la mémoire paginée à un niveau IRQL trop élevé.
• Le module nommé sur l’écran bleu n’est pas forcément le coupable. Le vidage mémoire, lui, nomme la pile d’appel complète.
• Trois suspects couvrent la majorité des cas : pilote Wi-Fi ou Ethernet, client VPN, filtre réseau d’un antivirus.
• La réinitialisation de la pile réseau se fait avec netsh winsock reset et netsh int ip reset, suivies d’un redémarrage.

Le rôle de tcpip.sys

tcpip.sys implémente les protocoles TCP/IP au coeur du noyau Windows. Chaque paquet reçu par la carte réseau traverse ce pilote, et chaque logiciel qui veut inspecter, filtrer ou rediriger le trafic vient s’y greffer par une couche intermédiaire. Cette position en fait un point de passage obligé, donc une victime fréquente.

La conséquence pratique est simple. Remplacer tcpip.sys n’a aucun sens, puisqu’il fait partie de Windows. Le travail consiste à retirer ou à mettre à jour ce qui s’est branché dessus.

Les causes classiques

• Pilote de carte réseau obsolète ou générique, en particulier sur les puces Wi-Fi Realtek, Intel et Killer installées par Windows Update plutôt que par le fabricant.
• Client VPN qui installe un adaptateur virtuel et un pilote de filtrage propre.
• Pare-feu ou antivirus tiers qui inspecte le trafic au niveau noyau.
• Adaptateur USB vers Ethernet alimenté par un pilote ancien.
• Mémoire vive défectueuse, qui provoque des accès mémoire invalides sans rapport direct avec le réseau.
• Surcharge de trafic sur une machine virtualisée dont les pilotes réseau synthétiques ne sont pas à jour.

Lire correctement le code d’arrêt

La documentation Microsoft décrit le code 0xD1 par quatre paramètres : l’adresse mémoire référencée, l’IRQL au moment de l’accès, le type d’opération, et l’adresse de l’instruction fautive. Ces valeurs figurent dans le fichier de vidage écrit dans C:\Windows\Minidump. Ouvert avec WinDbg, la commande !analyze -v affiche la ligne « Probably caused by », qui pointe souvent vers un pilote tiers alors que l’écran bleu affichait tcpip.sys.

Quand le vidage nomme un fichier .sys inconnu, la recherche de ce nom exact suffit à identifier le périphérique ou le logiciel à traiter. Le même raisonnement s’applique au pilote de couche inférieure décrit dans notre article sur l’écran bleu ndis.sys.

Les solutions, de la moins risquée à la plus lourde

1. Retirer le dernier élément réseau installé

VPN, antivirus avec module de protection web, utilitaire de partage de connexion, pilote d’adaptateur USB. Le composant installé juste avant l’apparition des plantages part en premier, avec son désinstalleur officiel. Un simple arrêt du service ne retire pas le pilote de filtrage du noyau.

2. Installer le pilote réseau du fabricant

Le pilote doit venir du site du fabricant de l’ordinateur portable ou de la carte mère, à défaut du fondeur de la puce Wi-Fi. Avant d’installer, désinstaller l’ancien depuis le Gestionnaire de périphériques en cochant la suppression du logiciel du pilote. Cette étape corrige à elle seule une grande partie des cas.

3. Réinitialiser la pile réseau

Dans une invite de commandes en administrateur, exécuter successivement netsh winsock reset, netsh int ip reset, ipconfig /release puis ipconfig /renew, et redémarrer. La réinitialisation du catalogue Winsock supprime les couches de service personnalisées laissées par des logiciels désinstallés à moitié. La procédure complète est détaillée dans notre article netsh winsock reset.

4. Désactiver temporairement les fonctions de déchargement de la carte

Dans les propriétés avancées de l’adaptateur, les options de déchargement matériel et la mise à l’échelle côté réception déplacent une partie du traitement des paquets vers la carte. Sur du matériel ancien ou mal piloté, leur désactivation stabilise le système. C’est un test de diagnostic, pas une solution définitive : le réglage se remet en place une fois le bon pilote installé.

5. Tester la mémoire vive

Un accès mémoire invalide peut être matériel. L’outil Diagnostic de mémoire Windows, lancé par mdsched.exe, fait une première passe. Un test plus long avec un outil dédié reste préférable quand les plantages touchent plusieurs modules différents, et pas seulement le réseau.

6. Isoler le pilote fautif avec le Vérificateur de pilotes

Le Vérificateur de pilotes de Windows force un écran bleu dès qu’un pilote surveillé commet une faute, ce qui nomme le coupable au lieu de le laisser se cacher derrière tcpip.sys. L’outil est réservé aux machines de test parce qu’il provoque volontairement des blocages, et il se désactive par verifier /reset. La marche à suivre est décrite dans notre article sur l’écran bleu DRIVER_IRQL_NOT_LESS_OR_EQUAL.

7. Réparer les fichiers système

sfc /scannow puis DISM /Online /Cleanup-Image /RestoreHealth restaurent une copie saine de tcpip.sys si le fichier a réellement été altéré. Ce scénario est rare, mais il coûte peu à écarter.

8. Réinitialiser le réseau, puis Windows

La réinitialisation réseau des paramètres Windows réinstalle tous les adaptateurs et remet leurs réglages par défaut. Elle supprime aussi les profils VPN et les mots de passe Wi-Fi enregistrés. Si les plantages survivent à cette étape et qu’aucun pilote tiers n’est en cause, la réinstallation de Windows devient l’option suivante, avec sauvegarde préalable.

Quand ça ne vient pas du réseau

Un écran bleu tcpip.sys qui se produit machine au repos, sans trafic, sort du cadre habituel. Mémoire défaillante, surchauffe, alimentation instable ou surcadençage trop optimiste produisent des plantages qui désignent au hasard le module actif à l’instant du crash. Le guide des écrans bleus Windows 10 et 11 détaille cette bascule entre piste logicielle et piste matérielle.

Questions fréquentes

Peut-on remplacer le fichier tcpip.sys par celui d’un autre PC ?

Non. Le fichier appartient à une version précise de Windows et il est protégé par le système. La bonne méthode passe par DISM et sfc, qui restaurent la version correspondant à l’installation en cours.

Le plantage arrive surtout en jeu en ligne, est-ce normal ?

C’est cohérent avec la cause la plus fréquente. Le trafic soutenu d’un jeu multijoueur sollicite le pilote réseau bien plus qu’une navigation web, et fait ressortir un défaut qui reste invisible au repos.

Faut-il désactiver l’IPv6 ?

Désactiver IPv6 masque parfois le symptôme, sans corriger le pilote défectueux, et casse des services qui en dépendent. Mieux vaut traiter le pilote et laisser la configuration par défaut.

Où trouver les fichiers de vidage à analyser ?

Dans C:\Windows\Minidump pour les petits vidages, et C:\Windows\MEMORY.DMP pour le vidage complet. Ils s’ouvrent avec WinDbg, disponible gratuitement chez Microsoft.

Un antivirus peut-il vraiment provoquer un écran bleu ?

Oui, dès lors qu’il installe un pilote de filtrage réseau en mode noyau. C’est précisément le type de composant qui vient se placer au contact de tcpip.sys.

_{Photo d’en-tête : Harke, domaine public, via Wikimedia Commons. La photo montre une carte réseau PCI, illustration du matériel concerné et non du message d’erreur.
Sources : Microsoft Learn, vérification de bogue 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL ; Microsoft Learn, analyser les données d’un code d’arrêt ; Microsoft Learn, netsh winsock ; Microsoft Support, résoudre les problèmes de connexion Ethernet ; Microsoft Learn, Vérificateur de pilotes.}