Silk.NET.OpenGLES.ANGLE.Native 2025.9.12 ships outdated Windows binaries containing a COM lifetime bug

Start with build/nuke/Native/Angle.cs and the Windows native files under src/Native/Silk.NET.OpenGLES.ANGLE.Native/runtimes/win-x86/native. Run the attached repro commands to confirm the STA registration failure, then verify the rebuilt package includes the upstream fix and records its native build revision. Done means the regression check passes and eglInitialize preserves the caller's COM registration.

FULL DISCLOSURE Codex tracked down this issue for me and wrote this bug report. The TLDR version of it is that the libGLESv2.dll that is shipped with the current version of Silk.NET.OpenGLES.ANGLE.Native is outdated (from 2022) and contains a COM lifetime bug which is causing failures in other unrelated COM components in my application. So this is a report/request to update to a newer libGLESv2.dll that contains the fix for the COM lifetime bug.

---

Silk.NET.OpenGLES.ANGLE.Native 2025.9.12 ships Windows binaries with an already-fixed COM lifetime bug

Summary

Calling eglInitialize() with the D3D11 backend on an existing STA thread removes the caller's COM apartment registration. EGL initialization succeeds, but subsequent STA-dependent operations, including WebView2 initialization, can fail with 0x800401F0 (CO_E_NOTINITIALIZED).

This reproduces with only Silk.NET.OpenGLES.ANGLE.Native 2025.9.12 and direct P/Invoke. The attached reproduction has no Silk.NET managed graphics bindings, windowing library, Skia, WebView2, payment SDK, or application dependencies.

The observed behavior matches an ANGLE bug fixed upstream in September 2022. The Windows x86 libGLESv2.dll in the current NuGet package is byte-for-byte identical to the file added to Silk.NET in March 2022. Please refresh the Windows ANGLE binaries to include the existing upstream fix.

Related Silk.NET tracking issue: #2024 - Re-enable ANGLE native builds.

Steps to reproduce

• Platform: Windows 11 Pro 25H2, build 26200.9457, 64-bit OS.
• Process: x86.
• Framework: .NET 10.0.12; project targets net10.0-windows.
• Package: Silk.NET.OpenGLES.ANGLE.Native 2025.9.12 (latest public version checked on 2026-09-21).
• API: EGL 1.5, ANGLE D3D11 backend.
• GPU: Intel UHD Graphics 770; driver 30.0.101.1371.
• DLL version: 2.1.0 git hash: unknown hash.

Install the .NET 10 SDK and .NET 10 x86 runtime. Extract the attached reproduction and run these commands from its root in PowerShell:

dotnet run --project .\repro\AngleComRepro.csproj
dotnet run --project .\repro\AngleComRepro.csproj -- --no-spy
dotnet run --project .\repro\AngleComRepro.csproj -- --no-angle

Silk.NET-ANGLE-COM-bug-report.zip

The project selects win-x86 explicitly. Each command starts a separate process.

1. Start on an [STAThread] entry point and verify the native apartment using CoGetApartmentType().
2. Obtain an ANGLE display with eglGetPlatformDisplay(EGL_PLATFORM_ANGLE_ANGLE, EGL_DEFAULT_DISPLAY, [EGL_PLATFORM_ANGLE_TYPE_ANGLE, EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE, EGL_NONE]).
3. Call eglInitialize().
4. Query the native apartment again. The default run also records IInitializeSpy callbacks without modifying initialization results or adding COM references.

Expected

The caller's existing STA registration and COM initialization reference count remain intact. An internal MTA initialization attempt may fail with RPC_E_CHANGED_MODE, but it must not be followed by a matching uninitialization because it acquired no reference.

Actual

eglInitialize() returns success, but the native apartment changes from APTTYPE_MAINSTA / APTTYPEQUALIFIER_NONE to APTTYPE_MTA / APTTYPEQUALIFIER_IMPLICIT_MTA. Managed Thread.GetApartmentState() continues to report STA.

Selected output from the attached angle-output.txt:

