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

Rider.Backend process is hanging

Files to download

Unix-based Operating systems (Linux, macOS)

macOS

Linux

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. 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.

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 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.

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:

1. Check the process PID of Rider.Backend in the Activity Monitor on Mac or with the following bash command: `ps aux | grep -i rider.backend`;
2. Attach LLDB debugger to the running dotnet 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`

   Please note, if you are running on another platform like macOS ARM64 one needs to choose the corresponding directory macos-arm64 and specify the path to libsosplugin.dylib.

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’s ReSharper host crashes, use `clrstack -all` to see the call stack;
7. Send the call stack to the Rider team for analysis with some way described here.

For Apple Silicon, we need dotnet sos which corresponds to the architecture of the process. Rider uses arm64 dotnet, so following commands will make it possible to debug the dotnet process with lldb:

dotnet tool install -g dotnet-sos
dotnet sos install --architecture Arm64

After that, only connection to the JetBrains symbols server is required.
Also, make sure that DOTNET_ROOT points to the arm64 arch dotnet, as it might be 64bit one which runs through Rosseta. Rider can be debugged with dotnet bundled with it, e.g.:

DOTNET_ROOT=/Applications/Rider.app/Contents/lib/ReSharperHost/macos-arm64/dotnet/

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

If you cannot catch a process id of Rider.Backend (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