starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Updating GPU drivers closed all terminals #20085

New Issue
Open
opened 2026-01-31 07:03:00 +00:00 by claunia · 33 comments
claunia commented 2026-01-31 07:03:00 +00:00
Owner
Copy Link

Originally created by @muchcharles on GitHub (Jun 15, 2023).

Windows Terminal version

1.18.1462.0

Windows build number

Version 10.0.19045.2965

Other Software

No response

Steps to reproduce

Open a terminal and have some work in progress.
Install new nvidia drivers.

Expected Behavior

Terminal windows don't close when updating GPU drivers.

Actual Behavior

During the GPU driver reset as part of the upgrade (when screen blanks), all terminal windows close and you lose all of your work.

Originally created by @muchcharles on GitHub (Jun 15, 2023). ### Windows Terminal version 1.18.1462.0 ### Windows build number Version 10.0.19045.2965 ### Other Software _No response_ ### Steps to reproduce Open a terminal and have some work in progress. Install new nvidia drivers. ### Expected Behavior Terminal windows don't close when updating GPU drivers. ### Actual Behavior During the GPU driver reset as part of the upgrade (when screen blanks), all terminal windows close and you lose all of your work.
claunia commented 2026-01-31 07:03:02 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 15, 2023):

Windows Terminal probably crashed when you upgraded your driver. Is there any chance you have a crash report in the Event Viewer for Windows Terminal?

image

Or do you maybe have any dumps in %LOCALAPPDATA%\CrashDumps?

I just upgraded my Nvidia graphics driver and didn't have any crashes, so it probably at least doesn't happen all the time. What graphics driver did you upgrade?

Edit: Discord on the other hand did crash after the upgrade. 😄

@lhecker commented on GitHub (Jun 15, 2023): Windows Terminal probably crashed when you upgraded your driver. Is there any chance you have a crash report in the Event Viewer for Windows Terminal? ![image](https://github.com/microsoft/terminal/assets/2256941/851ed4b0-fb30-46c8-a40c-47da1b9ef055) Or do you maybe have any dumps in `%LOCALAPPDATA%\CrashDumps`? I just upgraded my Nvidia graphics driver and didn't have any crashes, so it probably at least doesn't happen all the time. What graphics driver did you upgrade? Edit: Discord on the other hand did crash after the upgrade. 😄
claunia commented 2026-01-31 07:03:02 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jun 15, 2023):

It does have an entry in event viewer:

image

And there is a dump as well.

It was upgrading to Nvidia driver 536.23

@muchcharles commented on GitHub (Jun 15, 2023): It does have an entry in event viewer: ![image](https://github.com/microsoft/terminal/assets/7025369/f5952933-324a-45da-88bb-b52a84826436) And there is a dump as well. It was upgrading to Nvidia driver 536.23
claunia commented 2026-01-31 07:03:02 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 15, 2023):

nvwqf2umx.dll

That might be a bug in the Nvidia driver, I think? If you're willing to share the dump with us, you can share it either on GitHub or send it to us via mail. You can find my personal mail address on my GitHub profile, and I'll then forward it to the rest of the team. However, it might contain parts of your terminal's contents.

@lhecker commented on GitHub (Jun 15, 2023): > nvwqf2umx.dll That might be a bug in the Nvidia driver, I think? _If_ you're willing to share the dump with us, you can share it either on GitHub or send it to us via mail. You can find my personal mail address on my GitHub profile, and I'll then forward it to the rest of the team. However, it might contain parts of your terminal's contents.
claunia commented 2026-01-31 07:03:03 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023): 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**.
claunia commented 2026-01-31 07:03:03 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023): 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**.
claunia commented 2026-01-31 07:03:03 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023): 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**.
claunia commented 2026-01-31 07:03:04 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023): 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**.
claunia commented 2026-01-31 07:03:04 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023): 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**.
claunia commented 2026-01-31 07:03:04 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jun 19, 2023): 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**.
claunia commented 2026-01-31 07:03:05 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 19, 2023):

What's going on with the bot? ._.
Edit: Commenting fixes it? Buggy bot...

@lhecker commented on GitHub (Jun 19, 2023): What's going on with the bot? ._. Edit: Commenting fixes it? Buggy bot...
claunia commented 2026-01-31 07:03:05 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 19, 2023):

I'm sorry, I think the bot is having an episode.

@DHowett commented on GitHub (Jun 19, 2023): I'm sorry, I think the bot is having an episode.
claunia commented 2026-01-31 07:03:06 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jun 19, 2023):

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.

Not stale, sent attachment via email

@muchcharles commented on GitHub (Jun 19, 2023): > 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**. Not stale, sent attachment via email
claunia commented 2026-01-31 07:03:06 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 12, 2023):

I forgot to comment back... I tried to use the dump but unfortunately it has been corrupted during the crash. The stack trace contains 3 function calls where the second one is at address 0 and the usual WinDbg helpers failed to pull out any additional information as well.

I'll close the issue for now because of this, but I'd be happy to reopen it if it occurs again and we happen to get a valid crash dump. I suspect however that this is a bug in Nvidia's driver.

@lhecker commented on GitHub (Jul 12, 2023): I forgot to comment back... I tried to use the dump but unfortunately it has been corrupted during the crash. The stack trace contains 3 function calls where the second one is at address 0 and the usual WinDbg helpers failed to pull out any additional information as well. I'll close the issue for now because of this, but I'd be happy to reopen it if it occurs again and we happen to get a valid crash dump. I suspect however that this is a bug in Nvidia's driver.
claunia commented 2026-01-31 07:03:06 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 28, 2023):

It happened again today with the latest nvidia update.

On Wed, Jul 12, 2023 at 5:57 PM Leonard Hecker @.***>
wrote:

Closed #15553 https://github.com/microsoft/terminal/issues/15553 as
completed.

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

@muchcharles commented on GitHub (Jul 28, 2023): It happened again today with the latest nvidia update. On Wed, Jul 12, 2023 at 5:57 PM Leonard Hecker ***@***.***> wrote: > Closed #15553 <https://github.com/microsoft/terminal/issues/15553> as > completed. > > — > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/15553#event-9804364942>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABVTFWJM7H6POL5D5HXK2D3XP4MUNANCNFSM6AAAAAAZHCGVRY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
claunia commented 2026-01-31 07:03:06 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 28, 2023):

Only two places in the code check for DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET

/mnt/d/git/terminal$ ack DXGI_ERROR_DEVICE_REMOVED'|'DXGI_ERROR_DEVICE_RESET
src/renderer/atlas/AtlasEngine.r.cpp
58: if (hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET)

src/renderer/dx/DxRenderer.cpp
1538: recreate = hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET;
1558: recreate = hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET;

Does the normal run loop, when not typing in to the console, call any DX12 API calls other than present?

Also, in the handling of those errors it only seems to retry 3 times for a total of less than a second:

// Add a bit of backoff.
// Sleep 150ms, 300ms, 450ms before failing out and disabling the renderer.
Sleep(renderBackoffBaseTimeMilliseconds * (maxRetriesForRenderEngine - tries));

Display blanking during driver updates and stuff can go for considerably more than 900ms. Also consider something like detaching a Surface screen shortly after resume from hibernate when things are swappy.

Note if you change maxRetriesForRenderEngine you should also change that sleep line. Should probably have a static_assert in place or a min to make sure the sleep doesn't go negative when changing that value.

@muchcharles commented on GitHub (Jul 28, 2023): Only two places in the code check for DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET /mnt/d/git/terminal$ ack DXGI_ERROR_DEVICE_REMOVED'|'DXGI_ERROR_DEVICE_RESET src/renderer/atlas/AtlasEngine.r.cpp 58: if (hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET) src/renderer/dx/DxRenderer.cpp 1538: recreate = hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET; 1558: recreate = hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET; Does the normal run loop, when not typing in to the console, call any DX12 API calls other than present? Also, in the handling of those errors it only seems to retry 3 times for a total of less than a second: // Add a bit of backoff. // Sleep 150ms, 300ms, 450ms before failing out and disabling the renderer. Sleep(renderBackoffBaseTimeMilliseconds * (maxRetriesForRenderEngine - tries)); Display blanking during driver updates and stuff can go for considerably more than 900ms. Also consider something like detaching a Surface screen shortly after resume from hibernate when things are swappy. Note if you change `maxRetriesForRenderEngine` you should also change that sleep line. Should probably have a `static_assert` in place or a `min` to make sure the sleep doesn't go negative when changing that value.
claunia commented 2026-01-31 07:03:07 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 28, 2023):

WDDMConEndUpdateDisplayBatch that swaps the swap chain textures doesn't seem to handle errors assuming these are the calls to it via EndPaint:

src/interactivity/win32/windowproc.cpp
829:    // BeginPaint/EndPaint does a bunch of other magic in the system level
832:    // We've tried in the past to not call BeginPaint/EndPaint
847:    LOG_IF_WIN32_BOOL_FALSE(EndPaint(hwnd, &ps));

src/renderer/base/renderer.cpp
134:        LOG_IF_FAILED(pEngine->EndPaint());
@muchcharles commented on GitHub (Jul 28, 2023): WDDMConEndUpdateDisplayBatch that swaps the swap chain textures doesn't seem to handle errors assuming these are the calls to it via EndPaint: src/interactivity/win32/windowproc.cpp 829: // BeginPaint/EndPaint does a bunch of other magic in the system level 832: // We've tried in the past to not call BeginPaint/EndPaint 847: LOG_IF_WIN32_BOOL_FALSE(EndPaint(hwnd, &ps)); src/renderer/base/renderer.cpp 134: LOG_IF_FAILED(pEngine->EndPaint());
claunia commented 2026-01-31 07:03:07 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 28, 2023):

It happened again today with the latest nvidia update.

Ah, fuck... If it's a recurring issue, I'll leave it open.

Only two places in the code check for DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET

The crash is definitely not due to any of those error codes, nor due to the retrying. The hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET check is only there to decide whether an error is an expected or unexpected. If it's an expected one (either of the 2 error codes) it'll retry indefinitely. But if it's neither of the 2 then the retry loop you found will only try up to 3 times to rerender the contents. If that fails, the application won't simply exit/crash, however. Instead, you'll see this (last error code + a prompt to resume rendering):

It's also not the EndPaint(hwnd, &ps) either, because src/interactivity is code specific to conhost (the old console window) and is not used for Windows Terminal. WDDMConEndUpdateDisplayBatch is used for our WDDM renderer, because we also build and ship the conhost used for the Windows recovery image, etc., which don't use DirectX.

I suspect that this issue either happens due to a driver bug or due to us accessing a nullptr member when the renderer is gone. I think both of these are about equally likely and also equally hard to debug. 🫤
You could try sending me your latest crash dump again. Maybe it's uncorrupted this time?

@lhecker commented on GitHub (Jul 28, 2023): > It happened again today with the latest nvidia update. Ah, fuck... If it's a recurring issue, I'll leave it open. > Only two places in the code check for DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET The crash is definitely not due to any of those error codes, nor due to the retrying. The `hr == DXGI_ERROR_DEVICE_REMOVED || hr == DXGI_ERROR_DEVICE_RESET` check is only there to decide whether an error is an expected or unexpected. If it's an expected one (either of the 2 error codes) it'll retry indefinitely. But if it's neither of the 2 then the retry loop you found will only try up to 3 times to rerender the contents. If that fails, the application won't simply exit/crash, however. Instead, you'll see this (last error code + a prompt to resume rendering): ![](https://user-images.githubusercontent.com/3933920/199143388-924c2e93-34ed-4baf-9806-653c09e4aeca.png) It's also not the `EndPaint(hwnd, &ps)` either, because `src/interactivity` is code specific to conhost (the old console window) and is not used for Windows Terminal. `WDDMConEndUpdateDisplayBatch` is used for our WDDM renderer, because we also build and ship the conhost used for the Windows recovery image, etc., which don't use DirectX. I suspect that this issue either happens due to a driver bug or due to us accessing a `nullptr` member when the renderer is gone. I think both of these are about equally likely and also equally hard to debug. 🫤 You could try sending me your latest crash dump again. Maybe it's uncorrupted this time?
claunia commented 2026-01-31 07:03:07 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 28, 2023):

I had NDA'd stuff in the terminal and can't send.

Is it possible to switch off GPU rendering to WDDM or is that tied to the context the terminal is being used in? Stability of the terminal is the highest priority.

@muchcharles commented on GitHub (Jul 28, 2023): I had NDA'd stuff in the terminal and can't send. Is it possible to switch off GPU rendering to WDDM or is that tied to the context the terminal is being used in? Stability of the terminal is the highest priority.
claunia commented 2026-01-31 07:03:08 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 28, 2023):

I found the software rendering setting, I'll switch to that if it doesn't spin a core when not drawing anything or something, or slow down compiles which has been a problem with windows terminal in the past.

I can open the dump for you if there are instructions to get the project up easily at the right revision somewhere.

I'm on

Windows Terminal Preview
Version: 1.18.1462.0

@muchcharles commented on GitHub (Jul 28, 2023): I found the software rendering setting, I'll switch to that if it doesn't spin a core when not drawing anything or something, or slow down compiles which has been a problem with windows terminal in the past. I can open the dump for you if there are instructions to get the project up easily at the right revision somewhere. I'm on Windows Terminal Preview Version: 1.18.1462.0
claunia commented 2026-01-31 07:03:08 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 29, 2023):

In the Microsoft Store you can find "WinDbg" (and WinDbg Preview - either are fine). If you open the crash dump with WinDbg it'll automatically resolve symbols for you. In the "Command" window you can type !analyze -v for an initial triage of the issue. The "Stack" window (bottom right, in a tab, by default) shows the stack trace which is also important. You can also get a textual stack trace in the Command window by typing k. If you type kp you get a stack trace with function parameters. If you type ~* kp you get that but for all running threads.
In short, the commands !analyze -v and ~* kp might contain the most helpful information.

@lhecker commented on GitHub (Jul 29, 2023): In the Microsoft Store you can find "WinDbg" (and WinDbg Preview - either are fine). If you open the crash dump with WinDbg it'll automatically resolve symbols for you. In the "Command" window you can type `!analyze -v` for an initial triage of the issue. The "Stack" window (bottom right, in a tab, by default) shows the stack trace which is also important. You can also get a textual stack trace in the Command window by typing `k`. If you type `kp` you get a stack trace with function parameters. If you type `~* kp` you get that but for all running threads. In short, the commands `!analyze -v` and `~* kp` might contain the most helpful information.
claunia commented 2026-01-31 07:03:08 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 29, 2023):

Looks like more crash info than last time and not in a GPU driver call:

image


FAULTING_SOURCE_FILE:  C:\a\_work\1\s\src\renderer\atlas\BackendD3D.cpp

FAULTING_SOURCE_LINE_NUMBER:  1481

FAULTING_SOURCE_CODE:  
No source found for 'C:\a\_work\1\s\src\renderer\atlas\BackendD3D.cpp'


