I see two approaches to your issue:

• Configure your debugger to break when an exception is thrown and not just on unhandled exceptions. This is the approach I usually choose, but it only works if exceptions are only used for exceptional events and not all the time. So it doesn't appear to fit your application very well.

• You could put a break-point into the global exception handler in the dll.

  Something along the lines of: if(IsDebuggerPresent)__debugbreak()

Though it's unlikely that you can do anything about that, an access violation is generally considered an unrecoverable exception (because it might result from/in memory corruption) and you should use a separate process that gets terminated to contain the fallout instead of letting a process continue in which such an error happened.

I see two approaches to your issue:

• Configure your debugger to break when an exception is thrown and not just on unhandled exceptions. This is the approach I usually choose, but it only works if exceptions are only used for exceptional events and not all the time. So it doesn't appear to fit your application very well.

  Some debuggers allow configuring this settings based on the exception type. So you can use this approach for exceptions that should never happen (e.g. access violations) while resorting to the second approach for exceptions that happen frequently in your code-base.

• You could put a break-point into the global exception handler in the dll.

  Something along the lines of: if(IsDebuggerPresent())__debugbreak();

  Unfortunately part of the stack will already be unrolled by that point, removing a lot of information that'd be useful for debugging.

Though it's unlikely that you can do anything about that, an access violation is generally considered an unrecoverable exception (because it might result from/in memory corruption) and you should use a separate process that gets terminated to contain the fallout instead of letting a process continue in which such an error happened.