1

I have a C# WPF Application running on windows, which utilizes code written in c++ and compiled as dynamic libraries. We have c++-cli code segments for translating data between the C# GUI parts and the C++ engine parts. For unhandled exceptions in the C# part itself, we have added this following code segment:

static void Main(string[] args)
        {
            some code...
            AppDomain.CurrentDomain.UnhandledException += CurrentDomainOnUnhandledException;
            some code...
        }

private static void CurrentDomainOnUnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            Logger.Error(e.ExceptionObject.ToString());
        }

This works fine for exceptions thrown from the c++ code, also from the cli code, and of course for the c# code. What we are attempting now is to somehow (if it's possible) catch segfaults or other crashes coming from the c++\cli code? Obviously we can't wrap calls to c++\cli code with "try/catch" because it will not catch crashes of that sort.

Edited and added to explain better: I know segfaults and other system-crashes are bad and not something to cause. The thing is, our software is used by 200-something people in the organization who need to develop more code and are using the software to debug and perfect their code. As such, sometimes, their code will have those errors, and not all errors are captured fully by the other people and we are looking for a solution within the code itself to help maintain that, along with copying any errors.

I know it's not something we should "aspire" to, and if segfaults occur it's not good, but since our software is used by a couple hundreds of people across the organization, we must have a way to capture these crashes when they happen and the users reports it to us. At the moment, if such crash does happen, it will only generate the regular windows based pop-up box of the crash, and afterwards would simply close the application without any information about the crash logged.

Thanks for any kind of suggestion, and I apologize if there's a mistake in my question. If any clarification is needed, please let me know and I'll do my best to edit.

Edit #2: In the native version of our software (which is only a console program without any GUI element) we do have a solution that works. This solution works well in both Windows and Linux distributions of our software, and it is catching the signals and writing the stack trace to the logs before shutting down.

Mor Elmaliach
  • 101
  • 7
  • 2
    [Segmentation faults are beyond exceptions](https://stackoverflow.com/a/14900168/6717178) (+[more info](https://stackoverflow.com/questions/2346806/what-is-a-segmentation-fault)). The DLL is stopped hard by the OS and nothing is thrown. You are not going to be able to catch the exception in the external DLL. What you could do is catch the lost connection and reload the DLL. But actually: the DLL should be fixed... seg-fault is really bad... – JHBonarius Nov 19 '19 at 09:53
  • First of all, I appreciate your comment. The thing is, our application is also using quite a handful of dlls from other teams, they use our application to test-debug their dlls and make sure they work as intended. So part of that, is, well, the development itself. Sometimes some of the algorithms maybe behave badly, and end up crashing the system, and we must find a viable way to provide debugging capabilities for it. I hope this clears any follow-up questions on the matter. – Mor Elmaliach Nov 19 '19 at 11:06
  • That might be the way of working your company aspires, but you are limited by the way software works. Once the segmentation fault occurs, it's already too late. Exceptions have to be caught in the problematic dll. Your company should rethink their way to approach testing. Many examples of companies that have a working test framework can be found online. – JHBonarius Nov 19 '19 at 17:04
  • The commenter is not familiar with C++/CLI, try/catch does in fact work to catch an AccessViolationException thrown by native code. Not that this is a good idea, it just makes it harder to debug the cause. – Hans Passant Nov 19 '19 at 19:23
  • @JHBonarius thanks for the second comment. However, there is a distinction between exceptions and segfaults and core dumps, which are being dumped by the OS and not the code. We need a way to somehow catch those dumps (they appear with a nice "windows" pop up warning and then the OS terminates the application. We need somehow a way to log this before. Again, I mean the signals themselves sent by the OS, need to be captured on the application before the termination, if there's any way to do that. Of course it's not ideal or proper way to do stuff, but we need a solution for those cases. – Mor Elmaliach Nov 20 '19 at 08:05
  • @HansPassant Thank you for the comment as well. As I explained on the comment above yours, we need a way to capture the signals sent by the OS for things such as segfaults, before the application is terminated. – Mor Elmaliach Nov 20 '19 at 08:06
  • Hmm, no, you have not explained anything. An AVE should make the test fail. If you catch the exception then they'll have trouble finding the bug in their code. Or worse, assume it is a bug in your code instead of theirs. Don't do it. – Hans Passant Nov 20 '19 at 09:17

0 Answers0