this is part of qt5 application for yolo, but in s...

I’ll inspect the Qt5/YOLO project, identify the likely crash-prone paths, then add structured logging and top-level crash/error handling so affected PCs leave useful diagnostics instead of failing silently. I’ll keep changes conservative so they don’t alter normal behavior unless an error occurs.

I can already see one important limitation in the current design: C++ exceptions inside the detection thread are caught, but true access violations, driver faults, CUDA/TensorRT DLL crashes, and failures on other worker threads can still terminate the process without reaching those catch blocks. I’m tracing those boundaries now and adding diagnostics around them rather than only adding more try/catch.

I found a concrete crash bug: MainWindow::~MainWindow() calls delete ui; twice. That is a real double-free/heap-corruption defect and can appear “randomly” depending on the PC/runtime, especially during shutdown. I’ll fix that first, then add crash dumps/logging and harden the worker paths so the next failure gives a file with the failing component and exception code.

There’s a second PC-dependent risk in the camera code: the DirectShow FORMAT_VideoInfo2 buffer is validated using sizeof(VIDEOINFOHEADER) instead of sizeof(VIDEOINFOHEADER2). A driver returning a shorter/odd VideoInfo2 block could make the code read past the provided buffer. I’m correcting that validation too, because it matches the “works on some PCs/cameras, crashes on others” pattern.

The main hardening is now in place: normal C++/OpenCV failures are contained at the camera callback, detection loop, model load/inference, image save, and video-recording worker boundaries; hard Windows faults get an unhandled-exception record and minidump. I’m doing a final pass for Qt5/MSVC compatibility and shutdown/thread cleanup before packaging the modified source.

I found one more source-lifetime issue while reviewing shutdown: the XML QThread was parented to MainWindow and scheduled with deleteLater(), while MainWindow kept a raw pointer to it. I removed that self-delete path so the pointer can’t become dangling before the destructor. I also redacted the database password from the new persistent logs.

The camera path will also report a “silent stall” now: if the DirectShow callback throws or the stream stops delivering frames for several seconds, the worker won’t spin forever with a frozen UI—it will log the condition and surface an error dialog with the diagnostic-log path.

The source now passes a structural sanity check (balanced C++ delimiters), and I verified the two concrete memory/driver-format fixes are present: the UI is deleted once, and VideoInfo2 is parsed as VIDEOINFOHEADER2. I’m packaging the modified project with a short diagnostic guide and an optional main.cpp snippet so logging can start even earlier than MainWindow.

I modified the project to make crashes much easier to diagnose and fixed several real crash candidates.

The most important findings were:

• Real double-free: MainWindow::~MainWindow() called delete ui; twice. This can cause apparently random heap corruption, especially when closing the application.
• DirectShow driver-dependent bug: FORMAT_VideoInfo2 was being treated as VIDEOINFOHEADER instead of VIDEOINFOHEADER2. Different camera drivers/PCs can expose this differently, making it a strong candidate for machine-specific crashes.
• Removed a possible dangling xmlThread pointer caused by combining parent ownership with deleteLater().
• Added exception handling around the DirectShow frame callback, camera processing, OpenCV operations, YOLO inference, TensorRT loading, image saving, and video-recording worker.
• Added detection for a camera callback failure or 8 seconds with no camera frames, instead of silently freezing.
• Added detailed DirectShow HRESULT messages.
• Added CUDA diagnostics: GPU model, compute capability, VRAM, CUDA driver/runtime versions.
• Added TensorRT engine path/size/version and loading diagnostics.
• Added a persistent Qt log containing timestamps, process ID, thread ID, source file/line, warnings, errors, and existing qDebug() output.
• Added Windows unhandled-exception handling and .dmp minidump generation for things that normal C++ try/catch cannot catch, such as access violations.
• On the next startup after a hard crash, the application tells you a crash was detected and shows the diagnostics folder.
• Removed the database password from persistent log output.

The modified source is here:

Download the hardened Semen_V1 project

I also included documentation inside the archive. You can read it separately here:

Crash diagnostics guide

The diagnostic folder will be under Qt's local application-data directory and the application will show its exact path in error messages. The important files will be application.log, last_crash.txt, and, for a hard Windows crash, something like crash_20261003_115500_123_pid1234.dmp.

One limitation: the uploaded ZIP only contained this portion of the project—there was no .pro/CMake project, main.cpp, or the other referenced classes—so I could structurally validate the changes but could not perform a complete Qt/TensorRT build here. I included a MAIN_CPP_DIAGNOSTICS_SNIPPET.txt showing where to install the crash logger in main.cpp; doing that would also catch crashes that happen before MainWindow is constructed.

If one of the problematic PCs crashes with this build, send me its application.log, last_crash.txt, and .dmp file. With those, we should be able to narrow it down to camera driver/DirectShow, CUDA/TensorRT/GPU compatibility, OpenCV, or your application code.