Terminal window "not responding" #16332
Comments
cool-RR
added
Issue-Bug
|
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 |
microsoft-github-policy-service
bot
added
the
Needs-Author-Feedback
|
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? |
microsoft-github-policy-service
bot
added
Needs-Attention
|
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. |
|
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
<#16332 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAN3SV6PVZFZAWGCN4DXA3YE5PABAVCNFSM6AAAAAA7PWZ4CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJWGM4TQMJTGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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? |
|
The only notable thing I can see is that the active window thread is stuck in a call to But assuming that it calls into the venerable 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 |
|
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? |
|
Yep! I'm unfortunately not experienced enough with dumps to know why that is and a quick |
|
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. |
microsoft-github-policy-service
bot
added
the
Needs-Author-Feedback
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. |
microsoft-github-policy-service
bot
removed
the
Needs-Author-Feedback
carlos-zamora
added
Needs-Repro
|
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. |
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. |
At the time of writing, closing the last tab of a window inexplicably doesn't lead to the destruction of the remaining TermControl instance. On top of that, on Win10 we don't destroy window threads due to bugs in DesktopWindowXamlSource. In other words, we leak TermControl instances. Additionally, the XAML timer class is "self-referential". Releasing all references to an instance will not stop the timer. Only calling Stop() explicitly will achieve that. The result is that the message loop of a frozen window thread has so far received 1-2 messages per second due to the blink timer not being stopped. This may have filled the message queue and lead to bugs as described in #16332 where keyboard input stopped working.
At the time of writing, closing the last tab of a window inexplicably doesn't lead to the destruction of the remaining TermControl instance. On top of that, on Win10 we don't destroy window threads due to bugs in DesktopWindowXamlSource. In other words, we leak TermControl instances. Additionally, the XAML timer class is "self-referential". Releasing all references to an instance will not stop the timer. Only calling Stop() explicitly will achieve that. The result is that the message loop of a frozen window thread has so far received 1-2 messages per second due to the blink timer not being stopped. This may have filled the message queue and lead to bugs as described in #16332 where keyboard input stopped working. (cherry picked from commit 521a300) Service-Card-Id: 91620224 Service-Version: 1.18
At the time of writing, closing the last tab of a window inexplicably doesn't lead to the destruction of the remaining TermControl instance. On top of that, on Win10 we don't destroy window threads due to bugs in DesktopWindowXamlSource. In other words, we leak TermControl instances. Additionally, the XAML timer class is "self-referential". Releasing all references to an instance will not stop the timer. Only calling Stop() explicitly will achieve that. The result is that the message loop of a frozen window thread has so far received 1-2 messages per second due to the blink timer not being stopped. This may have filled the message queue and lead to bugs as described in #16332 where keyboard input stopped working. (cherry picked from commit 521a300) Service-Card-Id: 91642474 Service-Version: 1.19
This changeset ensures that the message queue of frozen windows is always being serviced. This should ensure that it won't fill up and lead to deadlocks, freezes, or similar. I've tried _a lot_ of different approaches before settling on this one. Introducing a custom `WM_APP` message has the benefit of being the least intrusive to the existing code base. The approach that I would have favored the most would be to never destroy the `AppHost` instance in the first place, as I imagined that this would be more robust in general and resolve other (rare) bugs. However, I found that this requires rewriting some substantial parts of the code base around `AppHost` and it could be something that may be of interest in the future. Closes #16332 Depends on #16587 and #16575
microsoft-github-policy-service
bot
added
the
Needs-Tag-Fix
This changeset ensures that the message queue of frozen windows is always being serviced. This should ensure that it won't fill up and lead to deadlocks, freezes, or similar. I've tried _a lot_ of different approaches before settling on this one. Introducing a custom `WM_APP` message has the benefit of being the least intrusive to the existing code base. The approach that I would have favored the most would be to never destroy the `AppHost` instance in the first place, as I imagined that this would be more robust in general and resolve other (rare) bugs. However, I found that this requires rewriting some substantial parts of the code base around `AppHost` and it could be something that may be of interest in the future. Closes #16332 Depends on #16587 and #16575 (cherry picked from commit 5d2fa47) Service-Card-Id: 91642478 Service-Version: 1.18
This changeset ensures that the message queue of frozen windows is always being serviced. This should ensure that it won't fill up and lead to deadlocks, freezes, or similar. I've tried _a lot_ of different approaches before settling on this one. Introducing a custom `WM_APP` message has the benefit of being the least intrusive to the existing code base. The approach that I would have favored the most would be to never destroy the `AppHost` instance in the first place, as I imagined that this would be more robust in general and resolve other (rare) bugs. However, I found that this requires rewriting some substantial parts of the code base around `AppHost` and it could be something that may be of interest in the future. Closes #16332 Depends on #16587 and #16575 (cherry picked from commit 5d2fa47) Service-Card-Id: 91642479 Service-Version: 1.19
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.
The text was updated successfully, but these errors were encountered: