Hi,

A few months later, we’re still at an impasse over how and why Windows 10 Enterprise 1607 x64 loses time on the taskbar’s clock. Part 1 detailed the problem and some of my early attempts to fix it. Many of my colleagues are surprised when I tell them about this problem and often have no idea why. The first response is “check the BIOS/CMOS battery” (first thing I did), then ask “What are the NTP settings? (default).”

One lead which brought forward some interesting information was the health of the SSD in one of the affected computers. After running the Intel SSD utilities on the drive, it was over tolerance in the read/writes dept. In the span of two and a half years, the 180GB SSD wrote 37TB of data to the drive. The drive’s health was “good” but over tolerance. That figure seems large to me, but considering that we wipe user profiles at logoff and every user gets a new profile every time they log in, it makes sense. The default user profile is around 500MB in size. The login process occurs on an average of 5 times per day (MMV), five days per week (sometimes six), 39 weeks per year. This is just logging in and logging off, not considering Windows updates, AV definitions, whatever BigFix writes to the drive and any other Windows processes.

Aside from the time shifting issues, Microsoft Windows 10 runs fine, albeit under strict control. While this problem seems intermittent, it is easily dealt with by the end user. Simply, move the mouse, or perform a key press, and the screen will refresh to the correct time. Students taking exams or performing timed assignments were the first to notice the time-shifting problem. Several websites are available that show a clock on the center of the page, along with some ads. Their text is much larger and easily seen by students, including those in the back rows. During my exams, some professors would show these types of webpages or use a watch or the clock on their smartphone as a timer and would announce the time remaining at thirty or fifteen minute intervals.

These alternatives are suitable for the time being, despite the fact that the builtin Windows clock should be a reliable time source without any question. Going forward, I’ll continue to monitor the progress of this issue and hope that build 1709 or 1803 brings one of those silent fixes.

Thanks!