How can a reproducible Windows Shell32 environment-regeneration defect be escalated to Windows engineering?

Question

How can a reproducible Windows Shell32 environment-regeneration defect be escalated to Windows engineering?

呂兆晞 20

I have investigated a reproducible Windows 11 environment-regeneration defect and would like to know the appropriate way to escalate the findings to the Windows Shell engineering team.

Problem summary

When the expected combined Machine PATH and User PATH reaches 4095 characters, Windows Shell32's environment-regeneration logic silently omits the entire User PATH, leaving only the Machine PATH.

In controlled tests, the internal, undocumented shell32.dll!RegenerateUserEnvironment function returned TRUE despite producing an incomplete PATH.

This can cause user-installed command-line tools to become inaccessible through normal command lookup, even though their executables and User PATH registry entries remain intact.

Verified environments

Windows 11 24H2 (OS Build 26100.4770)

shell32.dll version: 10.0.26100.4768
Relatively clean VM without ExplorerPatcher
Standard, non-elevated PowerShell 5.1 process
Expected combined PATH length 4094: correct
Expected combined PATH length 4095: User PATH completely omitted
CreateEnvironmentBlock successfully constructs the complete PATH using the same registry values

Windows 11 26H2 (OS Build 26300.9818)

shell32.dll version: 10.0.26100.9949
Exact 4094/4095 boundary independently reproduced on one additional PC
A separate PC reproduced Machine-only PATH regeneration with an existing combined Process PATH of 4162 characters

Root-cause investigation

Using WinDbg on the 24H2 VM, I traced the failure to a length check within:

shell32!BuildEnvironmentPath

The relevant conditional branch skips the User PATH append operation at the failing boundary.

A controlled in-memory diagnostic experiment on the disposable VM provided strong evidence that this check is responsible for the observed behavior. No production system DLL was modified.

This appears to be an issue in Windows Shell32 rather than WinGet, PowerShell, or a third-party shell modification.

Existing reports

I have already submitted the findings through Windows Feedback Hub and privately to Microsoft Security Response Center for assessment of potential security implications.

I also published the reproducible test results, screenshots, and original VM test transcript in this related GitHub discussion:

https://github.com/microsoft/winget-cli/issues/6606#issuecomment-6702696239

My question

What is the appropriate Microsoft-supported process for having a reproducible Windows Shell32 implementation defect, with WinDbg root-cause evidence, reviewed by the Windows product engineering team?

Since the issue has already been reported through Feedback Hub and MSRC, I would especially appreciate guidance on whether there is a way to associate the existing reports with the Windows Shell engineering team or obtain an engineering-level investigation without opening a paid Windows SDK support incident.

I understand that RegenerateUserEnvironment is undocumented, but the observable impact concerns the effective environment received by Windows applications and command-line tools.

Thank you for any guidance on routing this issue to the appropriate product team.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello @呂兆晞 and thank you for reaching out with your concerns.

Based on the details provided, you have already used the appropriate public channels for reporting this issue.

Feedback Hub is the supported channel for reporting Windows defects and submitting the relevant diagnostics. The GitHub issue is also a reasonable place to document the reproduction because the visible impact involves WinGet, although the underlying Shell32 implementation is outside the scope of the WinGet repository. Reporting it to MSRC was also appropriate for assessing any potential security implications.

There does not appear to be a separate public issue tracker through which a Shell32 defect can be submitted directly to the Windows Shell engineering team. You can add the Feedback Hub report link or ID to the GitHub issue, and include the GitHub reproduction details in the Feedback Hub report, so the available evidence is connected across both reports.

However, Microsoft Q&A cannot associate those reports with an internal engineering work item or guarantee review by a particular Windows product team. If you require a tracked investigation and direct support response, the remaining formal route would be to open a support case through an applicable Microsoft support agreement.

Otherwise, the Feedback Hub submission remains the appropriate route for the product team to review the defect and diagnostics.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. Thank you.