I've not seen this specifically, but there is a possibly related puTTY problem with VNC. If a SSH session in VNC ends unexpectedly, so the window becomes disabled rather then closes as it would on a normal termination, it seems to cause VNC to spin scanning for updates but not sending anything out.
I tunnel in via SSH though, rather than using a reverse tunnel - perhaps you could try this? If you setup Cygwin's SSH server on that machine and enable port 22 to be directed to it from your router you can SSH in rather than SSHing out so can reconnect if the previous SSH channel dies. When a dead puTTY session is causing VNC to lock, I can always still restart the VNC session. It locks again for screen updates once the screen is fully displayed in the VNC client but it still takes in input, so I can click where puTTY's window close button is, close the VNC connection again, and when I reconnect to VNC the errant puTTY window is gone and all else is working as it should be.
From the way I read your question, SSHing in will remove the need to use puTTY at the remote end of the tunnel anyway - if you are only using puTTY to manage the tunnel then that has now been replaced by Cygwin's OpenSSH (server end) and what-ever client (probably puTTY again) you call in using.
If SSHing in to the XP machine is not an option for what-ever reason, you could still try the client side or OpenSSH (via cygwin or some other port), using that for the call out to build the reverse tunnel instead of using puTTY. You could also try playing with the polling options in the VNC server settings but I don't remember this making any difference with the problem I've seen.
I think puTTY handles its window in non-standard (or at least generally unexpected) ways, as a number of window management utilities (like those which add snap-to-grid, or enhancements to the window decorations, and so forth) have an explicit exception for puTTY by default.
FYI: the places I've noticed VNC+puTTY issues are also machines running XP - though I don't think it will be XP specific, I've just not been in a situation where the problem as I understand it (some incompatibility between what puTTY does with itself and how VNC operates) would arise on other Windows versions. In all cases I'm using the TightVNC variant of VNC, both server and client.
