Does not work in 22572?

[Mario-Pajas]

I was using EP from months ago, but the latest releases are giving me a lot of problems. In the latest previous releases I did not get the preview image when hovering over a program opened in the taskbar. Now the taskbar is transparent and I get freezes after the start up that forces me to reboot the system. I had to uninstall it.

[Marfede]

Same here,

the taskbar (and even some windows) seem to go in background, when I click on them.
Uninstall Explorer patcher and restart did not fixed this (only in part - for example I have been able to click the Firefox Window, but not the windows explorer windows.
I needed 2 or 3 reinstalls and uninstalls of the explorer patcher to be able to work with windows 11 again.
(After the first uninstall and restart the Windows 10-taskbar still remained but was just noch clickable.)

Sorry for these unstructured information but the buggy behavior of the windows and the taskbar seemed very unstructured indeed.

BTW: Thanks for the nice solution for something microsoft completely fucked up.

[valinet]

Yeah, I don’t actively test it on Insider Preview; to be honest, I don’t have time for that. I hope to have EP work on the next major stable build as well, so eventually this should be fixed. It’s indeed next to impossible to figure something out without some structured information, as you said.

[Marfede]

Sorry, I did not look up my actual build before posting.
My system info says:
Windows 11 Home
21H2
22000.556

I opened a new discussion for that:
#1060

Sorry for mixing that up, but I think there could be major problems caused by explorer patcher in my windows build and I do not use any insider previews or something.

regards

[Mario-Pajas]

The transparent taskbar is apparently linked with trying to use unstacked buttons. If you do the trick of modifying the register to allow unstacked buttons you get the same behaviour than EP: transparent taskbar and explorer freezes,

[Marfede]

true true true, but one point maybe:
Instead of pointing on what the (noob- ;)) bug reporters did wrong, tell them how to do right or just ignore them.
Obviously you told in the mentioned documen... So could you please share the link here or an explenation where we missed it or what we should have read before posting.
Thanks

(The tool and the idea behind is great and the most people here really want to help but mostly just lacking expertise and - like me - even practice with github.... This reminds me, that I have to donate for the tool..., thanks!)

[Aokromes]

It is related to adding ‘UndockingDisabled = 1’ in
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell\Update\Packages

i don't have this key and i have the bug.

if you want real time chat to ask things to test / check you can contact me on telegram to @Aokromes :)

[valinet]

Man, you don’t have to donate for the tool. A lot seem to get this wrong too - donations are entirely voluntary, are nice but not required. The source code is public and using the app is free and donations neither condition that status, nor alter what the roadmap is.

And what’s to tell? I don’t have a clear recipe: if I knew how to solve this right away, I would have solved it. But “me too, uninstall worked” types of posts do not help in any way. This is a site for development: of course uninstall works, but it doesn’t solve the underlying issue, if any.

[valinet]

It is related to adding ‘UndockingDisabled = 1’ in
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell\Update\Packages

i don't have this key and i have the bug.

if you want real time chat to ask things to test / check you can contact me on telegram to @Aokromes :)

Which of the "bugs"? Taskbar thumbnail previews not working or transparent taskbar?

[Aokromes]

It is related to adding ‘UndockingDisabled = 1’ in
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell\Update\Packages

i don't have this key and i have the bug.
if you want real time chat to ask things to test / check you can contact me on telegram to @Aokromes :)

Which of the "bugs"? Taskbar thumbnail previews not working or transparent taskbar?

transparent taskbar + frozen after startup.

[merklegroot]

I ran into the same thing.
I'm on Win 11 Dev branch (Version 10.0.22572.1)
Uninstalling ExplorerPatcher got the taskbar to work again.

This is a great product.
Microsoft just so desperately wants to force me to combine taskbar items.

[valinet]

Endless posts, no one can determine a cause. Only @Mario-Pajas sketched up something of interest, couldn’t get all the way there in one message, @chip33 has to come up and provide the full story, no one can test the theory, everyone reports how “uninstall solved the issue”. What a surprise, indeed.

[Jawomo]

How should we determine a cause? Only the Dev can.

I updated to public 22000.556 and after the update the Explorer was freezing. Windows of apps did not show up after opening, Taskmanager window did not open... The whole PC was unusable.

Even after a uninstall of Explorer Patcher the problems and changes in explorer persisted.
It seem Explorer Patcher doesn't revoke all changes after a uninstall. That's a big problem and should not happen.

Had to reinstall Windows to get back to normal.

Similar apps have a 22000.500 support in their changelog. So the problem seems to be related to this update.

Hope this gets fixed as i really like the app and would even donate if all is working fine. Regards

[valinet]

How should we determine a cause? Only the Dev can.

Describe how the dev can guess what the problem could be on your end, without any useful info from the affected party. I am genuinely curious to learn about this common belief that the developer of an app posses some special powers that allows him/her to do magic stuff, like guess correctly what causes an issue, without any diagnostic info.

How to help? There are tons of wiki articles and posts regarding that here, I don’t understand why you have to be hand guided. Trash talking the app is not among the advice in those guides.

[Jawomo]

What info would you need?
Everything was fine before. After windows updated to 22000.556 automatically Explorer was freezing like described above. That's all i can report.

Btw, thats not trash talking. Just reporting bugs.

[valinet]

I repeat my question, how do you expect anyone to solve whatever you report with the amount of info you provided. I upgraded from 434 to 556 as well and had no issues.

What info would you need?

Again I repeat myself, there are pages written in these forums and on the wiki about what info to collect.

Btw, thats not trash talking. Just reporting bugs.

I disagree.

[chip33]

I just tried the regtweaks to StuckRects3 key to see if i could reproduce this transparent taskbar and explorer-freeze described by @Mario-Pajas but could not reproduce.
Am on Windows latest no insider 22000.556, latest EP preview build.

[valinet]

They mention (in the title) that it happens only on Insider Preview builds, where this new thing has been introduced. I run stable releases as well, indeed, nothing like this happens there, otherwise I would have noticed.

[chip33]

yes, I thought I would try it just to be sure it was on insider only.

[Aokromes]

They mention (in the title) that it happens only on Insider Preview builds, where this new thing has been introduced. I run stable releases as well, indeed, nothing like this happens there, otherwise I would have noticed.

maybe they have started shiping https://www.deskmodder.de/blog/2022/03/12/windows-11-snap-gruppen-an-die-taskleiste-anheften-waere-doch-mal-was/ and that breaks things

[Andre-10]

@valinet:
I'm not familiar with EP console etc.. so I can only provide what Windows does..
In my case .42.34 version EP, and Insider Dev build 22572, the faulting app is LockApp.exe

"Description
Faulting Application Path: C:\Windows\SystemApps\Microsoft.LockApp_cw5n1h2txyewy\LockApp.exe

Problem signature
Problem Event Name: MoAppCrash
Package Full Name: Microsoft.LockApp_10.0.22572.1_neutral__cw5n1h2txyewy
Application Name: praid:WindowsDefaultLockScreen
Application Version: 10.0.22572.1
Application Timestamp: 5d363b5e
Fault Module Name: StackHash12_734
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: 80004001
Exception Offset: 0
OS Version: 10.0.22572.2.0.0.256.48
Locale ID: 1060
Additional Information 1: cff5
Additional Information 2: cff59d4081bc86dd428adbe469902ba9
Additional Information 3: 2a8d
Additional Information 4: 2a8d8992349a9ea45adb46b72d76ba22
"

For any additional info, please point me to instructions about using console, dumps etc in EP

[valinet]

Taskbar thumbnails in OS builds 22567+ have been fixed in the latest pre-release. An update will be pushed soon.

It is beyond my understanding how things can break like this. Seems someone took out a few lines from the source code, enough to break the calls made by explorer.exe to the thumbnails API. Specifically, they seem to have taken out the following 2 lines, and it does not work without them, for some inexplicable reason:

        ptnProperties->dwFlags |= DWM_TNP_SOURCECLIENTAREAONLY;
        ptnProperties->fSourceClientAreaOnly = TRUE;

Btw, does anyone know in which build did the thumbnails break? I have set it to apply the patch for OS builds 22567 and up, although it may have started earlier, not that it really matters.

As I have been asked repeatedly, diagnosing this began by attaching with WinDbg to explorer.exe. Then, continue the program (g) and hover over a taskbar button. The WinDbg window will capture debug output like the following:

pcshell\shell\explorer\taskband2\thumbnail.cpp(297)\Explorer.EXE!00007FF715BAFFF2: (caller: 00007FF715BAF542) ReturnHr(2) tid(1560) 80070057 The parameter is incorrect.
pcshell\shell\explorer\taskband2\thumbnail.cpp(297)\Explorer.EXE!00007FF715BAFFF2: (caller: 00007FF715BAF542) ReturnHr(3) tid(1560) 80070057 The parameter is incorrect.
pcshell\shell\explorer\taskband2\thumbnail.cpp(297)\Explorer.EXE!00007FF715BAFFF2: (caller: 00007FF715BAF542) ReturnHr(4) tid(1560) 80070057 The parameter is incorrect.
pcshell\shell\explorer\taskband2\thumbnail.cpp(297)\Explorer.EXE!00007FF715BAFFF2: (caller: 00007FF715BAF542) ReturnHr(5) tid(1560) 80070057 The parameter is incorrect.
pcshell\shell\explorer\taskband2\thumbnail.cpp(297)\Explorer.EXE!00007FF715BAFFF2: (caller: 00007FF715BAF542) ReturnHr(6) tid(1560) 80070057 The parameter is incorrect.

This clearly indicates where the problem originates from. Line 297 in pcshell\shell\explorer\taskband2\thumbnail.cpp. Ofc we do not have access to the source code, but we can open explorer.exe in IDA and search for thumbnail.cpp. One match of interest is this: ?_CreateHThumbnail@CTaskThumbnail@@AEAAJPEAUHWND__@@@Z. If you go to that an decompile it, we see 2 calls that, on failure, can spit one of those messages. Out of the 2, one of them sets the line number (v6 = 297i64;) similar to what we see in the debug output. So, we can safely conclude that the following call fails: updated = DwmUpdateThumbnailProperties(*v2, &ptnProperties);. Why does it fail? Idk, but if we compare this area from the binary to previous builds of explorer.exe where it was working, we can see that in previous builds, they also had the above 2 lines in there. So, by writing a quick IAT patch in ExplorerPatcher for DwmUpdateThumbnailProperties, we can make sure to set those 2 parameters as well, and... yup, fortunately, it was as simple as that, taskbar thumbnails work again:

Again, idk how such breakage happens when it comes to human actions over the source code, but well... idk, I am very curious to find out. Unfortunately, the disassembly doesn't tell you that.

So yeah, once we decide from what build onward to have this patch active, I will push the update and a new pre-release will be generated. Is 22567 okay?

Regarding that transparent taskbar thing, I have yet to reproduce it. Everything else seems to work fine on my end. Maybe I'd have to install Windows Pro or Home instead of Enterprise? It's true that the install that I have is rock solid, moves fast, doesn't have the usual crap, since yeah, it's Enterprise.

[chip33]

I have learnt so much from following these kind of posts. thanks.

[valinet]

Yeah, it's a neat exercise, if you are interested, try to follow along and reproduce my steps outlined above. These types of challenges, let's call them, are very similar to what I had as homework on a regular basis during my college years. This one was unusually straightforward, and took a reasonable amount of time to sort out, perfect for handing it out as an assignment for students taking a course in this. Seems like the mindset and way of thinking I formed during those years is paying off.

[chip33]

Yes, and the patch will be in the code and findable when you release it so it is all there for anyone who wants to learn.

[valinet]

Yup, exactly. Speaking of which, yeah, I will leave it set to apply for 22567 and upwards, I want to push this to the repo. Thanks.

[valinet]

Well, yeah, seems to happen only in Windows "Pro" (and probably Home as well). I have switched from 22572 Enterprise to 22572 "Pro" in my VM and have a transparent taskbar now.

[valinet]

Yeah, it seems WCA_FORCE_ACTIVEWINDOW_APPEARANCE doesn't work in some circumstances anymore. explorer.exe calls SetWindowCompositionAttribute with that for the taskbar in order for it to have the "acrylic" appearance. Yeah, idk what a proper fix would be... Simple Window Switcher uses WCA_ACCENT_POLICY and that still seems to work, although one has to supply a color and opacity for that.

Wrong. Again, the old code is guarded by some if call that enters the wrong branch. The culprit seems to be explorer!UpdateWindowAccentProperties which now has an if check before taking the legacy code path which probably still works.

