1 13/10/2026 4 min

Errore 0x516 in Desktop remoto: dove si rompe davvero

L’errore 0x516 in Desktop remoto di Windows non va trattato come un messaggio “generico”. In pratica segnala che la sessione RDP non riesce a completare l’avvio o l’autenticazione nel punto giusto della catena: rete, servizio Remote Desktop, NLA, credenziali, policy, certificato o stato della macchina remota. Se lo affronti a tentativi, perdi tempo. Se lo leggi per layer, lo chiudi in pochi minuti.

Il caso tipico è questo: la connessione parte, l’host risponde, ma il client si ferma con 0x516 oppure con un messaggio affine di impossibilità a completare la sessione. In ambienti gestiti, il problema è spesso introdotto da una modifica recente: hardening, aggiornamento Windows, cambio di password, policy NLA, RDP disabilitato, firewall, o un servizio fermo dopo reboot.

Layer da controllare prima: rete, servizio, autenticazione

La sequenza corretta è semplice: DNS → porta TCP 3389 → servizio Remote Desktop → autenticazione/NLA → policy di accesso → stato del sistema. Se salti un livello, rischi di correggere la cosa sbagliata. Per esempio, cambiare credenziali non serve se il servizio RDP non ascolta; disattivare NLA non serve se il firewall blocca la porta; riavviare il client non serve se la macchina remota è in crash o saturata.

Diagnosi pratica: cosa significa 0x516 nella maggior parte dei casi

In ambito operativo, 0x516 tende a comparire quando il client non riesce a completare la sessione perché il server non accetta correttamente l’avvio del desktop remoto o interrompe la negoziazione. Le cause più frequenti sono queste:

  • RDP disabilitato o servizio TermService fermo.
  • Porta 3389 bloccata da firewall locale, firewall di rete o ACL.
  • NLA attivo con credenziali non valide, account bloccato o policy incompatibile.
  • Certificato RDP errato o profilo macchina incoerente dopo cambi di hostname/IP.
  • Sessione bloccata da un problema di sistema: risorse esaurite, update pendente, crash del servizio.

Se devi scegliere da dove partire, non partire dal client. Parti dall’host remoto: è lì che si decide quasi sempre il destino della connessione.

Verifiche immediate: evidenza minima in meno di 5 minuti

Prima verifica se il target è raggiungibile e se la porta RDP risponde. Dal client o da una macchina nella stessa rete:

ping NOMEHOST_O_IP
Test-NetConnection NOMEHOST_O_IP -Port 3389

Se Test-NetConnection fallisce, il problema è prima dell’autenticazione: rete, firewall o servizio non in ascolto. Se invece la porta è aperta, passa al controllo del servizio e dei log sul server remoto.

Su Windows Server o su un client Windows che accetta RDP, controlla il servizio:

Get-Service TermService

Stato atteso: Running. Se è Stopped o in errore, hai già una pista forte. A quel punto guarda anche se il servizio dipende da componenti bloccati o se il sistema ha appena installato aggiornamenti in sospeso.

Per i log evento, i punti utili sono questi:

Event Viewer → Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager → Operational
Event Viewer → Windows Logs → System

Cerca errori sul time range del tentativo di connessione. Se trovi eventi di login fallito, disconnessione, certificato o policy, hai un riscontro concreto invece di andare a intuito.

Ipotesi più probabili, in ordine

  1. RDP non è realmente disponibile: servizio fermo, porta chiusa, firewall o host non raggiungibile. Falsificazione rapida: Test-NetConnection host -Port 3389 e Get-Service TermService. Se porta aperta e servizio in running, questa ipotesi scende.
  2. NLA o credenziali non coerenti: password cambiata, account bloccato, permessi RDP mancanti, policy che impone autenticazione prima del desktop. Falsificazione rapida: prova con un account noto autorizzato e controlla eventi di logon fallito o blocco account.
  3. Problema locale sul server: risorse al limite, update, servizio corrotto, sessione bloccata o stato incoerente dopo reboot. Falsificazione rapida: verifica CPU, RAM, disco e eventi di sistema; se il server risponde ma non crea sessioni, il difetto è qui.

Soluzione consigliata passo-passo

Qui sotto c’è il percorso più sicuro: prima verifiche, poi una modifica minima reversibile, poi escalation solo se serve. Se lavori su produzione, considera impatto utenti e prepara sempre un rollback.

  1. Conferma che il problema sia sul layer RDP e non sul nome host. Se usi un nome DNS, prova anche l’IP diretto. Se l’IP funziona e il nome no, il problema è DNS o record errato, non Desktop remoto.

  2. Controlla il servizio Remote Desktop. Sul server remoto esegui:

    Get-Service TermService | Select-Object Status,Name,DisplayName

    Se non è in esecuzione, avvialo:

    Start-Service TermService

    Rollback: se l’avvio peggiora la situazione o il servizio cade di nuovo, interrompi e torna allo stato precedente dopo aver raccolto il messaggio di errore.

  3. Verifica il listener su 3389. Sul server:

    netstat -ano | findstr :3389

    Atteso: una riga in ascolto su 0.0.0.0:3389 o sull’IP corretto. Se non ascolta, il servizio non ha creato il listener o qualcosa lo sta bloccando.

  4. Controlla il firewall locale. Il gruppo regole Windows Firewall per Desktop remoto deve consentire traffico in ingresso. Verifica con:

    Get-NetFirewallRule -DisplayGroup