The patch has been adapted to employ the old behavior when setup is
elevated using the same credentials, while using the updated code with
`CreateProcessWithTokenW` when otherwise.
Original description (via email):
"I have two accounts on my Windows machine: A normal one that is a
standard user (not admin) which I use as my main account where I have
ExplorerPatcher installed and configured, and an Admin account which is
a Windows administrator account.
During installation and update the installer restarts itself and
requests admin privileges. For this I have to provide the password to
the Admin account. The installer then runs as that Admin user, stops
the explorer process, installs ExplorerPatcher and then tries to start
the explorer again. But the explorer never starts, which leaves me with
an empty screen and a session without an explorer. I can then start a
Taskmanager via Ctrl + Shift + Esc and manually start the explorer, but
this is annoying and maybe even frightening for a nontechnical user.
The reason why the explorer is not started again is that it is started
as the wrong user. It is started as the Admin user, which isn't logged
in so the explorer quits immediately.
The fix is to remember the user that the explorer was running under and
then start the new explorer for that user. I have tested these changes
in a Windows 11 virtual machine, by installing and uninstalling for a
standard user, as well as installing and uninstalling for an
administrator user."
Original patch: https://github.com/Abestanis/ExplorerPatcher/tree/fix_explorer_restart
Credit @Abestanis
When Windows is updated, it may fundamentally change the layout and
functionality of `explorer`'s internal data structure. Since
ExplorerPatcher intensively patches those in order to deliver its
functionality, it may lead to `explorer` crashing when it performs
these modifications while being unaware (outdated) of the latest OS
changes. The worst scenario is when the crashes happen when `explorer`
starts up (for example, when the user logs in), and could cause the
user to experience an endless loop of `explorer` crashes, and leave
him/her unable to practically use the computer.
In order to mitigate this scenario, when `explorer` starts up as the
shell, ExplorerPatcher increments a counter stored in the registry.
After a predefined timeout (by default, 10 seconds), ExplorerPatcher
will reset the counter to 0. If `explorer` crashes during this period,
the counter will not be reset. When `explorer` restarts, the cycle
repeats. If the counter reaches a predefined value (by default, 3),
instead of starting up again normally (and very probably crashing
again), ExplorerPatcher will display a message window informing the
user about what is happening, offering a few suggestions on how to
proceed next and disable its entire functionality until the next
File Explorer restart, in order to give the user a chance to perform
maintenance on the machine.
This fixes Task View and Win-Tab, Alt-Tab breaking after pressing
Win-Tab, flyouts alignment, notification center alignment, Windows key
shortcuts on OS builds 22621.1413+.
Thanks @CthRio for the heads up.
It seems Microsoft updated some stuff in `windowsudk.shellcommon.dll`
and has introduced a new interface (`ITaskbarSettings6`), from which
they call the `GetEffectiveSearchMode` method.
This is not relevant for the Windows 10 taskbar, but the code gets
called there anyway as well, so it had to be patched to support this
new interface.
This fix should address the issue and have ExplorerPatcher still work
on newer 22621-based OS builds, like 1344 ("Moment 2" update).
Impact: The actual layout setting from Windows Settings -
Personalization - Start is ignored and the "Default" layout setting is
always used when displaying the Windows 11 Start menu on 22621-based
builds when the setting to disable the "Recommended" section is NOT
used in ExplorerPatcher Properties.
Description: The issue has been addressed by remembering the current/
previous setting and using that when setting the height of the pinned
area when the setting to disable the "Recommended" section is NOT
used in ExplorerPatcher Properties, as opposed to the previous behavior
where a hardcoded value was being used.
Impact: Failure to check against a NULL value and dereferencing it
leads to a crash in `explorer.exe` with fault offset 0xfc69 on
22621-based OS builds. This happens when right clicking certain system
tray icons, like "Epic Games Launcher" when using the Windows 11
taskbar.
Description: The issue has been addressed with improved checks: a check
against NULL values is performed before attempting to work with the
data the variables might point to.
The final Windows 11 22H2 that is shipped to users is OS build 22621.
Unfortunately, I updated EP some time ago to 22622. This creates a
discrepancy between the OS build most people have and the version of
EP that they might have installed. Furthermore, I currently test EP
against OS build 22621. To make things more clear, the next version of
EP will have the major build number set to 22621.
In order to have EP use version 22621 from now on and not prevent
updating from EP 22622... to EP 22621..., I devised this workaround
where the EP version is kept to 22622 as far as updates are concerned,
but the internal build number of EP really is set to 22621.
In the future, if we want to bump the EP version to 22622 again, a
regular change in `version.h` will have the setup patcher insert a `!`
as the first character in the hash part of the version string, which
tells the updater to display that version as a real 22622 build and not
artificially decrement it to 22621.
The only slight inconvenience is that, when the next update arrives,
people will be told they upgrade to EP 22622... still, but they will
receive an EP 22621... build. But at least the updater will work and
detect the new version. From there on, subsequent versions will be
shown as 22621 in the notification if the build number for that version
really is 22621.
Amrsatrio
Valentin Radu