That if check seems to come up true for now on consumer Windows editions and thus fucks up the taskbar with that untested code path, thus not working on Windows Pro, while on Windows Enterprise it worked just fine because it was using the other branch.

[valinet]

Okay, figured out the transparent taskbar problem as well. Again, some new "addition" by Microsoft that they obviously haven't bothered to test that it works with the legacy taskbar as well.

To keep it short, the taskbar acrylic is set up in this function: explorer!UpdateWindowAccentProperties. In 22000-based builds, it looks something like this:

void __fastcall UpdateWindowAccentProperties(struct ITrayComponentHost *a1, HWND a2, __int64 a3)
{
  HWND v3; // rbx
  struct ITrayComponentHost *v4; // rcx
  __int64 v5; // r8
  int v6; // [rsp+20h] [rbp-38h] BYREF
  int *v7; // [rsp+28h] [rbp-30h]
  int v8; // [rsp+30h] [rbp-28h]
  int v9[4]; // [rsp+38h] [rbp-20h] BYREF

  v3 = a2;
// some telemetry call
  v9[3] = 0;
  v9[0] = (unsigned __int16)GetTaskbarTheme() >> 8 != 0 ? 4 : 1;
  v9[2] = GetTaskbarColor(v4, (unsigned int)v9[0], v5);
  v8 = 16;
  v9[1] = 19;
  v6 = 19;
  v7 = v9;
  SetWindowCompositionAttribute(v3, &v6);
}

Basically, the now classic SetWindowCompositionAtribute with attribute 19 and colors taken from those helper functions. In 22572+, they modified it like this:

void __fastcall UpdateWindowAccentProperties(struct ITrayComponentHost *a1, HWND a2)
{
  __int64 v3; // rdx
  int v4; // [rsp+20h] [rbp-30h] BYREF
  int *v5; // [rsp+28h] [rbp-28h]
  int v6; // [rsp+30h] [rbp-20h]
  int v7[2]; // [rsp+38h] [rbp-18h] BYREF
  unsigned int TaskbarColor; // [rsp+40h] [rbp-10h]
  int v9; // [rsp+44h] [rbp-Ch]

  if ( (unsigned __int8)wil::details::FeatureImpl<__WilFeatureTraits_Feature_STTest>::__private_IsEnabled(&wil::Feature<__WilFeatureTraits_Feature_STTest>::GetImpl'::2'::impl))
  {
    v9 = 0;
    TaskbarColor = 0;
    v7[0] = 2;
  }
  else
  {
// some telemetry call
    v9 = 0;
    v7[0] = (unsigned __int16)GetTaskbarTheme() >> 8 != 0 ? 4 : 1;
    TaskbarColor = GetTaskbarColor((struct ITrayComponentHost *)(unsigned int)v7[0]);
  }

  v6 = 16;
  v7[1] = 19;
  v4 = 19;
  v5 = v7;
  SetWindowCompositionAttribute(a2, &v4);
}

Basically, the old behavior is guarded by that if check. On my Windows Enterprise Insider Preview test VM I was not hitting this bug because, apparently, that if check returned false for me. The if check apparently looks for some feature in the OS, and presumably that "feature" is only available in consumer versions of Windows, like Home and Pro. Once I made a new VM with Windows Pro, I hit the problem as well, and got the transparent taskbar.

I don't know exactly what that if check does, but it seems to not set the color properly. I think the legacy behavior is preferred. I tried walking the call stack of that if check for an eventual avenue of exploitation, but for now, a binary patch is easier and quicker. Looking on the disassembly, we have:

.text:000000014019D052                 lea     rcx, ?impl@?1??GetImpl@?$Feature@U__WilFeatureTraits_Feature_STTest@@@wil@@CAAEAV?$FeatureImpl@U__WilFeatureTraits_Feature_STTest@@@details@3@XZ@4V453@A ; wil::details::FeatureImpl<__WilFeatureTraits_Feature_STTest> `wil::Feature<__WilFeatureTraits_Feature_STTest>::GetImpl(void)'::`2'::impl
.text:000000014019D059                 call    ?__private_IsEnabled@?$FeatureImpl@U__WilFeatureTraits_Feature_STTest@@@details@wil@@QEAA_NXZ ; wil::details::FeatureImpl<__WilFeatureTraits_Feature_STTest>::__private_IsEnabled(void)
.text:000000014019D05E                 test    al, al
.text:000000014019D060                 jz      short loc_14019D073
.text:000000014019D062                 and     [rbp+var_C], 0
.text:000000014019D066                 and     [rbp+var_10], 0
.text:000000014019D06A                 mov     [rbp+var_18], 2
.text:000000014019D071                 jmp     short loc_14019D0A2
.text:000000014019D073 ; ---------------------------------------------------------------------------
.text:000000014019D073
.text:000000014019D073 loc_14019D073:                          ; CODE XREF: UpdateWindowAccentProperties(ITrayComponentHost *,HWND__ *)+2C↑j
.text:000000014019D073                 mov     dl, 1
.text:000000014019D075                 lea     rcx, ?impl@?1??GetImpl@?$Feature@U__WilFeatureTraits_Feature_TUC@@@wil@@CAAEAV?$FeatureImpl@U__WilFeatureTraits_Feature_TUC@@@details@3@XZ@4V453@A ; wil::details::FeatureImpl<__WilFeatureTraits_Feature_TUC> `wil::Feature<__WilFeatureTraits_Feature_TUC>::GetImpl(void)'::`2'::impl
.text:000000014019D07C                 call    ?ReportUsage@?$FeatureImpl@U__WilFeatureTraits_Feature_TUC@@@details@wil@@QEAAX_NW4ReportingKind@3@_K@Z ; wil::details::FeatureImpl<__WilFeatureTraits_Feature_TUC>::ReportUsage(bool,wil::ReportingKind,unsigned __int64)
.text:000000014019D081                 call    ?GetTaskbarTheme@@YA?AUTaskbarTheme@@XZ ; GetTaskbarTheme(void)
...

Of course, of interest is jz short loc_14019D073. That says "when the if returns false, so 0, jump to loc_14019D073". This is what we want to always happen, we want the jump to take place irrespective of what the if returned, because we always want the legacy behavior employed when using the legacy taskbar. So, looking on the disassembly, we notice this pattern, corresponding to test al, al; jz short loc_14019D073; and ... from above is unique throughout the whole code: 84 c0 74 11 83 65. jz is the 74. If we change that to eb, it becomes a jmp. That's the patch; we run that and we get this:

This takes care of the second issue with the latest build. This Insider build is pretty sketchy out of the box nevertheless: the Settings app always fails to open for me, ExplorerPatcher installed or not. As well, I got some crashes, but can't yet pinpoint what is the culprit. For now, I have pushed the 2 fixes (transparent taskbar + taskbar thumbnails) to the repo, and hopefully they work for you as well.

Hopefully, the above 2 explanations will shed some light on why supporting these Insider builds is a pain the ass. The code is too volatile, they test a ton of shenanigans that do not even make it to final builds and so on.

Also, you see hands on why this can't run on ARM64 out of the box. The patch above clearly alters amd64 assembly, so of course it works only on amd64 processors. A different patch has to obviously be written for this to work on ARM64 as well, which runs an ARM64 version of explorer.exe on which amd64 patches at best have no effect, while at worst bork the entire application, obviously.

Regarding other issues with this build, I don't have much else time to investigate. It otherwise seems to work fine, although, as I said, in general, I personally can't to regular things in this build, like open Task Manager or the Settings app, and tbh, I don't even care to do. I solved a hang by hard resetting the VM, and it never happened since. Work in the area of fixing the program for this build has been done, you can build on that if you need more.

Thanks

[Aokromes]

i vote https://www.deskmodder.de/blog/2022/03/12/windows-11-snap-gruppen-an-die-taskleiste-anheften-waere-doch-mal-was/ the reason of your issues.

[valinet]

There're no elections here, c'mon... it's a technical forum, come with some technical argument. Why would it be that? First of all, people here talk about the Windows 10 taskbar while that is for the Windows 11 one.

your issues

My issues? I've none, the program works just fine on the stable builds which I use just fine. People around here seemed to have had an issue and I was trying to look into it...

[Aokromes]

ok, bad worded, the issues of valinet with newer insider builds.