Starting debug crashes PowerShell session if project is in onedrive folder

[jhoneill]

System Details Output

### VSCode version: 1.34.0 a622c65b2c713c890fcf4fbf07cf34049d5fe758 x64

### VSCode extensions:
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]


### PSES version: 1.12.1.0

### PowerShell version:

Name                           Value
----                           -----
PSVersion                      5.1.17763.503
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.503
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3

OS is windows 10 1809 build

Issue Description

My WindowsPowerShell directory is on onedrive.
C:\Users\james\onedrive\WindowsPowerShell has a symbolic link to
C:\users\james\documents\WindowsPowerShell so profile etc is found.

Although I can use the directory under documents, VS-Code the likes to convert it to the canonical name so when I work on a project in my WindowsPowerShell directory it's the one under onedrive.

If I have the debugger set for PowerShell interactive session, pressing F5 to start it crashes the interactive session with the message "The PowerShell session has terminated due to an error" ... the stack trace in the log suggests a problem with the path.

If I copy the files from
C:\Users\james\onedrive\WindowsPowerShell\modules\foo to
C:\Users\james\temp\foo

Then all is well (so I have a work round).

Attached Logs

Editor services log attached. This has a stack trace from when the error occurs.

EditorServices.log

[rjmholt]

Thanks for opening an issue @jhoneill.

This error looks pretty similar (but slightly different to) #1830.

The relevant entry in the log is:

2019-05-30 16:41:40.494 [ERROR] tid:20 in 'OnListenTaskCompleted' C:\PowerShellEditorServices\src\PowerShellEditorServices.Protocol\MessageProtocol\ProtocolEndpoint.cs: line 391
    ProtocolEndpoint message loop terminated due to unhandled exception:
    
    System.AggregateException: One or more errors occurred. ---> System.ArgumentException: Illegal characters in path.
       at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
       at Microsoft.PowerShell.EditorServices.Workspace.GetFile(String filePath)
       at Microsoft.PowerShell.EditorServices.Workspace.TryGetFile(String filePath, ScriptFile& scriptFile)
       at Microsoft.PowerShell.EditorServices.Protocol.Server.DebugAdapter.<HandleSetBreakpointsRequest>d__30.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher.<DispatchMessage>d__7.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.ProtocolEndpoint.<ListenForMessages>d__36.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Utility.AsyncContext.Start(Func`1 asyncMainFunc, ILogger logger)
       at System.Threading.Tasks.Task.Execute()
       --- End of inner exception stack trace ---
    ---> (Inner Exception #0) System.ArgumentException: Illegal characters in path.
       at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
       at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
       at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
       at Microsoft.PowerShell.EditorServices.Workspace.GetFile(String filePath)
       at Microsoft.PowerShell.EditorServices.Workspace.TryGetFile(String filePath, ScriptFile& scriptFile)
       at Microsoft.PowerShell.EditorServices.Protocol.Server.DebugAdapter.<HandleSetBreakpointsRequest>d__30.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher.<DispatchMessage>d__7.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.ProtocolEndpoint.<ListenForMessages>d__36.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Utility.AsyncContext.Start(Func`1 asyncMainFunc, ILogger logger)
       at System.Threading.Tasks.Task.Execute()<---
    

2019-05-30 16:41:40.494 [ERROR] tid:20 in 'ProtocolEndpoint_UnhandledException' C:\PowerShellEditorServices\src\PowerShellEditorServices.Host\EditorServicesHost.cs: line 448
    PowerShell Editor Services is terminating due to an unhandled exception, see previous logs for details.

The illegal characters in path message is curious. It might mean we're not handling the URI conversion properly. We might be able to determine more if we know what path VSCode is sending to the backend, which will be logged with Diagnostic logging.

So two things are:

• Enable diagnostic logging and when the error occurs again, upload the new diagnostic logs.
• Upgrade your version of the PowerShell extension to 1.12.2 2019.5.0

[jhoneill]

@rjmholt thanks . here's a version of the log with diagnostic level turned on
EditorServices.log

When I go to install a different version I've got the option for 2019.5.0 (released yesterday) or 1.12.1 (a month old) it looks like a new naming convention has been applied ...

[rjmholt]

2019.5.0

Oh yep that's totally right! I'm still converting over myself :)

[rjmholt]

Here's the relevant line:

2019-05-30 17:07:14.812 [VERBOSE] tid:5 in 'ReadMessage' C:\PowerShellEditorServices\src\PowerShellEditorServices.Protocol\MessageProtocol\MessageReader.cs: line 138
    Received Request 'setBreakpoints' with id 3
    
    {
      "command": "setBreakpoints",
      "arguments": {
        "source": {
          "name": "OneNote.ps1",
          "path": "git:/c%3A/Users/mcp/OneDrive/WindowsPowerShell/Modules/MsftGraph/OneNote.ps1?%7B%22path%22%3A%22c%3A%5C%5CUsers%5C%5Cmcp%5C%5COneDrive%5C%5CWindowsPowerShell%5C%5CModules%5C%5CMsftGraph%5C%5COneNote.ps1%22%2C%22ref%22%3A%22~%22%7D"
        },
        "lines": [
          338
        ],
        "breakpoints": [
          {
            "line": 338
          }
        ],
        "sourceModified": false
      },
      "type": "request",
      "seq": 3
    }

2019-05-30 17:07:14.821 [VERBOSE] tid:5 in 'ResolveFilePath' C:\PowerShellEditorServices\src\PowerShellEditorServices\Workspace\Workspace.cs: line 484
    Resolved path: git:/c%3A/Users/mcp/OneDrive/WindowsPowerShell/Modules/MsftGraph/OneNote.ps1?%7B%22path%22%3A%22c%3A%5C%5CUsers%5C%5Cmcp%5C%5COneDrive%5C%5CWindowsPowerShell%5C%5CModules%5C%5CMsftGraph%5C%5COneNote.ps1%22%2C%22ref%22%3A%22~%22%7D

I'm not sure I've ever seen a git: URI scheme before in VSCode, but it looks like it's throwing out all our URI parsing (we have to special-case file schemes because .NET handles encodes/decodes URIs differently to VSCode).

Unescaping this renders it as git:/c:/Users/mcp/OneDrive/WindowsPowerShell/Modules/MsftGraph/OneNote.ps1?{"path":"c:\\Users\\mcp\\OneDrive\\WindowsPowerShell\\Modules\\MsftGraph\\OneNote.ps1","ref":"~"}, which doesn't look so much like a path as a query that VSCode expects us to handle somehow (this is the first I've seen of it though).

I'll see if I can find more info, since it looks like we're forced to handle it (if only to quietly ignore it).

[rjmholt]

Following VSCode's processes and being unable to find any documentation or issues that describe what this is, I've asked about this on StackOverflow. If that's not responded to by next week, I'll open an issue on VSCode.

I'm not sure what VSCode expects us to be able to do with a message like this. Best case scenario we use the path from the JSON, but I need to know more about this URI format before we can implement a fix.

[rjmholt]

Ok, I've followed up with VSCode. This URI is coming from a git TextDocumentProvider, which we don't support. Instead of crashing, we should send back an error message.

[rjmholt]

The code we need to change for this is here: https://github.com/PowerShell/PowerShellEditorServices/blob/84a3d3f2ccb4af4e73ed5270712862d1242a6bad/src/PowerShellEditorServices/Workspace/Workspace.cs#L417-L476

Documenting so I can get back to it.

[rjmholt]

@rkeithhill, @TylerLeonhardt need to consult you on what those methods accept as an argument; I'm thinking it basically needs to be TryGetFile returns false for URI schemes we don't recognise

[rkeithhill]

Sigh... It seems like we need to do some redesign of how we manage client document representation in PSES. We have these test methods scattered about. It seems like a workspace should have a collection/dictionary of these documents - which I think today is a ScriptFile collection. That seems a bit too PS centric to me. Maybe it would be better to have a collection of EditorDocuments or TextDocument or something more inline with the LSP terms. Then move the workspace tests internal to that class and provide props like IsFile or IsFileScheme, UriScheme, that we could then use to determine if we can say, set breakpoints. If it's not a FileScheme document then sorry dude, you don't get breakpoints. Or maybe have a higher level of abstraction like IsDebuggable? Just thinking out loud here.

Sorry, don't have time at the moment to look at the source so some of this may already be there but fundamentally, IIRC once we put something into a ScriptFile object, I think we may be assuming too much in the rest of the code base that there's actually a file on disk. When as we've seen many times with VSCode, that is not the case.

[rjmholt]

Totally on your page there @rkeithhill.

I think this is worth patching in a small way for now and then we should come up with a better implementation going forward.

I'll try and open a PR this week

[scrambled2k3]

Any movement on a fix for this? Or at least how to work around it? I too am experiencing this issue all of the sudden and I have no idea why. I haven't added any new extensions. All of the sudden I can no longer execute PowerShell scripts in VSCode (it causes PowerShell terminal to crash). I am seeing the same issue with the "git:/" path in my error log.

[SydneyhSmith]

@scrambled2k3 we are hoping to get to this work item sooner rather than later but currently have no eta, thanks for your patience! In the meantime are you having trouble with all of your scripts or just those under this particular file structure?

[scrambled2k3]

@SydneyhSmith Ok, no problem. I'm having the issue with all of my powershell scripts, no matter their location. I can execute them fine withing PowerShell ISE.