I have looked for a statement on whether using the x86 version of PS on an x64 platform is supported, but could not find any.

A few questions..

• What operating system did you install it on?
• How did you install it, ZIP, MSI or some other way?
• If using the MSI did you add it to the global PATH?
• Do you also have x64 version installed?
• How did you start pwsh.exe, from old powershell, from start menu or from 32bit or 64bit cmd.exe?

I have just installed the PowerShell-7.3.0-win-x86.msi on Windows 10 Pro 22H2 and that installs in "C:\\Program Files (x86)\\PowerShell\7". That system also has the 64 bit version installed.

I did not check the box to add to the global PATH, or any other option.

I ran it from 64 bit cmd.exe after cd into "C:\\Program Files (x86)\\PowerShell\7" , and it started cleanly and now sits waiting at the prompt.

Sometimes I'm too impatient when writing bug reports.

• Windows 11 22H2 x64, current updates
• PowerShell-7.3.0-win-x86.zip
• N/A
• No
• It crashes from 64-bit and 32-bit cmd, from 64-bit and 32-bit WPS 5.1.22621.608, and when run from Explorer, both by double-click and Run.

Reproduction:

1. Have no version of PowerShell 7 installed (may not be necessary).
2. Extract PowerShell-7.3.0-win-x86.zip .
3. Open a command prompt window (i.e. tab in Terminal in 11 22H2 with October updates).
4. cd to the directory just extracted.
5. Run pwsh.exe.

The crash happens both with my regular cluttered PATH and with PATH=C:\windows\system32;C:\windows, and when starting it from another directory with an absolute path on the command line. It also happens with the MSI installed the same way you describe (same path, same no options), both from command prompt and start menu. Installing the MSI had no effect on the behavior of the copy I unzipped earlier. It also happens when run from an elevated "real" command prompt window.

I noticed that the delay, both before the first line of output and between the last line of the stack trace and the return of the prompt, is much shorter with the MSI (<< 1 s start, 1.5 s finish) than with the Zip (~2.5 s start, ~6 s finish).

Hope that's better :-)

Does the 64-bit version from a zip work on your system? Given the CPU requirements for Windows 11, are there any x86 only Windows 11 installations?

• 64-bit from Zip works.
• No idea, but since I'm not aware of any x86 Windows 11 release, I rather doubt it.

I just tried the 7.3.0 x86 zip on my Windows 11 Pro 22H2 and that throws exactly the same exception as you describe.

The function it crashes in only exists in 11 22H2. That at least explains why it works on 10. Procmon shows no obvious smoking gun, not that I expected one.

If I had to guess, I would guess that https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/security/wldpNativeMethods.cs#L699 should be "ref Guid". But what do I know?

GitHub

PowerShell/wldpNativeMethods.cs at master · PowerShell/PowerShell

PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

https://learn.microsoft.com/en-us/previous-versions/troubleshoot/visualstudio/foxpro/c0000005-error-troubleshoot

https://learn.microsoft.com/en-us/windows/win32/api/wldp/nf-wldp-wldpcanexecutefile

Does the export WldpCanExecuteFile exist in the x86 wldp.dll?

C0000005 error and troubleshoot - Visual Studio

This article defines a C0000005 error and offers troubleshooting suggestions.

WldpCanExecuteFile - Win32 apps

Queries whether the execution policy allows execution of the code in the supplied file.

C:\Windows\SysWOW64>dumpbin /exports wldp.dll | findstr WldpCanExecuteFile
         17    2 000237A0 WldpCanExecuteFile

