New Version of ExplorerPatcher

Anixx · May 31, 2022

I have a problem: certain key combinations crash session and video driver, throw me to the logon screen and with video driver disabled.

For instance, Win+;
Does this happen with others?

valinet · Jun 1, 2022

Spartan said:
@valinet Not sure if this is a bug or not but if I set the taskbar style to Windows 11, the combine taskbar icons set to never doesn't do anything even after restarting explorer, the taskbar icons are always combined.

View attachment 30376 View attachment 30377

Notice the label "The following settings only apply to the Windows 10 taskbar". That means "Never combine" is only available when using the Windows 10 taskbar style. In the next stable release, the Properties window will hide settings that do not apply to your current configuration, so you won't get to see those options unless you pick the "Windows 10" taskbar style.

JalapenoMunich · Jun 2, 2022

Thank you, @valinet for ExplorerPatcher. It's fantastic.

I do have one question/feature request, however. I checked the README and the feature descriptions on Github, but I couldn't find anything. Apologies if I have missed it.

I have pinned a few apps to the taskbar. My memory might be playing tricks on me, but I believe that under Windows 10, when I clicked on a thumbnail, the app opened to the very right, after all other open apps. With Explorer Patcher, the App opens directly where the thumbnail is located. I hope I've managed to explain what I mean, here's an illustration that might help.

Is there already an option in ExplorerPatcher to change this behaviour? If not, is there any chance you could add this feature?

Thanks for your hard work!

Anixx · Jun 2, 2022

@JalapenoMunich if you pin things to taskbar, they open where the icon is, it is a feature of Windows. The icon just grows into the taskbar button.

If you make a separate quick launch bar, then the apps start with new task buttons and the icon remains.

Pinned item:

Quick Launch bar:

This has nothing to do with EP.

JalapenoMunich · Jun 2, 2022

Thanks, @Anixx! "Quick launch bar" was the term I was missing. I managed to solve the problem.

shadowz1337 · Jun 2, 2022

Not sure if this is the right thread to post this question, but does anyone know whether ExplorerPatcher actually patches any system files? Also, after you uninstall ExplorerPatcher, does it restore any patched system files back to the original file?

I'm asking because I noticed that ExplorerPatcher seems to cause crashing issues with Unity games. Apparently it modifies "dxgi.dll", which is related to DirectX and I'm pretty sure a lot of games use DirectX. After uninstalling ExplorerPatcher, I noticed my game is a lot more stable now, but it's still crashing every now and then. I have tested this by installing a brand new Win11, run the game for hours without issues and then try the same thing with ExplorerPatcher installed and game will crash.

As far as I know, uninstalling ExplorerPatcher can be done from appwiz.cpl or via Command Prompt with the /uninstall parameter. But I'm not sure if it actually cleans up any leftover files in the registry or in folders like %appdata% or whatever, and whether it restores any original files that it has previously patched....

Anixx · Jun 2, 2022

shadowz1337 said:
Not sure if this is the right thread to post this question, but does anyone know whether ExplorerPatcher actually patches any system files?

No, it does not.

Anixx · Jun 2, 2022

shadowz1337 said:
Apparently it modifies "dxgi.dll", which is related to DirectX and I'm pretty sure a lot of games use DirectX.

It does not modify it, it adds a library with this name to the Windows folder which has priority over System32 folder

shadowz1337 · Jun 2, 2022

Anixx said:
It does not modify it, it adds a library with this name to the Windows folder which has priority over System32 folder

I see. Does uninstalling ExplorerPatcher remove this library then? And will other apps that use dxgi.dll use the wrong one, while ExplorerPatcher is installed?

Anixx · Jun 2, 2022

shadowz1337 said:
I see. Does uninstalling ExplorerPatcher remove this library then?

Yes.

And will other apps that use dxgi.dll use the wrong one, while ExplorerPatcher is installed?

All will use the ExplorerPatcher's dll as long as it is in the Windows folder. It should redirect the calls not related to Explorer to the one in System32 folder.

shadowz1337 · Jun 2, 2022

Anixx said:
Yes.

All will use the ExplorerPatcher's dll as long as it is in the Windows folder. It should redirect the calls not related to Explorer to the one in System32 folder.

Thanks. That probably explains why my Unity game was crashing when I had ExplorerPatcher installed and not crashing after I uninstalled ExplorerPatcher. I really like using ExplorerPatcher and it didn't give me any other issues apart from Unity games crashing, so it's a bit of a shame.....

valinet · Jun 2, 2022

Anixx said:
It does not modify it, it adds a library with this name to the Windows folder which has priority over System32 folder

Please, if we spread information, let's makre sure it is correct. The Windows folder doesn't have any priority over System32, that's a misinformation that can cause a lot of trouble.

