starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

wsl.exe attempts to load despite Windows Subsystem for Linux being disabled #15824

New Issue
Closed
opened 2026-01-31 04:49:27 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 04:49:27 +00:00
Owner
Copy Link

Originally created by @mattifestation on GitHub (Nov 9, 2021).

Windows Terminal version (or Windows build number)

1.11.2921.0

Other Software

wsl.exe (10.0.22000.1)

Steps to reproduce

Loading Windows Terminal will launch wsl.exe despite Windows Subsystem for Linux (WSL) being disabled.

This is problematic as I explicitly deny execution of wsl.exe per Microsoft recommended block rules in my Windows Defender Application Control (WDAC) policy. As a result, every time I launch Windows Terminal, a Microsoft-Windows-CodeIntegrity/Operational event ID 3077 event is generated. Example event message:

Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe) attempted to load \Device\HarddiskVolume3\Windows\System32\wsl.exe that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{5dc289d3-65e7-47a7-806f-4d092b07a36a}).

Steps to confirm that WSL is disabled:

PS> Get-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online

FeatureName      : Microsoft-Windows-Subsystem-Linux
DisplayName      : Windows Subsystem for Linux
Description      : Provides services and environments for running native user-mode Linux shells and tools on Windows.
RestartRequired  : Possible
State            : Disabled
CustomProperties :
    ServerComponent\Description : Provides services and environments for running native user-mode Linux shells and tools on Windows.
    ServerComponent\DisplayName : Windows Subsystem for Linux
    ServerComponent\Id : 1033
    ServerComponent\Type : Feature
    ServerComponent\UniqueName : Microsoft-Windows-Subsystem-Linux
    ServerComponent\Deploys\Update\Name : Microsoft-Windows-Subsystem-Linux

There is also nothing in my settings.json configuration that would explicitly launch any component of WSL. Here is my settings.json for reference:

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "actions": 
    [
        {
            "command": 
            {
                "action": "copy",
                "singleLine": false
            },
            "keys": "ctrl+c"
        },
        {
            "command": "find",
            "keys": "ctrl+shift+f"
        },
        {
            "command": "paste",
            "keys": "ctrl+v"
        },
        {
            "command": 
            {
                "action": "splitPane",
                "split": "auto",
                "splitMode": "duplicate"
            },
            "keys": "alt+shift+d"
        }
    ],
    "centerOnLaunch": true,
    "copyFormatting": "none",
    "copyOnSelect": false,
    "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "experimental.detectURLs": false,
    "initialCols": 150,
    "initialRows": 42,
    "profiles": 
    {
        "defaults": {},
        "list": 
        [
            {
                "antialiasingMode": "cleartype",
                "colorScheme": "Campbell",
                "commandline": "powershell.exe -NoLogo",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell",
                "startingDirectory": "%USERPROFILE%\\Desktop",
                "useAcrylic": false
            },
            {
                "commandline": "cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "hidden": false,
                "name": "Command Prompt",
                "startingDirectory": "%USERPROFILE%\\Desktop"
            },
            {
                "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
                "hidden": true,
                "name": "Azure Cloud Shell",
                "source": "Windows.Terminal.Azure"
            }
        ]
    },
    "schemes": 
    [
        {
            "background": "#0C0C0C",
            "black": "#0C0C0C",
            "blue": "#0037DA",
            "brightBlack": "#767676",
            "brightBlue": "#3B78FF",
            "brightCyan": "#61D6D6",
            "brightGreen": "#16C60C",
            "brightPurple": "#B4009E",
            "brightRed": "#E74856",
            "brightWhite": "#F2F2F2",
            "brightYellow": "#F9F1A5",
            "cursorColor": "#FFFFFF",
            "cyan": "#3A96DD",
            "foreground": "#CCCCCC",
            "green": "#13A10E",
            "name": "Campbell",
            "purple": "#881798",
            "red": "#C50F1F",
            "selectionBackground": "#FFFFFF",
            "white": "#CCCCCC",
            "yellow": "#C19C00"
        }
    ]
}

Expected Behavior

When Windows Subsystem for Linux is disabled, Windows Terminal will not execute wsl.exe.

Actual Behavior

