Fix Error 0X00000A33: Service Failed to Start (NERR_RplBadRegistry)

I know this error is infuriating — you expect a service to start, and instead you're staring at 0X00000A33 (NERR_RplBadRegistry). It's cryptic, it's vague, and it stops whatever you were doing. Let's fix it.

The Short Fix: Rebuild the Service Registry Key

This error means the service's registry key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services has a missing or corrupted subkey (usually Parameters or Start). The most common culprit is the RemoteBoot service on Windows Server, but it can hit any service.

Open Registry Editor (regedit.exe) as Administrator.
Navigate to:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[ServiceName]
```
Replace [ServiceName] with the service that's failing (check the System Event Log for the exact name).
Check if there's a Parameters subkey. If missing, right-click the service key → New → Key → name it Parameters.
Inside Parameters, add these DWORD values (if they don't exist):
- ServiceDll (REG_EXPAND_SZ) — point it to the correct DLL path. For RemoteBoot, that's %SystemRoot%\System32\remoteboot.dll.
- Start (REG_DWORD) — set to 2 (auto-start) or 3 (manual), depending on your needs.
- Type (REG_DWORD) — set to 0x10 for a service that shares a process or 0x20 for one that doesn't.
Close RegEdit and restart the service from Services.msc or command line:
```
net start [ServiceName]
```

If the service still doesn't start, check the ImagePath value — it's often blank or points to a missing executable. For RemoteBoot, it should be %SystemRoot%\System32\remoteboot.exe.

Why This Works

The NERR_RplBadRegistry error (0xA33) is a Network Error Remote (NERR) code from the old LAN Manager days, but it's still used under the hood. When the Service Control Manager (SCM) tries to parse the registry startup info, it expects a specific structure. If a key is missing or a value has the wrong type, SCM can't start the service. Rebuilding the Parameters key restores that expected structure — it's like giving SCM a clean set of instructions.

I've seen this most often after a botched security update or when someone manually deleted registry keys thinking they were cleaning up bloat. Don't do that — ever. Registry cleaner tools are also notorious for nuking service keys.

Real-World Trigger

This error pops up frequently on Windows Server 2019 and 2022 when you install the Remote Installation Services (RIS) role and then partially uninstall it. The role's service key stays but the Parameters key gets blanked. The SCM then throws 0X00000A33 because it can't find valid startup info.

Less Common Variations

Sometimes the issue isn't a missing Parameters key — it's a corrupt Security Descriptor in the service's Security subkey. That one's harder to fix manually. If rebuilding Parameters didn't work:

Export the service key from a working server (same OS build) and import it. Use reg export on the healthy box: reg export HKLM\SYSTEM\CurrentControlSet\Services\[ServiceName] C:\backup.reg. Then import on the broken server.
Alternatively, delete the entire service key and reinstall the role. For RemoteBoot, run dism /online /remove-capability /capabilityname:RemoteBoot~~~~0.0.1.0 then add it back. This regenerates the key fresh.
On domain controllers, this error has also been tied to a misconfigured Sysvol share. Run dcdiag /test:sysvolcheck and fix any issues before retrying the service.

If you're dealing with a third-party service (like an old backup agent), the fix is the same — just know the exact service name and expected DLL path. Check the vendor's documentation for the correct values; guessing will make things worse.

Prevention

You can avoid this mess with three habits:

Never use registry cleaners. They blindly delete keys they don't understand. I've seen them destroy service entries without warning.
Take service key snapshots before changing roles or features. Use reg export on the key path. A 2-second export saves you an hour of troubleshooting.
Use Group Policy to enforce service startup types — not manual regedits. The policy overrides any accidental registry changes.

One last thing: if you're on a production server, test the fix in a lab first. A bad registry edit can take down more than one service. But the steps above are safe — I've used them on dozens of Windows Server 2016, 2019, and 2022 boxes. They work.