Remote Just-In-Time debugging C# app

When an unhandled exception occurs on a remote machine, Windows looks at the local system configuration (in the registry) to decide whether to launch a debugger — that's the “Just-In-Time” (JIT) debugging mechanism. However, JIT debugging only works with a debugger installed locally. It cannot launch the Visual Studio Remote Debugger (msvsmon.exe) to start a session or connect to a remote Visual Studio instance. That's why you're seeing: “No installed debugger has Just-In-Time debugging enabled.” Even though msvsmon.exe is running and connected, it's not registered as a JIT debugger on that system.

JIT debugging relies on registry entries like:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

with values such as:

Debugger = "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\vsjitdebugger.exe" -p %ld -e %ld
Auto = 1

But this refers to vsjitdebugger.exe, which only exists with a full Visual Studio install. The remote debugger service (msvsmon.exe) does not include or register vsjitdebugger.exe. The system therefore cannot invoke remote JIT debugging because it requires a local process.

To resolve this, consider the following options:

Option 1: Attach manually to the remote process

This is the standard and supported method:

1. Run the app on the remote machine under msvsmon.exe.
2. In Visual Studio (host), go to Debug → Attach to Process.
3. Select Remote (no authentication) or Windows Authentication, connect to the remote machine.
4. Attach to the target process.
5. When the exception occurs, you'll break in on your host system.

Note that this is not JIT debugging — but functionally achieves the same goal for debugging crashes.

Option 2: Enable local JIT debugging

If you install the full Visual Studio (even just the debugger components) on the remote computer, JIT debugging will work locally — a dialog will pop up offering to start Visual Studio locally for that exception. However, it still will not automatically connect to a remote host.

Option 3: Collect crash dumps automatically

If your goal is to analyze post-crash behavior rather than live debugging:

1. Configure Windows Error Reporting (WER) or ProcDump to capture dumps:

      procdump -ma -i
   

   or through registry:

      HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps
   

2. When a crash happens, a dump file is generated.
3. Copy the dump to your dev machine and open it in Visual Studio — full stack, locals, etc.

This approach gives you the same insight with less runtime risk.

Option 4: Attach automatically via a watchdog

If you really want “JIT-like” remote behavior:

• Write a lightweight monitoring service on the remote computer that watches for crashes or exceptions.
• When detected, it can trigger procdump, or signal your dev machine to attach remotely via automation.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin