When starting a process on Win32 there's an internal exception
(breakpint) that leaks to the debug caller:
s 'Exception 0x8003 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 plat
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 sho
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
t
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
> On Mar 18, 2016, at 11:42 AM, Zachary Turner wrote:
>
> FWIW all the debuggers that people norma
ah yes! Disabling that fixed it. Thanks
Op 2016-03-18 om 19:29 schreef Zachary Turner:
Are you launching the process with -s (stop at entry)?
On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
When starting a process on Win32 there's an internal
Are you launching the process with -s (stop at entry)?
On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> When starting a process on Win32 there's an internal exception
> (breakpint) that leaks to the debug caller:
> s 'Exception 0x8003 encounter