When Windows Subsystem for Linux is disabled, Windows Terminal executes wsl.exe.

Originally created by @mattifestation on GitHub (Nov 9, 2021). ### Windows Terminal version (or Windows build number) 1.11.2921.0 ### Other Software wsl.exe (10.0.22000.1) ### Steps to reproduce Loading Windows Terminal will launch `wsl.exe` despite Windows Subsystem for Linux (WSL) being disabled. This is problematic as I explicitly deny execution of `wsl.exe` per [Microsoft recommended block rules](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) in my Windows Defender Application Control (WDAC) policy. As a result, every time I launch Windows Terminal, a `Microsoft-Windows-CodeIntegrity/Operational` event ID 3077 event is generated. Example event message: ``` Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe) attempted to load \Device\HarddiskVolume3\Windows\System32\wsl.exe that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{5dc289d3-65e7-47a7-806f-4d092b07a36a}). ``` Steps to confirm that WSL is disabled: ``` PS> Get-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online FeatureName : Microsoft-Windows-Subsystem-Linux DisplayName : Windows Subsystem for Linux Description : Provides services and environments for running native user-mode Linux shells and tools on Windows. RestartRequired : Possible State : Disabled CustomProperties : ServerComponent\Description : Provides services and environments for running native user-mode Linux shells and tools on Windows. ServerComponent\DisplayName : Windows Subsystem for Linux ServerComponent\Id : 1033 ServerComponent\Type : Feature ServerComponent\UniqueName : Microsoft-Windows-Subsystem-Linux ServerComponent\Deploys\Update\Name : Microsoft-Windows-Subsystem-Linux ``` There is also nothing in my `settings.json` configuration that would explicitly launch any component of WSL. Here is my `settings.json` for reference: ```json { "$schema": "https://aka.ms/terminal-profiles-schema", "actions": [ { "command": { "action": "copy", "singleLine": false }, "keys": "ctrl+c" }, { "command": "find", "keys": "ctrl+shift+f" }, { "command": "paste", "keys": "ctrl+v" }, { "command": { "action": "splitPane", "split": "auto", "splitMode": "duplicate" }, "keys": "alt+shift+d" } ], "centerOnLaunch": true, "copyFormatting": "none", "copyOnSelect": false, "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "experimental.detectURLs": false, "initialCols": 150, "initialRows": 42, "profiles": { "defaults": {}, "list": [ { "antialiasingMode": "cleartype", "colorScheme": "Campbell", "commandline": "powershell.exe -NoLogo", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "name": "Windows PowerShell", "startingDirectory": "%USERPROFILE%\\Desktop", "useAcrylic": false }, { "commandline": "cmd.exe", "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}", "hidden": false, "name": "Command Prompt", "startingDirectory": "%USERPROFILE%\\Desktop" }, { "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}", "hidden": true, "name": "Azure Cloud Shell", "source": "Windows.Terminal.Azure" } ] }, "schemes": [ { "background": "#0C0C0C", "black": "#0C0C0C", "blue": "#0037DA", "brightBlack": "#767676", "brightBlue": "#3B78FF", "brightCyan": "#61D6D6", "brightGreen": "#16C60C", "brightPurple": "#B4009E", "brightRed": "#E74856", "brightWhite": "#F2F2F2", "brightYellow": "#F9F1A5", "cursorColor": "#FFFFFF", "cyan": "#3A96DD", "foreground": "#CCCCCC", "green": "#13A10E", "name": "Campbell", "purple": "#881798", "red": "#C50F1F", "selectionBackground": "#FFFFFF", "white": "#CCCCCC", "yellow": "#C19C00" } ] } ``` ### Expected Behavior When Windows Subsystem for Linux is disabled, Windows Terminal _will not execute_ `wsl.exe`. ### Actual Behavior When Windows Subsystem for Linux is disabled, Windows Terminal _executes_ `wsl.exe`.
claunia commented 2026-01-31 04:49:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 9, 2021):

This is by-design. We need to call wsl.exe to be able to enumerate the list of distros that are installed. Though, that should have been fixed in #10967, where we're now doing that lookup in the registry. Hmm. The comments in that thread seem to suggest that's only in 1.11 Preview, and we didn't roll that forward to Stable?

