PowerShell 5.1 FileStream creation fails with 0x80070005 on an NTFS VHDX using a volume GUID path, while directory creation succeeds

I am investigating a persistent file-creation failure on a locally created NTFS VHDX mounted as R:. I would appreciate help identifying the access-control layer returning ACCESS_DENIED, rather than making speculative permission or security changes.

Environment

• Physical Windows 11 Home PC, not a Windows VM.

Windows PowerShell 5.1, approved standard user, Medium integrity.

Previous Windows version: 25H2, build 26200.9457.

After a Microsoft-support-guided Windows installation: 26H2, build 26300.9457.

The VHDX and its protection configuration were created by our own local installation scripts.

Observed failure In a fresh standard-user PowerShell session, live storage identity checks passed. Creating a new directory on the enrolled volume succeeded, but creating a zero-byte file inside that directory failed:

$file = [System.IO.FileStream]::new( $path, 'CreateNew', 'Write', 'Read' )

The intended modes are FileMode.CreateNew, FileAccess.Write and FileShare.Read.

$path uses this format: ?\Volume{<volume-guid>}<data-directory><new-test-directory>\sample.bin

The exception is UnauthorizedAccessException / 0x80070005. The failure occurs during the FileStream constructor, before writing any content.

This has been reproduced under the tested conditions, including after the Windows installation. It does NOT establish that every application, API or path format fails.

Checks and observations

An elevated session checked the attached VHDX, backing-file identity, disk identity, partition GUID and volume binding.

The standard session separately checked its identity and live target-volume identity.

Support reported that the volume appeared healthy and was not read-only.

Directory ownership, inherited permissions and attributes showed no obvious restriction; directory DACL access calculations allowed relevant operations. These observations do not prove that every access right requested by FileStream, or every additional access-control layer, permits the operation.

In an earlier diagnostic, file creation still failed after releasing the tested group of binding/protection handles. This does not exclude every possible handle-related interaction.

Docker is installed, but the failure occurs in the Windows process before any Docker container starts.

Support observed these filters attached to the volume: QQSysMonX64, TFsFlt, UCPD, bfs, Wof, FileInfo and FsDepends. No filter has been identified as the cause.

Available event-log review did not identify the component responsible for the denial.

An earlier Process Monitor capture did not yield a confirmed corresponding failed file-create event or stack, so it cannot support driver attribution.

Current status The failed test objects and original logs have been preserved. During the latest support session, a system restore point was created, but support confirmed no intentional changes to permissions, security settings, drivers, services, disk configuration or the VHDX, and no repair was performed.

A controlled comparison of drive-letter versus volume-GUID paths has been proposed, using the same standard-user session and identical FileStream arguments. It has NOT yet been executed; there are no comparison results to report.

Question What targeted evidence would distinguish among:

Permissions inherited by the newly created file versus the full access requested by FileStream;

Volume-GUID path handling in Windows PowerShell 5.1 / .NET Framework;

Additional token or integrity restrictions;

File-system filter or security-component interception?

Please suggest a minimal next diagnostic and explain how its results would narrow the cause. We prefer read-only analysis first. Any reproduction would use explicitly scoped new objects, without overwriting or deleting existing objects or changing security configuration