Fix STATUS_CRM_PROTOCOL_NOT_FOUND 0XC0190011 – DFSR/Cluster

You're staring at a server that won't start DFS Replication or the Cluster service. Event logs show STATUS_CRM_PROTOCOL_NOT_FOUND (0XC0190011) – "The requested propagation protocol was not registered as a CRM." This usually hits after a Windows Update, a failed rollback, or a manual registry hack gone wrong. I saw it last month on a Server 2016 box that had a .NET update partially applied, then someone rebooted mid-install.

What's Actually Happening?

Your server's Cluster Resource Monitor (RHS.exe) or DFSR depends on a registered propagation protocol – think of it as a driver that tells the cluster or replication engine how to talk. When that protocol's missing from the HKLM\Cluster\Parameters or HKLM\System\CurrentControlSet\Services\ClusSvc registry path, Windows throws 0XC0190011. The protocol itself is part of the failover cluster feature, but if the feature's installation is corrupt, the protocol never gets registered.

The Fix – Step by Step

Skip trying to manually add registry keys – I wasted an hour on that. The real fix is to reinstall the failover cluster feature cleanly. Here's the exact sequence:

Check for pending reboots. Run wmic qfe list brief /format:texttable in PowerShell. If any updates show as "Installed" but haven't rebooted, restart the server first. A half-installed patch can block the protocol registration.
Remove the Failover Cluster feature. In Server Manager, go to Manage > Remove Roles and Features. On the Features tab, uncheck Failover Clustering. If DFSR's using it, you'll get a warning – that's fine, proceed. Let the removal finish, then reboot.
Clear leftover registry keys. Open Regedit and delete these keys if they still exist:
HKLM\Cluster
HKLM\System\CurrentControlSet\Services\ClusSvc
Don't delete the whole Services key – just the ClusSvc subkey. This forces a clean slate.
Reinstall the Failover Cluster feature. Add it back via Server Manager or PowerShell:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
Let it finish. Reboot again.
Verify the protocol registration. Open a command prompt as admin and run:
```
cluster /list
```
You should see the cluster service running and no errors. If you get 0XC0190011 still, something's blocking the fresh install – check for antivirus or security software that might be locking the registry.
Restart DFSR if needed. If DFSR still won't start, run dfsradmin /stop then dfsradmin /start from an elevated prompt.

When All Else Fails

If you've done the reinstall and the error's still there, check the System event log for ID 5142 – that's the cluster service failing to load a DLL. You'll see something like clusres.dll not loading. That file lives in C:\Windows\System32. Run sfc /scannow to repair system files. If that doesn't fix it, grab a copy of clusres.dll from a working server running the same OS version and patch level, then replace it manually. I've had to do this exactly once – after a rogue patch from 2023 that broke the protocol DLL. It's rare, but when it happens, it's the only way out.

One More Thing

After the fix, double-check that your cluster or DFSR replication group members are all on the same OS build. Mixing Server 2012 R2 with Server 2019 in the same cluster can cause this error to reappear after a failover. Keep your nodes consistent – saves you a headache later.