PowerShell issue prevents running WinSetView

LesFerch said:

Hold down the alt key when you click OK in the Submit dialog. That will keep the console open and hopefully there will be an error message.

Click to expand...

Tried already but it doesn't keep the console open in my case.

dacrone said:

You can run powershell as admin and run:

Code:

set-executionpolicy -executionpolicy unrestricted

Click to expand...

I had already tried a similar code and also set the Gpedit policy about turning on script execution (both in the User and the Computer views).
I even turned off Defender's script scanning. Then I#ve tried turning off Defender completely.
Nothing works.

Here the result of running your code:
set-executionpolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by
a policy defined at a more specific scope. Due to the override, your shell will retain its current effective
execution policy of RemoteSigned.

And when I've run Get-ExecutionPolicy -List after that:
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy RemoteSigned
Process Undefined
CurrentUser RemoteSigned
LocalMachine Unrestricted

You set a GPO or modified the registry for executionpolicy. Disable that then run the command again

dacrone said:

You set a GPO or modified the registry for executionpolicy. Disable that then run the command again

Click to expand...

Done. I've reset the permissions so that they all are "undefined", and I've run your code.It only affects LocalMachine.
There's no difference, WinSetView still does nothing, the console doesn't stay with alt+enter.

But I've noticed something.
After using Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force and Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force from the PowerShell (admin) in Win+X, and setting the two script execution entries in Gpedit again in Unrestricted (which correspond to MachinePolicy and UserPolicy), when I get the list of execution policy from the PowerShell (admin) in the Win+X menu, it gives me:
MachinePolicy Unrestricted
UserPolicy Unrestricted
Process Undefined
CurrentUser Unrestricted
LocalMachine Unrestricted

But if I open a PowerShell (admin) from the context menu in the folder where WinSetView.exe is (on the desktop), and I do the same, it gives me:
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Unrestricted
LocalMachine Unrestricted

It's like it's on a separate reality.
Anyway, by using Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force and Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force and even Set-ExecutionPolicy Unrestricted -Scope Process -Force in the PowerShell triggered within the WinSetView.exe folder, and having (verified) the three of them registered as Unrestricted, it still doesn't work. Console still doesn't stay open with Alt+Enter, and nothing happens in the system.

Maybe this last piece of info give your all an idea of what might be wrong here?
I even tried reinstalling PowerShell, but nothing changed.

The only thing I could still try if someone tells me how to forcibly stop the Defender Antivirus and Defender Core services before submitting.
Maybe that's blocking this.
But WHY should it?! I never told it to.
And yet, if not this, I've no idea what else it can be.

In spite of the fact that Windows 11 is 64-bit, WinSetView uses the 32-bit version of PowerShell 5.1, i.e.,
%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe thereby causing any changes you make in the execution policy settings of 64-bit PowerShell to not apply to WinSetView.

This is because each version [of PowerShell 5.1] has its own registry hive where these policies are stored. As a result, changes made to the execution policy in one version do not affect the other. On 64-bit Windows, the 64-bit version of PowerShell 5.1 is:
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe

WinSetView runs as a 32 bit app in order to be as compatible with as many machines as possible with a single executable. In the future, I plan to rewrite it in C# which will allow for a single exe that runs 32 bit or 64 bit automatically. Making it 32 bit was extra work and trouble for me (e.g. ensuring that the registry values it sets are not redirected to the 32 bit registry) but this is the first time I know of that it's caused an end-user complication.

On Windows when some issue appears to make absolutely no sense, it's often a bitness problem. Thanks to @hdmi for getting us on the right track here.

hdmi said:

In spite of the fact that Windows 11 is 64-bit, WinSetView uses the 32-bit version of PowerShell 5.1, i.e.,

Click to expand...

Even more confusing for the less tech-savvy that wow64 is about 32bit but system32 is about 64bit. Wtf, seriously, that's why Windows is a mess, because IT people lack common sense and usability sense.
It's not by chance that it was someone from Apple and not from Microsoft, who invented UX Design.

LesFerch said:

On Windows when some issue appears to make absolutely no sense, it's often a bitness problem. Thanks to @hdmi for getting us on the right track here.

Click to expand...

And does that tell you something about how to solve my issue?

I went to the extreme to start in safe mode and manually deactivate all Defender's functions from the registry. Now Microsoft Defender Antivirus Service, which was in automatic and with no possibility to change its startup status or even only temporarily stop it, is deactivated.
Only Defender Core Service is still in automatic and running. No idea where to find the registry settings to put that down too.
If it's not Defender, what else can be preventing my system from running PS scripts and how do I change it?
Or is it a matter of setting the 32 bit PS in "unrestricted" (which btw, isn't enough in "remotesigned"?)? And how do I do that?

Ok, I've maybe found the issue.
Powershell 5.1 32 bit doesn't even start. I went to C:\Windows\SysWOW64\WindowsPowerShell\v1.0 and double clicked powershell.exe, but there's just some quick flicker like if a window was open and closed within half a second. And ultimately it doesn't start.

AlterNate37 said:

Ok, I've maybe found the issue.
Powershell 5.1 32 bit doesn't even start. I went to C:\Windows\SysWOW64\WindowsPowerShell\v1.0 and double clicked powershell.exe, but there's just some quick flicker like if a window was open and closed within half a second. And ultimately it doesn't start.

Click to expand...

Now to determine why it doesn't run. I would think if it's a policy, there would be a message, but not 100% sure about that. It seems more like something corrupted, but I think you already tried dism and sfc, IIRC. If so, I would try a repair via Windows Update:

LesFerch said:

Now to determine why it doesn't run. I would think if it's a policy, there would be a message, but not 100% sure about that. It seems more like something corrupted, but I think you already tried dism and sfc, IIRC. If so, I would try a repair via Windows Update:

Click to expand...

I did try sfc, I didn't try DISM for fear that the restorehealth might put back things which I removed and reverts changes I've made.
If that's not the case, I'd be willing to try DISM.

I'm trying to figure out how to force-reinstall PS 5.1 but I don't find a way.
There's an official download page for WMF 5.1 but all options seem for older Windows (7, 8.1, Server etc).
If you know a way let me know :)

Thanx

What if you run cmd.exe, and then powershell.exe from inside that? That at least might give you an error message, instead of a flicker and close.

pseymour said:

What if you run cmd.exe, and then powershell.exe from inside that? That at least might give you an error message, instead of a flicker and close.

Click to expand...

Can you give me instructions how to do it?
And, would that serve just as a test or what purpose would it have? I mean, would fix PS 5.1 32 bit so that I can run this utility finally?

Run the 32-bit version of cmd ("C:\Windows\SysWOW64\cmd.exe"), then type powershell.exe. It should automatically try to run the 32-bit version of powershell.exe, and we might get an error message to help diagnose the issue, since you seem averse to DISM/SFC.

pseymour said:

Run the 32-bit version of cmd ("C:\Windows\SysWOW64\cmd.exe"), then type powershell.exe. It should automatically try to run the 32-bit version of powershell.exe, and we might get an error message to help diagnose the issue, since you seem averse to DISM/SFC.

Click to expand...

'powershell.exe' is not recognized as an internal or external command,
operable program or batch file.

Btw I've tried with the 64bit CMD and it has the same result.

I am not averse to neither DISM nor SFC in the slightest.
I used SFC, no errors found. No errors found with chkdsk /x /b /f either, btw.
I would not mind using DISM if it's a command that won't forcibly undo all the changes I've made to the system (like the preinstalled apps I removed, or some features I disabled).

AlterNate37 said:

'powershell.exe' is not recognized as an internal or external command,
operable program or batch file.

Btw I've tried with the 64bit CMD and it has the same result.

I am not averse to neither DISM nor SFC in the slightest.
I used SFC, no errors found. No errors found with chkdsk /x /b /f either, btw.
I would not mind using DISM if it's a command that won't forcibly undo all the changes I've made to the system (like the preinstalled apps I removed, or some features I disabled).

