Attached is a minimal reproducer for the issue, written with the help of :bobowen for the AppContainer part. The brokered create file path only occurs within AppContainer processes, upon running into an ERROR_ACCESS_DENIED. It calls `RoInitialize`, `CoInitializeSecurity`, `RoUninitialize`. If this happens -- even on a different thread -- between a call to `CoInitializeEx` and a call to `CoInitializeSecurity`, then `CoInitializeSecurity` will fail with `RPC_E_TOO_LATE`. The brokered create file path in not present on Windows 10 22H2 (verified in `KernelBase.dll` version 10.0.19041.4842), so the issue detailed above should be specific to Windows 11. The symbols present in the `Windows.Storage.OneCore.dll` and/or imported by `KernelBase.dll` suggest that this behavior also exists for at least `CopyFileW`, `CreateDirectoryW`, `DeleteFileW`, `FindFirstFileExW`, `GetFileAttributesExW`, `MoveFileExW`, `RemoveDirectoryW`, `ReplaceFileW`, `SetFileAttributesW`, presumably with the same side effect. I'll write to Microsoft to let them know about this undesirable side effect.
Bug 1895174 Comment 33 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Attached is a minimal reproducer for the issue, written with the help of :bobowen for the AppContainer part. The brokered create file path only occurs within AppContainer processes, upon running into an ERROR_ACCESS_DENIED. It calls `RoInitialize`, `CoInitializeSecurity`, `RoUninitialize`. If this happens -- even on a different thread -- between a call to `CoInitializeEx` and a call to `CoInitializeSecurity`, then `CoInitializeSecurity` will fail with `RPC_E_TOO_LATE`. The brokered create file path in not present on Windows 10 22H2 (verified in `KernelBase.dll` version 10.0.19041.4842), so the issue detailed above should be specific to Windows 11. The symbols present in `Windows.Storage.OneCore.dll` and/or imported by `KernelBase.dll` suggest that this behavior also exists for at least `CopyFileW`, `CreateDirectoryW`, `DeleteFileW`, `FindFirstFileExW`, `GetFileAttributesExW`, `MoveFileExW`, `RemoveDirectoryW`, `ReplaceFileW`, `SetFileAttributesW`, presumably with the same side effect. I'll write to Microsoft to let them know about this undesirable side effect.
Attached is a minimal reproducer for the issue, written with the help of :bobowen for the AppContainer part. The brokered create file path only occurs within AppContainer processes, upon running into an `ERROR_ACCESS_DENIED`. It calls `RoInitialize`, `CoInitializeSecurity`, `RoUninitialize`. If this happens -- even on a different thread -- between a call to `CoInitializeEx` and a call to `CoInitializeSecurity`, then `CoInitializeSecurity` will fail with `RPC_E_TOO_LATE`. The brokered create file path in not present on Windows 10 22H2 (verified in `KernelBase.dll` version 10.0.19041.4842), so the issue detailed above should be specific to Windows 11. The symbols present in `Windows.Storage.OneCore.dll` and/or imported by `KernelBase.dll` suggest that this behavior also exists for at least `CopyFileW`, `CreateDirectoryW`, `DeleteFileW`, `FindFirstFileExW`, `GetFileAttributesExW`, `MoveFileExW`, `RemoveDirectoryW`, `ReplaceFileW`, `SetFileAttributesW`, presumably with the same side effect. I'll write to Microsoft to let them know about this undesirable side effect.
Attached is a minimal reproducer for the issue, written with the help of :bobowen for the AppContainer part. The brokered create file path only occurs within AppContainer processes, upon running into an `ERROR_ACCESS_DENIED`. It calls `RoInitialize`, `CoInitializeSecurity`, `RoUninitialize`. If this happens -- even on a different thread -- between a call to `CoInitializeEx` and a call to `CoInitializeSecurity`, then `CoInitializeSecurity` will fail with `RPC_E_TOO_LATE`. The brokered create file path in not present on Windows 10 22H2 (verified in `KernelBase.dll` version 10.0.19041.4842), so the issue detailed above should be specific to Windows 11. The symbols present in `Windows.Storage.OneCore.dll` and/or imported by `KernelBase.dll` suggest that this behavior also exists for at least `CopyFileW`, `CreateDirectoryW`, `DeleteFileW`, `FindFirstFileExW`, `GetFileAttributesExW`, `MoveFileExW`, `RemoveDirectoryW`, `ReplaceFileW`, `SetFileAttributesW`, presumably with the same side effect. I'll write to Microsoft to let them know about this undesirable side effect. Edit: For reference wrt the reproducer code, the output if the faulty code is present (e.g. on Windows 11 23H2) is the following: ``` handle: FFFFFFFFFFFFFFFF, last error: 00000005 CoInitializeSecurity result: 80010119 ``` I consider this output a bug and personally believe that the expected result should always be: ``` handle: FFFFFFFFFFFFFFFF, last error: 00000005 CoInitializeSecurity result: 0 ```