FRS_ERR_STARTING_SERVICE 0X00001F42 – Fix File Replication

What triggers FRS_ERR_STARTING_SERVICE (0X00001F42)?

You see this error when the File Replication Service (FRS) tries to start on a domain controller running Windows Server 2003, 2008, or 2008 R2. It usually happens after a forced reboot, a power failure, or if someone manually deleted files inside the %systemroot%\ntfrs\jet folder. The exact text is "The file replication service cannot be started. The error code is: 0X00001F42."

Don't panic. This isn't a hardware failure. It's almost always a corrupt database or log file. I've seen this dozens of times. The fixes below work in that order—start with the quick one, and only move up if needed.

30-second fix: Reset the FRS log files

This is the simplest and most common fix. Corrupt transaction logs prevent FRS from initializing. Here's what you do:

1. Stop the FRS service: Open Command Prompt as Administrator. Type net stop ntfrs and press Enter. You should see "The File Replication Service service is stopping." Wait for it to finish.
2. Delete the log files: Go to C:\Windows\ntfrs\jet\log. Inside that folder, you'll see files named edb.log, edbXXXXX.log (where XXXXX is a number), and res1.log, res2.log. Delete every single file in that folder. Yes, all of them. Don't touch any subfolders (like temp or system).
3. Start the service: Back in the Command Prompt, type net start ntfrs. After you hit Enter, watch the output. If it says "The File Replication Service service started successfully," you're done. Check Event Viewer for ID 13516 (FRS is operational).

Expected outcome: After deleting the log files and restarting, FRS should rebuild them automatically. If the service still fails with the same error, move to the moderate fix.

5-minute fix: Check and fix the FRS registry key

If the log reset didn't work, the problem is likely in the registry. FRS stores its working directory path under HKLM\System\CurrentControlSet\Services\NtFrs\Parameters. Sometimes this path gets corrupted or points to a missing location.

1. Open Registry Editor: Press Win + R, type regedit, and hit Enter. Click Yes on the UAC prompt.
2. Navigate to the key: Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters.
3. Check the value: Look for a string value named Working Directory. It should be %systemroot%\ntfrs\jet. If it's missing, empty, or points somewhere else, right-click in the right pane, choose New > String Value, name it Working Directory, and set its data to %systemroot%\ntfrs\jet.
4. Check permissions: Right-click the NtFrs key (not Parameters), choose Permissions. Make sure SYSTEM and Administrators have Full Control. Apply and close.
5. Reboot the server (or restart FRS manually: net stop ntfrs then net start ntfrs).

Expected outcome: After fixing the registry, FRS should start. If it still fails, the database itself is corrupt. Move to the advanced fix.

15+ minute fix: Reinitialize FRS (burrflag method)

This is the nuclear option. It wipes the FRS database and forces a full sync from a partner domain controller. Only do this if the first two fixes failed. You'll need NETDOM tool (available on the server by default in Windows Server 2008 R2 and later; for 2003 or 2008, you may need to install it from the Windows Support Tools).

1. Identify a good partner: Run netdom query fsmo to find the PDC (Primary Domain Controller) emulator. That's often the safest source. Or ask another admin which DC has a healthy SYSVOL.
2. Stop the FRS service: net stop ntfrs.
3. Delete the entire jet folder: Run rmdir /s /q C:\Windows\ntfrs\jet. This removes the database, logs, everything. Don't worry—FRS will create a new one.
4. Set the burrflag: Open Registry Editor, go to HKLM\System\CurrentControlSet\Services\NtFrs\Parameters. If you don't see a Backup/Restore subkey, create it: right-click Parameters, choose New > Key, name it Backup/Restore. Inside that key, create a DWORD named Bur Flags and set it to 4 (for a non-authoritative restore—it will copy from a partner).
5. Create a placeholder file: mkdir C:\Windows\ntfrs\jet\log (FRS needs the log folder to exist).
6. Start the service: net start ntfrs. This time it will take a while—up to 10 minutes. Check Event Viewer for ID 13516 (FRS is ready) or ID 13508 (cannot contact partner). If you get 13508, verify DNS and network connectivity to the partner DC.
7. Remove the Bur Flags after the service is running and SYSVOL has synced (check C:\Windows\SYSVOL for your domain folders). Set the Bur Flags value back to 0 or delete the DWORD.

Expected outcome: After a few minutes, FRS should rebuild the database and replicate SYSVOL from the partner. If replication still fails, you might have a deeper network issue—check firewall ports (UDP 389, TCP 135, TCP 445, UDP 138) between DCs, and verify time sync.

One more thing to check

I've seen FRS fail with 0X00001F42 when a server's system date was set to 10 years in the future. The database timestamps freak out. So verify the date and time are correct before you dive into these fixes. That takes 10 seconds and can save you a lot of headache.

If none of these work, consider migrating to DFS Replication if you're on Server 2008 R2 or newer. FRS is deprecated—Microsoft stopped supporting it in 2014. But that's a bigger project for another day.