Rider: how to collect a dump on a specific crashed or hanged process

In case you face Rider crash or hanging Rider.Backend.ni.exe 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

Rider.Backend process has crashed

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

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 (enable_dumps_rider (1).reg) . 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. 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 (disable_dumps_rider (2).reg). 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. Upload it to JetBrains Uploads service and share the Upload ID with support.

Rider.Backend process is hanging

In case you face the issue when Rider backend process Rider.Backend.ni.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. 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.

3. Share this dump file with the Rider team for analysis with some way described here.

Unix-based Operating systems

In case Rider backend crashes on Linux or macOS, a process crash dump can be collected with LLDB debugger and SOS plugin.

LLDB package is usually available in the Linux distribution's repositories. 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
• {RiderInstallationDirectory}/lib/ReSharperHost/macos-arm64/dotnet/sos/libsosplugin.dylib on MacOS arm64

To find {RiderInstallationDirectory}, use the menu Help | Diagnostic Tools | Special Files and Folders and double-click on Installation home directory.

On macOS Developer mode has to be enabled, as well as user should be added to the admin or developer group:

sudo DevToolsSecurity --enable
sudo dseditgroup -o edit -a %USERNAME% -t user _developer

How to collect a crash dump:

Important: If you are using a macOS ARM64 device, you might encounter issues collecting the process dump. If you are using an Apple Silicon device, please refer to Rider backend crash. MacOS Arm64. Collect Managed Call Stack for the hanged or crashed Rider.Backend process

Please follow the steps below to collect a backend proccess dump:

1. Check the process PID of Rider.Backend in the process monitor application of your choice or using the following bash command: ps aux | grep -i rider.backend;

2. Attach LLDB debugger to the running Rider Backend process with lldb -p {PID};

3. Load the SOS plugin (lldb) plugin load {path_to_sos_plugin}

   Example for Linux x64:

(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

5. Continue with (lldb) c and reproduce the crash;

6. After Rider Backend crashes, use clrstack -all to see the call stack;

7. Send the call stack to the Rider team for analysis.

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

If you cannot get a process id of Rider.Backend because Rider crashes too quickly, follow the steps below:

macOS

1. Core dumps are located in /cores directory by default, therefore, it is necessary to allow non-root users to write to /cores, and set the sticky bit:

   sudo chmod o+w /cores
   sudo chmod +t /cores
   

2. Run the command ulimit -c unlimited. This command will only affect the processes spawned from the same shell session.

   Verify that it says unlimited when you query ulimit -c.

3. Check what is inside the folder /cores via running ls /cores

4. Then run Rider from the console and wait until it crashes. Rider can be started from the terminal with /Applications/Rider.app/Contents/MacOS/rider for standalone installations. In the case of the Toolbox installation, open Settings for the problematic version of Rider and copy the installation location from there, then start Rider using a path to the executable, for example: ~/Applications/Rider\ EAP.app/Contents/MacOS/rider

5. Find a newly created dump in the /cores directory, archive it and share it with us via some way described here.

Linux

1. The location of core dumps is specified in the /proc/sys/kernel/core_pattern
2. Run the command ulimit -c unlimited
3. Check the directory specified in your core_pattern file (usually /tmp/ or current working directory)
4. 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 as described in How to Upload (Large) Files for JetBrains Support Team