Fix corrupted mini-dumps on Windows that VS can not load #13489
Comments
|
@mikem8361, can you help here? |
|
Ping @mikem8361 : ) In the meantime here are some things that may help: |
|
Thanks. Didn't investigate dotnet-dump so far. I am going to try the flags they use. |
|
You may not need all the flags that dotnet-dump collect uses. I need to look into it because windbg/cdb's |
|
I tried using the flags: But I keep getting a symbol error when trying to "Debug with mixed". Oddly, I don't get this when I generate with full memory. It seems like it's failing to retrieve
Could be an issue with VS, but it seems to be somehow related to the minidump flags. How come it successfully resolves symbols for fully memory dumps? Edit: Okay I narrowed down the issue a bit. For most flag combinations (except
|
|
I'm currently investigating this problem. Sorry for the delay. |
|
I think I’ve narrowed it down to the DAC’s (mscordaccore) memory enumeration API faulting. It may take me a while to figure out the root cause. The bad news if it is in the DAC the fix will have to go out in the next service release.
|
mikem8361
changed the title
pr8x
changed the title
|
I changed the title. It sounded like I fixed them 😄 |
|
Hey @mikem8361, did you figure out what is causing the issue? |
|
Yes. It is a both a fix in the runtime (DAC) and VS. We are hoping to get the runtime fix into 3.1.
|
Fix a function that was ifdef'ed needed for the metadata locator callbacks to work. Fix some not properly DAC'ized code in the type desc and server GC code. Caused an exception during dump generation. Issue: https://github.com/dotnet/coreclr/issues/26907
Fix a function that was ifdef'ed needed for the metadata locator callbacks to work. Fix some not properly DAC'ized code in the type desc and server GC code. Caused an exception during dump generation. Issue: https://github.com/dotnet/coreclr/issues/26907
|
That's great news! Do you have any tracking ticket for the Visual Studio update? |
|
Hi, Sorry for the bump, but do you happen to know if there's a release candidate for Visual Studio that fixes the issue? I am currently running VS2019 v16.3.7 and the problem still exists. I created a small repro here: https://github.com/pr8x/netcore31_bug_minidump |
|
It looks like the VS fixes are going into 16.5 preview 1. @chuckries can answer for sure. You will also need .NET Core 3.1 coming out in December for minidumps to work end-to-end. |
|
This issue is just waiting for @chuckries to confirm the VS version. |
|
Hey, sorry to revive this issue. But it seems like that with .NET Core 3.1 and Visual Studio 16.4.0 it is still crashing while generating the dump. This time it's a couple of
@chuckries Do you already know which version of VS is shipping the fixes? |
|
@pr8x it might be better to open a new issue with a link back to this closed one |
ghost
locked as resolved and limited conversation to collaborators
I am hosting a dotnet module inside my native C++ application and use google breakpad to generate minidumps. I noticed that only
MiniDumpWithFullMemoryseems to be useful for getting proper managed stacks. Some of these dumps can get quite big however. I was wondering if you guys have some clue on reducing the size a bit. Exporting "every readable page in the process" seems quite extreme.http://www.debuginfo.com/tools/clrdump.html claims to reduce the size of .NET dumps while maintaining relevant stack/thread information. It's not open-source AFAICT and seems to be targeting .NET Framework (not .NET Core!). Apparently he's using (according to https://stackoverflow.com/a/8258911/2354690):
They don't seem to work for me. Any ideas?
The text was updated successfully, but these errors were encountered: