VSCode Extension v2022.8.5 initializes wrong user profile path

[Adwaenyth]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

On a system with folder redirection for $env:AppData Folder to a UNC Path, the PowerShell extension does not resolve that path correctly on startup.

PowerShell Version

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.6
PSEdition                      Core
GitCommitId                    7.2.6
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

code --version
1.72.0
64bbfbf67ada9953918d72e1df2f4d8e537d340e
x64

Extension Version

code --list-extensions --show-versions | select-string powershell

[email protected]

Steps to Reproduce

The Extension creates the initial session files in C:\<shareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-<ID>.json and the intial log Folders in C:\<shareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID> on the local harddrive.

After creating these files however, the extension tries to use at least the log files from the UNC share (which aren't present there) and creates a partial log for the respective session in \\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>.

The initial call from the VS Code Terminal Console invokes a scriptblock like this : Import-Module 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2022.8.5' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules' -EnableConsoleRepl -StartupBanner "<BannerText>" -LogLevel 'Normal' -LogPath '\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>\EditorServices.log' -SessionDetailsPath '\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-<ID>.json' -FeatureFlags @()

Instead of what I believe would be correct:

Import-Module 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2022.8.5' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules' -EnableConsoleRepl -StartupBanner "<BannerText>" -LogLevel 'Normal' -LogPath '\\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>\EditorServices.log' -SessionDetailsPath '\\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-<ID>.json' -FeatureFlags @()

Visuals

No response

Logs

No response

[andyleejordan]

Hm...this may be an upstream problem with VS Code. As far as I can tell we're using the URIs and APIs correctly. We start with passing vscode.ExtensionContext.globalStorageUri to the logger:

vscode-powershell/src/main.ts

Line 124 in 3f98265

logger = new Logger(context.globalStorageUri);

That's used to create the directory logging directory here:

vscode-powershell/src/logging.ts

Lines 137 to 147 in 3f98265

	public async startNewLog(minimumLogLevel: string = "Normal"): Promise<void> {
	this.MinimumLogLevel = this.logLevelNameToValue(minimumLogLevel.trim());
	this.logSessionPath =
	vscode.Uri.joinPath(
	this.logBasePath,
	`${Math.floor(Date.now() / 1000)}-${vscode.env.sessionId}`);
	this.logFilePath = this.getLogFilePath("vscode-powershell");
	await vscode.workspace.fs.createDirectory(this.logSessionPath);
	}

Which is both joining URIs (no conversion to file paths) and passing the URI to vscode.workspace.fs.createDirectory. Yet as you indicated, you see that directory get incorrectly created at C:\<shareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID> instead of \\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>.

We then pass that URI to the server (what you see in the list of arguments):

vscode-powershell/src/process.ts

Line 54 in 3f98265

`-LogPath '${PowerShellProcess.escapeSingleQuotes(editorServicesLogPath.fsPath)}' ` +

We explicitly use the fsPath property of the URI which says its correctly handles UNC paths. I don't think the issue is the \ vs \\, as we're directly using the fsPath value, but that the first createDirectory API call takes the URI and then puts C:\ on it, instead of handling the UNC share path.

@TylerLeonhardt any ideas?

[TylerLeonhardt]

I would like to know the value of this.logSessionPath before it gets passed to createDirectory. If it's \ then the bug is before it... since it will create it under C:. If it's \\ and it's still creating it under C: that's a bug in createDirectory.

[andyleejordan]

It's:

this.logSessionPath = 
         vscode.Uri.joinPath( 
             this.logBasePath, 
             `${Math.floor(Date.now() / 1000)}-${vscode.env.sessionId}`);

and this.logBasePath is vscode.Uri.joinPath(logBasePath, "logs"); and finally logBasePath is context.globalStorageUri for an equivalent of:

vscode.Uri.joinPath(context.globalStorageUri, "logs", "<RandomID>")

[TylerLeonhardt]

Sure but I'm just saying it could be the joinPath that's messing up... or maybe the globalStorageUri is just totally wrongly represented.

[Adwaenyth]

After digging a little bit into it, it seems that the initially created session files are also not being created in the correct directory.

The session files directory actually does not get created - however if I create the directory sessions manually in the directory on the local hard drive path, the session files get created there. If I create that folder on the UNC share, no session files get created.

The extension then however still cannot access the session .json file. The part of the log that is being created on the UNC share then states:

11.10.2022 07:15:59 [NORMAL] - PowerShell executable: C:\Program Files\PowerShell\7\pwsh.exe
11.10.2022 07:15:59 [NORMAL] - pwsh.exe started.
11.10.2022 07:20:02 [ERROR] - Error: Timed out waiting for session file to appear!

The on the log-path that is created on the local hard drive two empty log files get created EditorServices.log and StartEditorServices.log.

I'm attaching the files of the most recent startup attempt that do get created along with the output of the visual studio extension logs.

local_hard_drive_session_file.zip
unc_share_log_vscode-powershell.zip
vs_code_extension_log_output.txt

Are the globalStorage paths evaluted differently during the extension startup?

[andyleejordan]

Sure but I'm just saying it could be the joinPath that's messing up... or maybe the globalStorageUri is just totally wrongly represented.

Yeah but these are both VS Code APIs 😆 I'll step through an extension startup on Windows later today and see what I can get you, though I don't have a UNC share so I'll have to set that up...somehow. Actually @Adwaenyth how the heck do you have a UNC path for AppData?!

[Adwaenyth]

@andschwa The AppData folder can be redirected (and is in my case) via GPO (User Settings -> Windows Settings -> Folder Redirection -> AppData(Roaming)). That in turn activates folder sync and sets the registry key for the AppData folder HKCU\Software\Microsoft\Windows NT\CurrentVersion\Explorer\User Shell Folders to the UNC path.

Programs usually accept this fine. On occasion I've seen some installers struggle with that too, but main reason for that so far was having hardcoded directory paths like C:\Users\ etc.

[andyleejordan]

@Adwaenyth would you be able to debug in your environment and check the value of the variable @TylerLeonhardt asked about above?

[Adwaenyth]

@andschwa @TylerLeonhardt to continue working on my project, I had had the group policy removed that enforced folder redirection for the %AppData% folder. With that removed, it went back to normal and the local %UserProfile%\AppData\Roaming folder on my harddrive was again used for the globalStorageUri without any issues.

I don't know when I'll get around to set up a test machine to reproduce the issue. All I can do atm is tell you the value the RegistryKey HKCU\Software\Microsoft\Windows NT\CurrentVersion\Explorer\User Shell Folders had a Value for AppData was set to a UNC path like \\<Server>\<ShareName>\AppData\Roaming\.

It might be different, if there's an actual drive letter mapped to that share instead of a UNC path.

To setup folder redirection and offline files for user profile folders via Group Policy this article https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-folder-redirection is maybe a hint.

PS: Since there were write actions to both the correct share name and the incorrect local hard drive folder, I'd think that in one place combining the path variable caused the issue, because I doubt that the value for gobalStorageUri changed during runtime. However currently I can't give you the value that was stored in the gobalStorageUri when the error happened.

Currently I'd suggest to avoid using folder redirection for AppData folder.

[kiwi-ice]

Hello, I have the same problem. We use a virtual environment with redirect users folder to network folders (DFS). I tried install an older version of the PowerShell extension and version 2022.6.3 works correctly. All the newer versions has the same problem with interpretation of the URI path to log directory.

[ychen1214]

Hi, I am having the same problem.

[TylerLeonhardt]

This is a tough one to investigate without some concrete repro steps, unfortunately :(

[andyleejordan]

I'm working on getting these properties emitted by the logger!

[andyleejordan]

Ok @Adwaenyth, I added logs for the paths that are getting used here. Can you please update to v2022.11.0, enable diagnostic logging, and give us a fresh copy? Thanks!

[confidentcyber]

Seeing the same issue with PS 2022.11.0

11/20/2022 10:23:11 AM [NORMAL] - PowerShell Editor Services args: Import-Module 'c:\Program Files\Microsoft VS Code\resources\app\extensions\ms-vscode.powershell-2022.11.0\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2022.11.0' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Program Files\Microsoft VS Code\resources\app\extensions\ms-vscode.powershell-2022.11.0\modules' -EnableConsoleRepl -StartupBanner "PowerShell Extension v2022.11.0
Copyright (c) Microsoft Corporation.

https://aka.ms/vscode-powershell
Type 'help' to get help.
"-LogLevel 'Normal' -LogPath '\<share>\<username>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\1668964991-edde0935-e326-4916-84a1-3d23e932ffd31668964860840\EditorServices.log' -SessionDetailsPath '\<share>\<username>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-14812-101695.json' -FeatureFlags @()

Should be

'\\<server>\<share>\<username>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-14812-101695.json

We are also using redirected AppData(Roaming) folders via GPO.

[andyleejordan]

@confidentcyber can you please set logging to diagnostic and share your logs with us?

[confidentcyber]

Andy, Please see redacted logs attached. Very Respectfully, Aaron Wallace https://send.bitwarden.com/#g1UCzF_3BUGBOq9UAToSIQ/BJM1VqnD2U0fcHABC1lhbA

[andyleejordan]

@confidentcyber Hm, I don't see anything attached! If you want to sift through them, I'm specifically look for the log lines that are like this, but filled in:

• Global storage URI: '${globalStorageUri}', log file path: '${this.logFilePath}',
• Creating log directory at: '${this.logDirectoryPath}'

[confidentcyber]

I attached it via email. Maybe this will work better.

https://send.bitwarden.com/#g1UCzF_3BUGBOq9UAToSIQ/BJM1VqnD2U0fcHABC1lhbA

[andyleejordan]

@TylerLeonhardt for the log storage path vscode.Uri:

vscode-userdata://<hostname>/UserData%24/<username>/AppData/Roaming/Code/User/globalStorage/ms-vscode.powershell/logs/1669053282-0ed59719-eac6-436a-8b8e-896adb7e92911669053275667

Its .fsPath appears to be:

\UserData$\<username>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\1669053282-0ed59719-eac6-436a-8b8e-896adb7e92911669053275667\EditorServices.log

As if the protocol vscode-userdata:// is interfering with vscode.Uri.fspath's stated goal of handling UNC paths.

And that sure seems to be the case! In VS Code's implementation:

/**
 * Compute `fsPath` for the given uri
 */
export function uriToFsPath(uri: URI, keepDriveLetterCasing: boolean): string {

	let value: string;
	if (uri.authority && uri.path.length > 1 && uri.scheme === 'file') {
		// unc path: file://shares/c$/far/boo
		value = `//${uri.authority}${uri.path}`;
	} else if (
		uri.path.charCodeAt(0) === CharCode.Slash
		&& (uri.path.charCodeAt(1) >= CharCode.A && uri.path.charCodeAt(1) <= CharCode.Z || uri.path.charCodeAt(1) >= CharCode.a && uri.path.charCodeAt(1) <= CharCode.z)
		&& uri.path.charCodeAt(2) === CharCode.Colon
	) {
		if (!keepDriveLetterCasing) {
			// windows drive letter: file:///c:/far/boo
			value = uri.path[1].toLowerCase() + uri.path.substr(2);
		} else {
			value = uri.path.substr(1);
		}
	} else {
		// other path
		value = uri.path;
	}
	if (isWindows) {
		value = value.replace(/\//g, '\\');
	}
	return value;
}

It does not handle a UNC path unless the protocol is specifically file://, yet it's documentation says it "Will not look at the scheme of this URI." and that it "Will handle UNC paths."

[kiwi-ice]

Hello, last plugin version has the same error:
-LogLevel 'Normal' -LogPath '\users$\data\mjezek\AppData\Code\User\globalStorage\ms-vscode.powershell\logs\1669116922-c7bc9fc4-5b3e-411d-a0d7-1d3393e6217d1669116913524\EditorServices.log' -SessionDetailsPath '\users$\data\mjezek\AppData\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-14760-953055.json' -FeatureFlags @() '

It should be \ice.corp\users$\data\mjezek\AppData.........
The path in SessionDetailsPath is also bad.

I don't know ho to enable diagnostic logging. Could you help me?

[andyleejordan]

@kiwi-ice can you please try the PowerShell Preview for VS Code? I pushed what I hope is a viable workaround for it, but don't currently have a test environment for this particular issue setup.

[TylerLeonhardt]

@andschwa i think the issue here is that vscode-userdata is used for UNC file paths when it probably shouldn't (since UNC paths are just normal file: paths).

I've heard that @sandy081 @bpasero are likely the ones to talk to.

tl;dr: the vscode-userdata scheme is being used for the global storage URI when that uses a UNC path.

[kiwi-ice]

@andschwa the Powershell Preview works well. I tried one easy script and it works. But the terminal shows weird prompt:
e]633;P;IsWindows=e]633;Ae]633;P;Cwd=\ice.corp\users$\data\mjezek\Documents\CodePS Microsoft.PowerShell.Core\FileSystem::\ice.corp\users$\data\mjezek\Documents\Code> e]633;B

[andyleejordan]

Hey @kiwi-ice that's #4279. We found out the hard way that VS Code's shell integration script didn't work for Windows PowerShell. We have actually fixed that both upstream and for the next preview, but for now you can use PowerShell 7 or disable Code's shell integration by setting terminal.integrated.shellIntegration.enabled to false.

[kiwi-ice]

@andschwa I have found out that on my disk C: is directory c:\users$\data\mjezek\AppData\Code\logs\ vith VSCode logs. I thing that it isn't right place to store my logs. They should be stored on my network folder. I use PowerShell Preview v2023.1.0

[ghost]

Thank you for your comment, but please note that this issue has been closed for over a week. For better visibility, consider opening a new issue with a link to this instead.