Terminal window "not responding"

[cool-RR]

Windows Terminal version

1.18.2822.0

Windows build number

10.0.19045.0

Other Software

No response

Steps to reproduce

I'm using a terminal window, and then not using it for a while and doing other stuff.

Expected Behavior

No response

Actual Behavior

The terminal window becomes nonresponsive. The content is gone. The window title shows "not responding" and I can only kill the process at that point.

[zadjii-msft]

Does this happen consistently/? Or was this a on-off kinda thing? I'd guess that this is because we just pushed an update to the app on the Store, and the Store tried to kill the Terminal to install the update.

If that's the case, the Terminal version should probably now be https://github.com/microsoft/terminal/releases/tag/v1.18.3181.0

[cool-RR]

This happened at least 10 times in the last few weeks, but I can't make it happen at will. My version right now is 1.18.2822.0.

Is there any way to find logs or something on my machine that would give us information about what's happening?

[lhecker]

That sounds a bit like a deadlock, so log files probably won't be of help. You could try to capture a dump of a hung process before killing it: https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#capturing-and-sending-dumps

That way we can see what threads are currently stuck and what the UI thread is most likely waiting on.

[cool-RR]

Thank you, I'll give it a try.

On Fri, Nov 17, 2023 at 3:11 PM Leonard Hecker @.***> wrote:

That sounds a bit like a deadlock, so log files probably won't be of help. You could try to capture a dump of a hung process before killing it: https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#capturing-and-sending-dumps

That way we can see what threads are currently stuck and what the UI thread is most likely waiting on.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/terminal/issues/16332#issuecomment-1816398136, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN3SV6PVZFZAWGCN4DXA3YE5PABAVCNFSM6AAAAAA7PWZ4CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJWGM4TQMJTGY . You are receiving this because you authored the thread.Message ID: @.***>

[cool-RR]

Today this happened again. I opened Process Explorer and saw these processes:

I wasn't sure which process you wanted a dump of, and whether it should be a mini-dump or a full dump, so I just made both mini- and full dumps of each of the 4 processes. They're available for download here: https://www.dropbox.com/scl/fo/ngzixgtvl9b4gms1ya0bl/h?rlkey=00vm814nojext99o8agdwwzu3&dl=0

Does that help you figure out why it's hanging?

[lhecker]

The only notable thing I can see is that the active window thread is stuck in a call to DefWindowProc with a WM_INPUTLANGCHANGEREQUEST message. Unfortunately, the dump ends at NtUserMessageCall which is just a syscall stub. Basically, the kernel-side stack trace is missing in the dump and I don't know how to fix that.

But assuming that it calls into the venerable xxxRealDefWindowProc, then the default WM_INPUTLANGCHANGEREQUEST handler tries to pass the request to the currently focused window using SendMessage which is synchronous. In other words, if the currently focused window is unresponsive then the currently active window will also deadlock. I'm not familiar with the ntuser implementation so I can't really tell if "currently focused window" is only in the current process or system-wide.

In case of the former the issue might be caused by the 2nd window thread in your dump because that one is frozen (aka: A previously closed window. Does the issue occur if you never had more than 1 window of the Terminal open at a time?). In case of the latter it might be caused by another application you have installed that is unresponsive. Also in case of the latter, it might be caused by xxxActivateKeyboardLayout which is called if the currently active window is already focused. I suspect that this call interacts with the "Text Input Management Service" via COM/RPC and that might also hang if it has a bug.

[cool-RR]

Thanks for the analysis. In that link were both mini-dumps and full dumps. Was the kernel-side stack trace missing also from the full dump?

[lhecker]

Yep! I'm unfortunately not experienced enough with dumps to know why that is and a quick ~Google~ Bing didn't bring any answers to that either...

[zadjii-msft]

I mean, maybe a dumb question is: are you changing the input language / method / something like that?

If you send /feedback via the Feedback Hub, we might be able to see if there's something else crashing on your machine that's correlated here. That's a real long shot though.

[cool-RR]

@zadjii-msft

I mean, maybe a dumb question is: are you changing the input language / method / something like that?

I do change language often, between English and Hebrew. I usually don't do it in the shell because I don't use Hebrew in the shell. It's possible that this problem is caused by an input language change, but I'm not noticing that it's happening immediately after a language change. Right now I opened terminal and changed language a bunch of times, both in the terminal app and outside it. I also typed some Hebrew in the terminal for good measure. The terminal did not crash.

Therefore I can't really do the recording action suggested above. The problem is not reproducible, though it keeps happening again and again.

[zadjii-msft]

We had a bit of a brain blast: Does this only occur after you've opened two simultaneous terminal windows, and closed one of them (but not both)?

We suspect that this hang is due to the window refrigeration code in Terminal 1.18 that gets used on Windows 10. We're guessing the message gets sent to the closed, refrigerated window, which just doesn't pump it.

[cool-RR]

Does this only occur after you've opened two simultaneous terminal windows, and closed one of them (but not both)?

I tried that now, it didn't make the problem happen. But I often have multiple terminal windows open, and I routinely open new ones and close existing ones.