VitisAI EP (VAIML): access violation (0xC0000005) kills the host during InferenceSession creation — Silero VAD and Sortformer, Ryzen AI 9 365, EP 1.8.68.0

[jkkma]

Two public ONNX speech models reproducibly take the host process down with an access violation
(0xC0000005) during InferenceSession creation on the Vitis AI EP. One of them is Silero VAD,
which is 2.2 MiB and about as widely deployed as an ONNX graph gets, so the repro is cheap.

This is not a caught error — no exception reaches managed code, no CPU fallback happens, and the
process exits 139. An application cannot log it or degrade around it.

Environment

CPU	AMD Ryzen AI 9 365 w/ Radeon 880M (Strix Point)
NPU driver	32.0.20102.3930 (2026-05-06)
XRT	2.21.0, hash 15e6319be8de1e76a6150111a3861729e988fdb5, 2026-05-07
NPU firmware	1.1.2.64
OS	Windows 11 Home 25H2, build 26200.8873
EP	VitisAIExecutionProvider, package MicrosoftCorporationII.WinML.AMD.NPU.EP.1.8 1.8.68.0
EP acquisition	Windows ML — ExecutionProviderCatalog.GetDefault() → EnsureReadyAsync(). The Ryzen AI SDK is not installed.
ONNX Runtime	1.23.x as supplied by Windows ML; the EP device reports ep.version 1.23.2
AI Engine Compiler	RAI 1.8, build b69afd0, 2026-06-05, target aie2p

The hardware and the EP are otherwise healthy

Establishing this first, because it rules out a broken install:

• xrt-smi validate passes all three tests: latency 68.0 µs, throughput 60,837 op/s, GEMM 51.3 TOPS.
• Synthetic ONNX graphs compile through VAIML and execute on the array — xrt-smi examine --report aie-partitions shows the process holding a hardware context across all 8 columns with
  9,538 completed submissions and 0 errors.
• A static MatMul and a small Conv/Relu stack both compile and run correctly.

Repro 1 — Silero VAD

Model: silero_vad.onnx, 2.2 MiB, the standard published graph
(https://github.com/snakers4/silero-vad). Inputs input [1, N] float32, state [2, 1, 128] float32,
sr [1] int64.

Creating an InferenceSession with the Vitis AI EP appended crashes. Last log lines before the
fault:

WARNING: Logging before InitGoogleLogging() is written to STDERR
I... register_dynamicdispatch.cpp:49] Running DynamicDispatchOpRegister::register_ops
I... register_castavx.cpp:48] Running CastAvxOpRegister::register_ops
Exception Code: 0xC0000005
 #0 0x00007fff9db31576 (...\ExecutionProvider\vaiml.dll+0x921576)
 #1 0x00007fff9f136f36 (...\ExecutionProvider\vaiml.dll+0x1f26f36)
 #2 0x00007fff9f136d52 (...\ExecutionProvider\vaiml.dll+0x1f26d52)
 #3 0x00007fffa0886734 (...\ExecutionProvider\vaiml.dll+0x3676734)
 #4 0x00007fff9d5a1d05 (...\ExecutionProvider\vaiml.dll+0x391d05)
 ...
#28 0x00007ff85038e957 (C:\WINDOWS\System32\KERNEL32.DLL+0x2e957)
#29 0x00007ff85252ad6c (C:\WINDOWS\SYSTEM32\ntdll.dll+0xaad6c)

Process exit code 139. The full 30-frame stack is all vaiml.dll offsets and can be attached if
useful.

Note the graph contains an If around an RNN — If_0_then_branch__Inline_0__/decoder/rnn/Squeeze
is a node name in it. AMD's MIGraphX EP fails on the same model differently, with a clean parse
error naming that node, rather than crashing.

Repro 2 — NVIDIA Streaming Sortformer diarizer

Model: NVIDIA Streaming Sortformer 4spk v2.1 exported to ONNX, 452.6 MiB. Same EP, same crash code,
faulting one frame higher:

