Fix 0X00000A34: NERR_RplBadDatabase service won't start

Quick answer

Stop the RemoteBoot service, delete the corrupt RPLMAP and RPLSVC database files from %SystemRoot%\System32\RPL, then restart the service. It'll auto-create fresh ones.

What actually triggers this error

This error is specific to the RemoteBoot service (RPLSVC) in older Windows NT-based systems — you'll see it on Windows NT 4.0, Windows 2000 Server, or legacy Windows Server 2003 installs still running Remote Installation Services (RIS) for diskless workstations. The error 0X00000A34 maps to NERR_RplBadDatabase, which literally means the service's internal database files (RPLMAP and RPLSVC) are either missing or corrupted.

I've seen this happen three ways: a sudden power loss while the service was writing to those files, a bad manual edit (some admin tried to tweak the database with Notepad), or a disk failure that silently trashed those files while leaving everything else intact. One client had a server that booted fine but the RemoteBoot service just refused to start after a UPS failure. Took me 10 minutes to fix once I knew what I was looking at.

How to fix it — step by step

Stop the RemoteBoot service. Open a command prompt as Administrator and run:
```
net stop rplsvc
```
If it's already hung, use:
```
sc stop rplsvc
```
Then kill any leftover processes:
```
taskkill /f /im rplsvc.exe
```
Delete the corrupt database files. Go to %SystemRoot%\System32\RPL and delete these two files:
- RPLMAP (no extension)
- RPLSVC (no extension)
Don't delete anything else in that folder — the RPLBIN and RPLFILES directories need to stay. If Windows says the files are locked, reboot into Safe Mode with networking and try again.
Restart the service. In the same command prompt:
```
net start rplsvc
```
Check the System event log — it should show an info event saying the database was rebuilt automatically. Verify the service is running:
```
sc query rplsvc
```
If you see STATE: 4 RUNNING, you're golden.

Alternative fix: restore from backup

If you have a recent backup of the %SystemRoot%\System32\RPL folder (or better yet, a full system state backup), just stop the service, restore those two files from backup, and restart. This preserves any custom workstation configurations you had in the database. I always tell clients to back up that folder weekly if they're using RemoteBoot — those configs are a pain to rebuild.

No backup? The delete-and-restart method above works, but you'll lose any custom mappings. You'll need to re-register workstations using RPLCMD or the Remote Boot Manager utility afterwards.

How to prevent this from happening again

Three things I make sure every client running RemoteBoot does:

Back up the entire %SystemRoot%\System32\RPL folder — not just the database files. A full copy takes 2 MB, and it's saved my bacon more than once.
Put the server on a UPS — the most common cause I see is a dirty shutdown corrupting those small database files. They're written to frequently during boot, so any power hiccup can trash them.
Never edit RPLMAP or RPLSVC manually — these aren't text files. Use the Remote Boot Manager or RPLCMD. I've had three clients over the years try to open them in Notepad to add a workstation, then save, and BAM — service won't start. It happens.

One last thing: if you're on Windows Server 2003 or older and still relying on RemoteBoot for diskless workstations, it's time to plan a migration. Remote Installation Services (RIS) was deprecated after Windows Server 2008. Modern alternatives like PXE boot with WDS are more reliable and better supported. But if you're stuck on legacy hardware, the fix above will keep you going.