Click to expand...

Try running the explicit path. That is, copy and paste this (at the CMD prompt):

%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

You may also try:

%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe

or:

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

From a 32 bit CMD prompt, those last two commands should get redirected to the 32 bit version (which is in the, unfortunately named, SYSWOW64 folder). If the only problem is that the PowerShell folder is missing from the search path, these commands should work. However, I also expect them to fail on your machine because WinSetView explicitly runs PowerShell.exe from it's normal location. It does not depend on the search path.

Edit: Have you already checked to see if C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe even exists on your machine?

LesFerch said:

Try running the explicit path. That is, copy and paste this (at the CMD prompt):

Click to expand...

all three codes (plus also C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe) give back:
Reading the value of registry key SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine\PowerShellVersion causes the following Win32 error:
The system cannot find the file specified.
Running the same codes in the 64bit CMD gives the same result for the 32bit powershell, while it seems to succeed for the 64bit one:
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Install the latest PowerShell for new features and improvements! Migrating from Windows PowerShell 5.1 to PowerShell 7 - PowerShell

can try installing WMF 5.1 and see if its updates to powershell will fix your 5.1 installation files
.https://www.microsoft.com/en-us/download/details.aspx?id=54616

once installed, try launching powershell again. when it opens, run:

output should be:

dacrone said:

can try installing WMF 5.1 and see if its updates to powershell will fix your 5.1 installation files

Click to expand...

Well, like I said somewhere, that download page doesn't offer a version for Windows 11.
It only offers:
Win7AndW2K8R2-KB3191566-x64.zip
Win8.1-KB3191564-x86.msu
Win7-KB3191566-x86.zip
W2K12-KB3191565-x64.msu
Win8.1AndW2K12R2-KB3191564-x64.msu


Btw @LesFerch I feel like I'm hijacking your thread with an issue which does prevent me from using your tool but it's not directly related to your tool.
If you want me to open a separate thread let me know.

AlterNate37 said:

Btw @LesFerch I feel like I'm hijacking your thread with an issue which does prevent me from using your tool but it's not directly related to your tool.
If you want me to open a separate thread let me know.

Click to expand...

Yes, I think it would be good if we can have a mod move messages starting at #72 to a new thread. Maybe a title of "PowerShell issue prevents running WinSetView"? I'll ping @Brink and @z3r010

LesFerch said:

Yes, I think it would be good if we can have a mod move messages starting at #72 to a new thread. Maybe a title of "PowerShell issue prevents running WinSetView"? I'll ping @Brink and @z3r010

Click to expand...

Done.

Ok, good that I asked.

So, @LesFerch , while I solve whatever tf issue is preventing my windows powershell 32 bit from starting:
What can I do to have WinSetView.ps1 run with Windows powershell 64 bit or with powershell core?
I tried editing it in notepad and replacing powershell.exe with pwsh.exe in the line:
Start-Process -WindowStyle Hidden -FilePath "PowerShell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command $Cmd" -Verb RunAs 2>$Null

AlterNate37 said:

Ok, good that I asked.

So, @LesFerch , while I solve whatever tf issue is preventing my windows powershell 32 bit from starting:
What can I do to have WinSetView.ps1 run with Windows powershell 64 bit or with powershell core?
I tried editing it in notepad and replacing powershell.exe with pwsh.exe in the line:
Start-Process -WindowStyle Hidden -FilePath "PowerShell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command $Cmd" -Verb RunAs 2>$Null

Click to expand...

That line is for the processing of the few settings that require UAC. It won't change how the script itself is launched.

What you can do for now is manually run the script. Since you already have your preferences saved, you can run a command like the following from any prompt, such as the Run box:

powershell "C:\Tools\WinSetView\WinSetView.ps1" "C:\Tools\WinSetView\AppData\Win10.ini"
or
pwsh "C:\Tools\WinSetView\WinSetView.ps1" "C:\Tools\WinSetView\AppData\Win10.ini"

Obviously, replace the paths in those examples to the correct paths for your computer.