Short-answer: The debugger (in Windows) sits between the first and second and chances, if I recall correctly, to "help" the user by displaying a dialogue notifying them that 'x' is unhandled. Anything in second chance has reached the kernel for handling and is no longer in the user space.
You'll often see this (second chance) as exception entries in the Windows Event Log for things like kernelbase.dll, which points to the offending instruction set. The handler in this space typically invokes Watson to generate Watson reports because it was unhandled elsewhere.
The debugger prevents all of that.
Of course, in JIT, you have things like read-ahead for first-chance exceptions...
A good book, in the Windows space, that cannot recommend enough, is Windows Internals[0]. They include how the managed and user spaces interact and coincide with the native and kernel spaces and how all of that transpires, such as how an exception in user mode transitions to kernel before Watson report is created.
There's other in-depth resources[1], as well, if books aren't your thing.
You'll often see this (second chance) as exception entries in the Windows Event Log for things like kernelbase.dll, which points to the offending instruction set. The handler in this space typically invokes Watson to generate Watson reports because it was unhandled elsewhere.
The debugger prevents all of that.
Of course, in JIT, you have things like read-ahead for first-chance exceptions...
A good book, in the Windows space, that cannot recommend enough, is Windows Internals[0]. They include how the managed and user spaces interact and coincide with the native and kernel spaces and how all of that transpires, such as how an exception in user mode transitions to kernel before Watson report is created.
There's other in-depth resources[1], as well, if books aren't your thing.
[0] - https://docs.microsoft.com/en-us/sysinternals/learn/windows-...
[1] - https://doar-e.github.io/blog/2013/10/12/having-a-look-at-th...