5

PuTTY crashes when the program tries to exit. When it crashes, the window will freeze and will not close no matter what. Force close will not work, the task manager will not work. pskill from pstools (using administrator command prompt) has no effect-- it says the process has been killed, but it remains. Nothing will make the window go away except for a computer reboot.

This has been happening for a few weeks, possibly caused by a recent Windows update, but that's just a guess. It doesn't happen every time, but maybe 50% of the time. It crashes whether it is a manual exit invoked by typing "exit" or "logout", or when it exits itself because the computer has gone to sleep.

It only happens when I use port tunneling. I always have several PuTTY windows open, and the only one that crashes is the one with a port tunnel open.

Before the most recent crash, I opened the PuTTY log to see what it said. The final line was "Server sent command exit status 0", which seems normal.

server exit status 0

Here is a screenshot of my port tunnelling settings, in case that's relevant:

port tunnel D9090

Here is the Windows error box, which identifies the type of error as "AppHangB1":

enter image description here

Google has given me zero results. Searches for this type of crash have told me that it's often caused by a buggy driver, so that's one possible avenue, if anyone knows what I should try to update/roll back.

I updated PuTTY to the most recent version to no effect. I have not tried updating the remote computer (which I control) or my router, but I'd hope that neither of them are related to this kind of crash, which seems related to Windows itself.

Windows 7


Update

I ran the debugging tools suggested, which generated a memory dump and an analysis of it. It's quite a lot of information, so I pasted into a jsfiddle you can see here. I quoted the summary below, but please see that page for the full report, because it's quite a lot of information.

Description: Detected possible blocking or leaked critical section at 0x041916d8 owned by thread 0 in putty.exe__PID__7768__Date__08_14_2018__Time_02_26_52PM__311__Manual Dump.dmp

Impact of this lock: 25.00% of threads blocked (Threads 2)

The following functions are trying to enter this critical section

mswsock!SockAsyncSelectCompletion+2a

The following module(s) are involved with this critical section:

C:\WINDOWS\System32\mswsock.dll from Microsoft Corporation


Update 3 weeks later

It has been nearly a month without a crash, and in that time there has been another Windows update. The timing is too coincidental; I think this must have been caused by a Windows update in the summer, probably July, and fixed in the August update.

  • Have you tried uninstalling and reinstalling the most recent version of PuTTY (not upgrade, but actually uninstall, reboot, re-install)? If so, have you tried the Snapshot version? Have you filed a Bug Report on PuTTY's site? – JW0914 Aug 6 '18 at 4:37
  • Try to type enter ~. (enter-tilde-dot) before entering exit or when PuTTY is hang. Questions: How exactly are you exiting PuTTY and do you use the exit command? What is your MTU on both sides? – harrymc Aug 6 '18 at 6:24
  • @harrymc: The crash happens whether I type exit, logout, or when PuTTY closes on its own because the computer goes to sleep. Typically I use exit. I don't know what my MTU is; I'm not familiar with the term. enter ~. is not a command recognized by the server, – felwithe Aug 6 '18 at 10:48
  • While I'm not all that familiar with port tunneling, is there anything on the "other end" that is relying on the connection that you sever when you issue the "exit" or "logout" command? Maybe putty is encountering an error because when you exit the client from the putty POV, the "other end" is trying to recconect which causes an issue. (Just a thought as I work with putty, just not port tunneling.) Also just for clarification by port tunneling to you mean port forwarding? – RickwhoPrograms Aug 6 '18 at 13:41
  • 1
    There certainly are people whom know more about Windows debugging than I do but ... It's stuck at "ws2_32!closesocket+cd" called from: "putty+a1050" - notice that the 'putty+....." has no Function name, you would want to compile Putty with debugging symbols so that you are told the Function name and Line number. It looks like you have a call to close a Socket, and it's not returning. Without the Source it's a guess what the problem is. If you're a wiz at asm language and Window's calls you can load Putty.exe into the debugger and look at the code leading up to the call at a1050 . – Rob Aug 14 '18 at 21:37
2

In the configuration settings of PuTTY, the setting of "Close window on exit" may take part in the problem, so try to test its other available settings.

