{"id":10560,"date":"2021-12-13T04:33:04","date_gmt":"2021-12-13T12:33:04","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=10560"},"modified":"2022-02-21T13:43:23","modified_gmt":"2022-02-21T21:43:23","slug":"running-powershell","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/alwaysup\/running-powershell\/","title":{"rendered":"Q&A: Why does AlwaysUp run the 32-bit Version of PowerShell?"},"content":{"rendered":"
\"Why<\/div>\n
\n  We have been trying to get a particular PowerShell script<\/a> 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.<\/p>\n

I am using a 64-bit PowerShell module (SqlServer). My script runs fine in the ISE<\/a>, 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\u2019m 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.<\/p>\n

Here is what I have specified in AlwaysUp:<\/p>\n

Application: C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe<\/span><\/b>
\nArguments: <The full path to my PowerShell script><\/b>
\nStart in: <The folder containing my PowerShell script><\/b><\/p>\n

How I\u2019m confirming my suspicions:<\/p>\n

I’m running the PS command [Environment]::Is64BitProcess<\/a> 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.<\/p>\n

Any help would be greatly appreciated.<\/p>\n

— Dustin<\/p>\n<\/div>\n

Hi Dustin, sorry to hear of the trouble! Thanks for doing the detective work to clearly illustrate the problem for our support team.<\/p>\n

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.<\/p>\n

The System32, SysWOW64 and Sysnative folders<\/h2>\n

On your 64-bit system, 64-bit applications distributed with the operating system live in this folder:<\/p>\n

C:\\Windows\\System32<\/b><\/p><\/blockquote>\n

Similarly, this folder holds the equivalent 32-bit versions of those Windows applications:<\/p>\n

C:\\Windows\\SysWOW64<\/b><\/p><\/blockquote>\n

For example, we have the 64-bit version of powershell.exe in the System32 directory:<\/p>\n

\"powershell.exe<\/a><\/div>\n

While the 32-bit version resides in exactly the same place under the SysWOW64 folder:<\/p>\n

\"powershell.exe<\/a><\/div>\n

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.<\/p>\n

Now here is where the magic comes in…<\/p>\n

When a 64-bit program launches an application under the System32 folder, Windows simply starts the application, as expected.<\/p>\n

However, when a 32-bit program tries to run an application that lives under the System32 folder, Windows:<\/p>\n

    \n
  1. \n

    Replaces C:\\Windows\\System32<\/b> with C:\\Windows\\SysWOW64<\/b> in the application’s path, and<\/p>\n<\/li>\n

  2. \n

    Runs the application from that SysWOW64 location.<\/p>\n<\/li>\n<\/ol>\n

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

    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.<\/p>\n

    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).<\/p>\n

    But then how does a 32-bit program start a 64-bit system utility?<\/h3>\n

    If a 32-bit program really needs to invoke a 64-bit system executable, it can do so by citing the Sysnative<\/b> virtual folder.<\/p>\n

    For instance, if a 32-bit application wants to run the 64-bit version of notepad, it should invoke:<\/p>\n

    C:\\Windows\\Sysnative\\notepad.exe<\/b><\/p><\/blockquote>\n

    In that way, the Sysnative folder makes it possible for 32-bit programs to call 64-bit operating system utilities.<\/p>\n

    Why AlwaysUp launches the wrong version of PowerShell<\/h2>\n

    AlwaysUp is a 32-bit application. As such, it is bound by the rules above.<\/p>\n

    So when AlwaysUp launches the application you provided:<\/p>\n

    C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe<\/b><\/p><\/blockquote>\n

    Windows actually starts:<\/p>\n

    C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe<\/b><\/p><\/blockquote>\n

    which is the 32-bit version of PowerShell.<\/p>\n

    How to make AlwaysUp launch the 64-bit PowerShell executable<\/h2>\n

    To make AlwaysUp run the 64-bit version of PowerShell, specify this value in the “Application” field:<\/p>\n

    C:\\Windows\\Sysnative\\WindowsPowerShell\\v1.0\\powershell.exe<\/b><\/p><\/blockquote>\n

    Doing so will force Windows to invoke the version you want.<\/p>\n

    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<\/a> if you don’t get the desired result!<\/p>\n

    Even though we have a solution, there is one corollary we should mention…<\/p>\n

    Why can’t I see the Sysnative folder?<\/h2>\n

    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<\/b>. 64-bit programs (like the File Explorer you started) simply cannot see that directory.<\/p>\n

    However, to prove for yourself that the folder exists for 32-bit applications, start a 32-bit command prompt by running this command:<\/p>\n

    C:\\Windows\\SysWoW64\\cmd.exe<\/b><\/p><\/blockquote>\n

    Magically, the Sysnative folder will be visible from there:<\/p>\n

    \"32-bit<\/a><\/div>\n