ANAVEM
Languagefr
Windows Event Viewer showing system event logs on a monitoring dashboard
Event ID 16384InformationMicrosoft-Windows-Kernel-GeneralWindows

Windows Event ID 16384 – Microsoft-Windows-Kernel-General: System Time Change Detected

Event ID 16384 fires when Windows detects a system time change, either manual or automatic. Critical for security auditing and troubleshooting time synchronization issues in domain environments.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 20269 min read 0
Event ID 16384Microsoft-Windows-Kernel-General 5 methods 9 min
Event Reference

What This Event Means

Event ID 16384 serves as Windows' primary mechanism for logging system time modifications. The kernel generates this event whenever the system clock undergoes adjustment, whether through user action, automated synchronization, or external time sources. This event plays a crucial role in maintaining audit trails for compliance requirements and troubleshooting time-related issues in enterprise environments.

The event structure includes the previous system time, new system time, and the process or service responsible for the change. When users manually adjust the clock through Control Panel or Settings, the event logs the user account and process details. For automatic changes via Windows Time service (W32Time), the event identifies the service and synchronization source.

In domain environments, this event becomes particularly important for tracking time drift and synchronization issues. Domain controllers rely on accurate time synchronization for Kerberos authentication, and time discrepancies exceeding five minutes can cause authentication failures. Event 16384 helps administrators identify when time changes occur and correlate them with authentication problems or service disruptions.

Security teams monitor this event for unauthorized time changes that could indicate tampering attempts or malware activity. Attackers sometimes modify system time to bypass time-based security controls or obscure log timestamps. Regular monitoring of Event 16384 patterns helps establish baseline time change behavior and detect anomalies.

Applies to

Windows 10Windows 11Windows Server 2019/2022/2025
Analysis

Possible Causes

  • Manual time adjustment through Windows Settings or Control Panel
  • Automatic time synchronization with domain controllers or NTP servers
  • Windows Time service (W32Time) corrections due to clock drift
  • Daylight saving time transitions handled by the operating system
  • Hardware clock adjustments during system boot or resume from sleep
  • Third-party time synchronization software making system time changes
  • Virtual machine time synchronization with hypervisor host
  • BIOS/UEFI firmware time updates during system startup
  • Network time protocol (NTP) client synchronization events
  • Time zone changes applied by users or group policy
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific details of Event ID 16384 to understand what triggered the time change.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSystem
  3. Filter for Event ID 16384 by right-clicking the System log and selecting Filter Current Log
  4. Enter 16384 in the Event IDs field and click OK
  5. Double-click on recent Event 16384 entries to view detailed information
  6. Check the General tab for old and new time values
  7. Review the Details tab for process information and change source

Use PowerShell to query multiple events efficiently:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=16384} -MaxEvents 20 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap
Pro tip: Look for the ProcessId and ProcessName in the event details to identify whether the change was user-initiated or service-driven.
02

Check Windows Time Service Configuration

Investigate the Windows Time service configuration to understand automatic time synchronization behavior.

  1. Open an elevated Command Prompt or PowerShell
  2. Check the current time service configuration:
w32tm /query /configuration
  1. Review the time source and synchronization settings:
w32tm /query /source
w32tm /query /status
  1. Check for recent time synchronization events:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'} -MaxEvents 10
  1. Verify domain time synchronization hierarchy:
w32tm /query /peers
  1. Test manual synchronization to identify issues:
w32tm /resync /force
Warning: Forcing time synchronization can cause temporary authentication issues if the time change is significant.
03

Analyze Time Change Patterns and Frequency

Examine the frequency and patterns of time changes to identify potential issues or establish baselines.

  1. Query Event 16384 occurrences over the past 30 days:
$StartTime = (Get-Date).AddDays(-30)
$Events = Get-WinEvent -FilterHashtable @{LogName='System'; Id=16384; StartTime=$StartTime}
$Events | Group-Object {$_.TimeCreated.Date} | Sort-Object Name
  1. Create a detailed analysis of time changes:
$Events | ForEach-Object {
    $EventXML = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        ProcessId = $EventXML.Event.EventData.Data[0].'#text'
        ProcessName = $EventXML.Event.EventData.Data[1].'#text'
        OldTime = $EventXML.Event.EventData.Data[2].'#text'
        NewTime = $EventXML.Event.EventData.Data[3].'#text'
    }
} | Format-Table -AutoSize
  1. Check for correlation with system events:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(1074,6005,6006,16384); StartTime=$StartTime} | Sort-Object TimeCreated
  1. Export time change data for further analysis:
$Events | Export-Csv -Path "C:\Temp\TimeChanges.csv" -NoTypeInformation
Pro tip: Look for patterns like daily occurrences that might indicate scheduled tasks or regular synchronization intervals.
04

Investigate Security and Compliance Implications

Examine time changes from a security perspective and ensure compliance with audit requirements.

  1. Check for unauthorized time changes by correlating with user logon events:
$TimeChanges = Get-WinEvent -FilterHashtable @{LogName='System'; Id=16384; StartTime=(Get-Date).AddDays(-7)}
$LogonEvents = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)}

# Correlate time changes with user sessions
$TimeChanges | ForEach-Object {
    $ChangeTime = $_.TimeCreated
    $NearbyLogons = $LogonEvents | Where-Object {[Math]::Abs(($_.TimeCreated - $ChangeTime).TotalMinutes) -lt 30}
    [PSCustomObject]@{
        TimeChange = $ChangeTime
        NearbyLogons = $NearbyLogons.Count
        Users = ($NearbyLogons | ForEach-Object {([xml]$_.ToXml()).Event.EventData.Data[5].'#text'} | Select-Object -Unique) -join ', '
    }
}
  1. Review Group Policy settings affecting time synchronization:
Get-ItemProperty -Path "HKLM\SOFTWARE\Policies\Microsoft\W32Time\TimeProviders\NtpClient" -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKLM\SOFTWARE\Policies\Microsoft\W32Time\Config" -ErrorAction SilentlyContinue
  1. Check for time-related security events:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=@(4616,4624,4625)} -MaxEvents 50 | Where-Object {$_.Message -match 'time|clock'}
  1. Generate compliance report for time changes:
$Report = $TimeChanges | ForEach-Object {
    $EventXML = [xml]$_.ToXml()
    [PSCustomObject]@{
        Timestamp = $_.TimeCreated
        EventId = $_.Id
        Source = $_.ProviderName
        ProcessId = $EventXML.Event.EventData.Data[0].'#text'
        ProcessName = $EventXML.Event.EventData.Data[1].'#text'
        Description = "System time changed"
        Impact = "Potential authentication/audit impact"
    }
}
$Report | Export-Csv -Path "C:\Temp\TimeChangeAudit.csv" -NoTypeInformation
05

Configure Advanced Time Monitoring and Alerting

Set up proactive monitoring for time changes to detect issues before they impact operations.

  1. Create a scheduled task to monitor time changes:
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-WindowStyle Hidden -Command \"Get-WinEvent -FilterHashtable @{LogName='System'; Id=16384; StartTime=(Get-Date).AddMinutes(-5)} | Export-Csv -Path 'C:\Logs\TimeChanges.csv' -Append -NoTypeInformation\""
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration (New-TimeSpan -Days 365)
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName "TimeChangeMonitor" -Action $Action -Trigger $Trigger -Settings $Settings -User "SYSTEM"
  1. Configure Windows Event Forwarding for centralized monitoring:
# On collector server
wecutil qc /q

# Create subscription for Event 16384
$SubscriptionXML = @"
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
    <SubscriptionId>TimeChangeEvents</SubscriptionId>
    <SubscriptionType>SourceInitiated</SubscriptionType>
    <Description>Forward Event ID 16384 time change events</Description>
    <Enabled>true</Enabled>
    <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
    <ConfigurationMode>Normal</ConfigurationMode>
    <Query>
        <![CDATA[
        <QueryList>
            <Query Id="0">
                <Select Path="System">*[System[EventID=16384]]</Select>
            </Query>
        </QueryList>
        ]]>
    </Query>
