-
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
Terminal Crashes when used with switchable GPU scenario #2183
Comments
Hi, @miniksa... 👋 Unfortunately, I only detected the last line inside the project where the problem is... Here's the line: terminal/src/renderer/dx/DxRenderer.cpp Lines 242 to 245 in f8f0798
And here, the relative stacktrace:
Oh... Right! I also tried to compare the value for those parameters ( For I'll keep trying in the coming days... Thank you. 🙂 |
Oooh. Excellent, @Byloth. What's the return code from I expect all the parameters to be the same, but something about the system/device/DX-stack is causing a difference in behavior in this circumstance. |
Oh, also, if you have the latest code... the interesting thing to know is which Was it the one that says terminal/src/renderer/dx/DxRenderer.cpp Lines 161 to 184 in f8f0798
|
I have to be honest: I don't know if this is what you're looking for... But... terminal/src/cascadia/WindowsTerminal/BaseWindow.h Lines 26 to 29 in 0da13cd
These parameters are equal to:
From then on, the execution step by step seems to be no longer useful...
It's always the I hope it can be useful! |
@Byloth, the return code is the number that is returned by the call to terminal/src/renderer/dx/DxRenderer.cpp Lines 242 to 245 in f8f0798
It should show up in the VS debugger as the "return value" and/or it should be logged to the debugger output window because it is inside a RETURN_IF_FAILED. It should be a number that starts with 0x887A like any of these: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-error |
Mmmh... Nooope! The entire debug output might be useful?
|
Hm, no, the return code from the dxrenderer.cpp isn't in that log. I don't really know how to further explain what a return code is, but that's what I need from the function. |
I made some other attempts trying to retrieve what you're asking me... I also tried setting a breakpoint on the BUT... There is a
I'm not sure it could be useful, though... 😔 |
No, it's not that. But that's strange. I wouldn't have expected it to point to a structured exception. Also none of those error codes show something related to DirectX. Thanks for trying, but I think we're just still stuck here. |
I referenced this ticket in #2646, whereby I couldn't launch the app while RDPing to my laptop (which has 2 GPUs), and a workaround I have found to keep it working is to change the graphics settings to force it to use the onboard one. The workaround was not necessary when physically working on the device. Hopefully this knowledge is useful for your diagnosis. |
@mtanatwine Thanks for submitting your feedback. Alas, we're unable to repro this on our machines. You also mention that you've 'graphics settings and by forcing the app to use the "Power Saving" (onboard) GPU, it launches and works via RDP as intended'. It's entirely possible that your graphics card vendor's drivers are causing some unexpected issue when RD is used. Could I ask you to ensure you're running the latest drivers from your device OEM and/or GFX card vendor. If you still see this issue re-occur, please let us know with more details re. your hardware setup. Thanks. |
Hi, everyone! From the Release v.0.5.2661.0 I'm no longer experiencing this problem. Thanks! 🚀 |
I believe I am encountering this same issue in v0.6.2951.0 with a Dell XPS laptop (having both Intel integrated and Nvidia discrete graphics) when connected to a display via displayport on an external dock. I can provide more details on the hardware if desired. The crash occurs if the window is started on the external display or if the window is moved from the laptop display to the external display.
This is consistently reproducible on the machine and I was able to narrow down the problem to a single setting. If |
@mpetito I have a Dell XPS 15 with Nvidia discrete graphics and Intel integrated. I have been experiencing the same problem for the past few days with version 0.6.2951.0. I have just set showTabsInTitlebar to false, I will see how it goes |
@chrismetz it does happens to me as well on an XPS, i have an XPS-9530 with a GT 750M graphics card. Terminal crashed when i run the program with the Auto settings in the NVIDIA control panel. But it runs perfectly well when i force it to run on the integrated graphics card in NVIDIA control panel i am on version 1.1.2021.0 edit: 31/07/2020 |
Just had the same/similar crash, creating two errors in eventlog:
It happened after resizing the terminal window. I'm on a Dell Latitude 7490 laptop - no dock, but with two screens plugged in (HDMI and VGA via dongle). Intel(R) UHD Graphics 620. |
Today I had an (identical?) crash to my previous post - eventlog details were the same, but the crash happened with moving the window between screens today. |
I am reporting this here since this issue is identified as being responsible for this issue, first reported in #1364, which I believe covers what I am reporting below:
Ever since I upgraded Windows to 21H1 on May 28, I have been unable to open Windows Terminal or Windows Terminal Preview. It immediately crashes with this error in the Event Log (very similar to @campbellkerr above, except the application is OpenConsole.exe vs. WindowsTerminal.exe):
I have a Microsoft Surface Book 2, which has 2 graphics adapters. I have tried changing the graphics settings for Microsoft Terminal to use one adapter or the other, but I get the same error regardless of which GPU is configured. The drivers for both GPUs are up-to-date, but have not changed since April. So it appears this problem is somehow related to the 21H2 update. |
Hmmm. So, there were a lot of issues with 1.9, so I'd bet that most of the crashes that folks in this thread were seeing were other 1.9 issues that we sorted out. We haven't really tested this on a switchable GPU in quite some time, but in the 3 years since this was filed, we've had a lot of general stability fixes for the renderer. At this point, even if the renderer encounters an error, it should just tap out and let the user restart the renderer manually (rather than killing the Terminal entirely). Anyone in this thread that does have a switchable GPU - you still seeing this on 1.14 / 1.15/? |
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. |
This is a split/follow on from #1364.
One common case in that massive thread is folks with:
Are experiencing issues where the Terminal only works properly on one of the GPUs or is having problems after certain driver updates.
I'm suspecting this is just a reliability problem in the
DxRenderer.cpp
code, but I don't have access to any of this type of device.So this represents:
OR
The text was updated successfully, but these errors were encountered: