{"id":230811,"date":"2020-10-08T09:30:14","date_gmt":"2020-10-08T16:30:14","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/visualstudio\/?p=230811"},"modified":"2020-10-13T10:58:23","modified_gmt":"2020-10-13T17:58:23","slug":"linux-managed-memory-dump-debugging","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/linux-managed-memory-dump-debugging\/","title":{"rendered":"Cross Platform Managed Memory Dump Debugging"},"content":{"rendered":"

I am really happy to announce that with the release of Visual Studio 16.8 Preview 3 you now have the ability to open and analyze managed dumps collected on Linux and use the best in class debugging tools available in Visual Studio.<\/strong><\/p>\n

Over the year\u2019s Windows developer have grown accustomed to a broad variety of tools to help diagnose issues occurring with apps and services running on remote Windows machines. More recently we have empowered our developer community with the tools to develop and deploy apps across multiple platforms including many of the popular Linux distros.<\/p>\n

Collecting and analyzing memory dumps remains a popular deep diagnostics technique, however, one of the primary limitations with cross platform memory analysis is that process dumps were not provided in a portable format. For example, it was not possible to directly diagnose a memory dump collected on Linux with the popular tools available on Windows.<\/p>\n

Cross Platform Collection<\/h3>\n

Analyzing dumps is one of the most commonly used techniques to debug issues on remote machines, this is especially true when you do not have immediate access to your production environment. Developers will use a dump file from a machine when they can’t reproduce a crash or unresponsive program state on their own machine.<\/p>\n

Here are some of my favorite tools for collecting dumps on Linux.<\/p>\n

createdump<\/h5>\n

The createdump<\/a> utility is an efficient mechanism for collecting memory dumps and can be run from the command line on any .NET Core processes.<\/p>\n

sudo createdump <pid> --full<\/code><\/p>\n

dotnet-dump<\/h5>\n

The dotnet-dump<\/a> is global CLI tool (currently requires the .NET SDK) that provides a convenient way to collect Linux dumps even without a native debugger involved like lldb on Linux.<\/p>\n

dotnet-dump collect -process-id <PID> -type Full<\/code><\/p>\n

dotnet-monitor<\/h5>\n

We also have the ability to capture a variety of diagnostics artifacts including dumps and traces and quickly egress them to any other environment using dotnet-monitor<\/a>.<\/p>\n

dotnet-monitor<\/strong> is an experimental tool currently available as a .NET Core global tool and as a container image via the Microsoft Container Registry (MCR)<\/a>. The setup instructions for dotnet-monitor vary based on the target environment and platform, check out this post for more details.<\/a><\/p>\n

Opening the Linux Core dump in Visual Studio<\/h3>\n

Memory dumps created on Windows machines have well known extension (*.dmp) and thus have a straightforward association with your favorite memory analysis tools. By default, core dumps produced on Linux machines are created without an extension.<\/p>\n

If your managed core dump doesn’t have an extension you can drag and drop the file into your IDE and Visual Studio will automatically identify and open it as a Linux core managed memory dump.<\/p>\n

However, if the file was renamed to include the Windows dump extension (*.dmp) then use Visual Studio\u2019s \u201cOpen with\u201d feature in the Open File dialogue box.<\/p>\n

\"Visual<\/p>\n

Select “Managed Linux Core Dump file summary”.<\/p>\n

\"Visual<\/p>\n

Linux Core Dump File Summary<\/h3>\n

The Managed Linux Core Dump File Summary<\/strong> window shows a summary and module information for the dump file, and a list of Actions<\/strong> you can take, this remains consistent with existing dump handling experiences in Visual Studio.<\/p>\n

\"Image<\/p>\n

From this window you can conveniently set your symbols paths, which allows you to point to program database (.pdb) files, also called symbol files. The .pdb file holds debugging and project information, and the Visual Studio debugger will use .pdb files to determine the source file name and line number. This makes it easier to determine the exact line of code being executed when the memory dump was taken.<\/p>\n

To start debugging, you can select Debug with Managed Only<\/strong> from the Actions<\/strong> section of the summary page and to start using the awesome debugging tools you have become accustomed to.<\/p>\n

You could, for example, start by reviewing the list of Threads or Tasks using the Parallel Stacks for Tasks<\/a> window. Or dig a bit deeper by examining the most interesting frames from Calls Stacks <\/strong>view. That might also lead you to examine the value and state of variables using the Locals<\/strong> or Autos<\/strong> window. Essentially you get to examine every detail of the process just as if you set a breakpoint on your Linux box.<\/p>\n

Please note the following limitations in our preview:<\/p>\n