New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Jackbennett opened this Issue May 2, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@Jackbennett

Jackbennett commented May 2, 2018

Steps to reproduce

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

image

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

This comment has been minimized.

GeeLaw commented May 2, 2018

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

@Jackbennett

This comment has been minimized.

Jackbennett commented May 2, 2018

@iSazonov

This comment has been minimized.

Collaborator

iSazonov commented May 3, 2018

/cc @bergmeister Could you please comment?

@iSazonov iSazonov added the Area-Build label May 3, 2018

@bergmeister

This comment has been minimized.

Contributor

bergmeister commented May 3, 2018

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

This comment has been minimized.

Contributor

bergmeister commented Oct 1, 2018

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

@Jackbennett

This comment has been minimized.

Jackbennett commented Oct 2, 2018

I'm afraid to report the same issue

image

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:
image

@bergmeister

This comment has been minimized.

Contributor

bergmeister commented Oct 2, 2018

@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

This comment has been minimized.

Jackbennett commented Oct 2, 2018

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

@bergmeister

This comment has been minimized.

Contributor

bergmeister commented Oct 2, 2018

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

This comment has been minimized.

GeeLaw commented Oct 2, 2018

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

@bergmeister

This comment has been minimized.

Contributor

bergmeister commented Oct 2, 2018

@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

This comment has been minimized.

GeeLaw commented Oct 2, 2018

@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.

@bergmeister

This comment has been minimized.

Contributor

bergmeister commented Oct 3, 2018

@GeeLaw Thanks for the detailed answer, I opened a pull request with a fix for the open verb to use openpwsh but I don't think we should change runas to runaspwsh due to the required elevation (and having a flickering launcher instead is not preferred instead, I proposed this already when I originally did the feature) because as far as I can see, continuing to use the default verb for runas should not cause a problem or is probably an edge case to be disregarded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment