Normally it's the other way around

 More from the department of bogus C++ behavior.

The problem of repeated crashes

Postmortem app crash reporting and analysis is a bit of a hobbyhorse for me. I see it as an extension of the bug reporting facility - a crash in production (typically, but not always) indicates a bug. But does every crash indicate a separate, distinct bug?

Can your ALM do that?

Support for runtime crash reporting and analysis should be a part of the Application Lifecycle Management (ALM).

Now, my exposure to the ALM landscape out there is limited. TFS/AzDevOps - I know it inside and out. Github (including the corporate edition) - moderate experience. GoCD, TeamCity, Jenkins - I have an idea what do they do.

You can try or you can __try

Some time ago, I've outlined a technique for wrapping a C++ fragment in a Structured Exception Handling (SEH) crash catcher. It involved a rather convoluted sequence of C++ to C back to C++ calls.

Your software WILL crash.

When reporting on unhandled .NET exceptions, don't use the builtin Exception.StackTrace. Instead, construct an instance of System.Diagnostics.StackTrace with the exception object as the parameter, and generate your own trace. The difference is, with the latter, you can get offset to the crash point within the method.

Geeky...

Those unfamiliar with the C/C++ programming language need not read any further.

So there's this legacy application, at least 12 years old, that we're trying to slightly modify and release a new version. The process involves migration from an old version of the Microsoft C compiler to the most recent one, the one that comes with Visual Studio 2005.