Python: onnxruntime-windowsml access violation in InferenceSession when a catalog EP (NvTensorRTRTX) is selected; same EP works under plain onnxruntime 1.30.0 #22

Activity

1. adrastogi commented on Sep 14, 2026

   

   adrastogi

   on Sep 14, 2026

   Collaborator

   More actions

   Thanks for reporting this. This is a bit of a sharp edge with the Python language machinery. The winrt-runtime package includes an older VC redist that is not compatible with the ones needed by the execution provider which is why you are seeing this crash. The samples in the main Windows App SDK repository have a workaround to this effect. https://github.com/microsoft/WindowsAppSDK-Samples/blob/0057c23a44157b4cc8a539d52282a3d1f3559de8/Samples/WindowsML/python/SqueezeNetPython/winml.py#L46-L55

   In the case of your sample program, you could do something like this near the top:

   import ctypes
   import os
   
   # Keep the handle alive for the application's lifetime.
   _msvcp140 = ctypes.WinDLL(
       os.path.join(os.environ["SystemRoot"], "System32", "MSVCP140.dll")
   )
   
   # rest of imports and program logic
   

   If you try something like this, are you able to get your sample working?
2. idocinthebox commented on Oct 3, 2026

   

   idocinthebox

   on Oct 3, 2026

   Author

   More actions

   Thanks adrastogi, that was it. Both workarounds fix the crash on every onnxruntime-windowsml build I tried.

   Results (same machine and SqueezeNet repro as above; the NVIDIA EP has since auto-updated to 2.30.49.0, Windows App Runtime 2.5.1 present):

   onnxruntime-windowsml	as filed	preload System32\MSVCP140.dll first	remove winrt\msvcp140.dll (the sample's _fix_winrt_runtime)
   1.25.2.202605110140	access violation	works	works
   1.28.0.202607272323	access violation	works	works
   1.30.0.202609102321	access violation	works	works

   "Works" = a session with NvTensorRTRTXExecutionProvider is created and the output matches the CPU EP (max abs diff 1.1e-4, same top-1). One process per run, python -X faulthandler.

   What the loaded modules show (EnumProcessModulesEx at each step of the repro):

   • winrt-runtime 3.2.1 ships site-packages\winrt\msvcp140.dll 14.29.30157.0; System32 has 14.50.35719.0.
   • onnxruntime-windowsml links the C++ runtime statically (its onnxruntime.dll and .pyd import no msvcp140.dll), so importing it first loads no msvcp140 at all. The first one into the process is winrt's 14.29, loaded by _winrt.pyd.
   • onnxruntime_providers_nv_tensorrt_rtx.dll and tensorrt_plugins.dll import msvcp140.dll dynamically, so they bind to the 14.29 copy already loaded. That is the MSVC 17.10 std::mutex break (VCRuntime incompatibility with older version in mutex code STL#4730), which needs msvcp140 >= 14.40.
   • This is also why the same EP worked under onnxruntime 1.30.0 and onnxruntime-directml 1.24.4: those link msvcp140 dynamically, so importing ORT first puts System32's 14.50 in the process before winrt loads.
   • With EP 2.30.49.0 the unpatched repro now crashes one step earlier than in my report: inside ort.register_execution_provider_library(...), before any session exists. Same cause.

   The workaround in your comment (preload) and the one in the linked sample lines (deleting the DLL from winrt-runtime) are different. Both work here. I'm going with the preload because it doesn't modify an installed package.

   It looks like the same root cause as pywinrt/pywinrt#139 (closed after the delete-the-DLL workaround). Since winrt-runtime 3.2.1 is still the current release and the maintainer prefers to keep a bundled copy, a 14.40+ copy there, or the preload in the Python bootstrap package or the Windows ML Python docs, would save the next person this crash.

   The original "Init provider bridge failed" note was unrelated: it goes away when an onnxruntime_providers_shared.dll is present in capi, and it never affected the result.

   Fine to close this from my side, or keep it open for the packaging fix, as you prefer.