Taskbar10: Try to make fixes for 22621.2134+

[Amrsatrio]

When using the Windows 10 taskbar on Windows 11 version 22621.2134+, I've made EP to:

• Fix Action Center, Control Center, and Toast Center (notification stack) placements.
• Fix Task View refusing to appear. Also fixes Alt+Tab not working.
• Fix volume and brightness popups refusing to show.
• Fix Win+A (Action Center), Win+N (Control Center), and Win+B (Focus on tray overflow button) shortcuts not working.

As a bonus:

• On 22H2 afterwards, fixed the context menu of the new IME button.
• Prevented outdated (read: bogus) offsets from symbols saved in registry from being returned. This should help prevent a TON of appearing GitHub issues related to Explorer not loading at all after updating.
• To make this work in at least Release Preview builds, added patterns of twinui.pcshell.dll whose matches are used when symbols are not available or not yet downloaded.

Remaining issues:

• On 22621.2134+, with "Do not change the taskbar context menu" off, right clicking the empty spot on the Windows 11 taskbar crashes Explorer. fe78dca
• On 22621.2134+, with Win11 input language switcher, when clicking the language button for the first time the Win11 switcher appears, but after subsequent clicks the Win10 one appears instead regardless of your settings.
• Windows Ink Workspace button crashes Explorer after clicking it when the taskbar is placed at the bottom.
• On 22621.2283, No "Settings", "Documents", "Downloads", etc. buttons on Start10 on 22621.2283 #2108.
• On 22631.2338 (Beta) and 23545.1000 (Dev):
  • Windows 10 taskbar doesn't work.
  • Going to "Home", then to another location, and then back to "Home" crashes Explorer.
• On 23545.1000 (Dev) classic (non-UWP) start menu folders and shortcuts do not appear in the Windows 10 start menu. Both in the app list and pinned tiles.

The fixes have been tested to work perfectly on:

• 22621.1992
• 22621.2134
• 22621.2283
• 22621.2338 (Beta)
  • Worked perfectly without tweaks for this version after my commit that made this work on 23545.1000.
• 22621.2359 (Release Preview)
• 22631.2338 (Beta)
  • Worked perfectly without tweaks for this version after my commit that made this work on 23545.1000.
• 23545.1000 (Dev)

Important note: My methods uses patterns with masks, therefore future updates might break my methods. I've added some safeguards before applying the patches when possible, to try to prevent unwanted effects.

Further explanations are in the code I have added. Feedback is welcome :)

[Amrsatrio]

Hold on, I messed up the line endings on dllmain.c

Edit: Fixed.

[valinet]

On 22621.2134+, with "Do not change the taskbar context menu" off, right clicking the empty spot on the Windows 11 taskbar crashes Explorer.

This fixes that (again, the vtable for TrayUI changed, kind of expected:

diff --git a/ExplorerPatcher/dllmain.c b/ExplorerPatcher/dllmain.c
--- a/ExplorerPatcher/dllmain.c
+++ b/ExplorerPatcher/dllmain.c
@@ -2501,4 +2501,5 @@
                     int offset = 656;
                     if (IsWindows11Version22H2OrHigher()) offset = 640;
+                    if (IsWindows11Version22H2Build2134OrHigher()) offset = 648;
                     if ((*(unsigned __int8(__fastcall**)(INT64))(**(INT64**)(TrayUIInstance + offset) + 104i64))(*(INT64*)(TrayUIInstance + offset)))
                     {

I will commit this as well.

[valinet]

I have merged this PR into master. Thanks again. We can continue talk here about the remaining issues, if you want.

On 22621.2283, No "Settings", "Documents", "Downloads", etc. buttons on Win 10-style start menu

I checked this out, but have yet to find a solution. The Settings app still writes the settings to the same place it did in Windows 10, for example (Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Start\VisiblePlaces), but the Start menu doesn't seem to read from there at all (even on Windows 10!). Idk, It's weird... Can you look into this as well? Thanks.

[Amrsatrio]

Thank you very much for merging and the Win11 taskbar context menu fix but why is this PR still open...?

And about the Win10 taskbar on 22631+, as a preparation for 23H2 dropping next week, if you don't mind can you give me pointers on how did you make your method for 21H2 and 22H2?

For the start menu buttons, they retained after I upgraded from 2134 to 2283 where starting from 2283 the changes from the settings app do not have any effect anymore and what you have is stuck "forever". Yeah I need to look into this as well.

Also I've added some more issues that I found.

[valinet]

PR is closed now :D I did not merge from here, I created a new branch locally from the PR, worked on that and then merged into master. GitHub doesn't seem to pick it up, so it left the PR open. Or maybe that isn't the workflow I am supposed to take, but that's how I managed to do it...

For the start menu buttons, they retained after I upgraded from 2134 to 2283 where starting from 2283 the changes from the settings app do not have any effect anymore and what you have is stuck "forever". Yeah I need to look into this as well.

Hmm, interesting, so it seems that whatever datastore it uses, it's stuck and doesn't get the updates in the newer builds. If we identify the library that handles this, an option might be to try to load that older version instead of the current version and see if it starts to work again. Currently, EP does that for AppResolver.dll, and it did so for StartTileData.dll in the past.

And about the Win10 taskbar on 22631+, as a preparation for 23H2 dropping next week, if you don't mind can you give me pointers on how did you make your method for 21H2 and 22H2?

What do you mean? As far as I remember, on 22H2 the taskbar worked on the build from the get go, so I did not have that hurdle. What I had to fix were a couple of problems, and I methodically solved each of them one by one. I made a thread where I tracked my issues then: #1082. Hopefully, the code for the Windows 10 taskbar is still there in explorer.exe - I am afraid that day will eventually come...

[Amrsatrio]

The GUID of WindowsUdk.ApplicationModel.AppExtensions.XamlExtensions has changed, so are the vtables. I tried commenting out the GUID check and it just outright crashed. I couldn't understand your method during my available time for this project since they're mostly nimpls without explanations. Because you wrote the method, that's why I asked if you can clear me (or everyone) up on how you made them.

[Amrsatrio]

Here's proof. Oh also on these two builds:

• Classic start menu folders/shortcuts do not appear on 23545. I can only see UWP app shortcuts, a complete opposite of the issue that we had starting from 22621.1413.
• Going to Home in Explorer, then to another location, then back to Home crashes Explorer. IDK if this is an EP issue, haven't checked. Maybe related to EnsureXAML? And explanations about how you made that hook would also be great.

[valinet]

Okay, I understand. Pfff, long time, I don't remember exactly, but basically it looked and worked like this in previous versions of explorer.exe:

In explorer.exe!CTray::Init, it requests this WindowsUdk.ApplicationModel.AppExtensions.XamlExtensions (the method underlined in red) in this image:

That method looks like this:

That get_runtime_activation_factory bla bla call (underlined in green) eventually gets down to a RoGetActivationFactory call, which I hook and override it to return a pointer to my custom made object (in EP in explorer_RoGetActivationFactoryHook). This is how I make it use my XamlExtensions object.

Now, back in CTray::Init, it calls that IsExtensionAvailable method (underlined in light blue), which looks like this:

You can see it basically looks like a standard COM QueryInterface, with IID:

Which my nimpls just check for that and return E_NOTIMPL: I return the same object if the requested IID is the one above, and further on I reply to IsExtensionAvailable with a 0 I think, otherwise it does not make any sense, now after reading your notes, that's what happened there:

HRESULT STDMETHODCALLTYPE nimpl1(__int64 a1, uintptr_t* a2, uintptr_t* a3)
{
    __int64 v4 = a1; // rcx

    if (*a2 != 0x5FADCA5C34A95314i64 || a2[1] != 0xC1661118901A7CAEui64)
        return E_NOTIMPL;

    *a3 = v4;
    return S_OK;
}

Now, back in CTray::Init, explorer checks what IsExtensionAvailable returned in order to decide which taskbar to initialize. By having it return E_NOTIMPL above, instead of taking the branch with CTray::InitializeTrayUIComponent which initializes the new taskbar, it goes to TrayUI_CreateInstance which initializes the old taskbar. You can tell by looking into CTray::InitializeTrayUIComponent that it is the Windows 11 taskbar, because in there it requests some object via COM, this usually indicating that the code lives in some other file (in this case the Windows 11 taskbar is located in Taskbar.dll), while in TrayUI_CreateInstance, some method from within explorer is called, which is correct, the code for the old taskbar mostly lives directly in explorer.exe:

vs

Initially, in early 22000-based builds, things were a bit different, I described them here: https://valinet.ro/2021/08/09/Restore-Windows-11-to-working-Windows-10-UI.html

I got info like this mostly from disassembling Microsoft's DLLs and explorer.exe, and also by disassembling StartAllBack. If I remember well, EnsureXAML is from there; tbh I don't know if I even understood it at all back then, and now I don't remember about it at all. It's some weird hack that keeps some object referenced in memory.

What I used to sometimes do, back in the day, was to download the new version of StartAllBack and the version before that, that was broken on some newer build, and then extract StartAllBack64.dll from those 2 and use Google's BinDiff to compare the binaries. The tool is rather effective, and usually it yielded me only a couple of actual differences. I'd then look on the disassembly of those manually in IDA and see what each does generally, then when finding something interesting, maybe a fix for some issue, port it over to ExplorerPatcher (for e.g., this really annoying bug where the taskbar buttons become annoyingly large when using a high DPI monitor was at some point fixed in StartAllBack, and I remember I poked around at the disassembly there and saw how they did it and ported that over to ExplorerPatcher as well - look for "Fix Windows 10 taskbar high DPI button width bug" in dllmain.c). Especially in the earlier days, ExplorerPatcher suffered from the same symptoms as StartAllBack, and fixes from one could be applied to the other rather effectively.

[Anixx]

I have build 22000 (Win11 22H2), the EP crashes, cannot start after this update.

[Amrsatrio]

Hooked 42952021 aka CategorySpecificXamlExtensions. But as what we've experienced with 22621.1413's issues reappearing in 22621.2134, this won't last long. Now onto crafting the vtables for the new interface that is used when the flag is on based on your explanations...

[valinet]

I have build 22000 (Win11 22H2), the EP crashes, cannot start after this update.

First off, 22000 is not 22H2. Second of all, we haven’t tested on 22000. As far as I looked, there are checks everywhere to enable the new behavior selectively only on newer builds, but maybe something slipped away. Idk. Compile a version locally while selectively rolling back commits until you find the one responsible, then selectively remove code there until you identify which portion exactly is causing it and report back. Thanks.

[valinet]

Hooked 42952021 aka CategorySpecificXamlExtensions. But as what we've experienced with 22621.1413's issues reappearing in 22621.2134, this won't last long. Now onto crafting the vtables for the new interface that is used when the flag is on based on your explanations...

So you’re saying everything is behind a featureId now? Yeah, not good… How does the disassembly of CTray::Init look now? I wonder whether they will remove the old taskbar altogether in a subsequent update…

The Windows 10 Start menu is indeed in a sad state. Try with StartTileData.dll from a previous build and see if that helps it ‘see’ non-UWP apps.

[Poopooracoocoo]

I wonder whether they will remove the old taskbar altogether in a subsequent update…

Now that you mention it, apparently OS build 25921, a 24H2 build that's still in the Canary insider channel, removes the old taskbar according to XenoPanther

[valinet]

I wonder whether they will remove the old taskbar altogether in a subsequent update…

Now that you mention it, apparently OS build 25921, a 24H2 build that's still in the Canary insider channel, removes the old taskbar according to XenoPanther

Yeah, hidding something behind a featureId is sometimes the first step towards removing it altogether, as hinted by previous experiences (STTest).

If the old taskbar code is removed altogether, I see 3 outcomes:

• Just rely on the new taskbar. On 23H2, it kind of reaches feature parity with the old one anyway, so the usefulness of the older one greatly diminishes. Basically, give up the fight with the upstream. Easiest.
• Attempt to fully or partially load some old explorer.exe in these newer builds and obtain the old taskbar from there. There was such an app in the Windows 8 days that loaded the Windows 7 shell there, back when things were less dependent on one another at binary interfacing level. Difficult.
• Reimplement a Windows 10-like taskbar from scratch. Suffice to say, this is difficult as well, if not the most difficult, due to the sheer amount of testing required to validate it working in all environments. RetroBar manages it though, so maybe look there?

Keep in mind that, besides learning, my initial goals with this project were to have a stop gap solution before Windows 11’s implementation kind of gets at feature parity with the Windows 10 taskbar (i.e. until never combine, taskbar labels are brought back), which they did in one form or another. Plus, nowadays we also have things like Windhawk and its modules which performed alternative implementations of never combine, taskbar labels etc.

[hakan-demirli]

• Just rely on the new taskbar.

Most users especially the ones who use wide monitors rely on 'move taskbar' functionality. It is also the most requested feature from Microsoft on Feedback Hub. I also use Explorer Patcher for this specific feature. I wonder if it will be possible to move it when the old one is completely gone. Since, it looks like Microsoft has no intention to add that feature.

[Amrsatrio]

apparently OS build 25921, a 24H2 build that's still in the Canary insider channel, removes the old taskbar according to XenoPanther

Hmm... Not good. Not good at all. This will reach the 23H2 stream maybe in January or March or something next year. But I am really down to do the 3rd option. Begin with the leaked Windows XP source code. Seriously.

[Amrsatrio]

How does the disassembly of CTray::Init look now?

P.S: I observe less functions being inlined in insider builds. Which is a good thing (and bad thing too speaking about patterns but mostly good) for us.

The code block in yellow has just got into 22H2 through 22621.2361 that was just released yesterday.

[Amrsatrio]

Done. Removed the 42952021 hook, and I've taken care of the new IXamlExtensionsStatics2 interface (we were handling IXamlExtensionsStatics since the early days). And also made your "weird stuff" into an actually readable one. Untested on 22000 builds though.

[Amrsatrio]

Also the modded Win11 taskbar context menu is still crashing on these builds, even after your commit. Can you tell me the function that you referred from? I'll make patterns to retrieve the offsets.

[valinet]

Now that the app is functional again, I suggest keeping new versions as pre-release for a while, so that side effects that might inadvertently slip, like the one @Anixx mentioned have a chance of being reported and fixed before the build reaches the bigger audiences. Once a new version "stabilizes" itself, i.e. no major reports for a few days/hours, we can then promote them as releases. This seemed to work best from my experiences here in the past, providing a good balance between thorough testing and quick access to new functionality.

Regarding the Windows 11 context menu, what I firstly suggest is to take a look at that latest commit I made there (fe78dca). That if check is taken straight from explorer.exe's disassembly, from the function that builds the Windows 10 taskbar context menu. What it does is check whether the user cascaded windows, in order to enable "Undo cascade" instead of offering them the option to do it again (I did not remember what it did, but I searched for that line using git log -S "line of code" which told me which commit was responsible for that, and the commit message told me what that line meant). My suggestion is to try playing with that number in the offset, changing it +8, -8, +16, -16 and see if it start working again eventually.** What happens is TrayUI's vtable seems to change and pushes these methods around. If you want to know the offset for sure, the function where explorer builds the Windows 10 taskbar context menu and where a similar if check is TrayUI::BuildContextMenu.

** That's what I did yesterday, it seemed to work. Now that I look, it doesn't work fully (Undo never appears), yet the menu doesn't crash on 22621.2283. Now I am actually looking on the disassembly, I still see a 640 there, which contradicts my 648... I am a bit stuck atm...

And yeah, I admit, in the rush of coding, I skipped over the parts where I add comments to actually explain wth I am doing. I am sorry for that, yet I hope my explanations make up for it. Thanks for adding bits of explanations to the source code as well, you can also even add links that point to comments here or any other relevant places.

[valinet]

My explanation above now I see was a bit erroneous, I corrected it after reading you notes. In nimpl1 I returned a pointer to an object with the _IActivationFactoryVtbl3 vtable on the in QI if the IID matched that XamlExtensionsStatics IID, and that object's wrongly calledActivteInstancemethod (in fact, it's directlyIsExtensionAvailable` as you said) took care of zeroing that pointer's data which is the reply to the question, meaning the extension was not available and to show the Windows 10 taskbar.

It's been done back in my early days in the "game", a mix of dissembling with a much less capable freeware IDA of both explorer and StartAllBack, as far as I remember.

I hope I didn't get in your way with my explanation more than I should. Tbh, I don't remember every detail and may not reckon exactly I took a certain path not the other in some situations, but I am trying my best to explain. I am still learning to this day, nowadays looking at this disassembly I wouldn't feel the need to check other sources to understand it properly, but back in the day I knew much less than I know today.

With a lot of stuff like this, it’s the struggle to get to a working version, after which you hang o to that patch until it breaks. And tend to forget a lot about how stuff works, idk, at least for me. It’s interesting and challenging at the moment, but hard to keep on my mind for too long.

[Amrsatrio]

It's all okay. I'm learning how the shell works under the hood as well as the ancient but reliable COM system. Despite having around 2 years of reversing experience (mostly on Fortnite and a remote desktop software I won't name) I still don't know much how the shell works 😅

[valinet]

All right, then I am glad that I made ExplorerPatcher’s source available to check out, and even though I admit, it’s not in the best shape, it could look much better, I still think it is a valuable resource worth looking onto, and if it helps you even a tiny tiny bit towards learning and developing your knowledge, then my “mission” is eventually accomplished and brings me the utmost joy knowing that I could be of assistance. Thanks.

[Anixx]

First off, 22000 is not 22H2.

For all I know, the Win11 original build, 22000 is 22H2.

[Amrsatrio]

No. It's 21H2. 22H2 is released the year after with build number 22621.

[Amrsatrio]

The Windows 10 Start menu is indeed in a sad state. Try with StartTileData.dll from a previous build and see if that helps it ‘see’ non-UWP apps.

No change. I don't know if I did this right, I couldn't delete that StartTileData.dll from 22621.1992, which means it should be loaded already.

Edit: The Windows 11 Start menu is also in a partially sad state 😭 I don't see Microsoft Edge in that list but the Accessibility folder is there. That's insider builds for you but at least we can make sure that everyone can get the most stable EP experience when new builds drop, though.

[Amrsatrio]

I defined the vtables in my local types for my 22621.1992 disassembly. This makes more sense now.

In case you don't know:
https://hex-rays.com/products/ida/support/idadoc/1695.shtml
I defined that function as HMENU __fastcall TrayUI::BuildContextMenu(ITrayComponentHost *__shifted(TrayUI,0x20) this, TrayCommon::TrayContextMenuItemFlags a2) so that the fields of this gets recognized properly.

[Amrsatrio]

Custom Win11 taskbar context menu on 22621.2134 afterwards, fixed. No longer uses hardcoded offsets. This should do until they nuke the old taskbar.

Now, the last important bug is only broken EnsureXAML on 2134+, and then we'll be ready for 23H2.

[Amrsatrio]

Fixed your EnsureXAML on 2134+. Only added the second GUID. Of course I tidied it up for future contributors to understand.

And I guess when the Win11 command bar + tabs is not used, we have to disable the new WASDK views because they're still crashing. They're so bad either ways 🤷

Also, since yesterday I just realized that my twinui.pcshell.dll pattern finder will crash if a pattern doesn't have a match (due to wrong argument placements), can you make a new release? I'm not sure with the versioning about this once since this adds support for initial 23H2 (22631) builds.

[valinet]

Yeah, if it's a breaking bug, absolutely sure we can make a new release. Pick what version you think is suitable and flag it as release, sure. Or it doesn;t let you do it?

[Amrsatrio]

Too tired now, it's 4 in the morning to think of a proper changelog message. I think 22621.2361 suits best as it's a very probable next GA cumulative update build which had the issues.

[Amrsatrio]

Hi @valinet, is vali20#6568 (User ID 470227942396526602) you on Discord? If so, I can you the highest role if you want, and I will DM you a webhook link to post info in the Discord server, and then you can set a new webhook in this repo with the URL and these checkboxes ticked:

[valinet]

Yup, that's me. I agree with the workflow described, once I get the links from you I will make sure to set them up. Thanks.

[Amrsatrio]

Reimplement a Windows 10-like taskbar from scratch. Suffice to say, this is difficult as well, if not the most difficult, due to the sheer amount of testing required to validate it working in all environments. RetroBar manages it though, so maybe look there?

@valinet I'm currently faithfully (trying to be 1:1) reimplementing the nuked CTrayNotify into EP, right now I've finished reimplementing ClockButton.

But we need to talk about this because I don't know what will happen if we push the faithful reimplementation to this repo or such. I'm thinking options such as private DLL or something but that would break your commitment to security (all binaries are built on GitHub's machines).

I think "zombifying" the explorer.exe of 22621/22631 that has the old taskbar code could be a painful thing to execute, to the point reimplementing is better because we have control over the code that is executed. Not only we have to find and initialize/sync global variables, suppose MS removes more stuff, then we have to adapt to them. Which means more patches to the zombified DLL, and that's painful as well.

[Anixx]

This is an AHK script that more or less fixes the appearance of the Win11 taskbar under Windows Classic theme. It would be very nice if these fixes were made a part of the "Classic Theme Mitigations" option that currently mostly affects the Win10 taskbar.

; This part is already implemented in EP as part of Classic Theme Mitigations for Win10 taskbar 
; (Valentin took it from the fixstrips.exe AHK script I have provided to him). It adds and removes 
; the window caption to the taskbar, which fixes the window border appearance. 
; Its effect should be extended from Win10 taskbar to Win11 taskbar.
WinSet, Style, +0x400000 , ahk_class Shell_TrayWnd
WinSet, Style, -0x400000 , ahk_class Shell_TrayWnd
; This hides the remnant of the older task button bar. It is still in Win11, I wonder 
; if it can be revived to work or not, but in Classic Theme it appears as a black rectangle. 
; It should be applied only to Win11 taskbar.
Control, Hide,, ReBarWindow321, ahk_class Shell_TrayWnd
; This hides and shows the new, XAML task buttons bar, making it to repaint
Control, Hide,, Windows.UI.Composition.DesktopWindowContentBridge2, ahk_class Shell_TrayWnd
Control, Show,, Windows.UI.Composition.DesktopWindowContentBridge2, ahk_class Shell_TrayWnd
; This re-paints the tray area. Besides initial taskbar load, it also should be activated 
; on hook each time the tray (number of tray icons) is changed.
Control, Show,, TrayNotifyWnd1, ahk_class Shell_TrayWnd

Please, add these mitigations for Classic Theme.