Yeah, that error's a pain. You're staring at the Service Control Manager, FRS won't die, and you're wondering if a reboot is the only way. Hold off on that. Here's the fix that works every time.
The Direct Fix
First, stop the service forcefully. Open an elevated command prompt and run:
net stop NtFrs /yThe /y flag tells it to drop dependencies. If that hangs for more than 30 seconds, you need to kill the process itself:
taskkill /f /im ntfrs.exeNow, don't restart it yet. Go to the FRS staging directory. The default path is:
C:\Windows\Sysvol\Staging\NtFrs_PreExisting__See_EventLogDelete everything in there. No, not the folder itself — just the contents. This is where the stuck files live, and they're what's blocking the stop.
Next, open the registry. Navigate to:
HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\ParametersLook for Staging Space Limit. If it's set below 300 MB, bump it to at least 300 MB. Low values cause journal wrap, which gets us to the root cause in a second.
Now start FRS again:
net start NtFrsThat'll fix it about 80% of the time. If it doesn't, check the event log for the FRS source. Look for event ID 13508 or 13509 — those indicate a journal wrap, and you'll need to do a non-authoritative restore.
Why This Works
The culprit here is almost always a journal wrap. NTFS's USN journal gets overwritten because the staging area fills up faster than replication can process it. FRS loses track of changes, panics, and enters a stuck state where it ignores stop requests.
Clearing the staging folder gives FRS a clean slate. It forces the service to rebuild its internal state, and the USN journal can catch up. Bumping the staging limit prevents the same overflow from happening again.
Also, the taskkill /f is your sledgehammer. Sometimes FRS just won't respond to normal stop signals, and killing the process is the only way to break the deadlock. It's not elegant, but it works.
Less Common Variations
Orphaned Staging Folder Junction
Sometimes the Staging folder is a junction point that points to a non-existent location. Check with:
dir C:\Windows\Sysvol\StagingIf you see a broken junction, remove it with rmdir /s and recreate the folder as a real directory. Then restart FRS.
Fsutil USN Journal Corruption
If journal wrap isn't the issue, try deleting the USN journal entirely. On the affected volume (usually C:), run:
fsutil usn deletejournal /d C:Reboot the server. FRS will recreate the journal. This is a last resort because it forces a full scan of the volume, but it clears up any corruption.
DNS or Network Path Issues
On rare occasions, FRS can't stop because it's stuck in an RPC call to a partner that's unreachable. Check the DNS entry for the partner server and make sure it's resolving correctly. Test with nslookup partner.domain.com. If the partner is dead, remove it from the FRS replica set via ntfrsutl ds.
Prevention
The real fix is to get off FRS altogether. Microsoft's been pushing DFSR since Windows Server 2008, and FRS is deprecated. If you're still on 2003 or 2008 (non-R2), start planning a migration. The dfsrmig tool is your friend.
If you're stuck with FRS for now, do these three things:
- Keep staging space above 300 MB — I'd set it to 1 GB if you have more than 500 user accounts.
- Monitor the FRS event log weekly. Don't wait for errors to pile up.
- Make sure all DCs are running the same service pack. Mixed versions cause replication quirks.
And don't bother with the Enable Journal Wrap Automatic Restore registry key — it rarely helps and can mask bigger issues.
That's it. Get FRS stopped, clean the staging, bump the limit, and you're back in business. If you're still stuck after this, you may have a deeper corruption — and that's when you call in a professional.