RuntimeMarshalManagedException is `handled:no` but didn't crash the app

[bruno-garcia]

Reported on Discord

[jamescrosswell]

This is a known limitation of RuntimeMarshalManagedException - there's no way for us to know whether the exception was handled or not as this information isn't present in the event args.

See this comment from the original PR where we introduced this event hook:

• Prevent Native EXC_BAD_ACCESS signal for NullRefrenceExceptions #3909 (comment)

[bruno-garcia]

so the best we can do is disable the integration?

or add a before send snippet so ppl can flip to handled?

if they handle, could they add something for Exception.Data so we know what to add to the final sentry exception?

[bruno-garcia]

I think we need something on the docs about this integration. GIve as much context to the user about it as we can.
How to turn it off DisableRuntimeMarshalManagedExceptionCapture() should also be added here: https://docs.sentry.io/platforms/dotnet/configuration/disable-integrations/

And a way to deal with the handled:no situation which I hope can be done by try/catch + ex.Data["Sentry:Handled"] = false on BeforeSend or something.

[jamescrosswell]

or add a before send snippet so ppl can flip to handled?
if they handle, could they add something for Exception.Data so we know what to add to the final sentry exception?

I don't actually know of a situation in which you'd receive one of these for a handled exception (I asked Ralph the same question a few months back and he couldn't think of any either).

If someone is doing a try catch, I'd recommend they do:

try {
    ...
}
catch (Exception e)
{
    SentrySdk.CaptureException(e);
}

If that doesn't prevent the exception that gets captured via RuntimeMarshalManagedException then yeah, the only thing people could do is disable the RuntimeMarshalManagedException integration (in which case they won't be aware of any unhandled exceptions on iOS - since this is the only way we have to detect these).

I think we need something on the docs about this integration.

👍🏻

[mlyrstad]

Hi, I am the person who asked the original question on your Discord. I am trying to figure out what to do here.

The false positives are very much getting in the way. We need Sentry to report actual crashes, otherwise it's just way too much of a workload to sort through what is and what isn't an actual problem, not to mention it hurts our statistics... in that the statistics simply isn't correct.

I am currently trying to figure out what we can do on our end to handle this problem. If we use the CaptureException above, won't this report the error anyway? Things that doesn't cause our users an issue is not interesting in terms of Sentry.

[jamescrosswell]

@mlyrstad you could implement a custom OnBeforeSend callback to try to detect the exceptions that you know have/will be handled and are being captured by the RuntimeMarshalManagedException handler.

You can see an example in the SDK internals where we do this to suppress exceptions that we know will be captured as managed exceptions.

You can easily wire up your own logic that will be processed before exceptions get sent to Sentry though.

• Using BeforeSend

So if there's anything obvious in the exception detail that you can use to identify the exceptions you want to filter out, you could do it here.