When starting a process on Win32 there's an internal exception (breakpint) that leaks to the debug caller:
s 'Exception 0x80000003 encountered at address 0x7789ccbc'#0
This one is dealt with by the debugger internally but there's still a StateType.eStateStopped event for it. On other platforms there's no exception like this for the internal start breakpoint (note that actual breakpoints after this hit just fine)
Are you launching the process with -s (stop at entry)?
Anything exception that is done by the implementation in order to implement normally stopping at the entry point should be covered up and not sent to the user. A thread has the notion of a private stop info and one that is produced for the public consumption. If this exception is indeed only showing up because this is the way we were able to stop at the entry point, we should not be showing that to the user.
ah yes! Disabling that fixed it. Thanks
FWIW all the debuggers that people normally use on windows show it this way as well. The reason is that by default, if you do nothing and simply launch a program under a debugger, you hit a breakpoint. There’s no way to avoid it, it’s done by the loader at the OS level. If someone doesn’t want to stop at entry point (e.g. doesn’t specify -s), we go out of our way to mask it. So seeing that a breakpoint was hit on startup, while not consistent with LLDB on other platforms, is consistent with other debuggers on Windows. For example, on WinDbg, I get this:
CommandLine: D:\infinite.exe
Symbol search path is: *** Invalid ***
Ok, sounds like there is platform level precedence to support this flow and things should stay this way to keep Windows user experience consistent with other debuggers. Thanks for the info.
Greg