Fatal error.
0xC0000005
   at Microsoft.ML.OnnxRuntime.InferenceSession.Init(System.String,
      Microsoft.ML.OnnxRuntime.SessionOptions,
      Microsoft.ML.OnnxRuntime.PrePackedWeightsContainer)

This graph carries an explicit state tensor in and out across chunks and has no If/Loop.

Minimal C# repro

using Microsoft.ML.OnnxRuntime;
using Microsoft.Windows.AI.MachineLearning;

var catalog = ExecutionProviderCatalog.GetDefault();
await catalog.EnsureAndRegisterCertifiedAsync();

var env = OrtEnv.Instance();
var dev = env.GetEpDevices().First(d => d.EpName == "VitisAIExecutionProvider");

var opts = new SessionOptions();
opts.AppendExecutionProvider(env, new[] { dev }, new Dictionary<string, string>());

// crashes here — 0xC0000005, process exits 139
using var session = new InferenceSession(@"silero_vad.onnx", opts);

net10.0-windows10.0.26100.0, Microsoft.WindowsAppSDK 1.8.250916003, with
<WindowsPackageType>None</WindowsPackageType> set so the bootstrapper initialises.

What I would expect instead

Either compile the graph, or decline it and let ONNX Runtime place those nodes on the CPU — which is
what the EP does cleanly for every other unsupported construct I tested. In a matrix of eight
minimal graphs covering LSTM, GRU, If, Loop, carried state and control flow wrapping
recurrence, none crashed; each was either compiled or declined, and the declines were recorded
properly in graph_partition_trace.csv. So the crash is not simply "unsupported operator" — the
decline path exists and works.

Not a duplicate of