</Subscription>
"@

$SubscriptionXML | Out-File -FilePath "C:\Temp\TimeChangeSubscription.xml"
wecutil cs "C:\Temp\TimeChangeSubscription.xml"
  1. Set up registry monitoring for time service changes:
# Monitor W32Time registry changes
$RegPath = "HKLM\SYSTEM\CurrentControlSet\Services\W32Time"
Register-WmiEvent -Query "SELECT * FROM RegistryTreeChangeEvent WHERE Hive='HKEY_LOCAL_MACHINE' AND RootPath='SYSTEM\\CurrentControlSet\\Services\\W32Time'" -Action {
    Write-EventLog -LogName Application -Source "TimeMonitor" -EventId 1001 -Message "W32Time registry modification detected"
}
Warning: Ensure adequate disk space for log files when implementing continuous monitoring solutions.

Overview

Event ID 16384 from the Microsoft-Windows-Kernel-General source logs whenever Windows detects a system time change. This event fires during manual time adjustments, automatic time synchronization with domain controllers or NTP servers, and daylight saving time transitions. The event captures both the previous and new time values, making it essential for security auditing and compliance tracking.

This event appears in the System log and provides detailed information about what triggered the time change, whether it was user-initiated, service-driven, or caused by external synchronization. In enterprise environments, unexpected time changes can indicate security issues, misconfigured time services, or hardware clock problems. The event helps administrators track time-related changes that could affect Kerberos authentication, certificate validation, and log correlation across systems.

Windows generates this event through the kernel's time management subsystem, which monitors all time adjustment operations. The event includes process information when the change is user-initiated and service details when triggered by the Windows Time service or other system components.

Frequently Asked Questions

What does Event ID 16384 mean and when should I be concerned?+
Event ID 16384 indicates a system time change occurred on your Windows machine. You should be concerned when these events appear frequently without explanation, occur outside of normal synchronization windows, or correlate with authentication failures. In domain environments, unexpected time changes can break Kerberos authentication and cause service disruptions. Normal occurrences include scheduled NTP synchronization, daylight saving time transitions, and manual time adjustments by administrators.
How can I determine what caused a specific time change in Event 16384?+
Examine the event details in Event Viewer or use PowerShell to parse the event XML. The event contains ProcessId and ProcessName fields that identify the source of the change. Common sources include 'svchost.exe' for Windows Time service, 'explorer.exe' for user-initiated changes through Settings, or specific application names for third-party time sync software. Cross-reference the timestamp with user logon events and scheduled tasks to identify the root cause.
Can Event ID 16384 indicate a security breach or malware activity?+
Yes, unexpected or frequent Event 16384 occurrences can indicate security issues. Malware sometimes modifies system time to evade time-based security controls, bypass certificate validation, or obscure log timestamps. Look for time changes that occur outside normal business hours, correlate with suspicious process activity, or happen without corresponding user logons. Establish baseline patterns for your environment and investigate deviations. Always correlate with other security events and endpoint protection alerts.
Why do I see Event 16384 multiple times during system startup?+
Multiple Event 16384 entries during startup are normal and occur due to various time synchronization processes. The hardware clock may differ from the last saved system time, triggering an initial adjustment. Windows Time service then performs synchronization with configured time sources, potentially causing additional changes. Virtual machines often experience this due to host time synchronization. UEFI firmware updates and time zone detection can also generate multiple events during boot. This behavior is expected unless the time changes are excessive or cause authentication issues.
How do I prevent unauthorized time changes while maintaining proper synchronization?+
Configure Group Policy to restrict time change permissions while ensuring proper service accounts can synchronize time. Set 'Change the system time' user right to only include Administrators and LOCAL SERVICE. Configure Windows Time service with appropriate NTP servers and synchronization intervals. In domain environments, ensure proper time hierarchy with PDC emulator as the authoritative time source. Monitor Event 16384 for unauthorized changes and implement alerting for time changes outside maintenance windows. Consider using hardware security modules or trusted time sources for high-security environments.
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...