Windows "previous versions" now opens pwsh.exe not explorer

[Jackbennett]

Steps to reproduce

1. Install the preview MSI
2. Click Open at a shadow copy prior date;

Expected behavior

Windows explorer at this file path.

Actual behavior

pwsh.exe at path PS V:\@GMT-2018.04.23-10.11.03\ (of the time opened)

Work Around

I can just type start . to get explorer

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.1.0-preview.2
PSEdition                      Core
GitCommitId                    v6.1.0-preview.2
OS                             Microsoft Windows 10.0.16299
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[GeeLaw]

Did you mean installing the preview PowerShell somehow makes File Explorer think pwsh.exe is the shell program (which is usually explorer.exe)?

[Jackbennett]

Yeh but it's not like win-e does anything different. I'm not sure what handler would have changed.

…

On Wed, 2 May 2018, 3:28 pm Gee Law, ***@***.***> wrote: Did you mean installing the preview PowerShell somehow makes File Explorer think pwsh.exe is the shell program (which is usually explorer.exe)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwSXlyPY6YFUdlrDP1JsiWkHasup5VYks5tucJ0gaJpZM4TvMxV> .

[iSazonov]

/cc @bergmeister Could you please comment?

[bergmeister]

On Windows 10 1803, when I click open on one of the previous versions of a library folder, then nothing happens at all, no matter if I have installed preview2, the latest preview or uninstall pwsh completely (but it works when opening e.g. a text file inside one of those folders)...
This should not be related to the optional context menu that was added in 6.1 but it would be good to know whether the behaviour is different on your machine if you have have the explorer context menu option in the PowerShell installer enabled or not. I rather suspect some other program has changed your system. Does this behaviour stop happening if you uninstall the preview and install 6.0.2 instead @Jackbennett ?
Otherwise, just for the record: After 6.0.2, MSFT did some compliance refactoring of the installer but I was not involved in that.

[bergmeister]

@Jackbennett Does this still happen with 6.1.0 in your environment?

[Jackbennett]

I'm afraid to report the same issue

Sorry it's been a while but on the up side this is completely re-imaged with MDT 1709 windows 10 x64 which was a fresh build from a microsoft ISO install from the initial report.

Steps to reproduce

1. Find a folder with previous versions
2. Select "open" on an older folder version
3. You will see explorer open at that point in time.
4. Install PowerShell-6.1.0-win-x64.msi
5. Click open again, You now get pwsh.exe at the previous version file path

> $PsversionTable
Name                           Value
----                           -----
PSVersion                      6.1.0
PSEdition                      Core
GitCommitId                    6.1.0
OS                             Microsoft Windows 10.0.16299
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Winver:

[bergmeister]

@Jackbennett Thanks for the detailed report. I suspect this might be related to #7815 that I started to investigate yesterday. I hope to have an answer in the next days. For the moment the recommendation is to re-install PowerShell without the context menu option if this is a blocking problem.

[Jackbennett]

For completeness removed/installed without the context option ticked does indeed fix the issue. Interesting coincidence.

[bergmeister]

Thanks for confirming this (as it proves the problem is caused by this feature). I will investigate but there is a chance that this might even be a bug in Windows

[GeeLaw]

Perhaps it is because PowerShell context menu assumed the default verb for folders?

[bergmeister]

@GeeLaw Where did you see that we assume the default verb for folders?
I checked all the registry keys and could boil it down to the HKCR\Directory\shell\PowerShell6x64 entry and HKCR\Directory\ContextMenus\PowerShell6x64\shell\open, which is necessary for non-admin sub menu context menu.

[GeeLaw]

@bergmeister Sorry, it isn't because PS6 assumes the default verb, it is because it takes the open verb -- the cascaded menu verb is named as open. If SEE_MASK_INVOKEIDLIST is used, this verb will be found by ShellExecuteEx, which is the case for "Open" in "Previous Versions".

If you rename HKCR\Directory\ContextMenus\PowerShell6x64\shell\open to openpwsh, the problem will go away.

Ordinarily, the open verb is found in HKLM\SOFTWARE\Classes\Folder\shell\open. PowerShell's context menu overrides this because it is found later than the should-be open.

I'm writing a blog entry for a detailed analysis on this issue. Will be modifying this comment to reflect the entry later. Updated: here it is.

It is also worth mentioning that currently the installer does not install on a per-user basis. The cascaded context menu will always be created for all users. As a piece of advice, the installer should be more specific on whether to install the keys to HKCU\Software\Classes or HKLM\SOFTWARE\Classes. Even if the installer is running as administrator, the value still might be written to HKCU\Software\Classes, if the key already exists in HKCU.