3

I have this code (using CLRMD) currently to attempt to get the stacktrace:

var pid = Process.GetCurrentProcess().Id;
using (var dataTarget = DataTarget.AttachToProcess(pid, 5000, AttachFlag.Passive))
    {
        ClrInfo currentRuntime = dataTarget.ClrVersions[0];
        var runtime = currentRuntime.CreateRuntime();

        Debug.Print("Stack Traces:");
        foreach (var t in runtime.Threads)
        {
            if (t.ManagedThreadId == 1)
            {
                foreach(var f in t.EnumerateStackTrace())
                {
                    Debug.Print(f.Method?.GetFullSignature());
                }
            }
        }
        Debug.Print("");
    }

And it prints out this:

System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame)
System.Windows.Application.RunDispatcher(System.Object)
System.Windows.Application.RunInternal(System.Windows.Window)
System.Windows.Application.Run(System.Windows.Window)
System.Windows.Application.Run()
App.App.Main(System.String[])

But when I open up the threads tab under debugging in Visual Studio, I see a much more descriptive Location tab that has this:

App.exe!App.ViewModels.SomethingSomethingViewModel.SomethingHandler
App.exe!App.ViewModels.SomethingSomethingParentViewModel.SomethingCommandHandler() Line 110
App.exe!App.Utilities.AsyncRelayCommand.ExecuteAsync(object parameter) Line 55...

How do I get the stacktrace with location tab information? Visual studio shows it perfectly, but I can't seem to find out how to access that through code so I can send it up as a log...

mattyb
  • 1,011
  • 2
  • 10
  • 26
Thomas
  • 555
  • 7
  • 29
  • 3
    That looks accurate to me, just the main thread of a WPF app that is waiting for a notification. The VS debugger has the great advantage of being able to show the current thread at the breakpoint location with all threads frozen. What you get from ClrMD is going to be quite random since these threads are busy executing code and you have no expectation that they are located anywhere in particular. Unless they are blocking, like the main thread is doing. Maybe this feature isn't as useful as you hoped for. – Hans Passant Jan 07 '19 at 23:39
  • You could try to do an `AttachFlag.Invasive`, which should "act like a debugger" and gives you more control over the target process (see [Attaching to a live process](https://github.com/Microsoft/dotnet-samples/blob/master/Microsoft.Diagnostics.Runtime/CLRMD/docs/GettingStarted.md); make sure you understand the caveats though). For a "causal" monitoring / diagnostics tool I would assume, however, that `Passive` still makes a lot more sense, since you don't want to affect the target process. – Christian.K Jan 08 '19 at 08:42

0 Answers0