You're seeing a Dwminit warning (Event ID 0) indicating that Desktop Window Manager (DWM) is crashing during Remote Desktop (RDP) initialization, with exit code 0xc0000005 - an Access Violation error. This means a process tried to access memory it shouldn't.

This, combined with the mention of RDPUDD Chained DD (Remote Desktop Protocol User-mode Display Driver), suggests the problem lies in the graphics stack for RDP, likely affecting your ability to connect via Remote Desktop.

Possible Causes

1. Corrupt or incompatible graphics drivers, especially those used during remote sessions.
2. RDP display driver failure - particularly RDPUDD.dll or RdpVideominiport.sys.
3. Third-party software interference - like screen recording, remote control, or GPU utilities.
4. Updates - recent Windows Update or driver installation that broke compatibility.
5. Group Policy or RDP configuration corruption - e.g. bad DWM setting or visual experience setting.

Suggested Steps to Resolve

1. Boot into Safe Mode or use Local Console Access

You may need physical access or use ILO/iDRAC/Hyper-V/VNC to access the console directly.

• Reboot the server in Safe Mode or via local user session (if available).
• From there, proceed with the steps below.

2. Disable Hardware Acceleration for Remote Sessions

From Registry Editor, disable hardware acceleration for DWM in remote sessions:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"DisableHardwareAcceleration"=dword:00000001

3. Force Basic Display Mode for RDP

In the same Registry location or via GPO, configure to disable RemoteFX or custom display drivers.

Also check:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"UseDDAPI"=dword:00000000

4. Disable/Uninstall Third-Party Display Software

Temporarily disable or uninstall:

• NVIDIA/AMD control panels
• DisplayLink drivers
• Screen sharing tools (e.g., TeamViewer, Splashtop)
• Graphics-intensive desktop themes

5. Update or Roll Back Display Drivers

Check Device Manager for display adapters and either:

• Roll back to previous working driver
• Update to latest WHQL-certified driver

6. Disable Desktop Composition via GPO (Optional)

Sometimes RDP fails when Aero/Composition is forced. Disable it:

GPO path:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment

• Enable: "Use WDDM graphics display driver for Remote Desktop Connections" Set to Disabled
• Enable: "Optimize visual experience for Remote Desktop Service" Set to Disabled

7. Restart Remote Desktop Services

Try from console:

net stop termservice
net start termservice

Optional: Use Event Viewer Filters

To confirm related failures, filter Application or System Logs with keywords like rdpudd.dll, dwm.exe, or c0000005 to see if anything else is compounding the failure.

Final Resort: Create New Admin User & Enable RDP Again

If corruption is user-profile-specific, create a new admin user and enable RDP using:

net user NewAdmin P@ssw0rd! /add
net localgroup administrators NewAdmin /add

Ensure RDP is still enabled:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Let me know if you're able to get local or Safe Mode access - that's the key to moving forward. If it's a VM, you might also check host GPU passthrough or driver issues from the hypervisor side.

Perfect - that narrows things down and removes a lot of physical GPU and driver weirdness from the equation. A Hyper-V VM will generally use:

• Microsoft Hyper-V Video as its display adapter
• RDPUDD Chained DD for remote rendering in sessions

So if DWM is crashing inside a Hyper-V VM with error 0xc0000005, it's likely tied to Windows updates, RDP session settings, or a corrupted user profile, rather than third-party drivers.

Focused Fix Steps for Hyper-V VM (DWM crashing on RDP)

1. Boot into Enhanced Session or Console via Hyper-V Manager

• Use Hyper-V Manager Connect Basic Session (no RDP).
• If it's stuck or blackscreening, use the "Turn Off" and "Start" options (not reboot) - this clears session state.

2. Check for Broken Updates or Patches

Run:

Get-HotFix | Sort-Object InstalledOn -Descending

Compare recent update dates with when the issue began. Uninstall any recent suspect with:

wusa /uninstall /kb:5000000

Replace 5000000 with the KB number.

3. Disable Hardware Acceleration for RDP in Registry

Still valid in VM environments:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
"DisableHardwareAcceleration"=dword:00000001

Reboot after applying.

4. Force RDP to Use Legacy Display Stack

Disable WDDM in RDP (which relies on DWM):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"UseDDAPI"=dword:00000000

And if this key doesn't exist, create it as a DWORD (32-bit).

5. Test with a New Local Admin User

Create a new admin account:

net user newadmin P@ssword123 /add
net localgroup administrators newadmin /add

Then try RDP using that account. If it works, your existing profile may be corrupted or loading something that's triggering the crash.

6. Check RemoteFX (Should Be Off)

RemoteFX is deprecated and can cause issues if somehow still enabled. Verify it's off:

Get-VMRemoteFx3dVideoAdapter -VMName "RDserv"  # Should return nothing

If it exists, remove it:

Remove-VMRemoteFx3dVideoAdapter -VMName "RDserv"

7. Check Event Viewer > Application Logs for dwm.exe

Look for accompanying Application Error logs that show:

• Faulting module (e.g., dwmcore.dll, ntdll.dll)
• Stack trace or any DLL involved

This will help pinpoint the real trigger.

Final Clean-Up Options

If nothing works:

Option: Replace RDP Session Shell Temporarily

As a test, set the shell to something like cmd.exe via GPO or:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="cmd.exe"

This may allow RDP login without DWM/Explorer launching. If successful, DWM/Explorer are the culprits.

Let me know what works or what you see when trying these steps. We'll tighten the scope from there - the 0xc0000005 access violation inside a Hyper-V VM is likely fixable with a registry patch, session reset, or user profile swap.