[Unpackaged] Fix taskbar glomming due to AUMID#20064
Open
carlos-zamora wants to merge 3 commits intomainfrom
Open
[Unpackaged] Fix taskbar glomming due to AUMID#20064carlos-zamora wants to merge 3 commits intomainfrom
carlos-zamora wants to merge 3 commits intomainfrom
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This comment has been minimized.
This comment has been minimized.
carlos-zamora
added a commit
that referenced
this pull request
Apr 6, 2026
carlos-zamora
added a commit
that referenced
this pull request
Apr 8, 2026
lhecker
requested changes
Apr 21, 2026
Member
lhecker
left a comment
lhecker
left a comment
There was a problem hiding this comment.
Neat code! One minor bug only.
Comment on lines
+318
to
+323
| // GH#20053: The shell resolves taskbar grouping identity as: per-window AUMID > | ||
| // per-process AUMID > auto-derived from exe path. Before we started setting a | ||
| // process AUMID, both the pinned .lnk and the process used auto-derived | ||
| // identity, so they matched. Now that we set an explicit AUMID, a pinned .lnk | ||
| // that predates the AUMID change has no AUMID and still uses auto-derived | ||
| // identity, causing a mismatch and a duplicate taskbar button. |
Member
There was a problem hiding this comment.
So LNK files essentially... cache? the AUMID that an app sets? Is that right?
So if my app ever changes the ID all LNKs are invalid?
Comment on lines
+328
to
+330
| // AUMID for THIS launch (both sides use auto-derived identity, so they match) | ||
| // and defer stamping the shortcut to process exit. On the next launch, the pin | ||
| // has our AUMID, so we set the process AUMID to match, and both agree. |
Member
There was a problem hiding this comment.
Why not update the LNK immediately?
| LR"(%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\*.lnk)"); | ||
|
|
||
| WIN32_FIND_DATAW findData{}; | ||
| const wil::unique_hfind findHandle{ FindFirstFileW(taskbarGlob.c_str(), &findData) }; |
Member
There was a problem hiding this comment.
Consider using
FindFirstFileEx(taskbarGlob.c_str(), FindExInfoBasic, &findData, FindExSearchNameMatch, NULL, FIND_FIRST_EX_LARGE_FETCH);This does two things:
- FindExInfoBasic avoids 8.3 short name conversion (sometimes expensive to calculate)
- FIND_FIRST_EX_LARGE_FETCH allocates larger buffers (the default is more appropriate for DOS times)
| continue; | ||
| } | ||
|
|
||
| if (_wcsicmp(targetPath, ourExePath.c_str()) != 0) |
Member
There was a problem hiding this comment.
_wcsicmp uses CompareStringW and is for linguistic / human comparisons. Here you want CompareStringOrdinal for machine-style comparisons. You can use til::compare_ordinal_insensitive for that or call CompareStringOrdinal directly. Both are just as readable IMO.
microsoft-github-policy-service
Bot
added
the
Needs-Author-Feedback
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of the Pull Request
The bug was caused by an AUMID mismatch between the Taskbar's .lnk file and Windows Terminal. Since no AUMID was associated with the .exe, the OS automatically creates one for us. However, #20018 added an AUMID for unpackaged scenarios, so now there was a mismatch, resulting in a new taskbar entry being created.
To fix this, we check if a .lnk points to our .exe in the taskbar. There's 3 cases here:
Validation Steps Performed
In unpackaged folder, move WindowsTerminal.exe to the taskbar (creates .lnk)...
✅ Double-click the .exe --> Same taskbar entry is used
✅ Double-click the .exe again --> second window goes to same taskbar entry
The first window doesn't have to close for this to work. It just * works *!
Bug introduced in #20018
Closes #20053