Microsoft → [WIN7] Calculator issue

OS: Windows 7, Pro, x64
Windows calculator, calc.exe runs fine in its default location, C:\Windows\System32\calc.exe or C:\Windows\SysWow64\calc.exe

But, when I copy it to a location, such as C:\temp\calc.exe or C:\Junk\calc.exe, it doesn't run. It doesn't issue an error message. ProcessMonitor sees it start, and I'm not seeing anything in there that explains this.

As of two months ago, I believe I was able to copy calc to another folder and run it. So, something happened, at least on this system. Maybe I jacked this system somehow. But I wondered if anyone else has observed this behavior?

Just tried it with notepad.exe, same thing. It runs in the folder where it originally resides, but I can't copy it elsewhere and run it. I copied some other executibles into C:\temp and they run.

I don't remember this happening a couple of months ago. Calc and notepad are reliable lightweight programs that don't cause damage, and are good for testing purposes.

Just copied cmd.exe to c:\temp - that one runs. Can't figure it out.

Here's the fix:

Stop moving .exe files.

I copied, I didn't move.

I wonder if they could have sent an update Frodo to stop thier programs from working anywhere else?? (Stuff they put on the computer)

What if you change the filename?? (then if that IS WHY it may still run)



When you right click CALC.EXE and choose COPY and place it in say MY DOCUMENTS it wont show up when you open it?? (I wonder what would happen if you open task manager and clicked BRING TO FRONT)

For what it is worth, I'm running Windows 8.1, and what you describe happens. I can double-click the "Calc.exe", which is located at C:\Windows\SysWOW64, and it runs as expected.

In my case, I have a 2nd hard drive in my system that I use for backup purposes, storage of installs, and so on. If I copy that to the root of that drive, and try to run it from there, it will not launch. The original exe in the Windows folder still runs as expected.

Like you, I thought that one point I was able to do this. Back when I had Windows 7, I was tracking down an issue my system was having with a corrupt icon cache (the exe's would loose their icon picture, rebuilding the icon cache fixed that). But, to troubleshoot the issue, I was moving EXE's around, and trying different ones in different places. From what I remember, I used windows exe's like regedit, notepad, and calc. Again, this was at least a year ago now, as I've been running Windows 8.0/8.1 since it came out.

So, I do feel something has changed. What, I do not know.

It is odd, however, that no error message is displayed. Task Manager does not even show the process start. Its like I did not even click on it at all. I even went so far to clear all the events out of event viewer (was left with just one informational event), and then clicked on the EXE. Nothing was logged there either.

As another test, I also ran calc.exe from a command prompt. In its default location, typing "calc" on the command line causes the program to launch as expected. From my copy on the root of my D drive, nothing happens. No error messages, no pop-ups, no events logged in the event viewer.

--Brian

Wild guesswork:

1. The program needs some other resource, such as a DLL.

2. The lookup for that resource is constrained to use the same directory as the main program image.

3. The program is written in such a way as to terminate when it can't find these other resources.

4. No error message is issued, since that would involve finding some other resources.

5. If the above is correct, then this was a security fix - I vaguely remember attacks based on dropped malware DLLs somewhere in the lookup path where they would be found before the real DLL, and the fix was to remove the (unnecessary) path flexibility.

Like I said, pure guesswork.

FWIW, if I run notepad.exe from its correct location, and then look at the process with Process Explorer, then it's actually got en-US\notepad.exe.mui open. Maybe that's the issue: it can't find its user interface resources if moved.

Edited: This page indicates that the localized resources are sought in a subdirectory of the directory containing the language-neutral app. So my guess probably is correct.

A couple of months ago, I was using a copy of calculator to test software restriction policies and other things, and it was working. I have a folder with a bunch of calc's with various names.

Something got introduced recently that I didn't hear about. It wasn't the immediate month's updates - I think I was running into this issue last week. Anyway, I have a calc from XP that seems to work.

Well, to test that theory, I copied C:\Windows\System32\en to c:\Junk\en and copied C:\Windows\System32\en-US\calc.exe.mui to C:\Junk\en-US\calccopy.exe.mui.
Lo and behold, calccopy is running.
But still, this is a change in behavoir. The properties on calccopy indicate that the original file name is calc.exe. I'm thinking it used to try the default MUI directory using the original file name before or something, because a couple of months ago, it was working.

quote:

---

Lo and behold, calccopy is running.

---

Ahh so maybe what i was thinking is what they did! (Changing the filename and having it work confirms this)

Changing the file name did not make it work. Copying the multilanguage user interface files was what made it work.

Thank you Dave I missed that!!

Why did they add language files to calc?? -- Seems unneeded on someone who has ENGLISH set as the language on thier computer.....

Hmmmmm

If the file name is changed, then the name of the MUI file must also be changed.

So, I wound up with a calccopy.exe and a calccopy.exe.mui . I did not need to create a junk\en folder, but I did need a junk\en-US folder with calccopy.exe.mui in it in order to run junk\calccopy.exe .

I followed your description: if you rename the exe then you must also rename the mui file. 19579823 's view (now corrected in his later post) seemed to be that simply renaming the exe is what causes it to work.

But that's the point: someone who sets the language to not-English also wants to be able to use calc.

'Language files' are not just for people who don't read English. The design calls for language-neutrality: all localizable resources should be located in a loadable module, selected based on the user's choice of language. English is not privileged in this regard. Or even American.

The point of outboarding the localized resources is twofold: (1) other language translations can be added without changing the main program, (2) shipping an update to the main program logic, say for a bug fix, does not require shipping new copies of all localized resources.

Good guess. ProcExp shows it's using gdiplus.dll and WINMM.dll.

Also running W7 Pro here. Get the same thing you describe if the program is "copied" to a new location such as the desktop.

In lieu of copying the program to a different location I create a shortcut instead. That seems to work with no problems here.

I just checked my calc.exe with Process Explorer and it has 8 files loaded.....



How many does your have loaded??

Presumably you're looking at the 'handles' display. DLLs mapped into the address space are listed in the 'DLLs' display, and there are too many for me to be bothered to count.

The word 'loaded' is not particularly meaningful in a virtual memory system, but the DLLs display comes closer.

Nope I have DLL selected Dave,you really have that many DLLs loaded when you run calc??

Sure... this seems like a fairly standard set.

Oh My Dave!!

Heres all I have...

Ah, you're running an entirely different operating system there.

Yup Im on Win98se

When i goto HANDLES only 1 shows up for Calc.exe