When breakpoint() is called in a debug build (e.g. for an fassertFailedNoTrace), it calls DebugBreak() on Windows. This throws an EXCEPTION_BREAKPOINT exception that is caught by a debugger if present. If no debugger is present, the exception is caught by the top level handler and transfers control to our unhandled exception handler. This handler prints a stack trace and begins a minidump.

Meanwhile, if this is process is signaled to stop, another thread can start the shutdown process while the minidump is working. For example, the process can be signaled to stop by a shell that has spawned the process and is waiting for a certain message to appear in the log as a result of triggering the fassert. This thread can commonly hit an access violation or stack overflow error, and the exit status of the process reflects those HRESULTs.
This appears to be the issue in BF-1843 and others.