ANAVEM
Languagefr
Windows server monitoring displays showing file replication status in a professional data center environment
Event ID 5805InformationDFSRWindows

Windows Event ID 5805 – DFSR: Database Recovery Completed Successfully

Event ID 5805 indicates that the Distributed File System Replication (DFSR) service has successfully completed database recovery operations after an unexpected shutdown or corruption event.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 5805DFSR 5 methods 12 min
Event Reference

What This Event Means

The Distributed File System Replication service maintains a local database that tracks file metadata, replication state, and version information for all replicated content. This database, typically located in the system volume information folder, is critical for maintaining consistency across replication partners. When Windows shuts down properly, DFSR cleanly closes this database and commits all pending transactions.

However, when the system experiences an unexpected shutdown, power loss, or the DFSR service terminates abnormally, the database may be left in an inconsistent state with uncommitted transactions or corrupted pages. During the next service startup, DFSR automatically detects this condition and initiates database recovery procedures using built-in transaction log replay mechanisms.

The recovery process involves several phases: first, DFSR checks the database integrity and identifies any corruption or inconsistencies. Next, it replays transaction logs to recover committed operations that weren't written to the database before the interruption. Finally, it rolls back any incomplete transactions and rebuilds necessary indexes. Event ID 5805 confirms that this entire recovery process completed successfully without data loss.

While this event indicates successful recovery, administrators should investigate the root cause of frequent database recovery events, as they may indicate hardware issues, improper shutdown procedures, or system instability that could eventually lead to data loss or replication failures.

Applies to

Windows Server 2019Windows Server 2022Windows Server 2025
Analysis

Possible Causes

  • Unexpected system shutdown or power failure during DFSR operations
  • DFSR service terminated abnormally by system crash or manual intervention
  • Storage subsystem issues causing database write failures
  • Memory corruption affecting DFSR database operations
  • Antivirus software interfering with DFSR database files
  • Disk space exhaustion on the system volume during database operations
  • Hardware failures affecting storage controllers or memory modules
Resolution Methods

Troubleshooting Steps

01

Review Event Details and Timeline

Start by examining the specific details of Event ID 5805 and correlating it with system events to understand the recovery context.

  1. Open Event Viewer and navigate to Applications and Services LogsDFS Replication
  2. Locate Event ID 5805 and review the event details for recovery duration and affected databases
  3. Check the System log for events around the same timeframe:
    Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddHours(-24)} | Where-Object {$_.Id -in @(1074,1076,6005,6006,6008)} | Select-Object TimeCreated,Id,LevelDisplayName,Message
  4. Look for shutdown events (1074), startup events (6005), or unexpected shutdown indicators (6008)
  5. Document the frequency of recovery events using PowerShell:
    Get-WinEvent -FilterHashtable @{LogName='DFS Replication'; Id=5805; StartTime=(Get-Date).AddDays(-30)} | Group-Object {$_.TimeCreated.Date} | Sort-Object Name
Pro tip: If Event ID 5805 occurs frequently (daily or multiple times per week), investigate system stability and shutdown procedures.
02

Verify DFSR Service Health and Configuration

Ensure the DFSR service is running properly and check for any configuration issues that might contribute to database problems.

  1. Check DFSR service status and startup type:
    Get-Service -Name DFSR | Select-Object Name,Status,StartType,ServiceType
  2. Review DFSR configuration and replication group health:
    Get-DfsReplicationGroup | Get-DfsrState -Verbose
  3. Check for DFSR database location and available disk space:
    $dfsrConfig = Get-ItemProperty -Path "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters"
    $dbPath = $dfsrConfig."Database Directory"
    Get-WmiObject -Class Win32_LogicalDisk | Where-Object {$_.DeviceID -eq (Split-Path $dbPath -Qualifier)} | Select-Object DeviceID,Size,FreeSpace,@{Name="FreeSpaceGB";Expression={[math]::Round($_.FreeSpace/1GB,2)}}
  4. Verify DFSR database integrity using built-in tools:
    dfsrdiag dumpmig /rgname:"ReplicationGroupName" /rfname:"ReplicatedFolderName"
  5. Check for any pending replication backlog that might indicate ongoing issues:
    dfsrdiag backlog /rgname:"ReplicationGroupName" /rfname:"ReplicatedFolderName" /smem:SourceServer /rmem:DestinationServer
