0

I am currently using the Windows Error Reporting service that is built into the Windows OS. It falls short in quite a few areas including automating new builds being submitted for crash collection and analysis of the actual crashes.

I found a few options including Dr Dump and CrashRpt for C++ applications.

The most appealing option that I found though was HockeyApp. My team already uses HockeyApp for hosting mobile applications as well as builds of our desktop applications. Plus, it just seems more well-supported and feature-rich than other services. It seems to only support crash reports for .NET applications.

The application that I am trying to gather crash reports for is a mixed C++ and C# application though. I'm not sure if there is a crash reporting service out there that can handle both languages.

Without going into immense detail, my application is mostly .NET wrapped up in a native C++ application. I'm assuming that this means I need a service to support C++ crash reporting.

To summarize:

  1. If my applications is mostly .NET based, but wrapped up in a native C++ appliaction, do I need a crash reporting service that just supports C++ applications?
  2. Is there a crash reporting service that supports applications with mixed C++ and C# code?
Brett Lesnau
  • 208
  • 3
  • 8
  • .NET has support for C++, is your C++ app not a C++.NET app? If not, is there a reason why it couldn't be? I would think this would make this problem much easier for you to tackle. – Chris Thompson Oct 28 '17 at 03:39
  • It is a legacy application that has been based in MFC for about a couple of decades. We've slowly replaced much of the UI with C# / .NET / WPF, but the window that sort of encompasses everything and a lot of the underlying logic is still in C++. We do have some C++ CLI / C++ .NET code, but that is mostly just the interop glue that allows the C++ native code and the C# .NET code to talk to each other. – Brett Lesnau Oct 28 '17 at 04:35

1 Answers1

1

Those tools have a disadvantage: they use the Unhandled Exception Handling mechanism and live in your process. If your application gets corrupted, you can no longer rely on things to work. I had that case in VB6, where the VB6 runtime was destroyed and no unhandled exception handler could help me.

That's also why WER (Windows Error Reporting) exists. While your process is dying, Windows itself still works pretty fine. And perhaps you can benefit from its features, too: the WER LocalDumps Registry Key

Set this Registry key during the installation of your product and it will save crash dumps into a folder. When your application starts up next time, you can do with them whatever you want (maybe ask for the user's permission):

  • analyze the crash dump (e.g. using ClrMd) and send some exception details to you
  • shrink the crash dump and send the shrunken one to you. (Convert a full memory .NET dump into a small minidump)
  • upon request ask the user to send the full crash dump to you
  • don't forget some clean up

All in all I would say it's not hard to do. Might be a good project for students. Pro: you don't need to care about all that crash handling, pointer mangling etc., because WER does it for you. You can't really mess it up.

Oh, and when you build that, consider building it as a reusable component and make it open source on Github. I would need that, too. You can't get a patent any more, because with this post I will claim "prior art" :-)

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222