When a debug version of a unit test application using Boost.Test crashes on Windows, no popup appears that asks for attaching the debugger. Instead, the process prints a stack dump to standard output and then exits normally. Attaching the debugger before the process crashes does not help. Although this is helpful when running tests automatically with no user interaction, it makes it very hard to manually debug unit tests that have crashed. According to the Boost.Test documentation, it is possible to pass framework parameters to Boost. In particular, there is a "catch system errors" parameter, which looks like it should be able to turn off this behavior (please correct me if I am wrong). http://www.boost.org/doc/libs/1_35_0/libs/test/doc/components/utf/parameters... http://www.boost.org/doc/libs/1_35_0/libs/test/doc/components/utf/parameters... We tried the following (on Windows) and then ran a test case which caused an access violation: set BOOST_TEST_CATCH_SYSTEM_ERRORS=no echo %BOOST_TEST_CATCH_SYSTEM_ERRORS The process still exited normally after printing a stack dump. We also tried using a command-line option: <TEST_APPLICATION> --catch_system_errors=no Same result as above. Is this intentional? Is there any way to prevent Boost.Test from catching system errors such as access violations (on Windows) and signals (on Linux and similar platforms) so that conventional debuggers can be used? Best regards, Florian