René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"FileSystem PSDrives not mounted when PowerShell runs inside an AppContainer","articleBody":"### Prerequisites\n\n- [x] Write a descriptive title.\n- [x] Make sure you are able to repro it on the [latest released version](https://github.com/PowerShell/PowerShell/releases)\n- [x] Search the existing issues.\n- [x] Refer to the [FAQ](https://github.com/PowerShell/PowerShell/blob/master/docs/FAQ.md).\n- [x] Refer to [Differences between Windows PowerShell 5.1 and PowerShell](https://learn.microsoft.com/powershell/scripting/whats-new/differences-from-windows-powershell).\n\n### Steps to reproduce\n\n1. Create a Windows AppContainer profile via `CreateAppContainerProfile`.\n2. Launch `pwsh.exe` inside the AppContainer using `CreateProcessW` with `PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES`.\n3. Run any cmdlet:\n\n```powershell\npwsh.exe -NoProfile -Command \"Write-Output hello\"\n```\n\n\n### Expected behavior\n\n```console\nhello\n``` \n\nPowerShell should mount filesystem PSDrives (`C:`, `D:`, etc.) and module auto-loading should work normally.\n\n### Actual behavior\n\n```console\nWrite-Output: The term 'Write-Output' is not recognized as a name of a cmdlet,\nfunction, script file, or executable program.\nCheck the spelling of the name, or if a path was included, verify that the path\nis correct and try again.\n\n``` \nNo filesystem PSDrives are created. The available drives are only: `HKLM, HKCU, Alias, Env, Temp, Function, Variable`. The `FileSystem` provider is loaded but has no drives attached to it.\n\nThis breaks **all** cmdlets — `Write-Output`, `Get-ChildItem`, `Import-Module`, `Get-Module`, etc. — because module auto-loading cannot resolve `$env:PSModulePath` entries (e.g. `C:\\Program Files\\PowerShell\\7\\Modules`) without a mounted `C:` PSDrive.\n### Error details\nThe root cause is in [`FileSystemProvider.InitializeDefaultDrives()`](https://github.com/PowerShell/PowerShell/blob/9c1272039cf8eab566a048fbfba8007567983cd6/src/System.Management.Automation/namespaces/FileSystemProvider.cs#L849):\n```csharp\nDriveInfo[] logicalDrives = DriveInfo.GetDrives();\n\nforeach (DriveInfo newDrive in logicalDrives)\n{\n    if (newDrive.DriveType == DriveType.Fixed)\n    {\n        if (!newDrive.RootDirectory.Exists)   // ← returns false in AppContainer\n        {\n            continue;                          // ← drive skipped entirely\n        }\n\n        root = newDrive.RootDirectory.FullName;\n    }\n    // … create PSDriveInfo …\n}\n``` \n\n`RootDirectory.Exists` calls [`FileSystem.DirectoryExists()`](https://github.com/dotnet/runtime/blob/cc78323ef440208bab9bd99fee82e3ea40ec61a5/src/libraries/Common/src/System/IO/FileSystem.Attributes.Windows.cs#L17) in the .NET runtime, which calls `GetFileAttributesEx`. On a typical Windows installation, `C:\\` does **not** have an `ALL APPLICATION PACKAGES` ACE, so `GetFileAttributesEx(\"C:\")` returns `ERROR_ACCESS_DENIED` (5). .NET interprets this as \"does not exist\" and returns `false`.\n\nSubdirectories like `C:\\Windows` and `C:\\Program Files` **do** have `ALL APPLICATION PACKAGES` ACEs and are fully accessible — only the volume root is blocked.\n\n**Why this breaks module loading specifically:**\n\nWithout a `C:` PSDrive, PowerShell's path resolution (`LocationGlobber` → `SessionStateDriveAPIs.GetDrive()`) throws `DriveNotFoundException` for any `C:\\…` path. Module auto-discovery iterates `$env:PSModulePath` entries (all on `C:`), each triggers a caught `DriveNotFoundException`, and all are silently skipped. No modules discovered → no cmdlets.\n\nNote: the underlying Win32 filesystem **is** accessible — `[System.IO.Directory]::GetDirectories(\"C:\\Program Files\\PowerShell\\7\\Modules\")` succeeds inside the AppContainer and returns all 14 module directories. The problem is purely in the PSDrive layer.\n\n**Diagnostic evidence:**\n\n| Check | Normal process | AppContainer |\n|---|---|---|\n| `GetFileAttributes(\"C:\\\")` (Win32) | ✅ `0x16` (DIR) | ❌ Error 5 (`ACCESS_DENIED`) |\n| `GetFileAttributes(\"C:\\Windows\")` | ✅ `0x10` (DIR) | ✅ `0x10` (DIR) |\n| `GetLogicalDrives()` | ✅ `0x3C` | ✅ `0x3C` (drives present) |\n| `TokenIsAppContainer` | `0` | `1` |\n| PSDrives | `C, D, E, F, Temp, …` | `HKLM, HKCU, Alias, Env, Temp, Function, Variable` |\n| `FileSystem` provider loaded | ✅ | ✅ (but no drives attached) |\n| `[IO.Directory]::GetDirectories(…)` | ✅ | ✅ (filesystem works) |\n\n**Suggested fix:**\n\nThe `RootDirectory.Exists` check is too strict. `DriveInfo.GetDrives()` already proved the drive exists via `GetLogicalDrives()`. An `ACCESS_DENIED` on the root does not mean the drive is absent. Options:\n\n1. **Remove the `RootDirectory.Exists` check** — `GetDrives()` is sufficient proof.\n2. **Treat `ACCESS_DENIED` as \"exists\"** — similar to the `VolumeLabel` read a few lines above which already catches `UnauthorizedAccessException`.\n3. **Fall back to `GetLogicalDrives()` bitmask** instead of `GetFileAttributes` on the root.\n\n### Environment data\n\n```powershell\nName                           Value\n----                           -----\nPSVersion                      7.5.5\nPSEdition                      Core\nGitCommitId                    7.5.5\nOS                             Microsoft Windows 10.0.26593\nPlatform                       Win32NT\nPSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}\nPSRemotingProtocolVersion      2.3\nSerializationVersion           1.1.0.1\nWSManStackVersion              3.0\n```\n\nAppContainer created via `CreateAppContainerProfile` + `PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES` (standard Win32 APIs).\n\n### Visuals\n\n_No response_","author":{"url":"https://github.com/asklar","@type":"Person","name":"asklar"},"datePublished":"2026-04-10T18:52:55.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/27253/PowerShell/issues/27253"}