CLRMD don't provide StackBase and StackLimit for full memory dumps

[koepalex]

Description

I have an application running in a linux container (debian-slim base image) and create a full memory dump of the process using either dotnet dump or procdump for linux. The application is running on .net 7.0.

This dump is downloaded to windows and analyzed with CLRMD (Microsoft.Diagnostics.Runtime) following the sample clrmd/clrstack.

For all threads the properties StackBase and StackLimit are always 0. So it is not possible to determine the size and stack objects.

I would expect that StackBase and StackLimit are available for all living threads, even if the dump from linux is analyzed under windows.

Configuration

What OS and version, and what distro if applicable?

• Container: mcr.microsoft.com/dotnet/runtime:7.0-bullseye-slim
• Windows PC: Win11 23H2 (OS Build 22631.2262)

What is the architecture (x64, x86, ARM, ARM64)?

• Container: x64
• Windows PC: x64

NuGet Package Version:

• 3.0.0-beta.23214.4

Regression?

I don't know

Other information

If I open the dump on windows in dotnet dump, I can switch to all living thread and run dump stack objects dso successfully.

[mikem8361]

The problem is the way CLRMD and SOS (dso) get the stack limits. On Windows the TEB is used and on Linux/MacOS there isn't any TEB like mechanism so it uses no limits (0/0xffffffff).

We can use this issue to track a better way to get the stack limits across all our platforms.