The code at the call site (line 120 of the same file I linked above; I hope it's the right one) catches EntryPointNotFoundException and continues with "legacy system checks".

Adding [MarshalAs(UnmanagedType.LPStruct)] to the Guid argument (ref does not work here) fixes the crash when building the v7.3.0 tag. I'm getting unrelated compiler errors from the master branch. Whether this is the correct fix is beyond me.

I can create a PR for adding the attribute, but I cannot be held responsible for it ...

So how does the 64 bit code work if it goes through the same code path?

Calling conventions.

Per wldp.h the first argument is a REFGUID, also known as a GUID*. The Windows x64 calling convention says that values larger than 64 bits (that is, larger than a register) are passed by address (i.e. as pointers). This means that in C# terms, Guid and ref Guid look the same to the called native function (but I think in the non-ref case the Guid is probably copied somewhere in case the native function changes it).

The x86 calling conventions, in this case __stdcall, are more complicated. Here, structures (such as Guid) are passed on the stack, that is, the compiler copies the structure to the stack instead of just pushing a pointer to it. This also means that the function will mistake the last four bytes of the GUID as a pointer to one, dereference it, and ... boom. I tried it from C, and this is exactly what happens.

My fix tells .NET to pass the Guid as a pointer to a structure, and the fact that this changes the behavior at all is the best proof that it is correct: If it works when passing a pointer, then it must not have been passing one before, and that is definitely wrong because we know the function expects a REFGUID.

Also note that a few lines down in the file, the declaration of SHGetKnownFolderPath() already uses the attribute, and that function's first argument is a REFKNOWNFOLDERID, another alternative spelling of GUID*.

Now that I have convinced myself of that (and you, I hope), my next problem is how to create a PR for the fix if I cannot get master to build for testing.

For illustration, this is a call to WldpCanExecuteFile(REFGUID, int, int, int, int) (the exact types don't matter):

push	0
push	0
push	0
push	0
push	OFFSET ?guid@?1??main@@9@9
call	_WldpCanExecuteFile

This is WldpCanExecuteFile(GUID, 0, 0, 0, 0):

push	0
push	0
push	0
push	0
sub	esp, 16
mov	eax, esp
mov	ecx, DWORD PTR ?guid@?1??main@@9@9
mov	DWORD PTR [eax], ecx
mov	edx, DWORD PTR ?guid@?1??main@@9@9+4
mov	DWORD PTR [eax+4], edx
mov	ecx, DWORD PTR ?guid@?1??main@@9@9+8
mov	DWORD PTR [eax+8], ecx
mov	edx, DWORD PTR ?guid@?1??main@@9@9+12
mov	DWORD PTR [eax+12], edx
call	_WldpCanExecuteFile

I just found that master works on another system (no idea why). There, Start-PSBuild -Runtime win7-x86 -Configuration Debug itself fails with the same error when it calls its own just-built pwsh.exe somewhere along the way. This probably just means that the "official" release was created on something other than 11 22H2.

@chrullrich, my condolences. 7.3.0 crashes upon launch on your end, whereas its x64 zip bundle hangs my Windows 7 x64 system completely, until it is rebooted via hard reset (literally holding that reset button for a few seconds). I was advised to try -NoProfile switch, no luck there. No such thing happens with 7.2.5, so I rolled back.

@chrullrich, No such thing happens with 7.2.5, so I rolled back.

Does 7.2.7 work?

Yes, 7.2.7 works. It does not contain this particular bug anyway, that was introduced between v7.3.0-preview.3 and .4 according to git.

@rhubarb-geek-nz, not sure if you asked me or Christian, so let me reply as well.
Yes, 7.2.7 launches fine. Upgraded from 7.2.5 successfully. Thanks for mentioning it.

Edit.
However I am not happy as it advises me to upgrade to 7.3.0 on every launch.
Too intrusive, not to mention that very build is not that stable after all.

C:\APPS\System\PowerShell727>pwsh
PowerShell 7.2.7
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

   A new PowerShell stable release is available: v7.3.0
   Upgrade now, or check out the release page at:
     https://aka.ms/PowerShell-Release?tag=v7.3.0

PS C:\APPS\System\PowerShell727>

@sergeevabc It can be turned off by setting an environment variable: POWERSHELL_UPDATECHECK=Off

Source: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_update_notifications?view=powershell-7.2

about Update Notifications - PowerShell

Notifies users on startup of PowerShell that a new version of PowerShell has been released.

This probably just means that the "official" release was created on something other than 11 22H2.

It is Windows 10.