03

Analyze Storage Subsystem and Hardware Health

Investigate potential hardware or storage issues that could cause database corruption requiring recovery.

  1. Check system event logs for storage-related errors:
    Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-7)} | Where-Object {$_.ProviderName -match 'disk|storage|ntfs|volsnap'} | Where-Object {$_.LevelDisplayName -match 'Error|Warning'} | Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message
  2. Run disk health checks on the system volume:
    Get-PhysicalDisk | Get-StorageReliabilityCounter | Select-Object DeviceId,Temperature,PowerOnHours,UnsafeShutdownCount,ReadErrorsTotal,WriteErrorsTotal
  3. Check SMART data for storage devices:
    Get-WmiObject -Namespace root\wmi -Class MSStorageDriver_FailurePredictStatus | Select-Object InstanceName,PredictFailure,Reason
  4. Verify file system integrity on the system volume:
    chkdsk C: /f /r /x
  5. Monitor memory usage and check for memory errors:
    Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 50 | Select-Object TimeCreated,Message
Warning: Running chkdsk with /f parameter requires system restart and can take several hours on large volumes.
04

Configure Proper Shutdown Procedures and Monitoring

Implement measures to prevent unexpected shutdowns and improve monitoring of DFSR database health.

  1. Configure Group Policy to prevent forced shutdowns during replication:
    Navigate to Computer ConfigurationAdministrative TemplatesSystemShutdown Options
    Enable "Turn off automatic termination of applications that block or cancel shutdown"
  2. Set up DFSR performance monitoring:
    $counterPaths = @(
        "\DFS Replication Service Connections(*)\Total Bytes Received",
        "\DFS Replication Service Volumes(*)\Database Commits",
        "\DFS Replication Service Volumes(*)\Database Lookups"
    )
    Get-Counter -Counter $counterPaths -SampleInterval 60 -MaxSamples 10
  3. Create a scheduled task to monitor DFSR health:
    $action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command Get-DfsrState | Out-File C:\Logs\DFSRHealth.log -Append"
    $trigger = New-ScheduledTaskTrigger -Daily -At "02:00AM"
    Register-ScheduledTask -TaskName "DFSR Health Check" -Action $action -Trigger $trigger -Description "Daily DFSR health monitoring"
  4. Configure Windows to delay shutdown for DFSR service:
    Modify registry key HKLM\SYSTEM\CurrentControlSet\Control
    Set WaitToKillServiceTimeout to 60000 (60 seconds)
  5. Enable DFSR debug logging for detailed troubleshooting:
    wevtutil sl "DFS Replication" /l:5
05

Advanced Database Recovery and Optimization

Perform advanced DFSR database maintenance and optimization to prevent future recovery events.

  1. Stop DFSR service and backup current database:
    Stop-Service DFSR -Force
    $dbPath = (Get-ItemProperty "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters")."Database Directory"
    Copy-Item $dbPath "$dbPath.backup.$(Get-Date -Format 'yyyyMMdd')" -Recurse
  2. Perform database compaction to reduce fragmentation:
    esentutl /d "$dbPath\DataBase_GUID.edb" /o
  3. Check database integrity and repair if necessary:
    esentutl /g "$dbPath\DataBase_GUID.edb" /v
    esentutl /p "$dbPath\DataBase_GUID.edb" /o
  4. Optimize DFSR database settings in registry:
    Navigate to HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters
    Create DWORD MaxLogFileSize with value 67108864 (64MB)
    Create DWORD LogFileCheckpointDepthMax with value 20971520
  5. Restart DFSR service and verify operation:
    Start-Service DFSR
    Start-Sleep 30
    Get-WinEvent -FilterHashtable @{LogName='DFS Replication'; Id=@(4102,5002)} -MaxEvents 5
  6. Monitor for successful startup and verify no immediate recovery events:
    Get-WinEvent -FilterHashtable @{LogName='DFS Replication'; Id=5805; StartTime=(Get-Date).AddMinutes(-10)} -ErrorAction SilentlyContinue
