Fix RPC_S_ZERO_DIVIDE (0x000006E7) on Windows Server

Quick answer

Run these two commands as Administrator, then reboot:

regsvr32 /s rpcrt4.dll
regsvr32 /s ntdll.dll

If that doesn't work, check for corrupt system files with sfc /scannow and update your network drivers.

What's actually happening here

The error 0x000006E7 (RPC_S_ZERO_DIVIDE) means the Microsoft RPC runtime tried to perform an integer division by zero. This isn't something you caused by bad input — it's an internal fault in the RPC subsystem. The most common trigger is a corrupt registration of RPC component DLLs (especially rpcrt4.dll or ntdll.dll), or a buggy network driver that passes malformed packets to the RPC endpoint mapper.

I've seen this most often on Windows Server 2019 and 2022 after a failed Windows Update or a third-party security tool that mucks with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs registry key. The RPC server itself doesn't crash — it just returns this error to the calling client. That's why you might see it in logs as Event ID 0 from source RPC, or as an application complaint like 'RPC server unavailable — division by zero'.

Step-by-step fixes

Re-register core RPC DLLs – Open an elevated Command Prompt (Admin) and run:
```
regsvr32 /s rpcrt4.dll
regsvr32 /s ntdll.dll
regsvr32 /s rpcss.dll
```
The /s flag suppresses success dialogs. This rewrites the COM class registration for these DLLs in the registry. Without it, stale GUID entries can cause the divide-by-zero in the RPC runtime's internal math.
Restart the RPC service – After re-registering, restart the service cleanly:
```
net stop rpcss && net start rpcss
```
Note: stopping RPCSS will also kill services that depend on it (like Remote Registry). That's fine — they restart with it.
Run SFC and DISM – If the error persists, system files might be corrupted:
```
sfc /scannow
```
If SFC finds issues it can't fix, run:
```
DISM /Online /Cleanup-Image /RestoreHealth
```
DISM restores the component store from Windows Update, which SFC then uses to replace bad files. Do SFC first, then DISM, then SFC again — order matters.
Update network and storage drivers – The RPC transport layer relies on network drivers. A buggy NIC driver (especially Realtek or Broadcom chipsets) can send malformed RPC packets that trigger the divide. Get the latest driver from the manufacturer's site, not Windows Update.

If the main fixes don't work

Check registry for orphaned RPC endpoints

Open Regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc. Look for subkeys with weird characters or empty default values. These are left behind by failed uninstalls. Back up the key, then delete any suspicious entries. Reboot.

Repair the RPC Locator service

On older Windows Server (2008-2016) or if you use RPC dynamic endpoints, the RPC Locator (RpcLocator) might be the culprit. Set it to start automatically and restart:

sc config RpcLocator start= auto
net start RpcLocator

Modern servers don't need this, but it won't hurt.

Reinstall the Windows RPC runtime

On Windows Server, you can reinstall the RPC components via Server Manager -> Remove Roles and Features -> Remote Server Administration Tools -> RPC tools. Remove, reboot, then add back. This forces a clean re-registration of all RPC proxy stubs.

Prevention — keep this from coming back

Don't install registry cleaners. They strip RPC endpoint mappings. I've seen CCleaner's registry cleaner cause this exact error on two separate Server 2019 boxes.
Set a restore point before any Windows Update that includes RPC changes (most security patches touch it). If the error appears, roll back and re-register the DLLs before retrying the update.
Monitor Event ID 0 from source 'RPC' – it's a canary. If you see it, re-run the regsvr32 commands proactively before clients start failing.

The division by zero isn't your fault. It's Windows shooting itself in the foot with stale registrations. The re-registration trick fixes 90% of cases. For the other 10%, it's a bad driver or a corrupt OS image — but you're already equipped to handle both.