We have been trying to get a particular PowerShell script running as a service for some time now. I have been pulling my hair out but I think I finally found the issue and I don’t understand why it’s happening.

I am using a 64-bit PowerShell module (SqlServer). My script runs fine in the ISE, no issues. But, every time I run it from AlwaysUp it gets an error that it cannot find the module. What I finally found out is AlwaysUp is launching the 32-bit version of PowerShell and not the 64-bit version that I’m calling out. So, even though my script calls the 64-bit version of PowerShell, it’s launching the 32-bit version, which is not compatible with what I’m doing.

Here is what I have specified in AlwaysUp:

Application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: <The full path to my PowerShell script>
Start in: <The folder containing my PowerShell script>

How I’m confirming my suspicions:

I’m running the PS command [Environment]::Is64BitProcess and dumping the display to a text file. When running this command, it returns true if the instance is 64-bit, otherwise false. I confirmed this works as expected by opening both PowerShell ISEs (32/64) and the correct response was given. However, the command always returns false when running through AlwaysUp.

Any help would be greatly appreciated.

— Dustin

Hi Dustin, sorry to hear of the trouble! Thanks for doing the detective work to clearly illustrate the problem for our support team.

The issue is caused by a bit of magic that Windows performs to maintain compatibility between 32-bit and 64-bit applications. Let’s explore some special folders.

The System32, SysWOW64 and Sysnative folders

On your 64-bit system, 64-bit applications distributed with the operating system live in this folder:

C:\Windows\System32

Similarly, this folder holds the equivalent 32-bit versions of those Windows applications:

C:\Windows\SysWOW64

For example, we have the 64-bit version of powershell.exe in the System32 directory:

While the 32-bit version resides in exactly the same place under the SysWOW64 folder:

If you switch to the “Details” tab, you will see that both executables have exactly the same version number. In fact, they perform identically when run.

Now here is where the magic comes in…

When a 64-bit program launches an application under the System32 folder, Windows simply starts the application, as expected.

However, when a 32-bit program tries to run an application that lives under the System32 folder, Windows:

1. Replaces C:\Windows\System32 with C:\Windows\SysWOW64 in the application’s path, and

2. Runs the application from that SysWOW64 location.

For example, if a 32-bit program tries to start C:\Windows\System32\notepad.exe, Windows will run C:\Windows\SysWOW64\notepad.exe instead!

Windows performs this “remapping” to provide stability for 32-bit applications, which often have trouble working with 64-bit applications. Microsoft thinks it is best to ensure that legacy 32-bit programs work with a legacy “32-bit view” of the operating system. Indeed, that makes sense when maintaining backward compatibility is top-of-mind.

However, the price of that safety is that a 32-bit application can never directly invoke a 64-bit executable sitting in the System32 folder. If it tries, Windows simply rewrites the path to target the 32-bit executable instead (as mentioned in the example above).

But then how does a 32-bit program start a 64-bit system utility?

If a 32-bit program really needs to invoke a 64-bit system executable, it can do so by citing the Sysnative virtual folder.

For instance, if a 32-bit application wants to run the 64-bit version of notepad, it should invoke:

C:\Windows\Sysnative\notepad.exe

In that way, the Sysnative folder makes it possible for 32-bit programs to call 64-bit operating system utilities.

Why AlwaysUp launches the wrong version of PowerShell

AlwaysUp is a 32-bit application. As such, it is bound by the rules above.

So when AlwaysUp launches the application you provided:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Windows actually starts:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

which is the 32-bit version of PowerShell.

How to make AlwaysUp launch the 64-bit PowerShell executable

To make AlwaysUp run the 64-bit version of PowerShell, specify this value in the “Application” field:

C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe

Doing so will force Windows to invoke the version you want.

Fortunately AlwaysUp is perfectly fine working with 64-bit applications, so you won’t run into any compatibility issues there. Please make the change and let us know if you don’t get the desired result!

Even though we have a solution, there is one corollary we should mention…

Why can’t I see the Sysnative folder?

Curiously, if you open the File Explorer and navigate to C:\Windows\Sysnative, the operation will fail. That’s because the Sysnative folder is only accessible by 32-bit applications. 64-bit programs (like the File Explorer you started) simply cannot see that directory.

However, to prove for yourself that the folder exists for 32-bit applications, start a 32-bit command prompt by running this command:

C:\Windows\SysWoW64\cmd.exe

Magically, the Sysnative folder will be visible from there:

You may also like...

Q & A: My VB6 App Doesn't Refresh in Session 0 — Help!

How to Disable Automatic Updates when Running MT4 as a Windows Service

Q&A: Why does AlwaysUp Restart my Application During Windows Shutdown?