You may also try an alternative free product, one of : KiTTY, MobaXterm, or Bitvise.

If one of the alternatives works for you, then first you have a workaround for the problem. Second, the problem itself is then probably some difficulty in the communication protocol of PuTTY with the remote computer, and you should report the problem to the developers.

However, if none of the alternatives works for you, then the problem is probably not on your side. You should examine the setup of the SSH server on the remote computer, try to debug it, and post here the trace logs if you would like us to have a look. If you do not have control of the remote computer, report the problem to its administrator.

  • could a server trying to reconnect to his putty session be causing the issue as mentioned a few times now? That is my hunch but as I don't work much with port tunneling (forwarding?) I'm not sure. Also if that is the case what would the potential workaround be? Would there be any way to force the "retry connection" to stop if the host goes down from the remote side? – RickwhoPrograms Aug 6 '18 at 19:47
  • Not enough information on your setup to answer (and not sure I could even then). My guess would be that PuTTY is hanging while waiting for the server to acknowledge the close-connection request, and that the problem is a racing condition, one of the sides using a wrong timeout. This may explain why the problem is intermittent - the server may have closed the connection on his side, just that PuTTY missed out on that, waiting on an answer that never arrives and a closed connection. In TCP, closing the socket on one side is not reported to the other, so one has to depend on the protocol. – harrymc Aug 6 '18 at 20:05
  • PuTTY might also be confused by the tunnel, so the tunnel itself may be preventing the closing of the connection to the server. – harrymc Aug 6 '18 at 20:18
  • The SSH-2 channel request bug message might indicate the return of this bug to your PuTTY version or in the server. In any case, you are surely encountering a software bug that is none of your doing. I suggest to ensure you are using the latest update on the server, then try some of the alternative clients I have listed above, doing the analysis as I have outlined in my answer. – harrymc Aug 7 '18 at 4:55
  • I may try KiTTY as an absolute last resort, but I'd rather not, because PuTTY has worked for me for so long. This problem just started out of nowhere less than a month ago. PuTTY hasn't even changed in a year, so I think the problem obviously must be in my system somewhere. – felwithe Aug 11 '18 at 21:23
2
+100

PuTTY crashes on exit and requires computer reboot

PuTTY crashes when the program tries to exit. When it crashes, the window will freeze and will not close no matter what. Force close will not work, the task manager will not work. pskill from pstools (using administrator command prompt) has no effect-- it says the process has been killed, but it remains. Nothing will make the window go away except for a computer reboot

I call that a "hang" and not a "crash". Crash means that execution continues either returning an error message (nice) or in the case of severe memory corruption there will be a pause (usually short, sometimes somewhat lengthy, rarely a watchdog) and execution will continue with a BSOD or reboot (not nice).

With a "hang" no amount of time waited will seem to further your progress, though other threads may continue to run normally if your Task Switcher is not affected and can switch to them.

Quite possibly what has happened is that PuTTY has spawned a VPN subroutine in order to tunnel, and that process has a problem; it has not returned to PuTTY and so PuTTY is hung.

The other process could have a temporary file open or a Port; termination of PuTTY might well close the subroutine but probably not remove any lock on files or ports from subprograms.

How to find out for certain - What is going on?

Reading a Microsoft Community webpage about that error titled: "Windows Explorer 7 is not responding - 'apphangb1 explorer.exe' error" it says:

"Andre.Ziegler

Create a hang dump of the Windows Explorer:

http://www.msfn.org/board/topic/130005-creating-memory-dumps/

compress the crash dump as 7z or RAR and upload it to your SkyDrive and post the link here.

Create the dump but you can analyze it yourself, or after searching all the SE sites for a duplicate question ask us: "How do I work with a .DMP file?".

Following that link to the webpage: "Creating memory dumps" it says:

"Memory dump from an application/process that is HANGING (not crashing):

  1. Create a directory called c:\adplus

  2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows"

  3. Type the following command in the command prompt:

cscript adplus.vbs -hang -pn appname -quiet -o c:\adplus

(where "appname" is the .exe name of the application that is hanging)

  1. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed.

