Votre session RDP vers une VM Azure s’ouvre très lentement, gèle puis se ferme avec l’erreur 0x10 ? Suivez ce guide pas‑à‑pas : il propose un plan d’action éprouvé, des commandes prêtes à l’emploi et des méthodes Azure pour rétablir des connexions Remote Desktop stables.
Problème : connexions RDP instables ou impossibles (erreur 0x10) vers une machine virtuelle
Vue d’ensemble de la question
L’utilisateur ne parvient plus à se connecter correctement en RDP : la session met longtemps à s’ouvrir, devient très lente puis se ferme avec le code d’erreur 0x10. Les vérifications classiques (mot de passe, adresse IP/DNS, redémarrage simple) ont déjà été tentées sans succès.
Ce que signifie l’erreur 0x10
Le code 0x10 est typiquement renvoyé quand le serveur interrompt de façon inopinée la connexion RDP. Dans la pratique, cela recouvre :
- Un timeout réseau (filtrage ou latence excessive sur 3389/TCP ou 3389/UDP) ;
- Un service RDP non opérationnel (
TermServicefigé, écouteur RDP endommagé) ; - Une police locale ou un pare‑feu qui rejette l’authentification ou la création de session ;
- Un incident hôte ou un problème de driver réseau côté VM ;
- Une concurrence de sessions (limite atteinte, session orpheline) ou un poste client mal configuré.
Rappelez‑vous que RDP utilise d’abord TCP 3389 pour le canal de contrôle et peut activer UDP 3389 (RDP 8+) pour optimiser les flux graphiques. Bloquer l’UDP n’interdit pas la connexion, mais peut la rendre erratique. L’interruption en phase de négociation TLS/NLA, la création de session ou l’ouverture du bureau aboutit très souvent à un 0x10.
Arbre de décision express (diagnostic en 10–15 minutes)
- Isoler le réseau : tester depuis un autre poste/réseau et via Azure Bastion (si disponible). Si Bastion fonctionne, le problème est hors de la VM (NSG, UDR, NVA, FAI, équipement client).
- Valider la couche Azure : IP Flow Verify sur 3389/TCP, vérifier un Allow entrant dans le NSG, routes effectives et Next Hop, état Resource Health.
- Observer le démarrage : Boot Diagnostics (écran/console) pour déceler BSOD, mise à jour Windows interminable, résolution vidéo anormale.
- Remettre RDP d’équerre : réinitialiser RDP depuis le portail (option « Réinitialiser le mot de passe »), redémarrer
TermService, rouvrir les règles pare‑feu « Remote Desktop ». - Renouveler le dataplane : Reset NIC si suspicion réseau côté invité ; Redeploy si l’hôte Azure semble dégradé.
- Plan B : activer la console série ou WinRE, exécuter
sfc/chkdsk, corriger les GPO RDP, désactiver temporairement NLA, purger les sessions bloquées.
Pistes de résolution et correctifs proposés
Tableau synthétique des actions recommandées. La colonne « Pourquoi » aide à prioriser ; la colonne « Comment faire rapidement » vous guide dans le portail Azure ou en ligne de commande.
| Catégorie | Actions recommandées | Pourquoi / complément utile | Comment faire rapidement |
|---|---|---|---|
| Configuration RDP sur la VM | Réinitialiser la configuration RDP depuis le portail Azure (l’option Réinitialiser le mot de passe répare aussi RDP). | Répare les clés de registre et le service TermService qui peuvent être corrompus. | VM > Opérations > Réinitialiser le mot de passe > choisir RÉINITIALISER. Puis redémarrer la VM. |
| Sécurité réseau (NSG) | Vérifier les règles NSG avec « IP Flow Verify » et s’assurer qu’un flux entrant TCP 3389 Allow existe. | Un blocage au niveau NSG est la cause la plus courante d’erreurs RDP. | Network Watcher > Vérificateur de flux IP > tester Inbound 3389. Sur la NIC/Subnet > Règles de sécurité effectives. |
| Diagnostics de démarrage | Consulter Boot Diagnostics (captures d’écran, journaux console). | Identifie un BSOD, une mise à jour Windows en boucle, ou une résolution d’écran incompatible. | VM > Diagnostics de démarrage > Capture d’écran et Journal. |
| Interface réseau | Réinitialiser l’interface NIC de la VM. | Rafraîchit l’adresse MAC et purge les caches ARP/DHCP. | VM > Opérations > Réinitialiser l’interface réseau (ou détacher/attacher la NIC si nécessaire). |
| État de la ressource Azure | Contrôler le Resource Health de la VM. | Détecte un incident de plateforme Azure impactant l’hôte physique. | VM > Intégrité de la ressource. Si dégradé : envisager Redeploy. |
| Redémarrage / redéploiement | 1) Redémarrer la VM. 2) Si nécessaire, Redéployer la VM sur un autre hôte. | Libère les verrous de fichier et migre la VM si l’hôte est dégradé. | VM > Arrêter/démarrer ou Redémarrer. Puis Opérations > Redéployer. |
| Routage et UDR | Vérifier les routes effectives et l’outil Next Hop. | Une route UDR ou un NVA mal configuré peut détourner le trafic 3389. | NIC > Routes effectives. Network Watcher > Prochain saut sur 3389. |
| Équipement local | Vérifier que le routeur/pare‑feu local laisse sortir TCP 3389 ; tester depuis un autre réseau. | Écarte un filtrage côté client ou FAI. | Tester via 4G/5G ou domicile/bureau. Si Bastion fonctionne : la VM est OK, le problème est côté client/chemin. |
| Environnement VMware (le cas échéant) | Mettre à jour ou réinstaller VMware Tools et VMware Workstation/ESXi drivers. | Des pilotes réseau obsolètes côté invité peuvent provoquer des déconnexions. | Mettre à jour les VMware Tools depuis la console, puis redémarrer la VM invitée. |
| Contrôles supplémentaires utiles | Windows Firewall (profil Public) doit autoriser « Remote Desktop » ; TermService doit être démarré ; version du client mstsc ; réduire la profondeur couleur/activer l’UDP ; tester via Azure Bastion. | Ces vérifications rapides règlent souvent des cas résiduels non identifiés. | Voir sections « Réparer RDP côté Windows » et « Ajuster le client MSTSC » ci‑dessous. |
Pas à pas détaillé
1) Valider le dataplane Azure (NSG, routes, santé)
IP Flow Verify & règles NSG
- Ouvrez Network Watcher > Vérificateur de flux IP. Entrez l’IP publique ou privée de la VM selon le scénario, le port 3389, la direction Inbound et testez.
- Sur la NIC ou le Subnet associé, ouvrez Règles de sécurité effectives. Assurez‑vous qu’une règle Allow 3389/TCP devance les éventuels Deny.
Astuce : si l’UDP 3389 est bloqué, RDP bascule en TCP uniquement. Autorisez les deux pour de meilleures performances.
Routes effectives & Next Hop
- Sur la NIC de la VM, consultez Routes effectives. Cherchez des routes UDR vers une NVA ou un tunnel qui ne connaît pas la source du client.
- Dans Network Watcher > Prochain saut, spécifiez la source, la destination et vérifiez que le Next Hop est attendu (Internet, VirtualNetwork, VPN, etc.).
Resource Health & métriques
- VM > Intégrité de la ressource : si l’état est dégradé, planifiez un Redeploy.
- Consultez Métriques (CPU, réseau). Une saturation CPU ou disque au moment des connexions peut déclencher des expirations.
2) Réparer RDP côté Windows (pare‑feu, service, écouteur)
Si vous avez accès au portail mais pas à RDP, utilisez Run Command ou la console série pour exécuter ces commandes. Exemple via Azure CLI :
az vm run-command invoke -g <groupe> -n <vm> --command-id RunPowerShellScript --scripts "
# Ouvrir les règles RDP (TCP/UDP) dans Windows Defender Firewall
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop' -ErrorAction SilentlyContinue
# Vérifier l'écoute sur 3389
netstat -ano | findstr :3389
# Redémarrer le service RDP
Stop-Service TermService -Force
Start-Service TermService
# (Optionnel) Désactiver temporairement NLA si l'authentification bloque
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 0
# Autoriser les connexions RDP côté système
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0
"Important : si vous désactivez NLA (valeur UserAuthentication=0), réactivez‑la après correction (=1) pour la sécurité.
Vérifications rapides
# Le service RDP est-il Up ?
sc query TermService
# Le port écoute-t-il localement ?
Test-NetConnection -ComputerName localhost -Port 3389
# Règles de pare-feu RDP actives ?
Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | select DisplayName,Enabled,ProfilePurger les sessions bloquées ou atteindre la console
# Lister les sessions
qwinsta
# Réinitialiser une session orpheline
rwinsta <ID>
# Se connecter en priorité admin (bypass limite de 2 sessions)
mstsc /admin3) Réinitialiser la configuration RDP depuis le portail
La commande Réinitialiser le mot de passe répare aussi les composants RDP : elle remet en place l’utilisateur local, recrée des clés de registre RDP et relance TermService.
- VM > Opérations > Réinitialiser le mot de passe.
- Sélectionner Mode : Réinitialiser. Renseigner utilisateur/mot de passe (ou SSH pour Linux).
- Valider, puis redémarrer la VM.
4) Redémarrage, Reset NIC et Redeploy
- Redémarrer : libère les verrous et réinitialise la pile RDP.
- Reset NIC : réinitialise l’interface, renouvelle la MAC et purge ARP/DHCP qui peuvent causer des goulots.
- Redeploy : migre la VM sur un autre hôte Azure. Note : en IP privée dynamique, l’adresse peut changer. Tenez compte des dépendances (ACL, liaisons statiques, configurations applicatives).
5) Diagnostics de démarrage (Boot Diagnostics)
Consultez la capture d’écran :
- Écran bleu : suspectez un driver (souvent réseau/vidéo). Démarrez en WinRE et restaurez.
- Mise à jour Windows prolongée : patientez ou relancez après échec, puis
sfc /scannow. - Écran noir à résolution étrange : réinitialiser l’affichage via la console série ou supprimer les pilotes vidéo tiers.
6) Console série / WinRE : réparation hors ligne
Si la VM est démarrée mais injoignable :
# Vérifier/réparer les fichiers système
sfc /scannow
# Vérifier le disque (peut nécessiter un redémarrage)
chkdsk /f C:
# Réparer l'écouteur RDP-Tcp par défaut
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d 3389 /f
# Réactiver RDP si désactivé par GPO
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /fSur serveur joint à un domaine, des GPO peuvent écraser ces réglages ; vérifiez les politiques liées au Bureau à distance et au pare‑feu.
7) Ajuster le client MSTSC (quand la latence est forte)
| Paramètre | Recommandation | Impact |
|---|---|---|
| Couleurs (Affichage) | 16‑bit (65536 couleurs) pendant le diagnostic | Réduit la bande passante, améliore la fluidité |
| Périphériques & ressources | Désactiver l’impression, presse‑papiers bidirectionnel si non nécessaire | Diminue les canaux RDP secondaires |
| Expérience | Cocher « Détecter la connexion » ou forcer « Bande passante faible » | Désactive thèmes/Aero, animations |
| UDP | Laisser activé « Utiliser UDP si possible » | Améliore stabilité sur réseaux fluctuants |
| Connexion admin | Utiliser mstsc /admin | Contourne la limite de 2 sessions administratives |
8) Scénarios spécifiques à considérer
- Sessions maximales atteintes : listez avec
qwinsta, libérez viarwinsta <ID>, ou connectez‑vous en/admin. - NLA et identités : une panne LSASS/Kerberos/NTLM peut casser NLA. Désactivez‑la temporairement le temps de corriger puis réactivez‑la.
- Antivirus/EDR : certains agents interceptent
TermServiceet le layer TLS. Testez en mode maintenance/désactivation contrôlée. - VMware/Drivers : si la VM est importée d’un environnement VMware, mettez à jour les drivers réseau/vidéo, ou réinstallez les « VMware Tools ».
Information complémentaire
- Erreur 0x10 : indique généralement une interruption de session par le serveur (timeout, quota, service RDP indisponible).
- Après un redéploiement, la VM change d’hôte et peut changer d’adresse IP privée si elle est dynamique ; anticipez l’impact.
- Avant toute opération lourde (redeploy, reset NIC), conservez un snapshot ou une image gérée.
- Pour un diagnostic poussé, activez le canal console série d’Azure ou lancez une console WinRE pour exécuter
sfc /scannowetchkdsk /f.
Plan d’action « 30 minutes »
- 5 min : Testez depuis un réseau alternatif et via Bastion. Si Bastion passe : suspectez NSG/UDR/NVA/FAI.
- 5 min : IP Flow Verify + Règles effectives + Routes effectives. Corrigez toute règle Deny antéposée.
- 5 min : Boot Diagnostics. Si BSOD/boucle Update : plan console série/WinRE.
- 5 min : Réinitialiser le mot de passe (répare RDP) puis redémarrer. Ouvrez les règles RDP via Run Command.
- 5 min : Reset NIC puis test. Si persistant : Redeploy.
- 5 min : Vérifiez client
mstsc(16‑bit, /admin), purgez une session bloquée (rwinsta), réactivez NLA ensuite.
Checklist de clôture
- Connexion RDP stable < 2 s d’ouverture de session ; pas de coupure lors d’un copier‑coller ou défilement d’une fenêtre.
- Journal TerminalServices‑LocalSessionManager/Operational sans erreurs récurrentes.
- NSG : règle 3389/TCP Allow positionnée avant tout Deny global ; routes effectives cohérentes.
- Windows Firewall : groupe « Remote Desktop » activé sur les trois profils (Domaine, Privé, Public).
- NLA réactivée, mots de passe administrateurs revus, comptes inutiles désactivés.
Prévenir les récidives
- Éviter l’exposition permanente de 3389 à Internet. Favorisez Azure Bastion, un VPN P2S/S2S ou une IP source filtrée.
- Just‑In‑Time (JIT) RDP : n’ouvrez 3389 que ponctuellement, automatiquement refermé par Azure.
- Monitoring : activez les NSG Flow Logs et des alertes sur les échecs de connexion RDP.
- Hygiène Windows : mises à jour régulières, pilotes à jour,
sfcpériodique si incidents, taille suffisant du disque OS.
Annexes : commandes utiles
PowerShell – pare‑feu & écoute RDP
# Activer toutes les règles Remote Desktop (TCP/UDP) sur tous les profils
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'
# Vérifier l'écoute locale sur 3389
netstat -ano | findstr :3389
# Tester la connectivité réseau depuis la VM (boucle locale)
Test-NetConnection -ComputerName localhost -Port 3389
# Service RDP
Restart-Service -Name TermService -Force
# NLA (1 = activé, 0 = désactivé)
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' UserAuthentication 1Cmd – sessions
# Qui est connecté ?
qwinsta
# Libérer une session bloquée
rwinsta <ID>Azure CLI – exécuter un script de réparation
az vm run-command invoke -g <groupe> -n <vm> --command-id RunPowerShellScript --scripts "
Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' fDenyTSConnections 0
Restart-Service TermService -Force
"FAQ
Q : Mon NSG autorise 3389, mais la connexion coupe encore. Que regarder ?
R : Vérifiez le profil actif du pare‑feu Windows (Public parfois) et les routes effectives (UDR/NVA). Si l’UDP 3389 est bloqué, autorisez‑le pour la stabilité. Surveillez aussi CPU/IO disque au moment de la connexion.
Q : Deux sessions RDP sont déjà ouvertes sur Windows Server sans licences RDS. Puis‑je me connecter ?
R : Utilisez mstsc /admin pour la console admin et/ou libérez une session avec rwinsta. Vérifiez qu’aucune GPO ne limite le nombre de connexions.
Q : Après un redeploy, je perds l’accès par IP privée. Normal ?
R : Oui si l’IP privée est dynamique. Passez la NIC en IP privée statique si des services dépendent de cette adresse.
Q : Désactiver NLA est‑il dangereux ?
R : Oui, c’est provisoire pour débloquer l’accès. Une fois la cause corrigée, réactivez NLA immédiatement.
Conclusion
En attaquant le problème par couches — réseau Azure (NSG/UDR/Next Hop), état hôte, pile RDP Windows (pare‑feu, service, NLA), puis dataplane (Reset NIC, Redeploy) — vous résoudrez la majorité des erreurs RDP 0x10 sans recréer la machine virtuelle. Conservez toujours un snapshot avant une action intrusive et privilégiez des voies d’accès sécurisées comme Azure Bastion et le JIT.