How to collect a dump on a specific crashed or hanged process

In case you face Rider crash or hanging JetBrains.ReSharper.Host64.exe backend process, the only way to diagnose the reason is to analyse dump files. There are several ways for collecting them depending on a case and on the Operating System.

Windows

ReSharper.Host process has crashed

ReSharper.Host process is hanging

Files to download

Unix-based Operating systems (Linux, macOS)

macOS

Linux

ReSharper.Host process has crashed

In case you see a report that a critical failure has occurred this means that the Rider backend process named JetBrains.ReSharper.Host64.exe has crashed.

Screenshot_2020-12-22_at_01.41.01.png

To diagnose this problem a full process dump of a crash is needed. To collect it do the following:

  1. Download files attached to this article;
  2. Run the attached enable_dumps file. This will add registry settings that collect dumps on Rider backend crash.
  3. Create a folder at C:\JetDumps
  4. Reproduce the crash
  5. Locate the dump. It will be located in the C:\JetDumps folder. It could take a bit of time for it to appear after the crash, up to a minute I'd say. You can check your Task Manager for the "Windows Error Reporting" process - if there is one and it's active, it means that the dump is still being produced.
  6. Run the attached disable_dumps file. It will remove registry settings added on step one.
  7. (Optional) Compress the dump into a zip, 7z, or another kind of archive. Dumps are typically large and typically highly compressible.
  8. Share this dump file with the Rider team for analysis with some way described here.

ReSharper.Host process is hanging

In case you face the issue when Rider backend process JetBrains.ReSharper.Host64.exe is hanging, the Windows Error Reporting system cannot help in collecting dumps. To capture it do the following:

  1. Open Windows Task Manager (Ctrl + Shift + Esc shortcut);
  2. In the “Application” tab or “Processes” tab find the hung process, right-click on it and select "Create dump" to write a full dump of this process.
    Screenshot_2020-12-22_at_01.52.22.png
    Dump files created by Task Manager are usually written to the TEMP directory of the current user who is running Task Manager "C:\Users\<username>\AppData\Local\Temp\".  Also, Task Manager displays the dump file name and location once the dump has been written.
    Screenshot_2020-12-22_at_01.54.33.png
  3. Share this dump file with the Rider team for analysis with some way described here.

Unix-based Operating systems

In case of catching Rider backend crash on Linux or macOS, process crash dump can be collected with LLDB debugger and SOS plugin. LLDB is packaged in most of the Debian & Ubuntu releases and in pkgsrc (NetBSD). On macOS LLDB is installed along with Xcode Command Line Tools. The SOS plugin is bundled in Rider’s lib directory:

- [RiderInstallationDirectory]/lib/ReSharperHost/linux-x64/dotnet/sos/libsosplugin.so on Linux

- [RiderInstallationDirectory]/lib/ReSharperHost/macos-x64/dotnet/sos/libsosplugin.dylib on MacOS

To find [RiderInstallationDirectory] use menu `Help | Diagnostic Tools | Special Files and Folders` and double-click on “Installation home directory”.

How to collect a crash dump:

  1. Check the process PID of JetBrains.ReSharper.Host.exe in the Activity Monitor on Mac or with the following bash command: `ps aux | grep -i dotnet`;
  2. Attach LLDB debugger to the running dotnet process with `lldb -p PID`;
    Screenshot_2020-12-22_at_02.15.21.png
  3. Load the SOS plugin "(lldb) plugin load <path_to_sos_plugin>"

    Example:

    (lldb) plugin load `/home/user/.local/share/JetBrains/Toolbox/apps/Rider/ch-0/201.6668.197/lib/ReSharperHost/linux-x64/dotnet/sos/libsosplugin.so`
  4. Load debug symbols from Microsoft and JetBrains symbol servers via running the following three lldb commands:
    (lldb) setsymbolserver https://msdl.microsoft.com/download/symbols
    (lldb) setsymbolserver https://resources.jetbrains.com/pdb
    (lldb) loadsymbols
    Screenshot_2020-12-22_at_02.20.30.png
  5. Continue with `(lldb) c` and reproduce the crash;
  6. After Rider’s ReSharper host crashes, use `clrstack -all` to see the call stack;Screenshot_2020-12-22_at_02.22.53.png
  7. Send the call stack to the Rider team for analysis with some way described here.

In case Rider crashes too quickly and it is hard to catch a process ID

If you cannot catch a process id of ReSharper.Host (because Rider crashes too quickly), then please do the following:

macOS

  1. Core dumps are located in /cores directory by default, therefore it is necessary to give other OS users rights to write to /cores via running a command chmod o+w /cores/
  2. Run the command ulimit -c unlimited;
  3. Check what is inside the folder /cores via running ls /cores/;
  4. Then run Rider from the console and wait until it crashes;
  5. Find a newly created dump in the /cores/ directory, archive it and share with us via some way described here.

Linux

  1. The location of core dumps is specified in the `/proc/sys/kernel/core_pattern`, please be sure it will not be piped to another program by `|/path/to/program` pattern, otherwise you have to reconfigure it to /tmp directory using echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern , and restore the previous core_pattern later;
  2. Run the command ulimit -c unlimited;
  3. Check the directory specified in your core_pattern file (usually it is /tmp/ or current working directory);
  4. Then run Rider from the console and wait until it crashes;
  5. Find a newly created dump in the appropriate directory, archive it and share with us via some way described here.

Files to download

Please sign in to leave a comment.

Have more questions?

Submit a request