ERR_INVALID_ARG_TYPE when testing extension on 1.47.1

[xisui-MSFT]

• VSCode Version: 1.47.1
• OS Version: Win10 1909

Steps to Reproduce:
After updating to 1.47.1, we started to see ERR_INVALID_ARG_TYPE when running automated tests for our extension in (Azure DevOps) pipeline. The agent runs as a service. I could NOT repro this error repro manually in any way. 1.47.0 doesn't have this problem. Error message:
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
at h._doHandleExtensionTests (c:\Agent_work\1\s\Extension.vscode-test\vscode-1.47.1\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:841:405)
at processTicksAndRejections (internal/process/task_queues.js:85:5)

[roblourens]

Looking at the code I think this is most likely an error that your extension threw while starting up. eg you would get this when calling node path APIs with undefined. Can you check whether that is possible in your code?

cc @jrieken if you have any ideas

[xisui-MSFT]

@roblourens That doesn't explain why 1.47.0 doesn't have this issue, and why starting the test manually via cmd or launch.json also doesn't have this problem. Is there anything I can try or any diagnostic messages I can provide?

[pkrukp]

I have the same problem. I'm running tests from jenkins that runs on some local account, on Windows 10.

When I log into my normal user account and try to reproduce it (run tests from command line), there is no error.
The error happens with 1.47.2, does not happen with 1.46.1 (didn't check versions between).

I have logged with remote desktop into the local account that jenkins is running on, tried to reproduce it from command line - didn't reproduce (no error). Restarted jenkins service, tried running it again from jenkins - the error disappeared. I disconneted but I think the session stil lives?
After that I restarted the machine and after restart the error reappeared.

I noticed that someone had similar problem (same error, different stacktrace, related to user windows user/session) - #102751

[xisui-MSFT]

Also repros with 1.47.2.

[roblourens]

cc @deepak1556 it kind of sounds like we are calling require with undefined, but do you know whether an electron update could be involved here?

[roblourens]

Do the tests run in admin mode in CI?

[xisui-MSFT]

Do the tests run in admin mode in CI?

I assume so for our CI, since we are also installing some software in the CI.

[bwateratmsft]

@roblourens We have another user hitting this with the Docker extension when running VSCode as admin: microsoft/vscode-docker#2175

[TylerLeonhardt]

Just wanted to add that the PowerShell extension is also hitting this with a similar error in 1.47.1:

From devtools:

abstractExtensionService.ts:411 Activating extension 'ms-vscode.powershell' failed: The "path" argument must be of type string. Received type undefined.

We're tracking it here: PowerShell/vscode-powershell#2808

[deepak1556]

Sorry about the issue, this seems to be related to the recent CVE fix https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-1416 where the node path resolution introduced a dependency on process.env.HOMEDRIVE and process.env.HOMEPATH to additionally check for preventing module loads from the Users directory.

Can the devs affected by this issue confirm if those env variables are undefined on your setup ?

[xisui-MSFT]

They are undefined in our CI builds, but are defined when remoting to the test machine and running node there manually. So this behavior seems to be consistent with our issue.

[deepak1556]

Thanks for the confirmation, just pushed a fix. But the earliest fix available for testing is tomorrow and recovery stable build will be out next week. As a temporary workaround until then you could define those env variables for ci.

Any ideas on why these might be undefined in some environments ?

[corbob]

Any ideas on why these might be undefined in some environments ?

I can't speak for OP, but in the PowerShell extension case, where this is happening is where the user is running vscode as another user elevated with administrator privileges. I can confirm that when I launch a process as this other user, the variables are there, but when I elevate the variables are no longer present.

With regards to what I understand of OPs description, when being run as a service, there likely won't be a homedrive or homepath variable as they're not fully loaded profiles so leave out some variables and such. This would explain why they couldn't reproduce with logging in remotely.

[deepak1556]

Would like some volunteering to validate the fix, please use any of the following builds

Win_x64 System setup
Win_x64 user setup
Win_x64 archive

[vkoprivica]

This looks promising. I am starting vscode from separate admin account and I experienced the issue where I could not set Python interpreter, postgresql extension could not be started, and I could not install Remote - WSL extension. All works now! How soon until you push update to official realize?

[utw4376]

Would like some volunteering to validate the fix, please use any of the following builds

Looks good to me. Starting from elevated PowerShell window and directly via "Run as administrator" work with the insider version. The PowerShell session within vscode gets started.

[xisui-MSFT]

Did some tests and looks like this fix works for our scenario. Thanks!

[deepak1556]

Thanks all for testing, this will be released into recovery 1.47.3 later this week after a couple of days with insiders testing.

[chrisduda]

Thanks for your help.

[jlapchuk]

Yup, I also confirm the latest insiders build works and properly launches the integrated PowerShell console.

[deepak1556]

Closing this issue in preparation for recovery release