PuTTY bug win11-suspend

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Terminal display updates stop happening after resuming from Windows 11 Modern Standby
class: bug: This is clearly an actual problem we want fixed.
difficulty: taxing: Needs external things we don't have (standards, users etc)
priority: high: This should be fixed in the next release.
present-in: 0.78

A couple of users have reported that on a Windows 11 laptop, if PuTTY is running when the laptop is suspended, then after the system resumes, the PuTTY window might no longer update its terminal window. Keystrokes typed into the window will still be sent to the server and have their usual effects, but data returned from the server won't be displayed in the window.

One of the users who reported this provided a helpful analysis of the problem (thank you!). According to their analysis, the problem starts with GUI PuTTY's use of the SetTimer Windows API function to request a WM_TIMER window message. This is used throughout PuTTY to manage scheduled future events, including display updates (which it rate-limits).

If a WM_TIMER message was due to arrive while the system was suspended, it will simply never be delivered. As a result, the code that would have responded to that by scheduling further timers gets into a confused state.

An obvious response would be to detect that the system has been suspended, and use that to reboot PuTTY's timer subsystem on purpose. Windows has a message WM_POWERBROADCAST which is intended to notify applications of changes to the power situation, including resume from suspend – but our user reports that Windows 11 has introduced a new type of suspension known as “Modern Standby” which does not send WM_POWERBROADCAST, or (as far as we know) any replacement message.

This issue is likely to affect other timed events in PuTTY as well as display updates. For example, SSH repeat key exchange may be affected too. Display updates are just the most obvious effect, and the one that shows up first.

This issue is listed as Taxing difficulty because as far as I know the PuTTY team currently doesn't have access to a Windows 11 machine of a type that exhibits this problem. (Apparently not even all Win11 devices can do Modern Standby.) So it's difficult for us to test a candidate fix, or even a candidate workaround.

Our helpful user suggested a workaround strategy that involves checking for a missed timer when any call to the timing subsystem occurs, and resetting the timing subsystem. This would arrange, for example, that the next keypress would be likely to unblock the display updates. However, we're unable to test this strategy. Also, it relies on the user noticing the problem and prodding the window, which might not be good enough if a security-relevant timer also went missing (e.g. for an SSH rekey).

Other possibilities that have occurred to me, which I also can't test easily:

(See also bug report in downstream KiTTY project.)

If you want to comment on this web site, see the Feedback page.
Audit trail for this bug.
(last revision of this bug record was at 2023-07-16 14:23:26 +0100)