Closed felixxu06 closed 2 years ago
@felixxu06 thanks for contacting us.
I've opened an issue in dotnet/diagnostics where they'll be better able to help you.
What is the complete version of the runtime you are targeting (the x in 3.1.x)? You have quite a few 3.1 versions installed.
What does sosstatus
display? Can you enable logging with logging enable
before running clrstack
?
Thanks.
@mikem8361 Hi Mike, Thanks for reaching out. Following is the information. Not quite sure why so many 3.1 versions installed. When I install VS 2019, I install one. I have manually installed one 3.1 SDK.
Following is the information printed in my console while enabling the log
PS C:\dumps> dotnet-dump analyze .\my.gcdump
Loading core dump: .\my.gcdump ...
Ready to process analysis commands. Type 'help' to list available commands or 'help [command]' to get detailed help on a command.
Type 'quit' or 'exit' to exit the session.
> logging enable
Logging is enabled
> sosstatus
Target OS: WINDOWS Architecture: X64 ProcessId: 16960 (0x4240)
Dump path: C:\dumps\my.gcdump
Directory: C:\dumps
Cache: C:\Users\felix.xu\AppData\Local\Temp\SymbolCache
Server: https://msdl.microsoft.com/download/symbols/
> clrstack
dotnet-dump Information: 0 : SOS initialized: sosPath 'C:\Users\felix.xu\.dotnet\tools\.store\dotnet-dump\6.0.257301\dotnet-dump\6.0.257301\tools\netcoreapp3.1\any\win-x64\sos.dll'
Failed to find runtime module (coreclr.dll or clr.dll or libcoreclr.so), 0x80004002
Extension commands need it in order to have something to do.
For more information see https://go.microsoft.com/fwlink/?linkid=2135652
dotnet-dump Error: 0 : SOS command FAILED 0x80004002
Point of clarification... @felixxu06 is trying to analyze a GC dump file with dotnet-dump
. @mikem8361 & @hoyosjs: is analyzing GC dumps actually supported by dotnet-dump
? I can't find a reference in the documentation that says this is supported: https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump
gcdumps (assuming they were collected with dotnet-gcdump) aren't analyzable with dotnet-dump. You can open it in PerfView or Visual Studio instead to analyze it.
Point of clarification... @felixxu06 is trying to analyze a GC dump file with
dotnet-dump
. @mikem8361 & @hoyosjs: is analyzing GC dumps actually supported bydotnet-dump
? I can't find a reference in the documentation that says this is supported: https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump
I collect this dump with dotnet-dump and try to analyze it with dotnet-dump. Does it make scense?
Point of clarification... @felixxu06 is trying to analyze a GC dump file with
dotnet-dump
. @mikem8361 & @hoyosjs: is analyzing GC dumps actually supported bydotnet-dump
? I can't find a reference in the documentation that says this is supported: https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dumpI collect this dump with dotnet-dump and try to analyze it with dotnet-dump. Does it make scense?
That statement in of itself does make sense. However, every single example you've cited thus far is trying to analyze a file called my.gcdump
, which is GC dump, not a memory dump.
Yeah, Jander. I am not quite sure about the differences between these two kinds of the dump. However, I just manually rename the dump's name with an extension. At the very beginning, there is no extension name, I still got the same error. I try this in WSL centOS 8 with only .net core 3.1 runtime and SDK. Everything goes well. So I am curious that the reason is multi-runtime and SDK. And how to correct it by specifying the SDK or runtime.
Could you run the modules
command in dotnet-dump? The error message usually means that it can't find the coreclr.dll module in the process (which is what the sosstatus
implies).
Are you still having this issue? We haven't heard from you about the modules
list. If you are still having issues and can provide the dump or more info please reopen this issue.
How about this question?
@jerviscui How about this question?
What question was that?
Hi @mikem8361 ,
I can run the modules
, and I get the result:
But I can't run dumpheap -stat
Failed to find runtime module (libcoreclr.so), 0x80004002
Extension commands need it in order to have something to do.
For more information see https://go.microsoft.com/fwlink/?linkid=2135652
dotnet-dump Error: 0 : SOS command FAILED 0x80004002
And run clrmodules
will get exception:
dotnet-dump Error: 0 : Microsoft.Diagnostics.DebugServices.DiagnosticsException: No CLR runtime set
at Microsoft.Diagnostics.ExtensionCommands.ClrModulesCommand.Invoke() in /_/src/Microsoft.Diagnostics.ExtensionCommands/ClrModulesCommand.cs:line 29
I use k8s and the pod yml:
containers:
- name: localservice-api-container
securityContext:
capabilities:
add:
- SYS_PTRACE
@jerviscui where do you get this runtime from? They rename images: /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.4/libcoreclr.so.dpkg-new
shouldn't have that dpkg-new
. The debugger doesn't see the runtime.
I also ran the application image in docker desktop and dotnet-dump works fine. Maybe there's something wrong with our k8s.
@hoyosjs Thanks very much, Let me check the k8s first.
Is there an existing issue for this?
Describe the bug
Expected Behavior
display the corresponding clrstack or dumpobj information in the console.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
.net core 3.1
Anything else?
No response