Differences between .dlls in NuGet and Python versions of DirectML provider

[Levy Barbosa (Levyks)]

I'm trying to write a C++ application that uses the DirectML Execution Provider, I was using the onnxruntime.dll and onnxruntime_providers_shared.dll from the NuGet C# package Microsoft.ML.OnnxRuntime.DirectML and everything worked fine for the first 2 models I tried to run, but later, when trying to run a YOLO one, it didn't ran on DML, only in CUDA or CPU.

After a lot of debugging, I tried running it on python and everything worked fine, out of curiosity, I tried copying the python dlls from Python313\Lib\site-packages\onnxruntime\capi to my own C++ project, and voala, it worked!

I noticed that the Python version has 1 extra dll, DirectML.dll, that the C# one does not.

Also, Python's onnxruntime.dll has 19-ish KB, while the one from C# has 16-ish KB

What's the reason for this difference? Shouldn't both packages just be thin wrappers around the same lib?

The error I was getting was

←[1;31m2025-05-26 17:36:02.1363987 [E:onnxruntime:, inference_session.cc:2281 onnxruntime::InferenceSession::Initialize:
:<lambda_5767435f92a738c7a221df2e7c461c0f>::operator ()] Exception during initialization: D:\a\_work\1\s\onnxruntime\cor
e\providers\dml\DmlExecutionProvider\src\AbiCustomRegistry.cpp(519)\onnxruntime.dll!00007FFDB396E372: (caller: 00007FFDB
38DDB99) Exception(3) tid(7150) 80070057 ParFailed to create segmenter: Exception during initialization: D:\a\_work\1\s\
onnxruntime\core\providers\dml\DmlExecutionProvider\src\AbiCustomRegistry.cpp(519)\onnxruntime.dll!00007FFDB396E372: (ca
ller: 00007FFDB38DDB99) Exception(3) tid(7150) 80070057 Incorrect parameter.

[Advait Kawale (Advait251206)]

The Python and NuGet packages are not necessarily identical deployment bundles, even when they contain the same ONNX Runtime version. They can package the runtime and execution-provider dependencies differently.

The key clue is DirectML.dll. The Python wheel’s Windows packaging explicitly includes DirectML.dll, while the DirectML execution provider also relies on this separate library to execute GPU work.

That means copying the Python package’s DLLs into your C++ application may have fixed the issue because it supplied a missing DirectML runtime dependency—or because it replaced one or more binaries with a different version. It does not by itself establish that the NuGet onnxruntime.dll was defective.

I would check these points before settling on the cause:

1. Keep the binaries from one matching ONNX Runtime release. Avoid mixing onnxruntime.dll, onnxruntime_providers_shared.dll, and provider binaries from different package versions.
2. Check how DirectML is supplied by your NuGet package. The DirectML runtime is a separate dependency; ensure the appropriate DirectML.dll is deployed beside the application executable, using a compatible version. ONNX Runtime’s build documentation shows that the Python packaging step copies this dependency into the Python package directory.
3. Confirm the provider is actually available in the C++ process, and inspect the session’s provider configuration. Having a provider DLL present is not the same as proving that the model’s nodes were assigned to it.
4. Treat the YOLO initialization error separately from provider availability. The message ParFailed to create segmenter and 0x80070057 (Incorrect parameter) suggests a failure during initialization, but the excerpt alone does not identify whether it comes from an unsupported graph/operator, an input or model configuration, or a dependency/version mismatch.

For a useful comparison, please share the exact versions of:

• Microsoft.ML.OnnxRuntime.DirectML NuGet package
• Python onnxruntime-directml package
• DirectML.dll from each package (file version, if available)
• The YOLO model’s opset and input dimensions

Also, test with a clean deployment directory containing only the DLLs from one package plus its documented dependencies. That will help distinguish a missing dependency from an accidental DLL-version mismatch.

If this answer helped or pointed you in the right direction, I'd appreciate it if you could mark it as the accepted answer so it's easier for others with the same issue to find.

Also, if you found my contribution useful, I'd appreciate it if you could check out my GitHub profile, follow me, and star any repositories you find interesting.

GitHub: https://github.com/Advait251206

[jinwoo (dev-jinwoohong)]

The DLL is supplied by a second NuGet package: Microsoft.AI.DirectML. For example, Microsoft.ML.OnnxRuntime.DirectML 1.22.0 declares a dependency on DirectML 1.15.4 or newer, including for native C++ projects.

Inside DirectML 1.15.4, the x64 runtime is bin/x64-win/DirectML.dll. Its MSBuild targets copy the matching runtime to the output directory. If you manually extract only the ONNX Runtime package's DLLs, you bypass that dependency deployment. Check the dependency version required by your actual ORT package and deploy its matching-architecture DLL alongside your executable.

One useful check is the loaded DLL's path in Visual Studio's Modules window. Windows also includes DirectML, so an absent app-local copy does not necessarily mean no DirectML was loaded. Comparing the loaded path and version before and after adding the redistributable would help isolate this without replacing onnxruntime.dll at the same time. The YOLO error alone does not establish which difference caused the failure.