Calling into Native Code is not supported in the context

[LostTime76]

Description

Sort of related to a few other issues I have created, this one deals with native code being called while debugging in general. I am using a debuggertypeproxy for the debug views. The proxies call into native code. In the example I show below, I have a few public properties defined on the proxy which show in the debug view. Those properties ultimately call native code and the evaluation fails.

I have blacked out a lot of the picture due to sensitive information. This is a general inquiry and bug report as this is not the only instance I have seen this behavior in. Whenever a debugged object seems to call into native code, evaluation fails.

Environment data

dotnet / vscode latest
omnisharp 1.25.1

OmniSharp log

Steps to reproduce

One thing to note is that I have I am not using DLLImport for the native method calls. I am using the NativeLibrary API to create function pointers to the native methods in the form: delegate* <x,y,z> NativeFunc. The function pointers are then executed as such: z = NativeFunc(x, y). I am not 100% sure, but fairly certain evaluation still fails with DllImport instead. Regardless, I need to use the function pointer mechanism for the native interaction, because I need to reload those pointers multiple times during runtime.

Expected behavior

Evaluation works

Actual behavior

Evaluation fails

Additional context

[333fred]

This isn't really an O# issue, it's something the debugger doesn't support. @gregg-miskelly, not sure where to forward this to?

[gregg-miskelly]

I think I would need more information in order to comment. "Evaluation of native methods in this context is not supported" errors come about because the debugger is in a scenario where it cannot execute real func-evals (force a real function to execute), so it falls back to interpreting IL. It's possible that your scenario is one where we are incorrectly interpreting when we don't need to be. It is probably more likely that this is "by design" because we really can't func eval. But I would need more information.

[LostTime76]

Can you explain what you mean by "real function"? Just to see what would happen, I replaced the native call in the code with a function pointer that does not call into the native method, but a managed method. I get the same result of "xxx calls into native code, context unsupported". I then went into Dot Peek to check out the IL. It seems like there is an issue with the calli instruction in the debugger. Are you saying that in this case, the function pointer represents a "real function" and the debugger is having an issue calling that function through the calli instruction?

Here is another oddity. The code in question here is part of a larger project; however, if I make a simple test with a top level main file (like my other tickets) show casing the bare minimum same scenario with that function pointer that calls into something like user32.dll - GetCursorPos, the debugger has no issue evaluating it. Yet its using a function pointer call the same way...

[LostTime76]

Woops.. Trying to create the bare minimum example reveals a different issue. I know for a fact that I can twiddle the code around and get the debugger to show that Point struct properly with the native call, because I have done it. I will just have to remember how I did it..

Anyways, this is a bare minimum example that reveals yet another issue I have run into. The debug view fails silently. Instead of an exception somewhere in the view, it just doesn't show any of the fields. Would be nice to have a Debug.WriteLine somewhere when exceptions are thrown internally so we can see when it fails in the debug console.

You can comment / uncomment the native call (GetPos) in the view constructor and see the view fail / not fail.
tst.zip

[LostTime76]

Ah! There it is. Change struct Foo to class Foo OR readonly struct foo. No clue why, but now it magically works fine.

Likewise if I change my object in the original issue to class OR readonly struct instead of struct, now it works.

Debugger doesn't like regular structs

[ni-erikcrank]

I also have this problem. For example, this conditional breakpoint expression reports an error because it calls a native method: System.IO.Directory.GetCurrentDirectory() == "". This is just a simple example, but in my real-world use cases, I would like to be able to use conditional breakpoints to detect error conditions in hardware devices and to do that, the .NET methods need to call native methods.

This limitation exists in Visual Studio 2022 also and I upvoted an similar issue on the developer community. I am using .NET framework 4.6.2 because it is required by some third-party dependencies.