[debugger] CORDBG_E_MISSING_METADATA error when inspecting EF Core classes in .Net 6

[jamesonweber]

Good afternoon dotnet runtime team!

Description

I am currently looking into a debugger error in our application when trying to inspect EF Core entities in Visual Studio and Rider. I was able to find the error code CORDBG_E_MISSING_METADATA in this repository, as well as this comment which seems to indicate something has gone wrong when fetching the metadata when debugging the EF class. I suspect it is a configuration issue with our project as when creating a new .Net 6 solution the issue does not happen, but I am not sure where to look for fixing it. This has only become an issue after updating our project from .Net 5 to .Net 6.

Please let me know if you have any insights into this error code and if there is any configuration I should validate is correct.

Here are some screen shots of the debugging window within Rider

Reproduction:

• Run the project using dotnet run
• In Rider or Visual Studio, Attach Debugger to Process
• Select the currently running .Net 6 process
• Inspect an EF Class variable with the debugger
• Receive the error Failed to get base type: The operation failed because the debugger could not get the metadata.

Environment details:

• Rider 2022.1.1, Visual Studio 2022 (Version 17.1.5)
• dotnet --version: 6.0.202
  • Note: this is the only version of dotnet installed on the machine
• Windows 10
• Intel 64 bit CPU

Project details I think might be relevant from the csproj file:

• Asp.Net Core application (<Project Sdk="Microsoft.NET.Sdk.Web">)
• <TargetFramework>net6.0</TargetFramework>
• <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.4">

Thank you in advance if any help / advice on the above error code!

[ghost]

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

Issue Details

---

Good afternoon dotnet runtime team!

Description

I am currently looking into a debugger error in our application when trying to inspect EF Core entities in Visual Studio and Rider. I was able to find the error code CORDBG_E_MISSING_METADATA in this repository, as well as this comment which seems to indicate something has gone wrong when fetching the metadata when debugging the EF class. I suspect it is a configuration issue with our project as when creating a new .Net 6 solution the issue does not happen, but I am not sure where to look for fixing it. This has only become an issue after updating our project from .Net 5 to .Net 6.

Please let me know if you have any insights into this error code and if there is any configuration I should validate is correct.

Here are some screen shots of the debugging window within Rider

Reproduction:

• Run the project using dotnet run
• In Rider or Visual Studio, Attach Debugger to Process
• Select the currently running .Net 6 process
• Inspect an EF Class variable with the debugger
• Receive the error Failed to get base type: The operation failed because the debugger could not get the metadata.

Environment details:

• Rider 2022.1.1, Visual Studio 2022 (Version 17.1.5)
• dotnet --version: 6.0.202
  • Note: this is the only version of dotnet installed on the machine
• Windows 10
• Intel 64 bit CPU

Project details I think might be relevant from the csproj file:

• Asp.Net Core application (<Project Sdk="Microsoft.NET.Sdk.Web">)
• <TargetFramework>net6.0</TargetFramework>
• <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.4">

Thank you in advance if any help / advice on the above error code!

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

[tommcdon]

Hello @jamesonweber! The CORDBG_E_MISSING_METADATA error can occur if we fail to extract the metadata for the module loaded into the debugger.

This has only become an issue after updating our project from .Net 5 to .Net 6... I suspect it is a configuration issue with our project as when creating a new .Net 6 solution the issue does not happen...

Would it be possible to reduce the repro down to a small test case that can shared a ZIP file? Also it might be useful to share a dump of the target process at the point of failure. I believe either a dump collected with Visual Studio or with task manager should be able to work in that scenario.
Feel free to open a Visual Studio feedback item and paste a link to it in this GH issue and share the dump. This should be possible to make the attachment non-public.

[jamesonweber]

@tommcdon thank you for the very quick response! I have opened a new issue with the dump file here: https://developercommunity.visualstudio.com/t/debugger-CORDBG_E_MISSING_METADATA-err/10035184?space=61&entry=problem

In it I noted that reducing our solution to a slimmed down version will require quite a bit of effort. Please let me know if it is needed with the dump file. If it is, I can discuss doing that with our team further, but we are hoping the dump file will be sufficient.

I would like to add that it looks like the debugger in visual studio is producing a different exception than rider that was not noticed in the original investigation (we just noticed the exception originally and not the type, sorry about that!). This is the stack trace when inspecting a variable from the debugger in visual studio:

myEfClassVariable
'myEfClassVariable' threw an exception of type 'System.IO.FileNotFoundException'
    Data: {System.Collections.ListDictionaryInternal}
    FileName: null
    FusionLog: null
    HResult: -2147024894
    HelpLink: null
    InnerException: null
    Message: "Cannot load assembly 'DynamicProxyGenAssembly2'."
    Source: "15f16a13bcf944549b51f22600b63f1b"

[davmason]

@jamesonweber based on your description, I strongly believe that the PR I just opened (#72315) will fix your issue. Would you be able to try your repro with a private runtime to confirm? I can give you instructions on how.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[jamesonweber]

@davmason That is great news! Sorry for the late reply, it's been a busy week.

Yup, I can try our project with the private runtime, but some instructions for how would be greatly appreciated.

[davmason]

@jamesonweber how to patch depends on how exactly you deploy your app and what runtime you can target. The actual patch is copying some files, but depending on how you publish and run you application it might vary a bit.

Are you able to retarget your app to the latest 7.0 preview? If so that makes it easier - I have private builds for Windows x86 and x64 here: https://github.com/davmason/runtime/releases/tag/7.0.0-rc1-debugger-metadata-fix. If you have to stay on 6 then I would have to make a special version of 6 with the fix.

To apply those, you would download the appropriate architecture and paste it over the existing binaries (be sure to make a backup of anything if you want to revert later). Assuming you are doing a framework dependent publish

• x64: overwrite the contents of C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.6.22324.4 with the contents from x64.zip
• x86/Any CPU: overwrite the contents of C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.6.22324.4 with the contents of x86.zip

You have to be administrator to copy and all dotnet processes using that runtime need to be stopped.

If you are publishing self contained then you would need to copy the contents of the appropriate architecture to your deployment folder, but otherwise it should be the same.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[ghost]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[jamesonweber]

I apologize in the delay testing this; it has been a very busy couple of weeks. I will look into testing the patch this week or next.

[jamesonweber]

@davmason I was able to sneak some testing time in today, and the results are that the patch appears to resolved the issue! 🎉

Before applying the patch:

After applying the patch:

Everything is evaluating as expected in the debugger now.

Thank you so much @davmason and @tommcdon for all the help on this, we really appreciate it. We can close this issue now from our perspective. I'll let you do that in case there are any loose ends you need to tie up.

[davmason]

Thanks for verifying, closing this issue

[slovely]

As this appears to be fairly straightforward change, is there any chance of getting this into a future .NET6 release, given that is the LTS version?

[tommcdon]

As this appears to be fairly straightforward change, is there any chance of getting this into a future .NET6 release, given that is the LTS version?

I will create a PR and send it for .NET 6 consideration