Apparently, for some people, PuTTY randomly becomes unresponsive with
Win2000/XP.

We've been getting rare but persistent reports of this for a while,
but there seems to have been a rash of them recently (Feb 2004). None
of us have ever seen this, so we're going to need some help if we're
to stop it happening.

Common characteristics of the reports we've had:

When one PuTTY hangs, they all hang, including any new instances
attempted (once they get to opening a terminal window), until the
system is restarted. But other applications on the same system are
unaffected.

When trying to close PuTTY via the task manager, one receives a
message like "This program cannot be closed. If it is being debugged,
please resume it or close the debugger first."

It doesn't seem to be correlated with any particular event - it
can occur hours into an established connection.

It's claimed that the PuTTY backend is still functional (sending
keepalives, etc).

Looks like it only happens with SSH (1 and 2)

May be absent in 0.49?

If I had to make a guess, I'd investigate some of the trickery we use
to get noise for random numbers. My notes also suggest that I thought
someone thought that sound might be implicated, but I can't find any
evidence for that now.

Once the system has got into this state, an SSH packet log of a new
session which hangs might be useful, so we can infer exactly where
it's hanging and what it might be doing (since there's been a
suggestion that it's some way into the SSH protocol).

If someone can debug one of the hanging PuTTY processes and tell us
where it's got stuck, that would be good too.
Update, 2004-03-17: someone did this, and PuTTY is
hanging in noise_get_light(), around the call to
GetSystemPowerStatus().

Update, 2004-03-17: one of our correspondents has been trying
a version of the development code (more or less equivalent to 0.54) with
the GetSystemPowerStatus() call disabled, and has reported
that the problem seems to have gone away.

This source of noise has now been removed as of 2004-03-18 (there were
other good reasons too).
Please let us know if this appears to solve (or not!) the problem.

(Perhaps we've been getting more reports recently because modern BIOI /
Windows versions / whatever are more upset by frequent calls to the
APM BIOS or whatever it is than older systems?)