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
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.
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.
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.
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 Parameters → Enable 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.
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
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.