-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug Report: crashing when Snap app window #1572
Comments
I can confirm this issue. Is happening to me too. I've got same build |
Strange. I don't have the issue, and I am running the same Windows Terminal Version. Does anyone have a dump from msvsmon.exe when the crash occurs? |
I only have Event Viewer application errors logs. |
tried for all terminals within the treminal app, couldn't reproduce the behavior. as u mentioned this probably is causing due to the version of the .Net framework installed in your system machine. |
I'm going to need a crash dump here to go further. I tried to reproduce it locally and could not. If you have the event viewer log of the crash in the Application log with event ID 1001 (Windows Error Reporting) and can give me that, I might be able to find the crash ID in our reporting system and figure this out from that. |
@miniksa I've attached the application logs when the Terminal app was crashing, as requested. There seemed to be a couple of different WER events for the app so they are included. Let me know if you need any thing else. |
So there are mainly 2 problems from the logs I see. PowerShell.exe and pwsh.exe are both crashing due to the console input being redirected somehow, and no processes attached to named/unnamed pipes. And WindowsTerminal.exe is crashing due to access violations. The module is TerminalControl.dll. Can someone use just in time debugging when the crash occurs and drop the VS debugger output? |
See this guy? The hashed bucket number? I looked in the one with WindowsTerminal.exe crashing. I can find the crash analysis on the back-end with that. Crash analysis tells me that this is the stack of the failure...
... checking the The line blamed is DxRenderer.cpp @ 689. Which doesn't make sense for a nullptr deref on master, but it does make sense as of this commit time: https://github.com/microsoft/terminal/blob/9b92986b49bed8cc41fde4d6ef080921c41e6d9e/src/renderer/dx/DxRenderer.cpp Now reasoning this out.... There are three paths above to calling this code.
OK. Let's find all places where the contents of
For Line 263, For line 308, For line 683, this is among the newest things going on. I added this code more recently than the other bits to attempt to resize without unspooling the entire device resources pipeline and recreating it because it was expensive (and was probably causing some sort of flickering or performance nightmare. I forget exactly, but it had to be something like that.) So I'm going to suspect line 683 here or the nearby code. Reasoning this out... I'm first concerned because the Secondly, I'm detaching the That sounds very plausible. So what I'm going to do here is go on the assumption that this is the problem. I don't want to "throw out the baby with the bathwater" by undoing this change which must have been for good reason. I'm just going to try to make it more robust. I'll set up a situation where:
I'm not certain exactly what the problem is while creating the render target, but this proposal should stop the crash from happening by eliminating the torn state. After that, if there's still weirdness when snapping the window, we should be able to reproduce it under the debugger and see what error codes are being thrown by DirectX (because the RETURN_IF and LOG_IF macros should be reporting those failures when attached to a debugger in the output window) and go from there. |
…hen quick on-the-fly resizing operations happen. #1572
Thanks again for the report! This was just submitted to the store with the v0.2.1831.0 servicing release. It may take some time for the store to process it. |
@DHowett-MSFT thanks for the update, that's great! |
Environment
Steps to reproduce
Open Windows Terminal, snap window to side or corner of desktop, attempt to interact with Terminal app with no response, then app crashes and closes unexpectedly.
Expected behavior
Snapping Windows Terminal window to corner or side of desktop, then interact with app as usual.
Actual behavior
After snapping app window, app becomes unresponsive, then crashes and closes unexpectedly.
The text was updated successfully, but these errors were encountered: