dotnet dump analyze threadpool fails to obtain threadpool data

[omajid]

Description

I am running a preview version of .NET 9. The dotnet dump threadpool command fails to work:

$ dotnet dump analyze coredump
Loading core dump: coredump ...
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.
> threadpool
Failed to obtain ThreadPool data.

Configuration

• Is this related to a specific tool? Yes dotnet dump analyze
• What OS and version, and what distro if applicable? Fedora 40
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? It is not specific to this configuration. I was able to reproduce this on Fedora 39 + arm64, RHEL 9 + x64 and even RHEL 9 + arm64
• Are you running in any particular type of environment? I can reproduce on baremetal as well as within VMs.
• Is it a self-contained published application? No. This is reproducible on an application executed with: dotnet new web && dotnet build && dotnet /bin/Debug/net9.0/app.dll
• What's the output of dotnet info

  
  $ dotnet --info
  .NET SDK:
  Version:           9.0.100-preview.7.24368.1
  Commit:            e91a30b8aa
  Workload version:  9.0.100-preview.7.24368.1
  MSBuild version:   17.12.0-preview-24366-01+e91a30b8a

Runtime Environment: OS Name: fedora OS Version: 40 OS Platform: Linux RID: fedora.40-x64 Base Path: /home/omajid/temp/dotnet-sdk/sdk/9.0.100-preview.7.24368.1/

.NET workloads installed: Configured to use loose manifests when installing new manifests. There are no installed workloads to display.

Host: Version: 9.0.0-preview.7.24366.18 Architecture: x64 Commit: static

.NET SDKs installed: 9.0.100-preview.7.24368.1 [/home/omajid/temp/dotnet-sdk/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 9.0.0-preview.7.24366.8 [/home/omajid/temp/dotnet-sdk/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 9.0.0-preview.7.24366.18 [/home/omajid/temp/dotnet-sdk/shared/Microsoft.NETCore.App]

Other architectures found: None

Environment variables: DOTNET_ROOT [/home/omajid/temp/dotnet-sdk/]

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

### Regression?

* Did this work in a previous build or release - either of the tool or of the .NET runtime being used? Yes. This works in .NET 8.

### Other information

* Please include any relevant stack traces or error messages. If possible please include text as text rather than images (so it shows up in searches).

$ dotnet tool uninstall -g dotnet-dump Tool 'dotnet-dump' (version '8.0.532401') was successfully uninstalled. $ dotnet tool update -g --prerelease dotnet-dump Tools directory '/home/omajid/.dotnet/tools' is not currently on the PATH environment variable. If you are using bash, you can add it to your profile by running the following command:

cat << \EOF >> ~/.bash_profile

Add .NET Core SDK tools

export PATH="$PATH:/home/omajid/.dotnet/tools" EOF

You can add it to the current session by running the following command:

export PATH="$PATH:/home/omajid/.dotnet/tools"

You can invoke the tool using the following command: dotnet-dump Tool 'dotnet-dump' (version '8.0.532401') was successfully installed. $ dotnet dump analyze coredump Loading core dump: coredump ... 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.

threadpool Failed to obtain ThreadPool data. exit

• If you have an idea where the problem might lie, let us know that here. Please include any pointers to code, relevant changes, or related issues you know of.
• Do you know of any workarounds?

[omajid]

FYI @tmds

[mikem8361]

@leculver, this may be in CLRMD because ClrRuntime.ThreadPool is null on both a .NET 9 and 8 dump. Hopefully you have time to look at.

[leculver]

I believe @kouvel might have more insights than me. Was anything changed in the threadpool that might need updating in ClrMD/SOS?

I can take a look if he isn't able to.

[tmds]

@kouvel have you had a chance to look into this issue?

[kouvel]

@leculver, this may be in CLRMD because ClrRuntime.ThreadPool is null on both a .NET 9 and 8 dump. Hopefully you have time to look at.

It's a bit surprising that the command would fail on a .NET 8 dump. I can't think of anything of consequence that would have changed in the thread pool to cause such a thing. I can take a first look.

[tmds]

It's a bit surprising that the command would fail on a .NET 8 dump. I can't think of anything of consequence that would have changed in the thread pool to cause such a thing. I can take a first look.

The issue we're seeing is only occurring with .NET 9.

The issue occurs when using dotnet-dump 8.0.532401 (latest on nuget.org) with a .NET 9 coredump.

[kouvel]

In a small test that just does the following:

        ThreadPool.QueueUserWorkItem(_ => { });
        Thread.Sleep(-1);

It looks like the read of the PortableThreadPool.ThreadPoolInstance static field is reporting null in clrmd here. The field is not null in the dumpclass output for PortableThreadPool. It doesn't look like anything has changed here from the thread pool side in .NET 9, not sure if something else changed. I'm seeing the same issue on Linux and Windows. @leculver, would you be able to take a look?

[tmds]

@leculver have you had a chance to look at this?

[leculver]

I am just back from vacation and currently I have pressing security work that takes priority. I will take a look when I can.

[leculver]

Ah, this is because we haven't added support for these new interfaces to ClrMD yet: https://github.com/dotnet/runtime/pull/100364.

I will take a look when the security work is done.

[leculver]

I have a fix for this. Should be in SOS early next week. See linked PR above.