search

dotnet / diagnostics

This repository contains the source code for various .NET Core runtime diagnostic tools and documents.
MIT License
1.18k stars 355 forks source link

SOS Plugin for Visual Studio #1397

Open AaronRobinsonMSFT opened 4 years ago

AaronRobinsonMSFT commented 4 years ago

There should be an integration point between the SOS plugin and Visual Studio. The Concord API seems to have an extensive surface area that at first glance appears capable of supporting whatever SOS needs.

/cc @gregg-miskelly @noahfalk

ghost commented 4 years ago

Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.

jkotas commented 4 years ago

It used to work in immediate window: https://docs.microsoft.com/en-us/archive/blogs/vijaysk/sos-your-visual-studio

AaronRobinsonMSFT commented 4 years ago

@jkotas Yep. I remember that one. It was a long time ago and if memory serves there were changes in VS that broke the ability to load that. @gregg-miskelly would know for sure though.

It might be useful to provide an agnostic API that allows third parties to consume a library they can use to build up support. This library could be used to enable real runtime development on the debugger of your choice. Perhaps a lower level ICorDebug API?

noahfalk commented 4 years ago

@AaronRobinsonMSFT - Appreciate the feedback! We were literally discussing this topic earlier today (cc @mikem8361) so this is very timely. The VS team has also started shifting a bit more priority towards production diagnostic scenarios where SOS is more commonly used.

Do you have specific tasks that SOS would help you accomplish or commands that you want to use? Partly this helps us build the customer value case and partly it could influence technical choices whether we port individual commands to run on top of a new API or we try to build an adapter that runs all of the SOS commands implemented as-is.

AaronRobinsonMSFT commented 4 years ago

We were literally discussing this topic earlier today

@noahfalk W00t! Love hearing that.

I appreciate the production diagnostics focus and hope that my needs align, I believe they would be a small subset of a production diagnostic experience. I will sketch out my inner dev loop as it should illustrate my immediate needs.

I am going to purposefully ignore non-Windows platforms; this is something we should revisit after we solve the current UX issue.

Visual Studio is my main entry point for live debugging. The UX around native memory inspection, disassembly, manipulating break points, and user driven symbol loading is unparalleled in my experience. I have found no other tool that makes each of these complex enough for advanced use cases while at the same time accessible to a new user. SOS requires WinDBG which forces me into a rather degraded UX compared to my primary work flow. Note that I do use WinDBG in many cases and it is a valuable tool, especially in DMP debugging. Its live debugging experience is, in my opinion, several orders of magnitude less efficient than Visual Studio - this has nothing to do with any type of project as an entry point that isn't in my work flow.

Since I am typically developing on the runtime I use CHK/DBG builds of CoreCLR. Using these kind of builds I get much of the details desired from SOS hanging off of the internal data structures - names of types, methods, etc. This means that looking at a MethodTable or a MethodDesc in Visual Studio isn't hard and I can ascertain the context from the data structures themselves. I could write a natvis for improved visualization but it isn't needed and I don't believe would improve at the margin. However, when working with a retail build of CoreCLR or a customer DMP none of the aforementioned diagnostic fields are present; therefore, I need to spin up WinDBG to inspect data structures and decode them.

Occasionally WinDBG becomes such a chore to be efficient in that I open the DMP in both and use WinDBG when I want/need these runtime details. For a live debug session of a retail CoreCLR scenario I have relied on the embarrassingly inefficient action of debugging in Visual Studio and then saving ad-hoc DMP files and opening them in WinDBG as needed - this is still faster in some cases than WinDBG but especially faster than using WinDBGX.

I focus almost entirely on interop so am constantly at the margins of the runtime. This makes native debugging my primary interest and I only need some inspection details to help build up my mental model and confirm suspicions - my primary need for most debugger related features. I don't need the full SOS experience because the native debugging in Visual Studio provides what I need almost immediately.

That is my experience so here are the commands I pine for when reaching for WinDBG:

Nice to have but not needed:

Visual Studio debugging could also learn from WinDBG by doing the following:

gregg-miskelly commented 4 years ago

Aaron, in case you aren't aware --

History of SOS in Visual Studio: The problem with that feature was that, historically, sos was just a regular windbg extension. Windbg extensions have access to a huge and ever expanded API surface, and attempting to implement it all was impractical. So VS engineers would implement what we thought SOS needed, but the the next day a CLR developer would add some cool new SOS feature that used a new windbg API, so VS support would be broken. A few months later we would notice and fix it up again, but then the cycle would just repeat. We eventually gave up. This might be all different now that SOS runs in multiple debuggers.

AaronRobinsonMSFT commented 4 years ago

@gregg-miskelly Those two features a really nice. I was aware of the Dump CCW feature, the Dump Obj is also nice. Unfortunately, I may not be able to interop debugging (mixed mode) since we do have scenarios where .NET Framework is also loaded. I accept these scenarios are more niche so perhaps the above would work in most cases.

History of SOS in Visual Studio:

That is an unfortunate history - thanks for the clarity. I hope we could solve these compat issues and provide additional support during non-interop debugging that allows the inspection that would allow greater utility during runtime development.

danmoseley commented 4 years ago

Are all the functions of dumpheap including -stat and -strings etc possible in VS now? That was one of the reasons I most often dropped to SOS when I was doing that kind of work.

noahfalk commented 4 years ago

@AaronRobinsonMSFT - thanks for all the info : ) As we keep looking into this I'll definitely refer back to it as a reference. (Also I totally relate to dual using windbg and VS just so I can get SOS command outputs)

@danmosemsft - I think all of the basic functionality of enumerating and counting objects by type is present in Visual Studio's memory diagnostics, but probably not the string specific functionality. Thanks for the feedback!