SYMBOL_NAME:  Microsoft_Terminal_Control!Microsoft::Console::Render::Atlas::BackendD3D::_drawSoftFontGlyph+19e
@muchcharles commented on GitHub (Jul 29, 2023): Looks like more crash info than last time and not in a GPU driver call: ![image](https://github.com/microsoft/terminal/assets/7025369/ff57609a-f7db-4eaa-86f5-6fc93c35cd37) ```FAULTING_SOURCE_LINE: C:\a\_work\1\s\src\renderer\atlas\BackendD3D.cpp FAULTING_SOURCE_FILE: C:\a\_work\1\s\src\renderer\atlas\BackendD3D.cpp FAULTING_SOURCE_LINE_NUMBER: 1481 FAULTING_SOURCE_CODE: No source found for 'C:\a\_work\1\s\src\renderer\atlas\BackendD3D.cpp' SYMBOL_NAME: Microsoft_Terminal_Control!Microsoft::Console::Render::Atlas::BackendD3D::_drawSoftFontGlyph+19e ```
claunia commented 2026-01-31 07:03:09 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 29, 2023):

That's amazing! Thank you so much for spending time on this!
I'm sure you're not actually using soft fonts (soft fonts are custom fonts you can specify via VT), right? This indicates that we have a bug where we either don't properly reset the BackendD3D::_glyphAtlasMap hashmap or the ShapedRow::mapping vectors.

If you go up in the callstack twice into _drawText you should be here:
57b9549ff8/src/renderer/atlas/BackendD3D.cpp (L1012)

Can you see the contents of the row variable? This one:
57b9549ff8/src/renderer/atlas/BackendD3D.cpp (L970)

A screenshot of its contents would be helpful, but in particular its mappings member would be interesting: Both, how many items the mappings vector has and which ones / how many of them have a fontFace value of nullptr. (Hopefully WinDbg loads the embedded NatVis data correctly - in that case you'll have a much easier time inspecting those containers.)

If you have trouble viewing the data, I'll try to investigate those BackendD3D::_glyphAtlasMap hashmap and ShapedRow::mapping anyways. I'm pretty sure it should be some code that uses them. You helped me a ton already! Thanks!

@lhecker commented on GitHub (Jul 29, 2023): That's amazing! Thank you so much for spending time on this! I'm sure you're not actually using soft fonts (soft fonts are custom fonts you can specify via VT), right? This indicates that we have a bug where we either don't properly reset the `BackendD3D::_glyphAtlasMap` hashmap or the `ShapedRow::mapping` vectors. If you go up in the callstack twice into `_drawText` you should be here: https://github.com/microsoft/terminal/blob/57b9549ff814b52cdcf2bf36c69488db22abcde2/src/renderer/atlas/BackendD3D.cpp#L1012 Can you see the contents of the `row` variable? This one: https://github.com/microsoft/terminal/blob/57b9549ff814b52cdcf2bf36c69488db22abcde2/src/renderer/atlas/BackendD3D.cpp#L970 A screenshot of its contents would be helpful, but in particular its `mappings` member would be interesting: Both, how many items the `mappings` vector has and which ones / how many of them have a `fontFace` value of `nullptr`. (Hopefully WinDbg loads the embedded NatVis data correctly - in that case you'll have a much easier time inspecting those containers.) If you have trouble viewing the data, I'll try to investigate those `BackendD3D::_glyphAtlasMap` hashmap and `ShapedRow::mapping` anyways. I'm pretty sure it should be some code that uses them. You helped me a ton already! Thanks!
claunia commented 2026-01-31 07:03:09 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Jul 29, 2023):

I don't think I'm using soft fonts, just running default ubuntu through WSL without much console customization.

Here's the locals for _drawText:

image

@muchcharles commented on GitHub (Jul 29, 2023): I don't think I'm using soft fonts, just running default ubuntu through WSL without much console customization. Here's the locals for _drawText: ![image](https://github.com/microsoft/terminal/assets/7025369/04b43768-ce27-4f0f-bb74-81048f500b56)
claunia commented 2026-01-31 07:03:09 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 30, 2023):

