I'm troubleshooting a Windows Server 2025 domain controller used with Citrix. A small number of users receive a black screen with a movable mouse cursor when they connect through RDP. The desktop never appears, although Ctrl+Alt+End works and allows them to log off. Task Manager does not open. Other user accounts can connect normally, and the affected users can still log in through the vSphere console.
The issue follows only certain users, even though they had previously connected successfully. I've already deleted their profiles, removed related registry keys and leftovers, terminated their sessions and processes, rebooted the server, disabled UDP, WDDM, and network detection through local policy, changed the display resolution, and disabled persistent bitmap caching. None of those changes helped.
Event Viewer shows an Application Error, Event ID 1000, where ctfmon.exe crashes in InputService.dll with error 0xc0000409. There is also Event ID 29 from the spell-checking service reporting that access to the spell-checking settings is denied for the affected user. Explorer.exe appears not to start at all. I suspect a stuck session, an application holding resources, or corrupted Windows components, but killing processes and resetting profiles has not resolved it. What else should I check?
3 Answers
Since new accounts and most existing accounts work, compare the affected users’ session state and shell-related settings with a working account. Confirm that explorer.exe is configured as the shell, inspect user-specific policies and logon scripts, and check for per-user registry values that could prevent the shell from launching. The spell-checking access error may be secondary, but the ctfmon crash could be stopping normal shell startup. Avoid repeatedly deleting profiles until you have copied any needed data and confirmed the profile is actually the cause.
The ctfmon.exe and InputService.dll crash points more toward damaged system components than an RDP display problem. Run DISM first to repair the component store, followed by System File Checker, then reboot the server and test an affected account again. It is also worth checking whether the same system files or application components fail for every affected user.
This could still be a ghost session or a process that did not release cleanly. Check the server for disconnected sessions belonging to the affected users, then log them off explicitly rather than only killing individual processes. Also try restarting the Print Spooler, since a stuck printer or document process can sometimes prevent the user shell from initializing. Adobe Reader or another application launched during the previous session could have a similar effect.
That makes sense. The display and RDP policy changes did not affect the behavior, so I’m going to focus on repairing the operating system and comparing the results across affected accounts.