PuTTY crashes on exit and requires computer reboot

Question

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.

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

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

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.

Answer 1

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.

Answer 2

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)

4. 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)

4. 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.

Answer 3

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.

Answer 4

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.