PackageFamilyName is not None even if it should be None

[mveril]

Windows Version

Microsoft Windows [version 10.0.26200.8117]

WSL Version

2.6.2.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.87.2

Distro Version

No response

Other Software

Rust 1.94.1
wslplugins-rs 0.1.0-beta.2

Repro Steps

I am the developer of wslplugins-rs a framework to easely develop WSL plugins in rust and I facing an issue when I try to debug an example I just developped.
1 clone the repo

git clone https://github.com/mveril/wslplugins-rs

2. Go to branch unpackaged-distro-blacklist-policy
3. sign the plugin and register it as you

cargo build --release -p unpackaged-distro-blacklist-policy

3. found the dll in the target folder of the project sign it and register it as described in the readme of my project or in the Microsoft WSLPlugin sample
4. Run WSL and check the logfile C:\\wsl-unpackaged-distro-blacklist.log and you can see something like

2026-04-03T17:25:06.790520Z  INFO unpackaged_distro_blacklist_policy: Distribution FedoraLinux-42 started with package family name Some("")

So the package family name is an empty string even if it should be None
This information is obtainied using this specific code

    #[inline]
    fn package_family_name(&self) -> Option<OsString> {
        // SAFETY: check already inside
        unsafe {
            let ptr = self.0.PackageFamilyName;
            if ptr.is_null() {
                None
            } else {
                Some(OsString::from_wide(PCWSTR::from_raw(ptr).as_wide()))
            }
        }
    }

Expected Behavior

Package family name should be a null pointer when it's an unpackaged distro but it's an pointer to an empty string

Actual Behavior

Package family name should be a null pointer when it's an unpackaged distro but it's an pointer to an empty string

Diagnostic Logs

No response

[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'.

[mveril]

WslLogs-2026-04-03_20-30-32.zip

[github-actions]

Diagnostic information

Detected appx version: 2.6.2.0

[chemwolf6922]

Hi @mveril, I tried to fix this. Unfortunately, some native plugins are already using this without a null check. Namely, the DefenderforEndpointPlug-in.dll. The fix will cause invalid access in it🤦‍♂️.
I don't think we can fix this given the situation. Sorry.
I'll suggest keep your null check and also add an empty string check to workaround this.

[mveril]

I @chemwolf6922

Ok thanks I will fix it in the code of the Rust lib (so I will treat empty string as null).
Maybe it can be explicitly said in the doc of the header.
Also is there other case in the plugin architecture ? Is it global or only affect package familly name ?

[OneBlue]

Hi @mveril, I tried to fix this. Unfortunately, some native plugins are already using this without a null check. Namely, the DefenderforEndpointPlug-in.dll. The fix will cause invalid access in it🤦‍♂️. I don't think we can fix this given the situation. Sorry. I'll suggest keep your null check and also add an empty string check to workaround this.

Agreed, unfortunately changing this behavior will likely break existing plugin, so we shouldn't change it.

[chemwolf6922]

@mveril The "Flavor" and "Version" fields are not clearly documented. And there are different assignment logics for those two...
Here, it's assigned as NULL if not present:

WSL/src/windows/service/exe/LxssUserSession.cpp

Lines 2383 to 2384 in 8496b40

	distributionInfo.Flavor = configuration.Flavor.empty() ? nullptr : configuration.Flavor.c_str();
	distributionInfo.Version = configuration.OsVersion.empty() ? nullptr : configuration.OsVersion.c_str();

But here, it's can be assigned to "":

WSL/src/windows/service/exe/LxssUserSession.cpp

Lines 3519 to 3520 in 8496b40

	distributionInfo.Flavor = Configuration.Flavor.c_str();
	distributionInfo.Version = Configuration.OsVersion.c_str();

[mveril]

Hello !
Ok so I will add empty check for all of them to allow to return a significant Option<OsString>
By this way if there is no significant value I will return None
Thanks @OneBlue @chemwolf6922
Maybe it can be useful to mention it on the header documentation

[mveril]

For info I fixed it on my lib side in mveril/wslplugins-rs#46.