The horrid amalgamation of code known as
Windows Vista wasn’t all bad. As a result of the many effected changes, users were given the ability to run an executable by typing its name in the navigation bar of
explorer.exe’s window1. By doing so the newly created process had its
working directory set to the one shown in that window.
Sadly, even this one redeeming feature has an unfortunate side effect: subsequent attempts to select the path of the directory from the nav bar will yield something else - the absolute path of the executable that was run.
Let the hate flow through you
After ~7 years of coping with this issue I eventually snapped. Fueled by anger due to my most recent path-related mishap I decided this merits a “proper” fix instead of always navigating one-dir-up-and-then-back ™ to revert the path to its correct value.
procmon and looked for the culprit. Evidently the blame should fall on
ExplorerFrame.dll, within which
SetWindowText and thus
making my life a living hell changing the navigation bar text.
It’s over, I have the high ground
windbg, I made it so the code would never reach the
SetWindowText call and it seemed to fix it. I went ahead and patched the DLL in
system32 with a boastful grin, foolishly forgetting Microsoft’s chronic new take on updates…
The new plan was to use the windows Debug API to get the symbol information for both functions and then use
Capstone to locate the call to
CAddressEditBox::_CanStompCurrentText. This way I could patch it every time my OS (forcibly) updates.
To prevent the path from changing I simply patch the code to make the path “un-stomp-able” by making sure the
ZF is always set:
I implemented this in
ctypes and also wrote a small
batch script to make overwriting the original DLL easier.
A surprise, to be sure, but a welcome one
To my amazement the patch not only works on my machine, but on older versions as well2. The only one that required a slight adjustment was
Windows 7 64-bit.