Memory dump from an application/process that is CRASHING (not hanging):

  1. Create a directory called c:\adplus

  2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows"

  3. Type the following command in the command prompt:

cscript adplus.vbs -crash -pn appname -quiet -o c:\adplus

(where "appname" is the .exe name of the application that is crashing)

  1. Once the application you have attached to in step 3 eventually crashes, the debugger will create a .dmp file (or files) of the process. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed.

See this Microsoft Support webpage: "Debug Diagnostics Tool v1.2 is now available" where it describes usage of the DebugDiag tool.

It discusses:

  • Generating Memory Dumps:

    • Process Crashes

    • Process Hangs or Slow Performance

To debug a process hang, or slow performance use one of the following:

  1. Create a performance rule. The performance rule could be based on Performance Counters or HTTP Response Times. This latter is specific to web servers or HTTP-based web services. The Performance Counters rule allows you to capture a series of consecutive userdumps when one or more Performance Counters exceed specified thresholds. The HTTP Response Times rule allows you to either use ETW (specific to IIS web server) or WinHTTP (to ‘ping’ any type of web server or HTTP-based web service) to capture userdumps when the configured timeout is reached.

  2. Create a manual memory dump series during the slow or hang state by right-clicking the process name in the processes view and choosing the “Create Dump Series” option.

    Then, analyze the resulting .dmp files with CrashHangAnalysis.asp and/or PerfAnalysis.asp (see below).

    • Memory or Handle Usage
  • Analyzing Memory Dumps:

    One of the most powerful features of DebugDiag is the ability to analyze memory dumps and generate a report file showing the analysis, along with recommendations to resolve identified problems.

    DebugDiag uses “Analysis Scripts” to analyze memory dumps. There are 5 analysis scripts shipped with DebugDiag 1.2 as follows:

    • Crash/Hang Analyzers - CrashHangAnalysis.asp

    • Memory Pressure Analyzers - DotNetMemoryAnalysis-BETA.asp

    • Memory Pressure Analyzers - MemoryAnalysis.asp

    • Performance Analyzers - PerfAnalysis.asp

    • SharePoint Analyzers - SharePointAnalysis.asp".

Whatever the problem you can locate the exact point and find out which process is at fault and debug it. If you have a question about the use of those tools feel free to check for and ask a new question.

  • 1
    Ok, I got a crash analyses that looks like it might point to mswsock.dll. I will add it to the question since there's not enough room in the comment section. – felwithe Aug 14 '18 at 18:29
0

It sounds like you may be having an issue with winsock filters, and your application is locking up on some sort of driver/IO issue.

In an administrative command prompt try: netsh winsock reset then reboot, and see if that makes a difference.

Off of the top of my head here are some other things to try:

  • Remove any unused VPN software.

  • Uninstall (and reinstall) the driver for your network card.

  • Update the driver for your network card.

  • If you have recently uninstalled an antivirus product, it is possible that network filter drivers have been left behind. If so you may want to find the removal tool for the appropriate security product and run it.

-1

Try running two scans:

Scan 1

  1. Run CMD as Administrator
  2. Type SFC /scannow and press enter
  3. When the scan is finished open cbs.log at %windir%\logs\cbs\cbs.log
  4. Look for cannot repair and copy down the files that were not repaired.
  5. Once you have located the files not repaired (if any), use your installation disk to access replacement file(s). Follow these direction for getting replacement files(s).

Scan 2 (Last Resort)

  1. Run CMD as Administrator
  2. Type Chkdsk /f /r and press enter
  3. You will be shown a message regarding the volume to be locked. Press y and then enter.
  4. Restart your computer
  5. The scan will take a while. Wait for the scan to finish.
  6. On reboot, go to Event Viewer > Windows > Application Log and then look for Winninet.
  7. Look at the results of your scan.

I have found the answer at Microsoft Community.

  • 7
    DON'T run chkdsk /f /r to test the disk as this may be destructive. Run first chkdsk and only if it has found errors, and only after having taken excellent backups, do the other. However, I don't think this is a disk error. – harrymc Aug 6 '18 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.