Repository navigation
Unhandled Win32Exception during network-drive discovery interrupts FileSystem provider initialization in AppContainer #28268
Description
Summary
On Windows, a failure to resolve a network drive's mapping inside an AppContainer-restricted process can abort FileSystemProvider.InitializeDefaultDrives().
In the observed environment, both WNetGetConnectionW and the subsequent DOS-device fallback fail with ERROR_ACCESS_DENIED (5). The fallback throws Win32Exception, which is not caught by the per-drive exception handling in InitializeDefaultDrives().
This leaves provider initialization incomplete even though ordinary filesystem operations in the permitted workspace still succeed.
Environment
- Windows 11 Pro for Workstations Insider Preview, x64, version 10.0.26220.
- Official MSI-installed PowerShell 7.6.8 was the unmodified control.
- Restricted execution: Codex Windows MXC sandbox with a workspace-write permission profile.
- The same Windows user has existing mapped network drives. Private share names are omitted.
- The launcher was a local build of Codex CLI 0.164.0 containing separate SystemRoot-environment and Windows SQL-migration line-ending fixes. This is not a claim that the launcher binary was an unmodified official release.
- The PowerShell source used for the local comparison was tag
v7.6.8, commit6e29e4530c5631b6d3d2afacb49c6f1267fb0b42.
Steps to reproduce
Prerequisite: a Windows environment with an existing network drive visible to DriveInfo.GetDrives(), and a restricted process in which network-mapping/DOS-device queries return access denied. I have reproduced this using MXC; I have not independently reproduced it with a minimal standalone CreateAppContainerProfile launcher, or established that every AppContainer configuration is affected.
-
Start the unmodified PowerShell executable outside the sandbox with
-NoLogo -NoProfile -NonInteractive. -
Execute:
[Console]::WriteLine($PSVersionTable.PSVersion.ToString()) [Console]::WriteLine([bool](Get-PSDrive -Name Temp -ErrorAction SilentlyContinue)) [IO.DriveInfo]::GetDrives() | Select-Object Name, DriveType Get-PSDrive -PSProvider FileSystem | Select-Object Name, Root, DisplayRoot
-
Run the same executable and commands through the MXC workspace sandbox. The launcher invocation used in the investigation has this form:
& codex -c 'windows.sandbox="mxc"' -c 'features.prefer_mxc=true' sandbox --permission-profile ':workspace' -C $independentTestDirectory -- 'C:\Program Files\PowerShell\7\pwsh.exe' -NoLogo -NoProfile -NonInteractive -File $probeScript
Both variables above designate an independent local diagnostic directory/script. No profile, registry execution-policy bypass, drive remapping, service change, or ACL adjustment is required for these comparisons.
-
Compare provider startup and the Temp drive. To investigate the underlying failure, capture managed first-chance exceptions while creating another runspace and triggering its FileSystem provider.
Actual behavior and captured exception
The sandboxed control prints the FileSystem provider initialization warning. Its initial $Error collection is empty, so inspecting $Error after startup did not recover the original exception. The command can still exit 0 and perform permitted local writes.
A process-local AppDomain.CurrentDomain.FirstChanceException handler, used while opening/using a separate runspace, captured this exception chain. Localized message text is omitted:
System.Management.Automation.ProviderInvocationException
---> System.Management.Automation.ProviderInvocationException
---> System.ComponentModel.Win32Exception (5)
at Interop.Windows.GetDosDeviceForNetworkPath(Char deviceName)
at Microsoft.PowerShell.Commands.FileSystemProvider.WinGetSubstitutedPathForNetworkDosDevice(String driveName)
at Microsoft.PowerShell.Commands.FileSystemProvider.GetRootPathForNetworkDriveOrDosDevice(DriveInfo driveInfo)
at Microsoft.PowerShell.Commands.FileSystemProvider.InitializeDefaultDrives()
at System.Management.Automation.SessionStateInternal.InitializeProvider(...)
Independent native API probes and direct reflection calls to the installed provider method gave:
| Probe | Normal process | MXC process |
|---|---|---|
| WNetGetConnectionW for each of two mapped drives | Success, correct UNC mapping | Error 5 |
| QueryDosDeviceW for those drive letters | Success | Error 5 |
| GetRootPathForNetworkDriveOrDosDevice for those drives | Correct UNC mapping | Win32Exception (5) |
| Temp PSDrive after startup | Present | Absent |
The API error results were measured directly, rather than inferred only from the warning.
Expected behavior
Failure to obtain optional network-drive mapping/display information should not prevent the provider from finishing initialization of other drives, including Temp.
A possible behavior is to retain the drive-letter root with an unavailable DisplayRoot and continue initialization. This does not require granting additional permissions to the restricted process or making inaccessible filesystem paths accessible.
The underlying reason MXC denies these queries has not been established here. This report concerns PowerShell's handling of that failure.
Source inspection and local comparison
In FileSystemProvider.cs at the tested commit:
GetRootPathForNetworkDriveOrDosDevice()catches failure of the initial network-mapping lookup and can attempt the DOS-device fallback.- The per-drive handling in
InitializeDefaultDrives()catchesIOException,SecurityException, andUnauthorizedAccessException, but notWin32Exception.
I built a local comparison that handles Win32Exception around this network lookup and retains a null DisplayRoot. This was tested with the same sandbox policy:
| PowerShell build/context | Initialization warning | Temp drive | Probe script and permitted file write |
|---|---|---|---|
| Official 7.6.8, normal process | No | Present | Pass |
| Official 7.6.8, MXC | Yes | Absent | Pass |
| Local comparison, normal process | No | Present | Pass |
| Local comparison, MXC | No | Present | Pass |
Fresh process tests after local installation also passed. Sandbox boundary checks continued to reject writes outside the permitted workspace. No configuration, service, or lasting ACL change was used to obtain these results.
This comparison supports handling the mapping exception gracefully; it does not establish that all network-drive initialization failures have the same cause.
Related reports
- PowerShell in Docker container does not map container drive mounts at start-up #7212, especially this comment, describes the same network-drive discovery function failing in a Windows container. That issue was later closed for inactivity, which does not establish that this current case was fixed.
- FileSystem PSDrives not mounted when PowerShell runs inside an AppContainer #27253 concerns a different AppContainer failure involving fixed-drive root existence checks; I am not claiming it is the same defect.
- openai/codex#55004 reports the startup warning and empty error collection, but does not contain this captured inner exception chain.
Please consider making FileSystem provider initialization resilient to this network-mapping Win32Exception, and adding coverage for failed mapping queries in a restricted Windows context.
No private share names, user/project paths, credentials, transfer URLs, or raw session logs are included.
Activity
stavin commentedon Oct 26, 2026
Same defect, much simpler trigger — no sandbox or AppContainer needed. On a stock Windows 11 desktop, any
substdrive whose target lives on a mapped network drive reproduces this:Result (PowerShell 7.6.9, Windows 11):
U:(local target) is registered;T:(network target) is silently dropped and is unusable in pwsh (Test-Path T:\→$false), whilecmd.exeand Windows PowerShell 5.1 see and use it normally.$Erroris empty after startup, as you observed.Why it hits the same path:
DriveInforeports the subst letter asDriveType.Network(it inherits the target's type), soGetRootPathForNetworkDriveOrDosDeviceruns;WNetGetConnectionfails for it —ERROR_NOT_CONNECTED(2250), orERROR_CONNECTION_UNAVAIL(1201) when a remembered mapping also exists for the letter — and the DOS-device fallback then throws theWin32Exceptionthat the per-drive handler inInitializeDefaultDrivesdoes not catch. ThePowerShellCore/Operationallog records event 4102 with "GetDosDeviceForNetworkPath() can be called only if PSDrive.DriveType == DriveType.Network" for every start.Two data points supporting the fix you propose (catch
Win32Exception, keep a nullDisplayRoot, continue):New-PSDrive -Name T -PSProvider FileSystem -Root 'T:\'succeeds after startup, so only the enumeration path rejects the drive.substwith a real mapping (net use T: \\server\share\somefolder) makes the warning disappear and the letter register with aDisplayRoot— i.e. the drive is perfectly valid; only the mapping lookup is.Also worth noting for triage: the warning itself names no drive and nothing is written to
$Error, so users cannot tell which letter was dropped or why. Including the drive letter and the inner exception message in that line would make it actionable. #20894 (a brokensubstdrive reported as nonexistent) looks like the same family.janfila commentedon Oct 29, 2026
Additional confirmation with bundled PowerShell 7.6.5 and Windows 26300.9711
Independent confirmation of the mapping-query/initialization boundary described here. These are observations from a separate host; the proposed source handling was checked against a public-source fixture only and was not compiled or installed locally.
Environment
Actual result
Ordinary sandboxed PowerShell startup prints:
Child commands can exit0, but initialization is incomplete: logical-drive discovery returns the four local drives and two mapped-network drives; Get-PSDrive only contains the four local drives and lacks the normally initialized Temp drive.
Direct local-metadata probes show:
Original-provider tracing captures Win32Exception5 at GetUNCForNetworkDrive -> GetRootPathForNetworkDriveOrDosDevice -> InitializeDefaultDrives.
Source mechanism
InitializeDefaultDrives queries the network display-root helper while enumerating drives. Its per-drive catch clauses cover IO/security/unauthorized-access exceptions, but not System.ComponentModel.Win32Exception. WNetGetConnection error5 becomes this uncaught exception. When the network drive is not ready in the restricted context, the helper rethrows it. Initialization then exits before adding Temp.
Sources:
Minimal reproduction
A transient narrower filesystem profile, with no root/all-volume grant, also reproduced the warning and the same visible drive list. It did not fix provider startup.
Expected behavior
Failure to obtain optional display metadata for a restricted network mapping should not abort initialization of unrelated local drives or Temp. Actual access to the network target must remain subject to existing permissions and must continue failing if denied.
Please consider handling Win32Exception around the optional network display-root query, keeping DisplayRoot unset when unavailable, and completing initialization. Alternatively skip only that unavailable drive. Do not change filesystem/network policy, grant AppContainer access to the mappings, or suppress unrelated errors.
Suggested regression checks: one restricted mapping, a later healthy local drive, Temp creation, actual denied network access still denied, and ordinary unrestricted mapping behavior unchanged.
No private logs, usernames, SIDs, share names, drive identifiers, configuration dumps, credentials or source-workspace data are included. No local vendor binary was patched. The root cause is still present in the installed version.