Get-StartApps : The term 'Get-StartApps' is not recognized as the name of a cmdlet, function, script

Daniel_Pineault 

Fair enough, though it means your functions will only work on 32-bit Office, since the virtual alias of sysnative only exists for 32-bit processes running on 64-bit Windows (with syswow64 being the alias in the opposite direction of 64-bit process requiring a 32-bit Windows resource).

Cheers,

Lain

Daniel_Pineault 

Above my pay grade again (on the why), but here's some doco on it:

• File System Redirector - Win32 apps | Microsoft Learn

On the how, it's a process-level translation, not a physical construct.

Still, as long as you're working, you're good. And you've got a new trick to leverage should this kind of occurrence arise again.

Cheers,

Lain

Just got that working.

c:\windows\sysnative\WindowsPowerShell\v1.0\powershell.exe

does launch PS x64.

But why????

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe does not exist.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe exists and tried that but it still launches PS x32

Where does SysNative come from???? I found it in a discussion, but why wouldn't the real path 'System32' work?

Why does MS do screwy things like this!  If I give the path to the exe I want t you, why would MS override that!

Daniel_Pineault 

"Furthermore, why wouldn't all CmdLets not be available in both 32 and 64 bitness."

Dunno - above my pay grade.

Cheers,

Lain

Daniel_Pineault 

A fifth (and final) function to quickly check if the instance of Windows PowerShell being launched by Excel is 32-bit (False) or 64-bit (True).

Fifth function (for is64Bit)

Function GetIs64Bit()
    Set Process = CreateObject("WScript.Shell").Exec("powershell.exe -Command ""& { [System.Environment]::Is64BitProcess; }""")
    
    Do While Process.Status = 0
        Application.Wait (Now() + TimeValue("0:00:01"))
    Loop
    
    GetIs64Bit = Process.StdOut.ReadAll
End Function

Output

Cheers,

Lain

Daniel_Pineault 

Okay, so that's an interesting observation.

I never use the Windows PowerShell x86 console, but in checking it now, the StartLayout module is indeed not available, meaning it's only available as x64.

Are you running x32 Office rather than x64?

FWIW, I'm running x64.

Cheers,

Lain

Daniel_Pineault 

Here's a fourth function to try and some Microsoft documentation you can use to try diagnosing your $env:PSModulePath value.

It seems like under Excel that perhaps the Windows system location (third option from the output below) may be missing, though I cannot begin to fathom why - assuming you're running both the ISE and Excel under the same user account.

But I guess the proof (or contradiction) of that assumption will be in the output from the fourth function.

Fourth Excel function

Function GetPSPath()
    Set Process = CreateObject("WScript.Shell").Exec("powershell.exe -Command ""& { $env:PSModulePath.Split(\"";\"", [System.StringSplitOptions]::RemoveEmptyEntries); }""")
    
    Do While Process.Status = 0
        Application.Wait (Now() + TimeValue("0:00:01"))
    Loop
    
    GetPSPath = Process.StdOut.ReadAll
End Function

Output

Microsoft documentation on search locations

• about PSModulePath - PowerShell | Microsoft Learn

I'm assuming that if you run a "Get-Module -ListAvailable -Name StartLayout" from a Windows PowerShell session, not from the ISE, that it does indeed find the StartLayout module?

Cheers,

Lain