What prevents copied/renamed/moved notepad.exe from running in some Windows editions?

Question

Test Environment:

• Windows 10 professional edition x64, True
• Windows Server 2003 R2 x86, False
• Windows Server 2008 R2 Enterprise x64, False
• Windows Server 2008 R2 DataCenter x64, True

There are 2(or 3 depends on x86 or x64) notepad.exe in Windows\, respectively Windows\notepad.exe; Windows\System32\notepad.exe; Windows\SysWOW64\notepad.exe. In the mentioned environments marked as True, all these three show this behavior below.

Behavior:

when I copy notepad.exe (to any location), the copied executable will not launch when executed, no matter where I put it. there is no warning, there is no process being created. For this I checked serveral settings:

1. file permission.
   • file permission looks OK, i.e. has the execution permission set.
2. file ownership.
   • actually this should be irrelevant, but just in case, I checked that ownership of original notepad is "TrustedInstaller", the copied executable's owner is Administrator Group, grant ownership back to TrustedInstaller didn't help, either.
3. Software Restriction Policy & AppLocker Policy
   • there are no such policies on my system when I use gpedit.msc to check them. ( I thought of hidden defaults, but that theory won't hold as it does not seem to be the case for other executables in System32, such as calc.exe/cmd.exe etc.)

Other Behaviors:

I have tried launching the copied executable using cmd/powershell/start, but no avail.

I tried copy cmd.exe/calc.exe/other executables in System32/other random executables I have/ to system32/, only notepad.exe seems to showing this behavior.

I tried to takeown of the original notepad.exe, and rename it to notepad2.exe, then it won't launch, if you change the name back to notepad.exe, it will launch again.

The Question:

I wonder what's the mechanism that does this?

Answer 1

Answered by Sander Berkouwer in social.technet.microsoft.com:

Mark Russinovich ran into the same problem when he copied notepad.exe from the Windows directory to his profile directory. After some fiddling he found out the following:

"I knew that .mui files store language-dependent resources like strings and accelerators, so I was pretty certain that Notepad’s failure to load its accelerators was due to its inability to find the appropriate resource file for my local, US English (En-us). To verify this I made an En-us subdirectory in my profile directory and copied Notepad.exe.mui into it, reran Notepad from my directory, and it worked."

I guess your solution is to get notepad.exe.mui in a subfolder named like your locale.

Your OS language may differ, if in doubt, just search for Notepad.exe.mui file.

The answer for the question is "this is not an explicit mechanism preventing the moved executable from being loaded, this is a reference resolution". I can confirm that the described method is working.