Aww... The dump doesn't contain the contents of the heap. I'll try option 2 then: Re-read all the code that touches those two member variables I mentioned before, until I found it. 😄 If you can, please keep the dump file for a few more weeks, just in case. 🙂

@lhecker commented on GitHub (Jul 30, 2023): Aww... The dump doesn't contain the contents of the heap. I'll try option 2 then: Re-read all the code that touches those two member variables I mentioned before, until I found it. 😄 If you can, please keep the dump file for a few more weeks, just in case. 🙂
claunia commented 2026-01-31 07:03:10 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 28, 2023):

Oh I only just now noticed:
image

Please correct me if I'm wrong @j4james (primary author around soft fonts), but I believe that a non-zero cellSize in the UpdateSoftFont call can only occur when a soft font is actually used right?

@muchcharles Could you perhaps be using soft-fonts unknowingly? Are you using any more "fanciful" VT applications through WSL? Or maybe the WSL output gets corrupted and the output is accidentally interpreted as a soft font?

@lhecker commented on GitHub (Aug 28, 2023): Oh I only just now noticed: ![image](https://github.com/microsoft/terminal/assets/2256941/cc539770-423b-4782-b198-dfa59656ec8c) Please correct me if I'm wrong @j4james (primary author around soft fonts), but I believe that a non-zero `cellSize` in the `UpdateSoftFont` call can only occur when a soft font is actually used right? @muchcharles Could you perhaps be using soft-fonts unknowingly? Are you using any more "fanciful" VT applications through WSL? Or maybe the WSL output gets corrupted and the output is accidentally interpreted as a soft font?
claunia commented 2026-01-31 07:03:10 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Aug 28, 2023):

I don't think so, mostly just vim with very few plugins and normal shell command stuff. What are some of the big terminal apps that use soft fonts?

@muchcharles commented on GitHub (Aug 28, 2023): I don't think so, mostly just vim with very few plugins and normal shell command stuff. What are some of the big terminal apps that use soft fonts?
claunia commented 2026-01-31 07:03:10 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 29, 2023):

Please correct me if I'm wrong @j4james (primary author around soft fonts), but I believe that a non-zero cellSize in the UpdateSoftFont call can only occur when a soft font is actually used right?

Yeah, it's only called with a non-zero size when the DECDLD sequence is finished processing here:
c4436157c1/src/terminal/adapter/adaptDispatch.cpp (L3899-L3902)

The only other time it's called is when in response to an RIS hard reset, but that's with a zero size. See here:
c4436157c1/src/terminal/adapter/adaptDispatch.cpp (L3062-L3064)

@j4james commented on GitHub (Aug 29, 2023): > Please correct me if I'm wrong @j4james (primary author around soft fonts), but I believe that a non-zero `cellSize` in the `UpdateSoftFont` call can only occur when a soft font is actually used right? Yeah, it's only called with a non-zero size when the `DECDLD` sequence is finished processing here: https://github.com/microsoft/terminal/blob/c4436157c116880c320b5df278d4d886a930c0f3/src/terminal/adapter/adaptDispatch.cpp#L3899-L3902 The only other time it's called is when in response to an `RIS` hard reset, but that's with a zero size. See here: https://github.com/microsoft/terminal/blob/c4436157c116880c320b5df278d4d886a930c0f3/src/terminal/adapter/adaptDispatch.cpp#L3062-L3064
claunia commented 2026-01-31 07:03:11 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 29, 2023):

Is it possible this is the result of the cellSize in the FontSettings structure not being initialized? See here:

c4436157c1/src/renderer/atlas/common.h (L335-L343)

As far as I can see the u16x2 structure isn't zero-initialized.

@j4james commented on GitHub (Aug 29, 2023): Is it possible this is the result of the `cellSize` in the `FontSettings` structure not being initialized? See here: https://github.com/microsoft/terminal/blob/c4436157c116880c320b5df278d4d886a930c0f3/src/renderer/atlas/common.h#L335-L343 As far as I can see the `u16x2` structure isn't zero-initialized.
claunia commented 2026-01-31 07:03:11 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 29, 2023):

@j4james The cellSize for soft fonts is here though: c4436157c1/src/renderer/atlas/common.h (L364)

Since it uses til::size it's always properly initialized.

But thanks for pointing this out! I'll go through all the *x* vector members in the code to fix them up. I've been planning to turn most of the u16 and u16x2 stuff into regular til::CoordType and til::point/size code anyways. Only few parts actually benefit from the tight packing as far as I can tell. Or maybe I should use int/int32_t? til::CoordType was mostly meant as buffer coordinates after all and not for pixel coordinates...
(The vector types aren't zero-initialized by default so that they're trivially copyable. BackendD3D processes through dozens of MB/s at >60 FPS after all.)

@lhecker commented on GitHub (Aug 29, 2023): @j4james The `cellSize` for soft fonts is here though: https://github.com/microsoft/terminal/blob/c4436157c116880c320b5df278d4d886a930c0f3/src/renderer/atlas/common.h#L364 Since it uses `til::size` it's always properly initialized. But thanks for pointing this out! I'll go through all the `*x*` vector members in the code to fix them up. I've been planning to turn most of the `u16` and `u16x2` stuff into regular `til::CoordType` and `til::point/size` code anyways. Only few parts actually benefit from the tight packing as far as I can tell. Or maybe I should use `int`/`int32_t`? `til::CoordType` was mostly meant as buffer coordinates after all and not for pixel coordinates... (The vector types aren't zero-initialized by default so that they're trivially copyable. `BackendD3D` processes through dozens of MB/s at >60 FPS after all.)
claunia commented 2026-01-31 07:03:11 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 29, 2023):

@j4james The cellSize for soft fonts is here though:

Yeah, sorry, I misread that.

But if it's not that, I have no idea how we're ending in this state. It seems like something must be getting corrupted at some point, and it's highly unlikely that the OP is using soft fonts if they aren't doing so consciously, so how do we end up in the _drawSoftFontGlyph method? Could it be something like the fontFaceEntry.fontFace field getting reset as a result of the driver update? Although that doesn't explain where that height value came from. I'm stumped.

@j4james commented on GitHub (Aug 29, 2023): > @j4james The `cellSize` for soft fonts is here though: Yeah, sorry, I misread that. But if it's not that, I have no idea how we're ending in this state. It seems like something must be getting corrupted at some point, and it's highly unlikely that the OP is using soft fonts if they aren't doing so consciously, so how do we end up in the `_drawSoftFontGlyph` method? Could it be something like the `fontFaceEntry.fontFace` field getting reset as a result of the driver update? Although that doesn't explain where that height value came from. I'm stumped.
claunia commented 2026-01-31 07:03:11 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Sep 5, 2023):

I'm marking this up for 1.20 so that we remember to ask next quarter if this issue popped up again after updating to 1.19.

@lhecker commented on GitHub (Sep 5, 2023): I'm marking this up for 1.20 so that we remember to ask next quarter if this issue popped up again after updating to 1.19.
claunia commented 2026-01-31 07:03:12 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 9, 2025):

So! Are you still seeing this issue?

@DHowett commented on GitHub (Dec 9, 2025): So! Are you still seeing this issue?
claunia commented 2026-01-31 07:03:12 +00:00
Author
Owner
Copy Link

@muchcharles commented on GitHub (Dec 9, 2025):

I switched to software rendered to keep my work safe, but next time I update nvidia drivers I'll switch it to hardware rendered first and see if I end up with a crash

@muchcharles commented on GitHub (Dec 9, 2025): I switched to software rendered to keep my work safe, but next time I update nvidia drivers I'll switch it to hardware rendered first and see if I end up with a crash
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Rendering Issue-Bug Needs-Attention Needs-Triage Product-Terminal Severity-Crash
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#20085
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?