sleepCOW
commented
5 days ago Initially, I thought that RiderLink might have been receiving exception messages before the HardwareBreakpoints plugin.
However, I later discovered the following information about how Windows handles exceptions when a debugger is attached.
When the system is searching for an exception handler, it makes two attempts to notify a process's debugger. The first notification attempt provides the debugger with an opportunity to handle breakpoint or single-step exceptions. This is known as first-chance notification. The user can then issue debugger commands to manipulate the process's environment before any exception handlers are executed. The second attempt to notify the debugger occurs only if the system is unable to find a frame-based exception handler that handles the exception. This is known as last-chance notification. If the debugger does not handle the exception after the last-chance notification, the system terminates the process being debugged.
Apparently, the LLDB implementation on Windows handles data breakpoint exceptions differently. It does not correctly verify whether the exception was set by the user, and simply notifies the user regardless. In contrast, the Visual Studio debugger only notifies the user about data breakpoints they explicitly set. Therefore, when an exception from the HardwareBreakpoints plugin occurs, Visual Studio ignores it, allowing it to be passed by ntdll to our vectored exception handler.
To verify and support this hypothesis, I need to debug the ntdll exception dispatch process to confirm whether the exception messages are being sent to the Rider (LLDB) process.
Source: MSDN Debugger Exception Handling
The project relies on AddVectoredExceptionHandler to handle breakpoints on Windows and unfortunately for some unknown (yet) reason it doesn't get calls when under Rider debugger (lldb)