Windows Server 2022 RDS: session arbitration hangs after Event 17 (0x8007045B), TermService and UmRdpService become unkillable and users cannot log on

Question

Windows Server 2022 Standard, build 20348.5622 (21H2), activated retail channel, running as a Hyper-V guest. Not domain-joined, all user accounts are local. RD Session Host role installed with Per Device licensing, 50 CALs installed and 44 available. Around 6 concurrent RDP users.

Symptom

RDP clients receive "The two computers couldn't connect in the amount of time allotted."

Authentication is succeeding on the server. RemoteConnectionManager/Operational logs Event 261 (listener received a connection) followed by Event 1149 (authentication succeeded) for every attempt. The session is then never created.

This is not limited to RDP. A local console logon through Hyper-V VMConnect also accepts credentials and then hangs indefinitely at "Welcome". That points at session creation itself rather than the RDP transport.

Evidence from LocalSessionManager/Operational

A successful session, logged before the fault appeared:

Id 41  Begin session arbitration: , Session ID 5
Id 42  End session arbitration:   , Session ID 5
Id 21  Session logon succeeded:   , Session ID 5
Id 22  Shell start notification:  , Session ID 5

A failed session:

Id 41  Begin session arbitration: , Session ID 2
(no Event 42, no Event 21, no Event 22 - the sequence never completes)

Event 41 with no matching Event 42 is the consistent signature of this failure.

How it started

The first occurrence followed a reboot after installing KB5122881, KB5122882 and KB5126050, all installed the same day. The previous update on this system dated from six months earlier, so a large amount of cumulative servicing was applied in a single pass.

During that boot, LocalSessionManager/Operational logged:

Id 54  Local multi-user session manager received system shutdown message
Id 17  Remote Desktop Service start failed. The relevant status code was 0x8007045B.

0x8007045B is ERROR_SHUTDOWN_IN_PROGRESS. Remote Desktop Services attempted to start while the system was still processing shutdown. The service subsequently reported status "Running", but session arbitration was non-functional from that point on.

The services cannot be stopped once the fault occurs

Restart-Service TermService -Force
WARNING: Waiting for service 'Remote Desktop Services (TermService)' to stop...
(repeats indefinitely)

On a later attempt:

Restart-Service : Service 'Remote Desktop Services (TermService)' cannot be
stopped due to the following error: Cannot stop UmRdpService service on
computer '.'.

And directly against the redirector:

Stop-Service UmRdpService -Force
Stop-Service : Service 'Remote Desktop Services UserMode Port Redirector
(UmRdpService)' cannot be stopped due to the following error: Cannot stop
UmRdpService service on computer '.'.

UmRdpService hangs first and blocks TermService from stopping.

Once wedged, query user, Get-CimInstance Win32_Service and tasklist /svc all hang and never return. Get-WmiObject Win32_Service still responds and can be used to retrieve the process IDs.

From the Hyper-V host, both Stop-VM and Stop-VM -Force time out with 0x800705B4, while Get-VM continues to report the guest as "Running / Operating normally".

Recovery that works without a reboot

Get-WmiObject Win32_Service -Filter "Name='UmRdpService' or Name='TermService'" | Select Name,ProcessId,State

Stop-Process -Id  -Force
Stop-Process -Id  -Force

Both services auto-restart with new process IDs and sessions work normally again, until the fault recurs. Both run in dedicated svchost.exe instances with no co-hosted services.

The interval between failures is shrinking

Occurrence 1   approx. 4 hour outage, cleared by a VM power cycle
Occurrence 2   approx. 22 hours later, cleared by terminating both processes
Occurrence 3   approx. 15 minutes after recovering from occurrence 2

Correlation

The hang follows new session creation rather than idle time. New session svchost processes spawn, and arbitration wedges shortly afterwards.

An application on the server also logged printer subsystem errors (OpenPrinter call failed, SetNameDriverAndPort call failed) roughly 20 minutes before one of the occurrences, which is what first led us to suspect printer redirection.

Mitigations attempted

fDisableCpm = 1   disable client printer redirection - fault recurred approx. 15 minutes later
fDisableCdm = 1   disable client drive redirection - applied, monitoring
UmRdpService      set to Disabled and stopped - monitoring

Print Spooler restarts cleanly with no error, so the spooler service itself is not hung.

Already ruled out

RDS CALs            50 installed, 44 available, 6 issued, valid to 2037
Windows activation  LicenseStatus 1, retail channel, not an evaluation build
Disk space          844 GB free on C:
Damaged profiles    no .TEMP directories present under C:\Users
Domain and GPO      machine is not domain-joined
RDP listener        fDenyTSConnections = 0, port listening, TCP connects successfully
Service crashes     no Event 7031, 7034, 7000 or 7009 during occurrences 2 and 3

Question

Is the Event 17 / 0x8007045B start-during-shutdown failure a known defect that can leave TermService in a degraded state while still reporting "Running", and is there a supported fix or mitigation for it?

I can reproduce this reliably and can capture diagnostic data before recovering, so I am happy to collect a user-mode dump of the hung svchost or specific RDS ETW traces if that would help identify the cause.

Answer

Hello @Mateo Morales

Based on the evidence you've collected, this doesn't look like an RDP listener, licensing, authentication, profile, or basic connectivity issue.

The strongest indicator is the LocalSessionManager sequence: Event 41 – Begin session arbitration with no corresponding Event 42, followed by no Event 21/22. Since the same hang occurs during a local VMConnect logon after credentials are accepted, the failure appears to be in Windows session creation/arbitration, rather than the RDP transport itself.

Be careful about treating Event 17 / 0x8007045B (ERROR_SHUTDOWN_IN_PROGRESS) as the confirmed root cause. It shows that Remote Desktop Services tried to start while Windows was still processing shutdown, and its timing makes it relevant, but it doesn't prove that this left TermService permanently corrupted. The fact that the problem subsequently recurs after you kill/restart UmRdpService and TermService suggests there may be another trigger.

Your observation that UmRdpService becomes unresponsive first and prevents TermService from stopping is particularly useful. I wouldn't disable UmRdpService permanently as the final fix because it provides RDP device/port redirection functionality. Disabling printer redirection also didn't prevent recurrence, so printer redirection alone doesn't appear to explain the problem.

At this stage, capture diagnostics while the server is in the failed state and before killing either svchost process.

First, capture full user-mode dumps of the hung UmRdpService and TermService svchost processes. Since you've already established that each is running in its own dedicated svchost instance, those dumps should be particularly useful to Microsoft engineering.

Also, export these Event Viewer channels covering several minutes before and after the failure:

Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational

System

Application

If Microsoft asks for deeper tracing, an RDS/Terminal Services ETW trace captured across a reproduction would be the logical next step.

Also, don't spend much more time on profile troubleshooting unless the diagnostic evidence starts pointing there. Microsoft recommends User Profile Service Operational/Diagnostic logging for profile load/unload failures, but your failure occurs before LocalSessionManager completes session arbitration and affects multiple local accounts.

One other thing to test is whether this reproduces on a fully patched Windows Server 2022 VM built cleanly at the current servicing level, rather than only on this machine that moved approximately six months of servicing forward in one update cycle. That gives you a useful A/B comparison without uninstalling individual security updates from the production server.

I can't find a currently published Microsoft known issue or documented fix that specifically maps Event 17 / 0x8007045B → Event 41 without Event 42 → hung UmRdpService/TermService, so we cannot represent this as a confirmed known Windows Server 2022 defect yet.

Since you can reproduce it and leave the machine in the failed state, this is a good candidate for a Microsoft Support escalation. Provide the dumps, ETL/event logs, exact Windows build, installed KB history, and timestamps for each occurrence. Ask specifically for analysis by the Windows Remote Desktop Services / Terminal Services team.

Your current process-termination method is useful for emergency recovery because it restores service without rebooting, but treat it as a workaround rather than a supported root-cause fix until the hung-process dumps identify what UmRdpService/TermService are waiting on.

References:

Troubleshoot user profiles with events - Microsoft Learn

Remote Desktop Services - Windows Server documentation

=============================================================================

Help make this community better for everyone: If the answer helped or resolved your issue, please accept it or upvote it. This helps others in the community find similar solutions.