Hmm. Okay well the bot must have been on a nap because https://github.com/microsoft/terminal/compare/v1.10.2714.0...v1.11.2921.0 suggests that f9a844dbda is in 1.11 stable.

@zadjii-msft commented on GitHub (Nov 9, 2021): This is by-design. We need to call `wsl.exe` to be able to enumerate the list of distros that are installed. Though, that should have been fixed in #10967, where we're now doing that lookup in the registry. Hmm. The comments in that thread seem to suggest that's only in 1.11 _Preview_, and we didn't roll that forward to Stable? Hmm. Okay well the bot must have been on a nap because https://github.com/microsoft/terminal/compare/v1.10.2714.0...v1.11.2921.0 suggests that f9a844dbdacff8b7b6b0a1221de7634668fa8ca7 _is_ in 1.11 stable.
claunia commented 2026-01-31 04:49:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 9, 2021):

UNLESS the registry lookup failed, and that caused us to fallback to the old method. I totally forgot I left that in there. What's in Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss? Does that key even exist?

@zadjii-msft commented on GitHub (Nov 9, 2021): UNLESS the registry lookup failed, and that caused us to fallback to the old method. I totally forgot I left that in there. What's in `Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss`? Does that key even exist?
claunia commented 2026-01-31 04:49:29 +00:00
Author
Owner
Copy Link

@mattifestation commented on GitHub (Nov 9, 2021):

Thanks for the quick response, @zadjii-msft. The Lxss key doesn't exist in HKCU but it does in HKLM but doesn't have any values defined:

PS> Get-Item -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss
Get-Item : Cannot find path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss' because it does not exist.
At line:1 char:1
+ Get-Item -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (HKCU:\Software\...entVersion\Lxss:String) [Get-Item], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemCommand

PS> Get-Item -Path HKLM:\Software\Microsoft\Windows\CurrentVersion\Lxss


    Hive: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion


Name                           Property
----                           --------
Lxss

The path of Windows Terminal that is attempting to launch wsl.exe is C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe. Confirming the version I'm running:

PS> $File = Get-Item -Path 'C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe'

PS> $File.VersionInfo.ProductVersion
1.11.211019001-release1.11

PS> $File.VersionInfo.FileVersion
1.11.2110.19001

Are there any additional repro steps you'd recommend I try? Thanks!

@mattifestation commented on GitHub (Nov 9, 2021): Thanks for the quick response, @zadjii-msft. The `Lxss` key doesn't exist in HKCU but it does in HKLM but doesn't have any values defined: ``` PS> Get-Item -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss Get-Item : Cannot find path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss' because it does not exist. At line:1 char:1 + Get-Item -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (HKCU:\Software\...entVersion\Lxss:String) [Get-Item], ItemNotFoundException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemCommand PS> Get-Item -Path HKLM:\Software\Microsoft\Windows\CurrentVersion\Lxss Hive: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion Name Property ---- -------- Lxss ``` The path of Windows Terminal that is attempting to launch `wsl.exe` is `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe`. Confirming the version I'm running: ``` PS> $File = Get-Item -Path 'C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe' PS> $File.VersionInfo.ProductVersion 1.11.211019001-release1.11 PS> $File.VersionInfo.FileVersion 1.11.2110.19001 ``` Are there any additional repro steps you'd recommend I try? Thanks!
claunia commented 2026-01-31 04:49:30 +00:00
Author
Owner
Copy Link

@mattifestation commented on GitHub (Nov 9, 2021):

Ah okay. I see the issue now. The Lxss key is only checked in HKCU and not checked in HKLM. And so because openWslRegKey returns null, it falls back to calling legacyGenerate which calls wsl.exe.

So perhaps a durable fix would be to also check in HKLM. A s short term fix for me personally, I confirmed that the event no longer surfaces after I created an Lxss key in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion. I'd love the more durable fix but I'm accepting of this short-term fix as I am likely among a small group of people who considers this to be an actual issue. Thanks!

