[BUG] After the WSL 2.7.3.0 update, custom kernel modules are not working due to an 'access denied' error

[Nevuly]

Windows Version

Microsoft Windows [Version 10.0.26200.8328]

WSL Version

2.7.3.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.114.1-1 (Used custom kernel: 7.0.5)

Distro Version

Ubuntu 26.04

Other Software

Scoop

Repro Steps

1. Install custom kernel module using Scoop (When installing via Scoop, it is downloaded to the following path: C:\Users\User\scoop\apps\<app_name>\<version>\<module vhdx>).
2. Use WSL Settings to set the custom kernel module path to the downloaded location.
3. Boot WSL distribution.

Expected Behavior

The WSL2 distribution should start and run correctly without any errors.

Actual Behavior

An error occurs (Access Denied):
Wsl/Service/CreateInstance/CreateVm/HCS/E_ACCESSDENIED

For further verification, if I copy the vhdx file to the C:\ root directory, update the path, and boot WSL, it boots correctly.

Upon further investigation, it only fails to work in the User directory (C:\Users\<Username>).

Diagnostic Logs

N/A

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[Nevuly]

There are no logs.

WSL2 is failing to boot due to the error below, and it is not a kernel-related issue.

Wsl/Service/CreateInstance/CreateVm/HCS/E_ACCESSDENIED

[Nevuly]

I would appreciate it if you could let me know if it is intended behavior that the vhdx image must be located in the C:\ root directory to work.

CC @benhillis

[benhillis]

I would appreciate it if you could let me know if it is intended behavior that the vhdx image must be located in the C:\ root directory to work.

CC @benhillis

Not intended, shouldn't matter where the VHD is located. I'll take a look.

[Nevuly]

I would appreciate it if you could let me know if it is intended behavior that the vhdx image must be located in the C:\ root directory to work.
CC @benhillis

Not intended, shouldn't matter where the VHD is located. I'll take a look.

I forgot to mention one detail. If you use the icacls.exe command in PowerShell to add the following SIDs to the VHDX image, it will work correctly in C:\Users\<username>:

• *S-1-5-32-545:(RX) (BUILTIN\Users)
• *S-1-15-2-1:(RX) (APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES)
• *S-1-15-2-2:(RX) (APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES)

[hansfn]

Just for the record, I can confirm this issue. I had 2.6.3 with custom kernel (and kernel modules) under C:\Users\<USERNAME> and updating to 2.7.3 made WSL fail with Wsl/Service/CreateInstance/CreateVm/HCS/E_ACCESSDENIED. Moving the files to C:\Dev\ worked.