before ANGLE: native HRESULT=0x00000000; apartment=3; qualifier=0; managed=STA
after eglGetPlatformDisplay: native HRESULT=0x00000000; apartment=3; qualifier=0; managed=STA
eglInitialize=1; EGL=1.5
after eglInitialize: native HRESULT=0x00000000; apartment=1; qualifier=1; managed=STA
eglInitialize: PreInitialize flags=0x0; refs=1
eglInitialize: PostInitialize HRESULT=0x80010106; flags=0x0; refs=1
eglInitialize: PreUninitialize refs=1
eglInitialize: PostUninitialize refs=0
FAIL: eglInitialize removed the caller's STA registration.

0x80010106 is RPC_E_CHANGED_MODE. The failed MTA initialization leaves the count at 1, then an unmatched uninitialization decrements it to 0. The resulting implicit MTA does not represent a successful conversion of the caller to MTA.

Run	Result on the machine above
Default: ANGLE plus read-only COM observer	STA lost; exit 1
--no-spy: ANGLE without observer	Same STA loss; exit 1
--no-angle: observer without ANGLE	STA preserved; exit 0

Comments: source diagnosis and existing fix

The relevant native source is src/libANGLE/renderer/d3d/d3d11/converged/CompositorNativeWindow11.cpp, specifically rx::RoHelper. This is separate from Silk.NET's managed src/OpenGL/Silk.NET.OpenGLES bindings.

The historical D3D11 extension-discovery path calls CompositorNativeWindow11::IsSupportedWinRelease(), which creates a temporary RoHelper.

In the old implementation:

• The constructor requests RoInitialize(RO_INIT_MULTITHREADED).
• It sets mWinRtAvailable = true even when that returns RPC_E_CHANGED_MODE.
• The destructor tests mWinRtAvailable and calls RoUninitialize().
• Therefore, the failed attempt is incorrectly uninitialized, releasing the caller's existing COM registration.

The MTA request is part of a Windows Runtime/composition capability check. This does not establish a requirement to run the application's UI or EGL caller in MTA.

ANGLE already fixed this in 59f496c099be5f4799ec3e0e5fe651f54da2736c - Only close COM if it was initialized, committed 2022-09-21. The change adds mWinRtInitialized, sets it only when SUCCEEDED(result), and makes the destructor test that flag. S_FALSE remains a successful initialization and is still balanced correctly.

Upstream references: review 3906325, original bug angleproject:7675. The Microsoft RoInitialize contract specifies a matching uninitialization for successful calls, including S_FALSE.

Evidence that the Windows binary is stale

The installed x86 libGLESv2.dll has these identifiers:

Size: 5465600 bytes
Git blob SHA-1: d3be354b0e777b8018937ffcddf256979e9bb3f5
SHA-256: 77EC21F13ECE79F73E45D195A797DD350893C8D50A07BFCD3842FD5A9F73A57B

Its Git blob hash matches the same file at all three checked Silk.NET revisions:

• bdefe5503f51bb1174ee8c0981b5d0adbb357c81, introduced 2022-03-06, before the upstream fix.
• 94605142f7b7bd6e69c9201e8e721d245c69eb7e, the Silk.NET commit recorded in the package metadata.
• main, checked 2026-09-21.

The ANGLE build target enables macOS builds while the Windows build block is commented out. A newer package version therefore does not imply newer Windows binaries.

The NuGet metadata pairs the ANGLE repository URL with commit 94605142..., but that commit belongs to Silk.NET. The DLL itself reports an unknown git hash. The precise original ANGLE build revision cannot be proven from this metadata; the historical source and existing upstream fix above explain the independently observed reference-count failure.

Application impact and requested change

This was discovered when recreating a WebView2-based payment interface after a configuration update. Initial startup could succeed, while later WebView2 initialization failed with CO_E_NOTINITIALIZED after ANGLE initialization had consumed the UI thread's COM reference. The SDK wrapped that underlying exception as a missing-WebView2-runtime error.

Please publish updated Windows ANGLE binaries containing commit 59f496c... or later, record the actual native build revision, and add a regression check that EGL initialization on an STA thread preserves the caller's COM registration. This reproduction should pass after the binaries are replaced. A rebuilt ANGLE DLL has not been tested in this report; the existing upstream fix and packaged-binary defect have been identified independently.