ANAVEM
Languagefr
Windows Event Viewer displaying system time change events on a monitoring dashboard
Event ID 11728InformationMicrosoft-Windows-Kernel-GeneralWindows

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

Event ID 11728 fires when Windows detects a system time change, typically from time synchronization services, manual adjustments, or hardware clock drift corrections.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
18 March 202612 min read 0
Event ID 11728Microsoft-Windows-Kernel-General 5 methods 12 min
Event Reference

What This Event Means

Event ID 11728 represents Windows' internal mechanism for logging system time modifications at the kernel level. When the system time changes by more than a minimal threshold, the kernel generates this event to maintain an audit trail of temporal modifications. The event captures the previous system time, new system time, and the process responsible for the change.

The Microsoft-Windows-Kernel-General provider generates this event as part of Windows' core system monitoring capabilities. Unlike user-level time change notifications, this kernel-level event cannot be suppressed or filtered by applications, ensuring complete visibility into system time modifications. The event includes detailed information about the time change magnitude and source process.

In enterprise environments, this event becomes crucial for maintaining time synchronization across distributed systems. Active Directory authentication relies heavily on synchronized time, with Kerberos tickets failing when time skew exceeds five minutes by default. Event 11728 helps administrators identify systems experiencing time drift before authentication failures occur.

The event also plays a vital role in forensic investigations and compliance auditing. Many regulatory frameworks require organizations to maintain accurate audit trails of system modifications, including time changes. Event 11728 provides the necessary evidence to demonstrate time synchronization integrity and identify potential tampering attempts.

Applies to

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

Possible Causes

  • Windows Time Service (W32Time) synchronizing with NTP servers
  • Manual time adjustment through Windows Settings or Control Panel
  • Hardware clock drift correction during system startup
  • Virtual machine time synchronization with hypervisor host
  • Third-party time synchronization software making adjustments
  • System resume from hibernation or sleep with significant time drift
  • BIOS/UEFI firmware updating system time during boot
  • Network time protocol corrections after connectivity restoration
  • Daylight saving time automatic adjustments
  • Time zone changes applied by Windows or applications
Resolution Methods

Troubleshooting Steps

01

Review Event Details in Event Viewer

Start by examining the specific details of Event ID 11728 to understand the time change context and magnitude.

  1. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and pressing Enter
  2. Navigate to Windows LogsSystem
  3. Filter the log by clicking Filter Current Log in the Actions pane
  4. Enter 11728 in the Event IDs field and click OK
  5. Double-click on recent Event ID 11728 entries to view detailed information
  6. Review the General tab for time change details including old time, new time, and time delta
  7. Check the Details tab for additional XML data including process information

Use PowerShell for more detailed analysis:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=11728} -MaxEvents 20 | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-Table -Wrap
Pro tip: Look for patterns in time changes - regular intervals suggest normal NTP sync, while irregular large changes may indicate hardware issues.
02

Analyze Time Synchronization Configuration

Investigate the Windows Time Service configuration to determine if time changes are expected behavior.

  1. Open an elevated Command Prompt or PowerShell session
  2. Check current time service status:
w32tm /query /status
  1. Review time service configuration:
w32tm /query /configuration
  1. Check NTP server sources:
w32tm /query /peers
  1. For domain-joined systems, verify domain controller time sync:
w32tm /monitor /domain
  1. Review time service registry settings at HKLM\SYSTEM\CurrentControlSet\Services\W32Time
  2. Check for third-party time sync software in Programs and Features
Warning: Modifying time service settings on domain controllers can affect entire domain authentication.
03

Monitor Time Drift Patterns with PowerShell

Create a comprehensive analysis of time change patterns to identify underlying issues.

  1. Extract detailed time change information:
$Events = Get-WinEvent -FilterHashtable @{LogName='System'; Id=11728; StartTime=(Get-Date).AddDays(-30)}
$TimeChanges = $Events | ForEach-Object {
    $XML = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        OldTime = $XML.Event.EventData.Data[0].'#text'
        NewTime = $XML.Event.EventData.Data[1].'#text'
        ProcessId = $XML.Event.EventData.Data[2].'#text'
    }
}
$TimeChanges | Export-Csv -Path "C:\Temp\TimeChanges.csv" -NoTypeInformation
  1. Analyze time change frequency:
$TimeChanges | Group-Object {$_.TimeCreated.Date} | Select-Object Name, Count | Sort-Object Name
  1. Calculate average time drift:
$TimeChanges | ForEach-Object {
    $OldTime = [DateTime]$_.OldTime
    $NewTime = [DateTime]$_.NewTime
    $DriftSeconds = ($NewTime - $OldTime).TotalSeconds
    [PSCustomObject]@{
        Date = $_.TimeCreated.Date
        DriftSeconds = $DriftSeconds
    }
} | Measure-Object DriftSeconds -Average -Maximum -Minimum
  1. Set up continuous monitoring with a scheduled task to track excessive drift
04

Investigate Hardware and Virtualization Issues

Examine hardware-related causes of time drift, particularly relevant for virtual machines and aging hardware.

  1. For virtual machines, check hypervisor time synchronization settings:
# VMware - Check VMware Tools time sync
Get-Service -Name "VMTools" | Select-Object Status, StartType
# Hyper-V - Check integration services
Get-VMIntegrationService -VMName $env:COMPUTERNAME -Name "Time Synchronization"
  1. Review system hardware information:
Get-WmiObject -Class Win32_ComputerSystem | Select-Object Manufacturer, Model, TotalPhysicalMemory
Get-WmiObject -Class Win32_BIOS | Select-Object Manufacturer, Version, ReleaseDate
  1. Check for hardware clock issues in System log:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1,6013,35,37} -MaxEvents 50 | Where-Object {$_.Message -like "*time*" -or $_.Message -like "*clock*"}
  1. For physical systems, verify CMOS battery status and BIOS time settings
  2. Review power management settings that might affect hardware clock:
powercfg /query SCHEME_CURRENT SUB_SLEEP
  1. Check Windows Hardware Error Architecture (WHEA) logs for hardware issues:
Get-WinEvent -LogName "Microsoft-Windows-Kernel-WHEA/Errors" -MaxEvents 20
05

Configure Advanced Time Monitoring and Alerting

Implement comprehensive monitoring to proactively detect and alert on time synchronization issues.

  1. Create a custom Event Viewer view for time-related events:
<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[(EventID=11728 or EventID=1 or EventID=35 or EventID=37)]]</Select>
  </Query>
</QueryList>
  1. Set up PowerShell-based monitoring script:
# Save as Monitor-TimeChanges.ps1
param(
    [int]$MaxDriftSeconds = 60,
    [string]$EmailTo = "admin@company.com",
    [string]$SMTPServer = "mail.company.com"
)

$RecentEvents = Get-WinEvent -FilterHashtable @{LogName='System'; Id=11728; StartTime=(Get-Date).AddHours(-1)}
foreach ($Event in $RecentEvents) {
    $XML = [xml]$Event.ToXml()
    $OldTime = [DateTime]$XML.Event.EventData.Data[0].'#text'
    $NewTime = [DateTime]$XML.Event.EventData.Data[1].'#text'
    $DriftSeconds = [Math]::Abs(($NewTime - $OldTime).TotalSeconds)
    
    if ($DriftSeconds -gt $MaxDriftSeconds) {
        $Subject = "High Time Drift Detected on $env:COMPUTERNAME"
        $Body = "Time drift of $DriftSeconds seconds detected at $($Event.TimeCreated)"
        Send-MailMessage -To $EmailTo -Subject $Subject -Body $Body -SmtpServer $SMTPServer
    }
}
  1. Create scheduled task for monitoring:
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-File C:\Scripts\Monitor-TimeChanges.ps1"
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Hours 1)
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName "TimeChangeMonitoring" -Action $Action -Trigger $Trigger -Settings $Settings -RunLevel Highest
  1. Configure Windows Event Forwarding for centralized monitoring in enterprise environments
  2. Implement SCOM or other monitoring solutions to track time synchronization across the infrastructure

Overview

Event ID 11728 from Microsoft-Windows-Kernel-General appears in the System log whenever Windows detects a system time change. This event fires during normal time synchronization operations, manual time adjustments through Control Panel or Settings, or when the system corrects for hardware clock drift. The event captures both the old and new time values, making it valuable for auditing time changes across your environment.

This event commonly appears on domain-joined systems during NTP synchronization with domain controllers, standalone systems syncing with internet time servers, or virtual machines experiencing time drift corrections. While typically informational, frequent occurrences may indicate underlying hardware issues, network connectivity problems, or misconfigured time services.

System administrators use this event to track time synchronization health, investigate authentication issues caused by time skew, and maintain compliance with audit requirements. The event provides precise timestamps and time delta information, making it essential for forensic analysis and troubleshooting time-sensitive applications.

Frequently Asked Questions

What does Event ID 11728 mean and when should I be concerned?+
Event ID 11728 indicates that Windows detected a system time change. This is normal behavior during time synchronization with NTP servers, manual time adjustments, or hardware clock corrections. You should be concerned if you see frequent large time changes (more than a few minutes), which could indicate hardware clock issues, network connectivity problems, or potential security concerns like time tampering attempts.
How can I distinguish between normal time sync and problematic time changes?+
Normal time synchronization typically involves small adjustments (seconds to minutes) at regular intervals, usually every few hours. Problematic changes show irregular patterns with large time jumps, frequent corrections, or changes occurring outside of scheduled sync windows. Use PowerShell to analyze the time delta in Event 11728 entries - consistent small adjustments indicate healthy sync, while erratic large changes suggest underlying issues.
Can Event ID 11728 help me troubleshoot Kerberos authentication failures?+
Yes, Event ID 11728 is crucial for diagnosing Kerberos authentication issues caused by time skew. Kerberos requires client and server times to be within 5 minutes by default. Review Event 11728 entries around the time of authentication failures to identify if time changes occurred. Large time adjustments or frequent corrections may indicate the system cannot maintain accurate time, leading to authentication problems.
Why am I seeing Event ID 11728 frequently on my virtual machines?+
Virtual machines commonly experience time drift due to CPU scheduling, host system load, or hypervisor time synchronization mechanisms. VMware Tools, Hyper-V Integration Services, and other virtualization platforms automatically correct time drift, generating Event 11728. This is normal behavior, but excessive frequency may indicate resource contention on the host or misconfigured time synchronization settings between guest and host.
How do I prevent excessive Event ID 11728 entries from cluttering my logs?+
While you cannot disable Event ID 11728 (it's a kernel-level audit event), you can reduce frequency by optimizing time synchronization. Configure appropriate NTP polling intervals using 'w32tm /config /update-interval', ensure stable network connectivity to time servers, address hardware clock issues, and properly configure virtualization time sync. For log management, use Event Viewer filters or log forwarding rules to separate time events from critical system events.
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...