Cross Platform Managed Memory Dump Debugging

Mark Downie

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.

Over the year’s 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.

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.

Cross Platform Collection

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.

Here are some of my favorite tools for collecting dumps on Linux.


The createdump utility is an efficient mechanism for collecting memory dumps and can be run from the command line on any .NET Core processes.

sudo createdump <pid> --full


The dotnet-dump 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.

dotnet-dump collect -process-id <PID> -type Full


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.

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

Opening the Linux Core dump in Visual Studio

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.

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.

However, if the file was renamed to include the Windows dump extension (*.dmp) then use Visual Studio’s “Open with” feature in the Open File dialogue box.

Visual Studio Open Linux Dump file

Select “Managed Linux Core Dump file summary”.

Visual Studio Open with for Linux dump file

Linux Core Dump File Summary

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

Image Visual Studio Dump File Summary for Linux

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.

To start debugging, you can select Debug with Managed Only from the Actions section of the summary page and to start using the awesome debugging tools you have become accustomed to.

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

Please note the following limitations in our preview:

If you are interested in “Native Only” dump debugging for Linux systems for unmanaged C++ please check out the blog post here.

Try it out!

Debugging managed Linux core dumps on Windows has been difficult to accomplish until now, it might mean setting up another Linux environment that exactly mirrored production and then installing a set of tools for the analysis. Thankfully with the latest Visual Studio 2019 16.8 preview you can simply drag and drop a managed Linux core dump directly into your IDE and immediately start debugging.

Please reach out to us on the Developer Community to site to suggest and/or vote on features, help us prioritize what is most important to you!


Discussion is closed. Login to edit/delete existing comments.

  • Dean Jackson 0

    Let someone know that the purple “Visual Studio Roadmap” button on the “Release Version” tab at this page:

    does not work, it doesn’t take you to the roadmap. This is what happens when you don’t link the button to the actual page, but instead use some redirection service.

    • Mads KristensenMicrosoft employee 0

      Thanks for the heads up. It’s now fixed.

  • Michal Dobrodenka 0

    Looks like a very interesting feature!

    But doesn’t work here:
    VS2019 16.8.0 Preview 4.0
    Process on Linux, ARM32, selfcontained, NET5.0 RC2, Trimmed.

    “Managed information is not available for this minidump.

    The debugee memory space does not have the expected debugging export table.”

  • 彭伟 0

    Core dump need mscoredbi.dll?

    • Mark DownieMicrosoft employee 0

      Debugging managed core dumps is similar to other .NET debugging scenarios, Visual Studio finds and downloads the right versions of mscordaccore.dll and mscordbi.dll from the public Microsoft symbol server so it can understand the internal data structures of that particular build of the .NET runtime. You can find more information here: ,

      • 彭伟 0

        But visual studio not found(404) mscordbi.dll on Microsoft symbol server.

        • Mark DownieMicrosoft employee 0

          Is there an error message you are seeing?

          • 彭伟 0

            All right now

Feedback usabilla icon