Windows Application Error 0xc0000005 in 3D Object Tracking

In a built Unity application (and also reproducible in editor) running a very lightly modified version of the 3D Object Detection demo, I seem to be regularly getting a full-crash which takes out all visual apps and the Desktop Window Manager process after 90-150 minutes. The Windows Application Log of the Event Viewer shows

Faulting application name: ZEDCamera.exe, version: 2022.3.38.54695, time stamp: 0x668dacd1
Faulting module name: sl_ai64.dll, version: 0.0.0.0, time stamp: 0x660d81ad
Exception code: 0xc0000005
Fault offset: 0x00000000006c9874
Faulting process id: 0x6834
Faulting application start time: 0x01db09ffaf9b4d8b
Faulting application path: D:\[redacted]\ZEDCamera.exe
Faulting module path: C:\Program Files (x86)\ZED SDK\bin\sl_ai64.dll
Report Id: 965601f4-64db-4f32-a90b-273f55c55a69
Faulting package full name: 
Faulting package-relative application ID: 

which seems to be a file access violation in one of the libraries. I’m trying to build an experience which will need to have 8-12 hours of uptime at a stretch. Any idea what might be going on? CPU, GPU, RAm and VRAM loads all appear to be well within system capacity.

Hi,

Thanks for the feedback.

I’ll run some tests on my side to see if I can reproduce your crash.

Did you notice if the crash is happening in a specific situation or parameters?

Best,

The good news is that on a clean system, it doesn’t appear to manifest. Because the crash is so disruptive, I’ve been avoiding running extended tests on my dev system ever since I found a clean deployment system seemed stable.
The last time I did really dig into the windows application logs looking for contributing factors, it appeared possible that my antivirus (Bitdefender) might have been sniffing that particular library file moments before the crash. But that could easily be a red herring, since I would expect dlls to already be loaded into RAM by 90 minutes in.

Thanks for the report!

I’ll still run extensive test and hopefully I can reproduce the issue.

Getting our experience loaded out onto reasonably clean Dell laptops with mobile RTX 4060 GPUs, and I’m back to seeing the issue intermittently. Always a 0xc0000005, frequently in sl_ai64.dll, sometimes after 16+ hours, sometimes after <2 hours, possibly correlated to total body throughput (the most problematic systems are pointed at more people / more activity), with a slight bias towards more problems on the laptops running Windows 11 Pro 26100.1742 (24H2) over the laptops running Windows 11 Pro 22631.4249 (23H2).

I am also noticing that the Unity process seems to creep consistently towards 9.5-10GB of memory, even though this is theoretically a pretty minimal demo. Just for sheer footprint, that might increase the odds of an access violation. Even a build of the vanilla Object Tracking demo as provided seems to grow its footprint by about 10MB/second, and a trial run of the Unity memory profiler shows that is predominantly in the Untracked category, which appears to be the dll/plugin bucket.

I am also noticing that the Unity process seems to creep consistently towards 9.5-10GB of memory, even though this is theoretically a pretty minimal demo. Just for sheer footprint, that might increase the odds of an access violation. Even a build of the vanilla Object Tracking demo as provided seems to grow its footprint by about 10MB/second, and a trial run of the Unity memory profiler shows that is predominantly in the Untracked category, which appears to be the dll/plugin bucket.

[Discourse post]

gonna pin this other thread here.

Digging into the issue from the memory side, it appears this is still an ongoing thing, and fortunately (for me), 3D Object Tracking does not require the Tracking ParametersEnable Tracking option to be enabled. With it off, the app no longer grows indefinitely. Going to drop new builds on our test boxes and see if we get longer & more stable runtime.

Hi,

Thanks for the extensive report.

Can I ask you what version of the SDK/plugin you are using please?

Best regards,

I can’t find it quickly within the project, but from the residual installers on my system, it’s probably ZED_SDK_Windows_cuda12.1_v4.1.0 and whatever Unity starter project was contemporary to that release.
Edit: Rather, it’s definitely that SDK, since that’s what I put on the laptops as well, but I can’t precisely identify the Unity plugin

I’m asking this because I pushed a fix for a memory leak some time ago (this commit : fix memory leak, remove obselete parameter · stereolabs/zed-unity@d142e4a · GitHub).

It might be worth trying to use a more recent version to see if you still have the memory leak.

Unfortunately, this was such a fast turnaround project that we had to use the stack we’d been developing/customizing on. We literally shipped the hardware out this morning.