• Ryzen AI 1.8 Whisper Medium encoder compile does not finish and cached graph times out on Ryzen AI 9 365` #392 (Whisper Medium encoder, same 9 365 part) — that is a compile that never finishes plus a
  cached-graph timeout, ERT_CMD_STATE_TIMEOUT. This is an immediate access violation.
• [VAIML Runtime Bug] xir_deserialize_cif crash (0xC0000005) after successful AIE compilation — PP-DocLayoutV3 on Ryzen AI MAX+ 395 (STX) #378 (xir_deserialize_cif, PP-DocLayoutV3, MAX+ 395) — that faults after a successful AIE
  compilation. These two fault before any compile output is produced.

Happy to attach full logs, the preliminary-vaiml-pass-summary.txt / graph_partition_trace.csv
from the cache, or a trimmed repro project if that helps.

[jkkma]

Narrowed the Silero one using the artefacts the EP itself leaves in
C:\temp\<user>\vaip\.cache\<key>\. Both crashed runs left partial cache directories, and they died
at different depths, which suggests these are two separate bugs rather than one.

Silero VAD — dies on the top-level If

The cache directory for that run contains original_graph_nodes.json, graph_nodes.json,
tensor_shape.json, gops.csv and a vaiml_partition_fe.flexml/0/ directory — but no
preliminary-vaiml-pass-summary.txt, no graph_partition_trace.csv and no cache/. So it got
through op counting and then faulted.

gops.csv, complete contents:

Node,OPs,Note
Equal_0,2
If_0,0

The whole model is two nodes at the top level: Equal_0 compares the sr int64 scalar input
against a constant (the 8 kHz / 16 kHz switch), and If_0 holds the entire network in its branches.
VAIML counted ops on If_0 — recording 0 — and the access violation follows.

Sortformer — dies earlier, and has no If at all

Its cache directory contains only original_graph_nodes.json (1.1 MB, first node
/pre_encoder//conv/Unsqueeze, input chunk [1, 3048, 128]). No gops.csv, so it faulted before
op counting finished. That graph is a convolutional/transformer stack carrying an explicit state
tensor and contains no control flow, so whatever kills it is not the If path above.

What does not reproduce it

I tried to reduce the Silero case to a minimal graph and failed, which seems worth reporting
since it narrows where to look. All of these build and run cleanly on the EP — no crash:

graph	shape
if_int64cond	Equal(int64 scalar input, const) → If, trivial MatMul branches
if_bigbranch	float-derived condition → If, branches containing 4 × (MatMul → Relu)
if_silero	both together — int64 scalar condition and substantial branches

So it is not simply "an If whose condition comes from an int64 scalar input", nor "an If with a
lot inside it", nor the two combined. Something else about Silero's branch contents is required.
Earlier minimal graphs containing LSTM, GRU, If-around-LSTM and Loop-around-LSTM were all
declined cleanly and recorded properly in graph_partition_trace.csv, so the decline path works for
the obvious candidates.

Happy to attach the two partial cache directories if that is useful — the Silero one is 14 KB.

[jkkma]

Bisected the Silero graph by stubbing If branches — replacing a branch body with constants of the
declared output type and leaving everything else intact. This surfaced a second, more informative
failure mode with an assertion in your own source, and narrowed the fault to a subtree.

The assertion

Stubbing some branches turns the access violation into this, which looks like the same underlying
defect caught by a check rather than corrupting:

Warning: Failed to import output type for
         'If_0_else_branch__Inline_0__/decoder/rnn/If_4_output_0',
         using (potential inferred) type of node connected to result instead.
Warning: Failed to import output type for
         'If_0_else_branch__Inline_0__/decoder/rnn/If_4_output_1',
         using (potential inferred) type of node connected to result instead.

Assertion failed: (existingDims.size() == inferredDims.size()) &&
  "Inferred shape and existing shape are inconsistent in the number of elements",
  file G:\vitis_flexml\third-party\onnx-mlir\src\Dialect\ONNX\ONNXOps\ShapeHelper.cpp, line 87

Exception Code: 0xC000001D

The sequence reads as: the importer cannot recover the declared output type of a nested If, falls
back to an inferred type, and the two then disagree on rank at the point ShapeHelper compares
them. In the unmodified model the same disagreement appears to go unchecked and lands as
0xC0000005 instead.

If_4 here has two outputs, each produced by a further nested If.

Where it lives

Silero's top level is Equal_0 → If_0, and If_0's two branches are the 16 kHz and 8 kHz paths —
113 nodes each, 24 nested subgraphs each, structurally symmetric.

what was stubbed	result
If_0.else_branch only	still crashes (0xC0000005)
If_0.then_branch only	still crashes (0xC0000005)
both top-level branches	builds cleanly
then_branch + decoder/rnn/If.{then,else}	0xC0000005
then_branch + decoder/rnn/If_1.{then,else}	0xC0000005
then_branch + decoder/rnn/If_4.{then,else}	the ShapeHelper assertion above

So either path alone reproduces it — consistent with one defect hit twice rather than two — and the
fault is inside the decoder/rnn subtree, which is the LSTM and the nest of Ifs around it.

What still does not reproduce it synthetically

Worth recording because it rules things out. All of these build and run cleanly on the EP:

tried	result
If with an Equal(int64 scalar input, const) condition	builds
If with substantial branch bodies (4 × MatMul→Relu)	builds
both together	builds
If nested 2, 3, 4 and 5 deep, conditions computed per level	builds
If with two outputs	builds
If with two outputs, each produced by a nested If	builds
bare LSTM, bare GRU, If-around-LSTM, Loop-around-LSTM	declined cleanly, recorded in graph_partition_trace.csv

So it is not depth, not multi-output, not the int64 condition, not branch size, and not the presence
of an LSTM — individually. Something about the combination in decoder/rnn is required, and the
ShapeHelper assertion is the most direct lead: whatever makes the importer fail to recover
If_4's output types is likely the root.

I can attach the stubbed models that produce each row above if they would help — the one that trips
the assertion is under 1 MB.