@mattifestation commented on GitHub (Nov 9, 2021): Ah okay. I see the issue now. The `Lxss` key is [only checked in HKCU](https://github.com/microsoft/terminal/blob/479ef264b2d9e284db1fc8457f3897d1b19ac32e/src/cascadia/TerminalSettingsModel/WslDistroGenerator.cpp#L181) and not checked in HKLM. And so because `openWslRegKey` returns null, it falls back to calling `legacyGenerate` which calls `wsl.exe`. So perhaps a durable fix would be to also check in HKLM. A s short term fix for me personally, I confirmed that the event no longer surfaces after I created an `Lxss` key in `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion`. I'd love the more durable fix but I'm accepting of this short-term fix as I am likely among a small group of people who considers this to be an actual issue. Thanks!
claunia commented 2026-01-31 04:49:30 +00:00
Author
Owner
Copy Link

@SebCT commented on GitHub (Nov 27, 2021):

Ah okay. I see the issue now. The Lxss key is only checked in HKCU and not checked in HKLM. And so because openWslRegKey returns null, it falls back to calling legacyGenerate which calls wsl.exe.

So perhaps a durable fix would be to also check in HKLM. A s short term fix for me personally, I confirmed that the event no longer surfaces after I created an Lxss key in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion. I'd love the more durable fix but I'm accepting of this short-term fix as I am likely among a small group of people who considers this to be an actual issue. Thanks!

Thanks a lot for that hint Matt - i really needed that, too, because WDAC rocks and this was really annoying in the Operational Log ;-)

@SebCT commented on GitHub (Nov 27, 2021): > Ah okay. I see the issue now. The `Lxss` key is [only checked in HKCU](https://github.com/microsoft/terminal/blob/479ef264b2d9e284db1fc8457f3897d1b19ac32e/src/cascadia/TerminalSettingsModel/WslDistroGenerator.cpp#L181) and not checked in HKLM. And so because `openWslRegKey` returns null, it falls back to calling `legacyGenerate` which calls `wsl.exe`. > > So perhaps a durable fix would be to also check in HKLM. A s short term fix for me personally, I confirmed that the event no longer surfaces after I created an `Lxss` key in `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion`. I'd love the more durable fix but I'm accepting of this short-term fix as I am likely among a small group of people who considers this to be an actual issue. Thanks! Thanks a lot for that hint Matt - i really needed that, too, because WDAC rocks and this was really annoying in the Operational Log ;-)
claunia commented 2026-01-31 04:49:30 +00:00
Author
Owner
Copy Link

@mattifestation commented on GitHub (Nov 29, 2021):

Thanks for chiming in, @SebCT. I'm glad I wasn't the only one who found this to be obnoxious. And good on you for deploying Microsoft's recommended block list! 🤜🤛

@mattifestation commented on GitHub (Nov 29, 2021): Thanks for chiming in, @SebCT. I'm glad I wasn't the only one who found this to be obnoxious. And good on you for deploying Microsoft's recommended block list! 🤜🤛
claunia commented 2026-01-31 04:49:30 +00:00
Author
Owner
Copy Link

@SebCT commented on GitHub (Dec 4, 2021):

Thanks for chiming in, @SebCT. I'm glad I wasn't the only one who found this to be obnoxious. And good on you for deploying Microsoft's recommended block list! 🤜🤛

Hello Matt!

Thank you, without your Twitter and blog postings i couldn't do WDAC - so it makes lots of fun now ;-)

Actually i found out, that VSCODE also triggers WSL.exe (on my WDAC test system) if the following happens:

I start my VS Code with the "PowerShell integrated console V2021.10.2" because i installed the official PowerShell VS Code Add-On from Microsoft for scripting in PowerShell ISE Style on VS Code - in the operational log of WDAC i get a 3076 event (only once when starting):

"Code Integrity determined that a process (\Device\HarddiskVolume15\Windows\System32\cmd.exe) attempted to load \Device\HarddiskVolume15\Windows\System32\wsl.exe that did not meet the Enterprise signing level requirements or violated code integrity policy"

Can you confirm that behaviour on your system(s), too (in case you use the VS Code PS Add-On)?

I don't have a solution now for finding out why that happens, because the LXSS Regkey is set, but it doesn't help in this case.

Of course it's not a big problem and i can live with it, but would be curious why that happens and if you can confirm that.

Thanks in advance for your help and looking forward for your answer 😊

Update: found out the problem: i had wrong/old profile settings in my extension, i resetted it with the help of this article: https://code.visualstudio.com/docs/editor/integrated-terminal#_terminal-profiles - now no more WSL.exe in WDAC Event Log :-)

@SebCT commented on GitHub (Dec 4, 2021): > Thanks for chiming in, @SebCT. I'm glad I wasn't the only one who found this to be obnoxious. And good on you for deploying Microsoft's recommended block list! 🤜🤛 Hello Matt! Thank you, without your Twitter and blog postings i couldn't do WDAC - so it makes lots of fun now ;-) Actually i found out, that VSCODE also triggers WSL.exe (on my WDAC test system) if the following happens: I start my VS Code with the "PowerShell integrated console V2021.10.2" because i installed the official PowerShell VS Code Add-On from Microsoft for scripting in PowerShell ISE Style on VS Code - in the operational log of WDAC i get a 3076 event (only once when starting): "Code Integrity determined that a process (\Device\HarddiskVolume15\Windows\System32\cmd.exe) attempted to load \Device\HarddiskVolume15\Windows\System32\wsl.exe that did not meet the Enterprise signing level requirements or violated code integrity policy" Can you confirm that behaviour on your system(s), too (in case you use the VS Code PS Add-On)? I don't have a solution now for finding out why that happens, because the LXSS Regkey is set, but it doesn't help in this case. Of course it's not a big problem and i can live with it, but would be curious why that happens and if you can confirm that. Thanks in advance for your help and looking forward for your answer 😊 Update: found out the problem: i had wrong/old profile settings in my extension, i resetted it with the help of this article: https://code.visualstudio.com/docs/editor/integrated-terminal#_terminal-profiles - now no more WSL.exe in WDAC Event Log :-)
claunia commented 2026-01-31 04:49:30 +00:00
Author
Owner
Copy Link

