Tabs leak GDI handles on tab title resizes #8201

Closed
opened 2026-01-31 01:23:15 +00:00 by claunia · 7 comments
Owner

Originally created by @RealDolos on GitHub (May 17, 2020).

Originally assigned to: @miniksa on GitHub.

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): 0.11.1333.0

Steps to reproduce

  1. In the preferences, set "tabWidthMode": "titleLength" or any other configuration that allows for variably-sized tab titles (to trigger this bug)
  2. Run the following in a powershell tab (or anything similar in any type of tab) to trigger lots of tab title resizes
for ($i=0;;++$i) { $host.UI.RawUI.WindowTitle = "oops " + @(Get-Random -Minimum 0.0 -Maximum 100000000.3) + @(Get-Random) + @(Get-Random) + " oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooops"; }

Expected behavior

Windows Terminal should keep running, keep updating the tab title, without leaking GDI handles.

Actual behavior

Windows Terminal keeps allocating new GDI handles (as seen in Task Manager/ProcessHacker) and will eventually crash and just vanish.

The leaked GDI handles will be retained even when the corresponding tab is closed

term resource ex

Please note

It is not enough to just update the title when tabs are in equal mode/are not resized.

Originally created by @RealDolos on GitHub (May 17, 2020). Originally assigned to: @miniksa on GitHub. # Environment ```none Windows build number: 10.0.18363.0 Windows Terminal version (if applicable): 0.11.1333.0 ``` # Steps to reproduce 1. In the preferences, set `"tabWidthMode": "titleLength"` or any other configuration that allows for variably-sized tab titles (to trigger this bug) 2. Run the following in a powershell tab (or anything similar in any type of tab) to trigger lots of tab title resizes ```powershell for ($i=0;;++$i) { $host.UI.RawUI.WindowTitle = "oops " + @(Get-Random -Minimum 0.0 -Maximum 100000000.3) + @(Get-Random) + @(Get-Random) + " oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooops"; } ``` # Expected behavior Windows Terminal should keep running, keep updating the tab title, without leaking GDI handles. # Actual behavior Windows Terminal keeps allocating new GDI handles (as seen in Task Manager/ProcessHacker) and will eventually crash and just vanish. The leaked GDI handles will be retained even when the corresponding tab is closed ![term resource ex](https://user-images.githubusercontent.com/9981466/82151292-1c273980-985b-11ea-9c3f-82612b135f37.png) # Please note It is *not* enough to just update the title when tabs are in `equal` mode/are not resized.
Author
Owner

@miniksa commented on GitHub (May 18, 2020):

This is leaking before any of the user mode GDI code is being hit. I see a single DC getting left behind every time. But breakpointing on literally all the GDI Create and Delete functions... the handle is leaked before we even hit our user mode code.

@miniksa commented on GitHub (May 18, 2020): This is leaking before any of the user mode GDI code is being hit. I see a single DC getting left behind every time. But breakpointing on literally all the GDI Create and Delete functions... the handle is leaked before we even hit our user mode code.
Author
Owner

@miniksa commented on GitHub (May 18, 2020):

I think this will have to be found with a KD. Also, I think it's not really our fault as ONE handle is leaked when the tab is stood up by MUX. It's just not leaked again otherwise because it doesn't resize.

@miniksa commented on GitHub (May 18, 2020): I think this will have to be found with a KD. Also, I think it's not really our fault as ONE handle is leaked when the tab is stood up by MUX. It's just not leaked again otherwise because it doesn't resize.
Author
Owner

@WSLUser commented on GitHub (May 18, 2020):

@miniksa I wonder if that leak exists in 2.4 preview of WinUI. Because this sounds alot like it's coming from there.

@WSLUser commented on GitHub (May 18, 2020): @miniksa I wonder if that leak exists in 2.4 preview of WinUI. Because this sounds alot like it's coming from there.
Author
Owner

@DHowett commented on GitHub (May 18, 2020):

Looks like this is a bug in WIL, actually. I failed to update WIL months ago because of static analysis failures, but in so doing I missed microsoft/wil#100.

@DHowett commented on GitHub (May 18, 2020): Looks like this is a bug in WIL, actually. I failed to update WIL months ago because of static analysis failures, but in so doing I missed microsoft/wil#100.
Author
Owner

@miniksa commented on GitHub (May 18, 2020):

Oof good catch, Dustin.

@miniksa commented on GitHub (May 18, 2020): Oof good catch, Dustin.
Author
Owner

@ghost commented on GitHub (Jun 18, 2020):

:tada:This issue was addressed in #6229, which has now been successfully released as Windows Terminal Preview v1.1.1671.0.🎉

Handy links:

@ghost commented on GitHub (Jun 18, 2020): :tada:This issue was addressed in #6229, which has now been successfully released as `Windows Terminal Preview v1.1.1671.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.1671.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Author
Owner

@ghost commented on GitHub (Jun 30, 2020):

:tada:This issue was addressed in #6229, which has now been successfully released as Windows Terminal v1.0.1811.0.🎉

Handy links:

@ghost commented on GitHub (Jun 30, 2020): :tada:This issue was addressed in #6229, which has now been successfully released as `Windows Terminal v1.0.1811.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.0.1811.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8201