dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.7k stars 1.06k forks source link

SOS DLL is missing in .NET Core for Windows #4903

Closed Raviuppa closed 4 years ago

Raviuppa commented 8 years ago

When you install .NET Core on Windows, the SOS file which is a key binary to debug any coreclr issues is missing from the installation folder. It does ship with Linux and OSX repositories but NOT with Windows.

Not having this binary on Windows makes it difficult to debug the apps especially when the issue is around .NET Core. Please address this ASAP.

Another thing noticed is, when you do a “dotnet run” on Linux or OSX, the output folder will have appname.dll, appname.exe, sos.so/dylib and other files. Where as on Windows, the output folder will have all but sos binary.

blackdwarf commented 8 years ago

/cc @Sridhar-MS @gkhanna79

gkhanna79 commented 8 years ago

This needs to be part of .net core ask package and not runtime package.

@blackdwarf is there such sdk?

blackdwarf commented 8 years ago

@gkhanna79 have no idea. Do we then move this then to dotnet/coreclr?

TheRealPiotrP commented 8 years ago

@Petermarcu seems this should go into one of the SDK installers. Who can provide guidance?

ellismg commented 8 years ago

Is this the same as dotnet/sdk#4827?

Raviuppa commented 8 years ago

@ellismg , Yes, seems like the same issue.

gkhanna79 commented 8 years ago

Does SOS from the tools folder not suffice @Raviuppa ?

ellismg commented 8 years ago

@gkhanna79 When you run dotnet under the debugger and it loads coreclr.dll, there should be an SOS SxS with it, so that you can do .loadby sos coreclr in windbg. Looking at the MSI and ZIP today for windows that isn't the case for the runtime the dotnet commands themselves run on.

gkhanna79 commented 8 years ago

@ellismg Given that CoreCLR nuget package contains SOS, you can do ".load <path to SOS under tools folder". If you dont find them in the CLI MSI/ZIP, then we need to figure out why that is the case.

TheRealPiotrP commented 8 years ago

@gkhanna79 this is true, though not intuitive, on dev machines. It's a non-solution in production.

TheRealPiotrP commented 8 years ago

Also, CLI zip contents are in no way coupled to the runtime used by the app. If we had an SOS in the CLI zip, it would only be usable to debug the CLI and apps that happen to use the same runtime. If we gave folks guidance to use it to debug their apps we'd generally provide only confusion and angst.

If we want to debug apps produced by CLI, we need to have an easy path to correlate that app to its own SoS.dll. The only easy way I know to do this is by including sos with the runtime dependencies of the app.

gkhanna79 commented 8 years ago

We could package SOS netx to the runtime so thta ".loadby sos coreclr" will pick it up. However, your response above brings up another interesting question - what is the production debugging experience for CLI? Using SOS to debug managed app requires you to know fair bit of runtime internals - I have not seen folks outside the product team and CSS use SOS for common place production debugging. So, even if package it next to coreclr.dll, it will only help folks like @Raviuppa (who, at that point in time, also know how to load from tools) and not the managed code developers at large.

If we want to debug apps produced by CLI, we need to have an easy path to correlate that app to its own SoS.dll.

To confirm, is SOS (present in the runtime package under tools folder) not published to the app folder as part of "dotnet publish"?

TheRealPiotrP commented 8 years ago

sos.dll is now in the shared framework packages. Closing this issue.

HppZ commented 6 years ago

where is "shared framework packages" ? how to find specific version of sos.dll?

HppZ commented 6 years ago

I use Windbg to debug my UWP app(in Debug mode), lm command shows that coreclr is loaded from C:\Program Files\WindowsApps\Microsoft.NET.CoreRuntime.1.1_1.1.25305.1_x64__8wekyb3d8bbwe, but no sos.dll exist in this folder, and Windbg did not download it from MS symbol server automatically. so is there a way to download specific version of those debugging dlls? really need it.

Petermarcu commented 6 years ago

That runtime is for UWP apps and not for .NET Core Apps. @zamont can you give pointers on where to get SOS that matches the runtime shipped for UWP?

HppZ commented 6 years ago

@zamont I need your help, please.

alx9r commented 4 years ago

$Env:ProgramFiles\dotnet\shared\Microsoft.NETCore.App\3.1.4\SOS_README.md on this computer reads as follows:

SOS and other diagnostic tools now ship of band and work with any version of the .NET Core runtime.

SOS has moved to the diagnostics repo here: https://github.com/dotnet/diagnostics.git.

Instructions to install SOS: https://github.com/dotnet/diagnostics#installing-sos.

Invoking the following installed $Env:USERPROFILE\.dotnet\sos\sos.dll:

dotnet tool install -g dotnet-sos
dotnet-sos install

Invoking .load c:\users\username\.dotnet\sos\sos.dll in WinDBG then succeeded.