@mattifestation commented on GitHub (Dec 6, 2021):

Good to hear you discovered the solution, @SebCT! I have yet to attempt building an allowlist for VSCode. You are brave! Haha. I run it in a VM when I need to do stuff locally. Otherwise, vscode.dev in meeting my basic needs.

@mattifestation commented on GitHub (Dec 6, 2021): Good to hear you discovered the solution, @SebCT! I have yet to attempt building an allowlist for VSCode. You are brave! Haha. I run it in a VM when I need to do stuff locally. Otherwise, [vscode.dev](vscode.dev) in meeting my basic needs.
claunia commented 2026-01-31 04:49:31 +00:00
Author
Owner
Copy Link

@SebCT commented on GitHub (Dec 6, 2021):

Good to hear you discovered the solution, @SebCT! I have yet to attempt building an allowlist for VSCode. You are brave! Haha. I run it in a VM when I need to do stuff locally. Otherwise, vscode.dev in meeting my basic needs.

Thanks for that hint with vscode.dev - totally forgot that, it's a very interesting solution for locked down devices, nice! 👌👍

Well, unfortunately my workaround didn't work, after a restart or two if VSCode i had the same thing again - so i used SysMon to find out wht's going on - here is the result, maybe you will find it interesting. I must admit i don't know how to solve it now, but will live with it - i think it's a VSCode thing, in bold text you see the Command Line in the event log:

Sysmon Event Log:

