Explorerpatcher crashes 3rd party application as it tries to patch system DLLs

[jb-wisemo]

Before reporting your issue

• I have confirmed that this issue does not happen when ExplorerPatcher is not installed
• I do not have "register as shell extension" enabled (disabling it is a workaround but looses EP functionality)
• I have tried my best to check existing issues

Repro ExplorerPatcher versions

ExplorerPatcher 26100.8457.70d.4 (also happened in .3)

Repro Windows Versions

Win11 10.0.22631.6199

Third-party tweak software installed

OpenShell for its start menu

Describe the bug

Affected application PwSafe (64 bit) 3.72.1 from pwsafe.org

Observed in x64 WinDbg: process crashes when ExplorerPatcher tries to patch a shell related system dll loaded in the PwSafe.exe process.

In EP 10.0.22631.6199.4 this is in the call to VnPatchIAT(hShell32, "user32.dll", "TrackPopupMenu", TrackPopupMenuHook); where an attempt to zero out an IAT entry en SHELL32.dll crashes .
In EP 10.0.22631.6199.3 this was in an attempt to change byte 3 of an instruction in ExplorerFrame.DLL to 0x03 even though that byte was already 0x03

At this particular point in time, it doesn't look like PwSafe was about to display any Explorer-based UI, the DLL to patch just happened to be loaded as part of process startup. I suspect this was triggered via the "Install as shell extension" feature

As a workaround, I suggest providing an advanced option to exclude a list of named processes from getting DLLs patched by ExplorerPatcher.
Alternatively always remember to VirtualProtect the destination of a patch write and be prepared for VirtualProtect() to fail.

Expected outcome

Nothing happens and PwSafe opens normally.

Actual outcome

PwSafe crashes (status C0000005).
Running PwSafe under WinDbg with the PE 26100.8457.70.4 source zip and PDB file downloaded shows a crash as ExplorerPatcher tries to patch a system DLL, specifically PE version 26100.8457.70.4 was trying to patch the IAT in SHELL32.DLL, while PE version 26100.8457.70.3 was trying to patch an instruction in ExplorerFrame.dll (PE debug info not downloaded for this build).

Also, the EP source zip appears to lack the source for libvalinet, but I recognize DLL patching code when I see it in the Disassembly window.

Additional info

EP had the option to download and use symbol files enabled.

Crash Dumps

Because PwSafe was loading secret information, crash dumps cannot be shared, but I have tried to describe the crash location seen.

Media

No response

[jb-wisemo]

Please note that this seems to be a rare bug in the "Shell Extension" feature, please treat it as such.

[pyrates999]

if you enabled the option register as shell extension, disable it by opening up the EP properties application, go to File Explorer, and untick Register as shell extension.

Here's why: https://github.com/valinet/ExplorerPatcher/wiki/Using-ExplorerPatcher-as-shell-extension

[Amrsatrio]

I had this issue with DisplayFusion, so blacklisted it. I already wrapped the binary patching code behind a VirtualProtect check, the problem is even though it returns TRUE a write to the VP'ed region still causes an AV. I need to investigate further and find the root cause or develop a user-configurable blacklist feature. And I have to stop the address bar shrinker code from running on 3rd party programs. That's for 70.5.

https://github.com/valinet/ExplorerPatcher/blob/master/ExplorerPatcher/dllmain.c#L9067

[Amrsatrio]

Also, can you check if OldNewExplorer works with PwSafe? It uses the same techniques to hook into system DLLs.

A closer inspection into PwSafe's source code reveals that it has its own IAT patching routines to achieve dark mode in its Win32 UI.

[jb-wisemo]

From the comment about DisplayFusion, it seems that adding PwSafe.exe to the list would be a likely workaround, but my suggestion in the bug report was to allow the blacklist to be loaded from an EP config setting instead of being hard coded at build time.

From the crash, it seems the failure was in accessing the IAT shell32.dll, not the IAT of PwSafe.exe . The symptoms are very similar to what the EP code comment says about DisplayFusion.