Managed Debugging Assistants

[afr1983]

Are there plans to bring the MDAs (Managed Debugging Assistants) to .NET Core / .NET 5?

I just spent an awful lot of time trying to pinpoint an issue that could have been easily fixed by having MDAs.

For those who don't know, in .NET Framework these assistants are extra checks done (when enabled) by the runtime when dealing with unmanaged code. In my case, a .NET function was passed as a callback to a native function, however by the time the callback was called it has been garbage collected.

Since the project was targeting .NET 5, it results in an exception (System.ExecutionEngineException). Not being familiar with this exception, I went into a rabbit hole of trying to find what was happening, since a lot of different bad stuff can cause this exception to be thrown (for example, heap corruption due to unsafe code done wrong).

After exhausting a lot of dead-ends, I started trying different versions of .NET. It was only when I moved the source code to a different project targeting the .NET Framework (not Core), which I found the problem - - well, Visual Studio found the problem, as it popped a CallbackOnCollectedDelegate exception right on my face! From then on it was easy to found the culprit and fix it.

These checks must be valuable for whoever will deal with unmanaged code calls in any platform, not only on Windows. But I couldn't find any information on it being available on .NET Core - the documentation is under .NET Framework. https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/diagnosing-errors-with-managed-debugging-assistants

[carlossanlop]

@terrajobst @richlander @danmosemsft do you know who can answer this question?

[danmoseley]

@tommcdon can

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Are there plans to bring the MDAs (Managed Debugging Assistants) to .NET Core / .NET 5?

I just spent an awful lot of time trying to pinpoint an issue that could have been easily fixed by having MDAs.

For those who don't know, in .NET Framework these assistants are extra checks done (when enabled) by the runtime when dealing with unmanaged code. In my case, a .NET function was passed as a callback to a native function, however by the time the callback was called it has been garbage collected.

Since the project was targeting .NET 5, it results in an exception (System.ExecutionEngineException). Not being familiar with this exception, I went into a rabbit hole of trying to find what was happening, since a lot of different bad stuff can cause this exception to be thrown (for example, heap corruption due to unsafe code done wrong).

After exhausting a lot of dead-ends, I started trying different versions of .NET. It was only when I moved the source code to a different project targeting the .NET Framework (not Core), which I found the problem - - well, Visual Studio found the problem, as it popped a CallbackOnCollectedDelegate exception right on my face! From then on it was easy to found the culprit and fix it.

These checks must be valuable for whoever will deal with unmanaged code calls in any platform, not only on Windows. But I couldn't find any information on it being available on .NET Core - the documentation is under .NET Framework. https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/diagnosing-errors-with-managed-debugging-assistants

Author:	afr1983
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[tommcdon]

@afr1983 Thank you for the feedback. Our hope is that MDA's would not be needed and instead and instead provide useful information to the developer through exceptions. Would it be possible to share a test case demonstrating the issue where CallbackOnCollectedDelegate would have been useful? We would be interested in providing rich exception information that points to the source of the problem instead of throwing ExecutionEngineException's.

[reflectronic]

It seems like callbackOnCollectedDelegate specifically was addressed in 2.1: dotnet/coreclr#15809