Virtual Machine: RDP Listener Initialization Failure — Ongoing Issue

Question

Virtual Machine: RDP Listener Initialization Failure — Ongoing Issue

Callum Woodward 41

Problem description

I am experiencing an issue where the RDP-Tcp listener fails to initialize on my Windows virtual machine. Despite replacing registry configurations, regenerating certificates, verifying permissions, and restarting services, the listener still does not appear, and TCP 3389 is not listening. I am seeking guidance on how to resolve this persistent problem.

Environment

Azure Virtual Machines, Windows OS, region not specified in case information.

What I've already tried

I replaced the RDP-Tcp registry configuration from a working VM with the same Windows build, regenerated the RDP self-signed certificate, verified registry and certificate permissions, ran DISM /ScanHealth and SFC /scannow, restarted Windows and Remote Desktop Services, copied the listener registry configuration from a matching VM, regenerated the RDP certificate, repaired system files, and restarted Windows and the RDP services.

Current status

I am seeking escalation for further investigation to identify the root cause and restore the RDP listener functionality, as all standard troubleshooting steps have been exhausted without success.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

1 answer

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Hello @Callum Woodward

Because TCP 3389 isn’t listening and the RDP-Tcp listener is absent, this is a guest OS Remote Desktop Services initialization problem, not an NSG or Azure network-path problem.

Before making further changes, take a snapshot of the OS disk. This is a required precaution before repairing an RDP listener or modifying the offline registry.

I suggest the following supported sequence:

From the VM’s Help menu, open Reset password, select Reset configuration only, and choose Update. This invokes the VMAccess extension to enable Remote Desktop Services and recreate the Windows Firewall rule for TCP 3389. This procedure doesn’t reset the account password.
If the listener remains missing, use Azure Serial Console to confirm that TermService and UmRdpService are running and verify these documented listener settings:
1. fEnableWinStation = 1
2. fLogonDisabled = 0
3. fDenyTSConnections = 0, including the policy path if configured
Check the System log for TermService, Service Control Manager, and Microsoft-Windows-TerminalServices-RemoteConnectionManager errors.
If VMAccess and Serial Console don’t restore the listener, perform the documented offline repair: attach a copy of the OS disk to a repair VM, repair the offline configuration, and restore the disk. Azure VM repair commands provide Microsoft’s supported workflow without deleting and recreating the original VM.

Since the registry, certificates, permissions, and system files have already been repaired without restoring the listener, don’t continue replacing registry branches from another VM. Preserve the current event logs and collect the exact Windows version/build, relevant event IDs, and the VMAccess extension result before escalating to Microsoft Support.

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

Callum Woodward 41 Reputation points

2026-11-12T08:37:13.55+00:00

Hi @Allan Solomon Mejia ,

Thanks for the recommendations.

We have already completed the majority of these steps, unfortunately without resolving the issue.

To confirm:

OS disk snapshot has been created.

Azure Reset Configuration Only has already been attempted.

I have already checked TermService and UmRdpService, they are both running.

fEnableWinStation = 1, fLogonDisabled = 0 and fDenyTSConnections = 0.

The active Windows control set is ControlSet001.

We replaced the RDP-Tcp registry key using a working Windows 10 Enterprise LTSC VM, then restarted Windows.

DISM /ScanHealth found no component store corruption.

SFC /scannow repaired corrupted files.

The RDP certificate was regenerated and its permissions verified.

Registry and event logs have been exported.

Despite all this, TCP 3389 remains closed, the standard RDP-Tcp listener is missing, and Event ID 227 continues reporting:

"Can't find listener registry key in Winstations" (0x2).

We have not yet performed an offline OS disk repair.

However, the documented offline repair appears to modify the same RDP registry values that we have already confirmed are correct.

Can you clarify what additional repair or diagnostic operation we should perform offline that would differ from the repairs already completed?

In particular, is there a way to identify the exact registry key or Windows component that is failing when CUMRDPProtocolManager::CreateListener returns 0x2?

This is a production Azure VM running SQL Server, so we want to avoid unnecessary disk swaps or further changes without a specific remediation plan.

We also have an active Microsoft Support request: 2611110050004334.

Thanks.