Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
We've had numerous reports that if a PuTTY session on Windows Vista or Windows 7 closes with a network error -- for instance, "Connection timed out" at startup, or "Software caused connection abort" in an established session -- then after hitting OK, and after the window title has changed to "PuTTY (inactive)", the PuTTY window becomes unresponsive, and the PuTTY process consumes a lot of CPU, and must be killed via Task Manager.
This apparently happens with PuTTY's default setting of "Close window on exit": "Only on clean exit". Changing this to "Always" is reported to avoid the problem.
Unfortunately, while this is readily reproducible for sufferers, none of the development team who have tried it on a variety of Vista and Win7 systems have managed to reproduce the problem.
Intriguingly, some of the reports hint that dwm.exe -- Windows' Desktop Window Manager -- also consumes significant CPU until PuTTY is killed. One report appears to say that stopping the 'uxsms' service ("Desktop Window Manager Session Manager") made the problem go away, but that probably isn't a good idea as a workaround. (On this developer's machine at least, that service is running and I still can't reproduce the problem.)
There are also a couple of reports of very similar behaviour on XP, but nowhere near as many as Vista / Windows 7. It could be that this is a manifestation of unclean-close-crash that's just particularly reproducible on the new versions of Windows.
(Note that we did fix another Vista-specific CPU-bound hang in r8030, after 0.60 was released, but that was specific to processing of disconnection messages sent by SSH servers -- for instance after entering an incorrect password too many times -- and can't be implicated in these instances of network errors.)
Reports on Vista and Windows 7:
Other reports that don't fit the pattern in some way:
Update, 2011-03-02: Committed r9115, which looks like a probable cause of this; it's made it go away for at least two people, so we've counted it as fixed despite never being able to reproduce it; if anyone still sees the problem with a version after r9115, please let us know.