readRawData() reliably crashes with an access violation (0xC0000005) — ClariusL15

[ilabenedetti]

Hi everyone,
I'm trying to get raw/RF data saving working through the Cast API in Python. I've run into a crash I can't get past, and I've done a fair amount of testing to narrow it down — hoping someone from the team can point me in the right direction.

Setup

• Probe: Clarius L15, research/raw data mode enabled on the account
• OS: Windows 11
• Python: 3.12 (64-bit)
• SDK build: cast.dll / pyclariuscast.pyd, built 2025-10-29 (checked via the PE header timestamp, since these binaries don't expose a version number through Windows file properties)
• I'm working from a modified version of the official pycaster.py sample

What's happening

requestRawData() works exactly as expected — after connecting and streaming for a few seconds, it consistently returns a correct byte count for the requested time range. But the very next call, readRawData(), crashes the whole Python process every time, with Windows exit code -1073741819 (0xC0000005 / STATUS_ACCESS_VIOLATION). This isn't a Python exception I can catch — it's a native crash inside the SDK itself.

What I've tried to rule out

I went through this pretty systematically because I wanted to be sure it wasn't something on my end before writing in:

• Data size: tested a ~20MB window (2s) and a ~5.6MB window (0.5s) — same crash both times
• Timing: called readRawData() immediately after requestRawData() returned, and after waiting 5 seconds — same crash both times
• LZO compression: tried both lzo=False and lzo=True — same crash both times
• Imaging state: tried with the probe actively streaming, and with imaging frozen right before the read — same crash both times

Running with python -u (unbuffered output) confirms the crash happens inside the readRawData() call itself, in every one of these scenarios — a print statement right before the call runs, but the one right after (on success) never gets reached.

One thing I noticed: the changelog mentions "Fixed: Raw data collection" in v12.2.2 and "Fixed Windows crashes" in v12.2.4, both from late 2024. My build is from October 2025, so this doesn't seem to be the same issue — maybe a regression, or something specific to the L15 (I saw issue #211 also involves RF data with an L15 probe, though the symptoms described there are a bit different from mine).

Where I'm stuck

I don't have visibility into the SDK internals, so I can't tell if this is a known limitation, something version-specific, or a genuine bug worth filing more formally. Has anyone on the team seen this before, or is there a recommended way to get raw data out reliably that I might be missing? I share my full test script and logs if that helps track it down.

crash_logs.txt

pycaster_rf.py

[clariusk]

Thanks for the thorough report — the elimination matrix you ran made this quick to root-cause, and it's a genuine bug in the Python binding. Nothing in your script is wrong.

What's happening: when readRawData() fails or times out internally, the binding's error handling raises the error while the Python GIL is released. The error can't be delivered in that state, so instead of a catchable Python exception you get a native access violation that kills the interpreter. That's why every variation you tested crashed identically: data size, LZO, freeze state, and delay all funnel into the same error path. The crash is the error handling, not the transfer itself.

What's triggering it in your case: the binding gives the bulk transfer a fixed 5-second internal wait. Your request succeeded (the ~20 MB package was prepared — the returned byte count proves the channel is healthy), but pulling a multi-megabyte tar from the probe, especially with live imaging still streaming on the same link, routinely takes longer than that. The timeout then fires and crashes the process. The C/C++ API doesn't have this wait (or the GIL involvement), which is why the issue is specific to the Python wheels.

Fix: this is now fixed in our mainline for the next SDK release — failures raise a catchable RuntimeError, and the read wait scales with the package size instead of being a flat 5 seconds. We also hardened a related memory-safety issue in the same path while we were in there.

Workaround on the current wheels: keep the requested window small enough that the transfer completes within 5 seconds — try --request-raw-seconds 0.1 (roughly 1 MB), ideally with imaging frozen before the read so the download has the link to itself. If that returns data cleanly, it confirms you're hitting the timeout and you can step the window up until you find your link's practical limit. It would help us if you could confirm that.

[ilabenedetti]

Tested the workaround: froze imaging before calling readRawData() (confirmed via the freezeFn callback, not just before the request), and dropped the window to ~0.1s. requestRawData() returned 1,443,328 bytes (~1.4MB) — about 4x smaller than the 5.6MB window that already crashed, with imaging already frozen. Should be well inside any 5s transfer budget.

Result: identical crash. No output after "about to call readRawData()", process terminated, $LASTEXITCODE = -1073741819 (0xC0000005), no file produced.

Crash dump (Report.wer) for this run:

• Faulting module: python312.dll 3.12.1150.1013
• Faulting application: python.exe 3.12.1150.1013
• Exception code: c0000005, offset 0x1a709
• cast.dll and pyclariuscast.pyd both loaded at crash time

Same fault offset in python312.dll across every crash in my original matrix too (20MB, 5.6MB, all LZO/timing/freeze combos) — one deterministic crash point, not random corruption.

The faulting module being python312.dll rather than cast.dll fits your explanation — raising a Python exception while the GIL isn't in the right state would crash inside the interpreter itself. What doesn't fit is the trigger: 1.4MB with imaging already frozen shouldn't be near a 5s timeout, but it fails identically to 20MB with live imaging. So readRawData() seems to be hitting its internal error path essentially every time in my environment, not only when the transfer genuinely runs long — the GIL bug looks right, but the trigger may not be transfer duration.

How can I proceed?

pycaster_rf_v2.py

Report_wer_1.txt

[clariusk]

we'll work on a fix for the next release. for now you should use the C++ version to bypass this