alt.hn

4/10/2026 at 7:52:35 PM

Windows Secure Lock Screen clock may appear up to 30 seconds behind

https://support.microsoft.com/en-us/windows/secure-lock-screen-clock-may-appear-up-to-30-seconds-behind-7093a752-93b3-423a-9558-902bceb2ae47

by shscs911

4/10/2026 at 9:13:59 PM

> Both experiences use the same Windows kernel system clock.

Ah yes, the lock screen experience. I could stare at it forever.

On a more serious note, does anyone know why they would do it like that? Why is one polling interval aligned and the other isn’t? What’s the security impact?

by echoangle

4/10/2026 at 11:56:42 PM

The security impact relates to the fundamental design architecture of the lock screen.

Similar to iOS Before First Unlock (BFU) security mechanisms being stronger and less capable overall, so too do you see this behavior on Windows.

The user mode lock screen is simply a full screen app, for which glitching the resolution of an “external” monitor which video out ports is often enough to desync the resolution of the full screen lock screen app and the full logged in user desktop behind it. IE: you can just… click past the lock screen app briefly running at a smaller resolution. As you might imagine, there’s a timing aspect to this.

That’s why this behavior exists.

by jerrythegerbil

4/11/2026 at 12:15:13 AM

I don’t really follow. Can you not get the time to the next minute flip and schedule the update 1s after that? How does the lock screen being different prevent that?

by echoangle

4/10/2026 at 9:54:18 PM

I’ve done clocks like this before. It was sheer laziness. Easier to just set a 30 second update window than to actually compute the time to next update. Particular in some of my sloppier projects without an event loop. Of course, the only person who saw the result was me and it made me chuckle at considering the complexity of managing time well.

by manwe150