Image: C:\Windows\System32\cmd.exe
FileVersion: 10.0.19041.746 (WinBuild.160101.0800)
Description: Windows Command Processor
Product: Microsoft® Windows® Operating System
Company: Microsoft Corporation
OriginalFileName: Cmd.Exe
CommandLine: C:\WINDOWS\system32\cmd.exe /d /s /c "wsl.exe -l -q"
CurrentDirectory: C:\Program Files\Microsoft VS Code
User: StandardUser
LogonGuid: {8a12ecd4-2ce5-61ad-e692-140000000000}
LogonId: 0x1492E6
TerminalSessionId: 1
IntegrityLevel: Medium
Hashes: MD5=8A2122E8162DBEF04694B9C3E0B6CDEE,SHA256=B99D61D874728EDC0918CA0EB10EAB93D381E7367E377406E65963366C874450,IMPHASH=272245E2988E1E430500B852C4FB5E18
ParentProcessGuid: {8a12ecd4-8353-61ad-bb08-000000001000}
ParentProcessId: 6244
ParentImage: C:\Program Files\Microsoft VS Code\Code.exe
ParentCommandLine: "C:\Program Files\Microsoft VS Code\Code.exe" --type=renderer --disable-color-correct-rendering --field-trial-handle=1540,11676687341578546723,3858864379961801446,131072 --disable-features=CookiesWithoutSameSiteMustBeSecure,SameSiteByDefaultCookies,SpareRendererForSitePerProcess,WinRetrieveSuggestionsOnlyOnDemand --lang=de --user-data-dir="C:\Users\StandardUser\AppData\Roaming\Code" --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --app-user-model-id=Microsoft.VisualStudioCode --app-path="C:\Program Files\Microsoft VS Code\resources\app" --no-sandbox --no-zygote --disable-blink-features=Auxclick --node-integration-in-worker --device-scale-factor=1.5 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=7 --no-v8-untrusted-code-mitigations --mojo-platform-channel-handle=2980 /prefetch:1 --vscode-window-config=vscode:47b0147a-7eea-4b40-af6a-a4833063640c
ParentUser: StandardUser

It's invoked because of the PowerShell Add-On, which starts the VSCode Terminal - interesting thing....

@SebCT commented on GitHub (Dec 6, 2021): > Good to hear you discovered the solution, @SebCT! I have yet to attempt building an allowlist for VSCode. You are brave! Haha. I run it in a VM when I need to do stuff locally. Otherwise, [vscode.dev](vscode.dev) in meeting my basic needs. Thanks for that hint with vscode.dev - totally forgot that, it's a very interesting solution for locked down devices, nice! 👌👍 Well, unfortunately my workaround didn't work, after a restart or two if VSCode i had the same thing again - so i used SysMon to find out wht's going on - here is the result, maybe you will find it interesting. I must admit i don't know how to solve it now, but will live with it - i think it's a VSCode thing, in bold text you see the Command Line in the event log: Sysmon Event Log: Image: C:\Windows\System32\cmd.exe FileVersion: 10.0.19041.746 (WinBuild.160101.0800) Description: Windows Command Processor Product: Microsoft® Windows® Operating System Company: Microsoft Corporation OriginalFileName: Cmd.Exe **CommandLine: C:\WINDOWS\system32\cmd.exe /d /s /c "wsl.exe -l -q"** CurrentDirectory: C:\Program Files\Microsoft VS Code\ User: StandardUser LogonGuid: {8a12ecd4-2ce5-61ad-e692-140000000000} LogonId: 0x1492E6 TerminalSessionId: 1 IntegrityLevel: Medium Hashes: MD5=8A2122E8162DBEF04694B9C3E0B6CDEE,SHA256=B99D61D874728EDC0918CA0EB10EAB93D381E7367E377406E65963366C874450,IMPHASH=272245E2988E1E430500B852C4FB5E18 ParentProcessGuid: {8a12ecd4-8353-61ad-bb08-000000001000} ParentProcessId: 6244 ParentImage: C:\Program Files\Microsoft VS Code\Code.exe ParentCommandLine: "C:\Program Files\Microsoft VS Code\Code.exe" --type=renderer --disable-color-correct-rendering --field-trial-handle=1540,11676687341578546723,3858864379961801446,131072 --disable-features=CookiesWithoutSameSiteMustBeSecure,SameSiteByDefaultCookies,SpareRendererForSitePerProcess,WinRetrieveSuggestionsOnlyOnDemand --lang=de --user-data-dir="C:\Users\StandardUser\AppData\Roaming\Code" --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --app-user-model-id=Microsoft.VisualStudioCode --app-path="C:\Program Files\Microsoft VS Code\resources\app" --no-sandbox --no-zygote --disable-blink-features=Auxclick --node-integration-in-worker --device-scale-factor=1.5 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=7 --no-v8-untrusted-code-mitigations --mojo-platform-channel-handle=2980 /prefetch:1 --vscode-window-config=vscode:47b0147a-7eea-4b40-af6a-a4833063640c ParentUser: StandardUser It's invoked because of the PowerShell Add-On, which starts the VSCode Terminal - interesting thing....
claunia commented 2026-01-31 04:49:31 +00:00
Author
Owner
Copy Link