Warning: Database repair operations can take several hours and may result in data loss. Always backup the database before performing repair operations.

Overview

Event ID 5805 from the DFSR (Distributed File System Replication) service indicates successful completion of database recovery operations. This event fires when the DFSR service starts up and detects that its internal database requires recovery due to an improper shutdown, power failure, or database corruption. The recovery process involves checking database integrity, rolling back incomplete transactions, and ensuring the replication database is in a consistent state.

This event typically appears in the DFS Replication event log after system restarts, particularly following unexpected shutdowns or when the DFSR service was terminated abnormally. While this is an informational event indicating successful recovery, frequent occurrences may suggest underlying issues with system stability, storage subsystem problems, or improper shutdown procedures.

The DFSR database stores metadata about replicated files, version vectors, and replication state information. When this database becomes inconsistent, the service automatically initiates recovery procedures to maintain data integrity across the replication topology. Understanding this event helps administrators monitor DFSR health and identify potential infrastructure issues.

Frequently Asked Questions

What does Event ID 5805 mean and is it serious?+
Event ID 5805 indicates that DFSR successfully completed database recovery after detecting an inconsistent state, typically following an unexpected shutdown. While the event itself shows successful recovery, frequent occurrences suggest underlying system stability issues that should be investigated. The recovery process ensures data integrity, but repeated events may indicate hardware problems, improper shutdown procedures, or storage subsystem issues that could eventually lead to more serious problems.
How often should I expect to see Event ID 5805 in my environment?+
In a healthy environment, Event ID 5805 should be rare, appearing only after genuine unexpected shutdowns like power failures or system crashes. If you see this event more than once per month per server, investigate system stability, shutdown procedures, and hardware health. Frequent recovery events (weekly or daily) indicate serious underlying issues that require immediate attention, as they suggest the DFSR database is repeatedly being left in an inconsistent state.
Can Event ID 5805 cause data loss in my replicated folders?+
Event ID 5805 itself indicates successful recovery without data loss. The DFSR recovery process is designed to maintain data integrity by replaying committed transactions and rolling back incomplete ones. However, the underlying conditions that trigger frequent recovery events (hardware failures, corruption, unexpected shutdowns) could potentially lead to data loss if not addressed. The recovery process protects against database corruption but cannot prevent data loss from physical storage failures or severe system corruption.
What should I do if Event ID 5805 appears every time I restart my server?+
If Event ID 5805 appears after every restart, check your shutdown procedures and system configuration. Ensure the DFSR service has adequate time to shut down cleanly by increasing the WaitToKillServiceTimeout registry value. Verify that no applications or processes are forcibly terminating the DFSR service during shutdown. Check for storage subsystem issues, antivirus interference, or insufficient disk space. Consider enabling DFSR debug logging to capture more detailed information about what's causing the database to require recovery on each startup.
How can I prevent Event ID 5805 from occurring in the future?+
Prevent Event ID 5805 by ensuring proper system shutdown procedures, maintaining adequate disk space on the system volume, and addressing hardware issues promptly. Configure Group Policy to prevent forced application termination during shutdown, increase service shutdown timeout values, and implement UPS systems to prevent unexpected power loss. Regular monitoring of storage health, memory integrity, and system stability will help identify potential issues before they cause database corruption. Establish proper maintenance windows for system updates and reboots to ensure clean shutdowns.
Documentation

References (2)

Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Senior IT Journalist & Cloud Architect

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...