Describe the bug
On Windows x64, shutting down a Prism context that has used the ZDSR backend can intermittently crash the host process with an access violation.
Windows Error Reporting consistently records:
- Faulting module:
ZDSRAPI_x64.dll_unloaded
- Module version:
1.0.0.5
- Exception code:
0xc0000005
- Exception offset:
0x1d11
- Exception information:
0x8 (attempted execution)
The same signature was captured in separate runs with Prism 0.18.2.
To reproduce
This is timing-dependent and requires ZDSR to be installed and running, so I do not yet have a portable standalone reproduction.
The sequence in a .NET 9 WPF desktop client is:
- Initialize Prism with an availability callback.
- Create and initialize the ZDSR backend.
- Send output through the backend.
- Free the backend.
- Call
prism_shutdown while the application exits.
- Repeat process startup and shutdown.
With the official Prism 0.18.2 Windows x64 binary, an automated exit loop reproduced the crash in 3 of 5 runs. Each failing process exited with 0xc0000005, and Windows Error Reporting named ZDSRAPI_x64.dll_unloaded as the faulting module.
Expected behavior
prism_shutdown should release the Prism context and return without crashing the host process, including when a delay-loaded backend DLL has internal asynchronous work.
Prism version or commit hash
v0.18.2 / f237af6
Operating system(s) and/or CPU architecture(s)
Windows 11 x64, build 26220
Affected backend(s)
ZDSR (ZDSRAPI_x64.dll 1.0.0.5)
Compiler and version
N/A for the failing official prebuilt binary. The workaround was verified with MSVC 19.51.36256.0.
Non-default build options
None for the failing official binary. Verification build used BUILD_SHARED_LIBS=ON, PRISM_ENABLE_SHIMS=ON, and PRISM_ENABLE_LEGACY_BACKENDS=ON.
Additional context
In prism_shutdown, Prism deletes the context and then calls __FUnloadDelayLoadedDLL2 for both ZDSRAPI.dll and ZDSRAPI_x64.dll. The crash signature indicates that code was subsequently executed from the unloaded module.
As a diagnostic workaround, I rebuilt v0.18.2 after removing only those two ZDSR unload calls. Prism still frees the backend, context, and availability enumerator normally; the ZDSR module remains loaded until Windows terminates the process.
Results with that build:
- 25 consecutive Debug exits succeeded.
- 5 consecutive Release exits succeeded.
- Every exit code was 0.
- Exit time was approximately 0.6–0.75 seconds.
- No new Windows Error Reporting crash was recorded.
Other delay-loaded backend cleanup was left unchanged. A Prism test cannot reproduce this in CI without the proprietary ZDSR installation, but the application-level exit loop is deterministic and bounded once that backend is available.
An AI coding assistant helped analyze the crash records and draft this report. The reporter remains responsible for reproducing the behavior and verifying the technical details above.
Confirmation/verification
Describe the bug
On Windows x64, shutting down a Prism context that has used the ZDSR backend can intermittently crash the host process with an access violation.
Windows Error Reporting consistently records:
ZDSRAPI_x64.dll_unloaded1.0.0.50xc00000050x1d110x8(attempted execution)The same signature was captured in separate runs with Prism 0.18.2.
To reproduce
This is timing-dependent and requires ZDSR to be installed and running, so I do not yet have a portable standalone reproduction.
The sequence in a .NET 9 WPF desktop client is:
prism_shutdownwhile the application exits.With the official Prism 0.18.2 Windows x64 binary, an automated exit loop reproduced the crash in 3 of 5 runs. Each failing process exited with
0xc0000005, and Windows Error Reporting namedZDSRAPI_x64.dll_unloadedas the faulting module.Expected behavior
prism_shutdown should release the Prism context and return without crashing the host process, including when a delay-loaded backend DLL has internal asynchronous work.
Prism version or commit hash
v0.18.2 / f237af6
Operating system(s) and/or CPU architecture(s)
Windows 11 x64, build 26220
Affected backend(s)
ZDSR (ZDSRAPI_x64.dll 1.0.0.5)
Compiler and version
N/A for the failing official prebuilt binary. The workaround was verified with MSVC 19.51.36256.0.
Non-default build options
None for the failing official binary. Verification build used BUILD_SHARED_LIBS=ON, PRISM_ENABLE_SHIMS=ON, and PRISM_ENABLE_LEGACY_BACKENDS=ON.
Additional context
In
prism_shutdown, Prism deletes the context and then calls__FUnloadDelayLoadedDLL2for bothZDSRAPI.dllandZDSRAPI_x64.dll. The crash signature indicates that code was subsequently executed from the unloaded module.As a diagnostic workaround, I rebuilt v0.18.2 after removing only those two ZDSR unload calls. Prism still frees the backend, context, and availability enumerator normally; the ZDSR module remains loaded until Windows terminates the process.
Results with that build:
Other delay-loaded backend cleanup was left unchanged. A Prism test cannot reproduce this in CI without the proprietary ZDSR installation, but the application-level exit loop is deterministic and bounded once that backend is available.
An AI coding assistant helped analyze the crash records and draft this report. The reporter remains responsible for reproducing the behavior and verifying the technical details above.
Confirmation/verification