@mattifestation commented on GitHub (Dec 7, 2021):

Interesting. Thanks for that context, @SebCT. To an extent, I've accepted that some things will fill up the logs. For example, I get events all the time of mscorsvw.exe being prevented from loading Microsoft.Build.Framework.dll. When I audit events from the CodeIntegrity event log, I can filter those events out based on a verification error code of 26 (Explicitly denied by WDAC policy) in the 3089 events. In the WDACTools module, I can filter them out with the following:

Get-WDACCodeIntegrityEvent -SinceLastPolicyRefresh -Enforce -SignerInformation -IgnoreDenyEvents

Note: there's a bug where VerificationError 26 doesn't populate when you're in audit mode which is annoying. I hope that helps!

@mattifestation commented on GitHub (Dec 7, 2021): Interesting. Thanks for that context, @SebCT. To an extent, I've accepted that some things will fill up the logs. For example, I get events all the time of mscorsvw.exe being prevented from loading Microsoft.Build.Framework.dll. When I audit events from the CodeIntegrity event log, I can filter those events out based on a verification error code of 26 (Explicitly denied by WDAC policy) in the 3089 events. In the WDACTools module, I can filter them out with the following: ```powershell Get-WDACCodeIntegrityEvent -SinceLastPolicyRefresh -Enforce -SignerInformation -IgnoreDenyEvents ``` Note: there's a bug where VerificationError 26 doesn't populate when you're in audit mode which is annoying. I hope that helps!
claunia commented 2026-01-31 04:49:31 +00:00
Author
Owner
Copy Link

@SebCT commented on GitHub (Dec 9, 2021):

Interesting. Thanks for that context, @SebCT. To an extent, I've accepted that some things will fill up the logs. For example, I get events all the time of mscorsvw.exe being prevented from loading Microsoft.Build.Framework.dll. When I audit events from the CodeIntegrity event log, I can filter those events out based on a verification error code of 26 (Explicitly denied by WDAC policy) in the 3089 events. In the WDACTools module, I can filter them out with the following:

Get-WDACCodeIntegrityEvent -SinceLastPolicyRefresh -Enforce -SignerInformation -IgnoreDenyEvents

Note: there's a bug where VerificationError 26 doesn't populate when you're in audit mode which is annoying. I hope that helps!

Thanks for that Matt, that really helps me for future Audits, very nice! 👍👌😊

@SebCT commented on GitHub (Dec 9, 2021): > Interesting. Thanks for that context, @SebCT. To an extent, I've accepted that some things will fill up the logs. For example, I get events all the time of mscorsvw.exe being prevented from loading Microsoft.Build.Framework.dll. When I audit events from the CodeIntegrity event log, I can filter those events out based on a verification error code of 26 (Explicitly denied by WDAC policy) in the 3089 events. In the WDACTools module, I can filter them out with the following: > > ```powershell > Get-WDACCodeIntegrityEvent -SinceLastPolicyRefresh -Enforce -SignerInformation -IgnoreDenyEvents > ``` > > Note: there's a bug where VerificationError 26 doesn't populate when you're in audit mode which is annoying. I hope that helps! Thanks for that Matt, that really helps me for future Audits, very nice! 👍👌😊
claunia commented 2026-01-31 04:49:32 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 6, 2022):

:tada:This issue was addressed in #13436, which has now been successfully released as Windows Terminal v1.14.186.🎉

Handy links:

@ghost commented on GitHub (Jul 6, 2022): :tada:This issue was addressed in #13436, which has now been successfully released as `Windows Terminal v1.14.186`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.14.186) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 04:49:32 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 6, 2022):

:tada:This issue was addressed in #13436, which has now been successfully released as Windows Terminal Preview v1.15.186.🎉

Handy links:

@ghost commented on GitHub (Jul 6, 2022): :tada:This issue was addressed in #13436, which has now been successfully released as `Windows Terminal Preview v1.15.186`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.15.186) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Help Wanted Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15824
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?