-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Add .NET 11 breaking change documentation for Environment.TickCount/TickCount64 #50921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ickCount64 Co-authored-by: gewarren <24882762+gewarren@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds comprehensive documentation for a behavioral breaking change in .NET 11 Preview 1 affecting Environment.TickCount and Environment.TickCount64 on Windows. The change aligns Windows behavior with other platforms and underlying OS wait APIs by excluding sleep/hibernation time from elapsed time measurements.
- Created breaking change documentation with detailed technical explanation of the behavior change from
GetTickCount64toQueryUnbiasedInterruptTime - Established .NET 11 compatibility documentation infrastructure including overview page and TOC structure
- Updated navigation links and added redirection for deprecated file paths
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
docs/core/compatibility/core-libraries/11/environment-tickcount-windows-behavior.md |
New breaking change article documenting the Windows-specific behavior change with comprehensive before/after descriptions and migration guidance |
docs/core/compatibility/11.md |
New .NET 11 breaking changes overview page following the established pattern from previous versions |
docs/core/compatibility/toc.yml |
Added .NET 11 section and entry for the TickCount breaking change; updated .NET 10 href to use 10.md |
docs/fundamentals/toc.yml |
Added .NET 11 breaking changes navigation entry and corrected .NET 10 reference path |
docs/core/install/upgrade.md |
Added .NET 11 breaking changes link to "See also" section |
.openpublishing.redirection.core.json |
Added redirection from 10.0.md to 10.md for consistency |
docs/core/compatibility/10.md |
Removed unused no-loc entries (Blazor, Kestrel) |
| @@ -0,0 +1,56 @@ | |||
| --- | |||
| title: "Breaking change - Environment.TickCount made consistent with Windows timeout behavior" | |||
Copilot
AI
Jan 7, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The title should use a colon instead of a hyphen after "Breaking change" to maintain consistency with other .NET 10 breaking change articles. Change "Breaking change -" to "Breaking change:".
Documents the behavioral change in .NET 11 Preview 1 where
Environment.TickCountandEnvironment.TickCount64on Windows now useQueryUnbiasedInterruptTimeinstead ofGetTickCount64, excluding sleep/hibernation time and aligning with OS wait API behavior.Changes
Created breaking change article (
core-libraries/11.0/environment-tickcount-windows-behavior.md)GetTickCount64(10-16ms resolution, included sleep time)QueryUnbiasedInterruptTime(interrupt timer resolution, excludes sleep time)SleepEx,WaitForMultipleObjectsEx) which changed in Windows 8/Server 2012Added .NET 11 compatibility infrastructure
11.0.mdoverview pagetoc.ymlwith new .NET 11 sectionImpact
Timers dependent on elapsed time during sleep/hibernation should migrate to
DateTime.UtcNow. Code already impacted on Linux/macOS will see consistent behavior across platforms.Original prompt
This section details on the original issue you should resolve
<issue_title>[Breaking change]: Environment.TickCount and Environment.TickCount64 made consistent with underlying OS timeout behavior</issue_title>
<issue_description>### Description
On Windows,
Environment.TickCountandEnvironment.TickCount64were brought inline with the behavior seen in the underlying wait APIs for the OS to no longer include sleep or hibernation time as part of the elapsed time measured. This also makes it consistent with the behavior seen on other platforms and ensures it updates at the same frequency as the underlying interrupt timer for the system allowing for higher responsiveness in apps that opted in to higher frequency updates.Version
.NET 11 Preview 1
Previous behavior
On all platforms,
Environment.TickCountsimply returns the truncated result ofEnvironment.TickCount64and so sees identical behavior, but is subject to overflow approximately every 49 days.On Windows,
Environment.TickCount64simply returned the result of the Win32GetTickCount64which updates at a fixed cadence of 10-16ms (typically 15.5ms) and included the time the system spent in sleep, hibernation, or other low-power states.On other platforms (such as Linux and MacOS),
Environment.TickCount64updated at the same frequency as the underlying interrupt timer for the system and only includes the time the system is considered "awake".New behavior
On all platforms,
Environment.TickCountmaintains its implementation and so mirrors the behavior ofEnvironment.TickCount64.On Windows,
Environment.TickCount64was updated to return the result of the Win32QueryUnbiasedInterruptTimeAPI. This brings it inline with the behavior used in the underlying wait APIs for the OS to no longer include non-awake time and update at the same frequency as the underlying interrupt timer for the system.On other platforms,
Environment.TickCount64retains its behavior, which is inline with the new behavior on Windows.Type of breaking change
Reason for change
Windows took a similar behavior breaking change in Win8/Server2012 and newer such that APIs which took a timeout (like
SleepExorWaitForMultipleObjectsEx) would no longer factor in non-awake time. This caused an inconsistency with .NET as such wait APIs are frequently used in conjunction withEnvironment.TickCount64leading to hard to diagnose bugs such as timers firing unexpectedly.Additionally, the underlying API used,
GetTickCount64, was a less precise, only updating at a fixed resolution. This resolution was not adjusted if the underlying interrupt timer for the OS had its frequency changed which could lead to additional work being done for apps that had opted to run at a higher priority. The behavior was then also inconsistent with the behavior seen on other platforms such as MacOS and Linux.The break therefore ensures consistency with the underlying OS and across platforms. It can also lead to higher responsiveness in apps that have opted into more frequent updates.
Recommended action
Most code should not experience any change in behavior as they will not have opted into higher frequency interrupt times, so they will continue seeing updates at the same frequency as before. However, if update frequency is relevant, users should ensure that their timeouts are passing in a correct value that meets the expectations of their code or ensure that the application is not opting into too high of a update frequency (this can only be done via P/Invoke APIs today).
Some code may see timers no longer fire immediately after a machine wakes from a sleeping or low-power state. If such time is relevant, the developer should utilize APIs such as
DateTime.UtcNowto ensure such time can always be included. Such code may have to account for potential clock adjustments.As a reminder, the behavior here is only changing on Windows and is now inline with the behavior seen on other platforms. Code that finds itself impacted by this on Windows is therefore likely already impacted by the same scenario on other platforms such as Linux and MacOS.
Feature area
Core .NET libraries
Affected APIs
System.Environment.TickCountSystem.Environment.TickCount64Associated WorkItem - 543456</issue_description>
Comments on the Issue (you are @copilot in this section)
@tannergooding @gewarren, we'...💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.
Internal previews