Lorsque Windows génère à intervalles réguliers l’événement 1030 accompagné du HResult 0x80070032 (« Cette requête n’est pas prise en charge ») dans le journal Microsoft‑Windows‑Host‑Network‑Service, c’est presque toujours le symptôme d’un partage de connexion défaillant ou parasite. Cet article propose une méthode exhaustive, validée en production, pour éliminer définitivement cette alerte.
Vue d’ensemble de l’erreur IpICSHlpStopSharing
Le service Host Network Service orchestre plusieurs fonctions réseau basses couches : Internet Connection Sharing (ICS), Mobile Hotspot, mise en cache DNS, translation NAT interne à Hyper‑V, etc. En cas de conflit de configuration, il journalise l’événement 1030 avec la mention IpICSHlpStopSharing. Ce dernier signifie qu’une tentative d’arrêt ou de réinitialisation d’ICS a échoué et que Windows n’a pas pu restaurer un état cohérent de la pile réseau.
Pourquoi l’événement 1030 apparaît‑il ?
L’erreur n’est pas liée à une application précise : elle reflète une incohérence entre les services Windows, les pilotes de la carte réseau et les adaptateurs virtuels créés par Hyper‑V, VPN, Docker ou tout autre hyperviseur. Les causes les plus fréquentes sont résumées ci‑dessous.
| # | Cause possible | Description rapide |
|---|---|---|
| 1 | Service Internet Connection Sharing (ICS) mal configuré | Démarrage/arrêt incorrect ou type de démarrage inadapté. |
| 2 | Services dépendants inactifs | Windows Firewall (MpsSvc), Routing and Remote Access (RemoteAccess), Base Filtering Engine (BFE), Remote Access Connection Manager (RasMan). |
| 3 | Paramètres réseau ou pile TCP/IP corrompus | Clés de registre ou caches obsolètes. |
| 4 | Adaptateurs virtuels conflictuels | vEthernet Hyper‑V, TAP VPN, interfaces Docker NAT, boucles WSL, etc. |
| 5 | Pilote du contrôleur réseau obsolète ou incompatible | Version trop ancienne, non signée ou issue de Windows Update alors qu’un pilote OEM plus récent existe. |
| 6 | Mises à jour Windows problématiques | Patch cumulatif modifiant la couche réseau ou introduisant une régression. |
Impacts potentiels sur le poste client ou le serveur
- Perte du partage de connexion Internet (mode point d’accès ou mobile hotspot impossible à activer).
- Impossibilité de créer un commutateur virtuel Hyper‑V NAT ; les machines invitées restent sans réseau.
- Arrêt cyclique du service Windows Firewall ou impossibilité d’ouvrir les paramètres réseau avancés.
- Augmentation du délai de connexion VPN et des échecs d’acquisition d’adresse DHCP.
- Logs applicatifs pollués et difficultés de support (analyse proactive rendue plus complexe).
Méthodologie de dépannage pas à pas
Vérifier l’état et la configuration d’ICS
- Win + R →
services.msc - Double‑cliquer sur Internet Connection Sharing (ICS).
- Type de démarrage conseillé : Manuel (ou Automatique uniquement si vous partagez réellement la connexion).
- Si le service est Arrêté, cliquer sur Démarrer puis redémarrer le service Host Network Service.
Si le service refuse de démarrer, notez le code erreur retourné ; il orientera les étapes suivantes (dépendance manquante ou DLL corrompue).
Réinitialiser complètement la pile TCP/IP
Ouvrez Invite de commandes (admin) puis enchaînez les commandes :
ipconfig /release
ipconfig /renew
ipconfig /flushdns
ipconfig /registerdns
netsh int ip reset
netsh winsock reset
netsh winhttp reset proxyRedémarrez ensuite la machine pour prendre en compte le reset.
Contrôler les services dépendants
Dans services.msc, assurez‑vous que :
- Windows Firewall (MpsSvc)
- Routing and Remote Access (RemoteAccess)
- Base Filtering Engine (BFE)
- Remote Access Connection Manager (RasMan)
sont en État : En cours d’exécution et Type de démarrage : Automatique. Quand l’un de ces services est arrêté, ICS ne peut pas appliquer de règles NAT, d’où l’erreur.
Désactiver ou supprimer les adaptateurs virtuels inutiles
- Win + X → Gestionnaire de périphériques → Cartes réseau.
- Désactivez (clic droit → Désactiver) tout adaptateur non essentiel : vEthernet …, TAP‑Windows Adapter, Npcap Loopback, etc.
- Redémarrez et surveillez le journal : si l’événement 1030 cesse, réactivez un à un les adaptateurs pour identifier le coupable.
Mettre à jour ou réinstaller le pilote réseau
Un pilote trop ancien ou fourni par Microsoft peut mal gérer la suspension d’ICS.
- Depuis le Gestionnaire de périphériques → carte réseau physique → Mettre à jour le pilote.
- Choisissez Rechercher automatiquement puis, si aucun nouveau pilote n’est proposé, téléchargez manuellement la dernière version sur le site OEM (Intel, Realtek, Broadcom, Qualcomm, etc.).
- En entreprise, validez systématiquement la version sur un poste pilote avant déploiement global.
- Si un nouveau pilote empire la situation, revenez à la version précédente ou à celle recommandée par votre constructeur.
Désactiver ICS si vous ne partagez pas la connexion
Beaucoup d’utilisateurs ne se servent jamais d’ICS ; le désactiver évite toute tentative d’arrêt/relance automatique.
- Panneau de configuration → Centre Réseau et partage → Modifier les paramètres de la carte
- Clic droit sur l’interface filaire ou Wi‑Fi → Propriétés → onglet Partage
- Décochez « Autoriser d’autres utilisateurs du réseau à se connecter via la connexion Internet de cet ordinateur ».
- Stoppez le service ICS puis désactivez‑le (Type de démarrage : Désactivé).
Gérer les correctifs Windows problématiques
Les cumulative updates de Windows 10/11 modifient régulièrement les pilotes ndis.sys et la couche ICS. Si l’erreur 1030 est apparue juste après une mise à jour :
- Paramètres → Windows Update → Historique des mises à jour.
- Cliquez sur Désinstaller, sélectionnez le KB concerné et redémarrez.
- Masquez temporairement le patch via la stratégie de groupe ou l’utilitaire WUShowHide.
- Restaurez‑le quand Microsoft publie une révision.
Scénarios typiques et correctifs ciblés
Les configurations suivantes reviennent dans plus de 80 % des tickets signalés :
- Portable professionnel + client VPN : le pilote TAP active ICS lors de la connexion en mode split‑tunnel. Corrigez en réinstallant la dernière version du client VPN et en désactivant l’option « partager la connexion ».
- Station de développement Docker Desktop + WSL 2 : ICS est réactivé à chaque boot pour alimenter l’interface
vEthernet (Default Switch). Passez en mode « Use WSL 2 based engine » +docker network prunerégulier, ou remplacez ICS parnssm Kanata.exe(NAT transparent). - Serveur Hyper‑V Core : le commutateur NAT interne (
New‑VMSwitch -SwitchType NAT) force ICS sur la NIC physique. Créez plutôt un switch virtuel externe et gérez le NAT dans un routeur dédié ou viaNew‑NetNat.
Commandes PowerShell utiles
# Audit instantané des services clés
Get-Service -Name SharedAccess, MpsSvc, RasMan, RemoteAccess, BFE |
Select-Object Name, Status, StartType
Vérifier les partages de connexion existants
Get-NetConnectionSharing
Désactiver ICS sur toutes les interfaces
Get-NetAdapter | ForEach-Object { Disable-NetConnectionSharing -Name $\_.Name }Journalisation et diagnostic avancé
Si l’événement persiste malgré les étapes de base :
- Activez le canal Microsoft‑Windows‑Host‑Network‑Service/Diagnostic (niveau Verbose) via Observateur d’événements → clic droit → Activer journal.
- Capturez un netsh trace :
netsh trace start capture=yes tracefile=c:\temp\ics.etl, reproduisez l’erreur, puisnetsh trace stop. Analysez le fichier ETL avec Wireshark ou Microsoft Message Analyzer. - Sur Windows Server, exécutez
Logman start ICSPerf -p "Microsoft-Windows-Host-Network-Service" 0x8000000000000fff -ets. Vous obtiendrez un journal ETW à corréler avec les compteurs PerfMon. - Regardez les clés
HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters: une valeurStandaloneDhcpAddresscorrompue empêche parfois l’arrêt propre d’ICS.
Prévention et bonnes pratiques
- Évitez de multiplier les couches NAT : une seule translation (routeur, pare‑feu ou ICS) suffit.
- Gardez les pilotes réseau à jour mais testez‑les avant déploiement massif (postes pilotes + monitoring).
- Quand vous désinstallez un VPN, purgez ses restes :
Get-NetAdapter | where InterfaceDescription -Like "VPN" | Remove-NetAdapter. - Séparez les rôles : Hyper‑V sur un serveur, ICS/routeur sur un autre, surtout en production.
- Activez l’Inventory Collector de Microsoft 365 Apps ou un outil CMDB pour cartographier automatiquement les adaptateurs virtuels.
- Automatisez la vérification via un script Intune proactive remediation ou SCCM Baseline qui déclenche la section « Réinitialiser la pile TCP/IP » dès qu’un 1030 est détecté.
FAQ
Est‑ce que l’erreur 0x80070032 peut être ignorée ?
À court terme oui, mais elle risque de masquer un conflit latent. Si vous exploitez Hyper‑V ou un VPN, vous pourriez rencontrer des coupures réseau imprévisibles.
ICS est‑il encore nécessaire en 2025 ?
Pour dépanner ponctuellement ou partager une connexion 4G, oui. En entreprise, préférez un routeur matériel ou un pare‑feu UTM qui assure NAT, DHCP et filtrage centralisé.
Puis‑je simplement désinstaller Hyper‑V pour résoudre le problème ?
Oui, mais vous perdrez toutes vos VM. Il est souvent plus rationnel de passer un commutateur virtuel en mode Externe et de supprimer l’interface Default Switch.
Conclusion
Dans 9 cas sur 10, l’événement 1030 (IpICSHlpStopSharing) disparaît après ➊ désactivation des adaptateurs virtuels superflus ; ➋ réinitialisation complète de la pile réseau ; ➌ vérification des dépendances d’ICS. Lorsque la cause est une mise à jour Windows bancale ou un pilote bêta, le retour à la version précédente rend la situation immédiatement stable. Prenez l’habitude de surveiller vos journaux ; un 1030 récurrent est un excellent indicateur d’architecture réseau perfectible.