When applications load external libraries, they use system provided functions like `LoadLibraryW` and `LoadLibraryExW`. Developers can choose either to provide the full path to the library they want, which ensures the loader loads it from the path specified only, either only its name, in which case the loader adopts a strategy for identifying a library with that name on the system and loading it. This is useful for a ton of reasons I won't go into. What is important is understanding what is the strategy the loader adopts in such a case.

Unless the app runs under some special condition (it uses some compatibility shim etc) and unless the app requests a particular search strategy from the loader, the default behavior, largely is this (it is more in-depth documented [here](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order)):

* The folder where the application is located
* System32 folder
* Windows folder
* Folders in PATH

As you can see, the loader will first attempt to load a library from the folder where the application resides into.

In the case of `explorer.exe`, weirdly enough it lives in `C:\Windows` instead of the more usual `C:\Windows\System32`. It references `dxgi.dll`, so the loader attempts to load that library. In a clean Windows install condition (i.e. without EP installed), it tries to load `dxgi.dll` from the application's folder (`C:\Windows`) and it fails, then it tries from System32, where it finds it and probably succeeds; this is per the search strategy listed above.

As you can see, there is a window of opportunity here, where if you create a library called `dxgi.dll` and place it in `C:\Windows`, that will get loaded instead of the one in `C:\Windows\System32`. So, ExplorerPatcher places itself in `C:\Windows` named `dxgi.dll` in order to have the loader load it instead of the OG `dxgi.dll` when `explorer.exe` runs. One thing to note here is that, theoretically, all executables from `C:\Windows` would load the EP-provided `dxgi.dll`, but since `regedit.exe` and what's in there do not actually use `dxgi.dll`, it only really affects `explorer.exe`. The EP-provided `dxgi.dll` exports the same entry points as the OG `dxgi.dll` and redirects calls to those entry points to the OG `dxgi.dll`. The injection happens when `explorer.exe` calls `DXGIDeclareAdapterRemovalSupport`, which happens very early when `explorer.exe` starts. Then, EP sets itself up, and then forwards the call to the OG `dxgi.dll`, as usual.

So no, EP doesn't actually screw with other applications, as those will surely, unless placed in `C:\Windows`, load the OG `dxgi.dll` from `C:\Windows\System32`, which is correct.

Also, of very important note is to make sense of why was `dxgi.dll` specifically chosen:

* As said above, one of its function is called very early when `explorer.exe` loads, thus ensuring `explorer.exe` hasn't done much so EP can patch it freely and extensively. Side note: when the loader loads a DLL, it actually calls a function from it (`DllMain`). So injection could happen there as well, right? Well, not really, since in this case, injection means patching things from other libraries used by `explorer.exe`, libraries which may not have been loaded yet (the load order is hard to predict in a maintainable way). Thus, one would net to load those libraries in code. The trouble is, the loader is already loading our library, so if we attempt loading other libraries, it may enter a deadlock (library loads are serialized) or loop indefinitely, idk exactly how it is implemented (imagine the EP-provided `dxgi.dll` loading `shell32.dll`, for example, which, hypothetically, also loads and requests `dxgi.dll` - this would lead to an infinite loop). So yeah, not doable, the proper way to do the patching is to do it when some function from the exploited DLL is called by the originale executable.
* The loader uses a special search strategy that only looks for the DLL in `C:\Windows\System32` for highly-sensitive DLLs that are located on the `KnownDLLs` list from `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\`. When you request the loader to load a path-less DLL that is located on the `KnownDLLs` list, it always searches it in System32 instead of following the usual search order. This is to make sure that the kind of behavior I described above cannot be deployed against most DLLs that are likely to be linked to by every application (99.99% of the apps link to certain DLLs, like `user32.dll`, for example). `dxgi.dll` is not on that list, for example, so I use it to have EP load in `explorer.exe`. Another one that's not on the list is `wincorlib.dll` and that's how I inject EP in `StartMenuExperienceHost.exe` to bring back the Windows 10 Start menu. Side note: `StartMenuExperienceHost.exe` also references `dxgi.dll`, but by the time something from `dxgi.dll` is called, the code for deciding which Start menu to use already has run and thus, the decision to run the Windows 11 menu has already been taken and cannot be patched anymore. Entry points from `wincorlib.dll` run way earlier, thus giving the opportunity to make this patch and have the Windows 10 menu show.

The idea with EP is to have things patched at runtime, so that it survives Windows updates, `chkdsk.exe`, it doesn't tamper the system files etc. Only thing it does it adds its DLLs near some of the applications it hooks, but doesn't replace any system file. When Windows updates come, EP always survives, things that usually happens is Microsoft changes some functionality code wise and EP has to be reworked for that, or the symbols which are used for something else entirely (described in the wiki) have not been published for that build.

I hope this clarifies more how the app works in the regards mentioned lately.

Anixx · Jun 2, 2022

valinet said:
In the case of `explorer.exe`, weirdly enough it lives in `C:\Windows` instead of the more usual `C:\Windows\System32`. It references `dxgi.dll`, so the loader attempts to load that library.

Hmmm, thanks for the extensive explanation. I was under impression that C:\Windows has a priority because the DLLs that inject DWM rather than Explorer also should be placed in C:\Windows to override the DLLs in C:\Windows\System32.

I mean these: Download for ClassicTheme.exe's DWM DLLs | WinClassic

The-Hive · Jun 6, 2022

I had an update to Microsoft Edge WebView2 Runtime from version 101.0.1210.53 to the new version 102.0.1245.33 and found that it stopped the ExplorerPatcher weather app from working, so if you are thinking of the upgrade, think twice

Anixx · Jun 7, 2022

The build 708 seemingly removed the accent color and desktop color pickers dialogs from the control panel "personalization" sheet (they now redirect to the Settings app):

I wonder whether they can be restored?

hdmi · Jun 7, 2022

valinet said:
, not read opinions about software preferences of some.

Last time I checked, nobody has forced you to read those. This thread is about everything related to ExplorerPatcher, which also includes things like Battery Mode and Open-Shell, as both of these two had previously been mentioned in the official documentation of ExplorerPatcher on GitHub by YOU. Like it or not...

valinet said:
Open a blog for that or use some other thread, please.

Everything I posted is directly related to the subject of this thread. Creating a separate new thread will only obfuscate the discussion more, so no.

valinet said:
I don't understand the reason for your posts

The reason for my posts is quite simple. It is to try to be helpful to those who seek to achieve a more productive work environment on Windows 11.

valinet said:
Please, there's no need for unsolicited attacks; where do you see me trying to impose what to use, eh?

I see no attacks nor any attempts to impose what to use, as people are still free to futz around with live tiles (read: live tiles that need to be attacked, cunningly, just so you'll be able to Pin to Start...) if that's what they TRULY prefer. It was just an advice, lol!

valinet said:
You're free to use the software alongside whatever you'd like, I never changed my stance, only you (maybe) lived with that impression.

I don't live with those kinds of impressions, as they are irrelevant, and, I generally prefer to communicate with people who believe it's trivial the fact that these kinds of impressions are irrelevant.

valinet said:
I still like developing in the open and free software as well, despite many of you vigorously trying to prove why choosing the opposite model might actually work out better.

I am a trained Java Enterprise software developer, and have been that for more than 15 years so basically I ignored the .NET movement and I learned EJB 2.1 on JBOSS back then. I vastly prefer open source because I honestly believe that no one who works for Mickeysoft has the capacity to know how stuff factually works. Worse, I don't think it's technically materially possible for one to write something like ExplorerPatcher and still not see the overwhelming evidence that is in support of such a belief, even. lol

valinet said:
So your 'recommendation' is to have OpenShell get out of the way and still use the EP-patched OG Start menu for my purpose. So, what was really the point of your statement? Please don't answer.

I'll still answer anyway. It's so people can hopefully better understand that they don't have to reinvent the wheel, in the possible event that they don't want to. Ivo did a wonderful job and so did you! :)

valinet said:
Again, the reason you felt attacked by the statement is beyond my comprehension, but whatever.

I didn't feel attacked by it. Heck, I'm not even mad at the live tiles on my phone anymore now, as that problem has easily been solved also, multiple years ago by moving to a new phone with Android.

hdmi · Jun 7, 2022

The-Hive said:
I had an update to Microsoft Edge WebView2 Runtime from version 101.0.1210.53 to the new version 102.0.1245.33 and found that it stopped the ExplorerPatcher weather app from working, so if you are thinking of the upgrade, think twice

Yeah, ExplorerPatcher's weather recently has changed to the People view on my Win 10 taskbar.

The-Hive · Jun 7, 2022

hdmi said:
Yeah, ExplorerPatcher's weather recently has changed to the People view on my Win 10 taskbar.

That's what happed to me, I removed the WebView update and it went back to normal, so that is what it was on my machine

valinet · Jun 7, 2022

The-Hive said:
I had an update to Microsoft Edge WebView2 Runtime from version 101.0.1210.53 to the new version 102.0.1245.33 and found that it stopped the ExplorerPatcher weather app from working, so if you are thinking of the upgrade, think twice

Pre-release 22000.708.46.5 should fix this issue, I have made the commits, it will be generated soon.

Steerpike · Jun 7, 2022

valinet said:
...

I hope this clarifies more how the app works in the regards mentioned lately.

Beautiful explanation! Well written. After reading this, it's amazing to me that EP doesn't get flagged as a virus or malware or whatever. Also, what's to stop MS from adding the dll names you rely on to the 'known dll' list? Do you feel you could keep EP working even if MS were to tighten things up a bit, or do you think you are sailing close to edge on this one? I truly hope EP keeps working as it does a fantastic job, and obviously represents a lot of hard, hard work on your behalf.