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, commit 6e29e4530c5631b6d3d2afacb49c6f1267fb0b42.
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() catches IOException, SecurityException, and UnauthorizedAccessException, but not Win32Exception.
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 commented on Oct 26, 2026
Same defect, much simpler trigger — no sandbox or AppContainer needed. On a stock Windows 11 desktop, any subst drive 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), while cmd.exe and Windows PowerShell 5.1 see and use it normally. $Error is empty after startup, as you observed.
Why it hits the same path: DriveInfo reports the subst letter as DriveType.Network (it inherits the target's type), so GetRootPathForNetworkDriveOrDosDevice runs; WNetGetConnection fails for it — ERROR_NOT_CONNECTED (2250), or ERROR_CONNECTION_UNAVAIL (1201) when a remembered mapping also exists for the letter — and the DOS-device fallback then throws the Win32Exception that the per-drive handler in InitializeDefaultDrives does not catch. The PowerShellCore/Operational log 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 null DisplayRoot, continue):
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 broken subst drive reported as nonexistent) looks like the same family.
janfila commented on 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.
wtq0816 commented on Nov 7, 2026
mcc (@mcc1), I am investigating the same initialization warning in Codex-bundled PowerShell 7.6.5, but have not established the same cause. Could you share a minimal probe based on your first-chance-exception investigation that outputs only exception types, native error codes, and method names? Please identify any file writes, settings changes, or identifying metadata it could collect. I would like to preserve the existing sandbox and installed runtime.
Gupus (@stavin), your reproduction without AppContainer suggests that the warning alone cannot identify the trigger. Which read-only observation best distinguishes the subst-to-network-drive case from the restricted mapping-query case? Is the exception type and native error code sufficient, or is another specific signal required? I am looking for a diagnostic distinction without creating, removing, or remapping drives.
mcc1 commented on Nov 8, 2026
wtq0816 I reviewed the records from my original investigation. These results are from PowerShell 7.6.8, not a new test of 7.6.9. I have not revalidated the cause on 7.6.9.
Environment and reproduction:
Findings:
This establishes the restricted mapping-query failure for that earlier environment, but not the exact MXC restriction responsible for error 5. I would not infer the same cause in another environment from the startup warning alone, or treat an exception type or error code alone as a universal distinction from the network-subst case.
Regarding the requested minimal probe: my original harness wrote local diagnostic files and collected full exception messages, stacks and drive/mapping metadata, including paths. It was not limited to exception types, native error codes and method names. The comparison did not change sandbox settings, services, ACLs or drive mappings. I am sharing the sanitized historical findings, not the old harness or a validated minimal probe.