Break in Visual Studio on process exit

Question

I'm having some difficulties determining what is causing a process to exit. I have a breakpoint in some shutdown code that I'm debugging, but, after breaking in the debugger at the breakpoint and stepping once, the whole process exits immediately. Every thread reports an exit code of -1 in the output window. There are a large number of threads in the process at that time, and the code base is quite large, making searching for the culprit difficult.

I've tried installing a std::atexit function, but this doesn't get hit. I've also tried overriding SetUnhandledExceptionFilter, in case it is caused by a crash, and it also doesn't get hit. The project has exceptions disabled (#define _HAS_EXCEPTIONS=0), so I cannot call std::set_terminate or std::set_unexpected.

Is there some other way to determine what is causing the process to exit? Some option to break in the debugger when the process is about to terminate?

Ghee

I'm not very expert...Debugger step by step not help? If not help image the sequence of operation in time, use printf("1") printf ("2") in the code ecc for identify where is the code not executed – Holism

Exception disabled by project settings (C/C++->Code Generation) not by #define. So Debug->Windows->Exception Settings could be useful. – Wier

or add a try{}catch{...} in your main and then even without debugger settings you can see if it's an uncaught exception with a break point. – Vault

@Vault - there is already a __try/__finally block inside main, and the __finally block doesn't get hit. – Ghee

"atexit" is only run on normal termination; so I'm not surprised that isn't getting called. I would look into adding some signal handlers en.cppreference.com/w/cpp/utility/program/signal so that you can at least track what's going on. – Vault

Similar case: https://mcmap.net/q/1281797/-exit-fails-to-set-error-code – Antic

@HansPassant - based on that answer, my machine is about to go out the window :). Tried breakpoints on ExitProcess, TerminateProcess, NtTerminateProcess (the context specific one also didn't work for me), and _exit. The breakpoints window all says they are valid, but none get hit after stepping. – Ghee

@Vault - added a signal handler for 1..NSIG, but the signal handler doesn't get hit either. – Ghee

My last guesses are that you're building something in release mode or there's some non-matching debug information... after that, I'm all out of ideas :)# – Vault

Building debug, and as I said, the breakpoints say they match in the debug window, which wouldn't happen if the debug information didn't match. – Ghee

Answer 1

Run your app with debugger and read the debug output. If the app terminates because C++ exceptions, or SEH, you’ll read it in the output window.

If you’ll see nothing interesting there, it means your app called ExitProcess/ExitThread/exit, or worse, TerminateProcess/TerminateThread/_exit.

You can put breakpoints on these. Set a breakpoint at startup, launch debugger. Ensure you have debug symbols loaded for relevant DLLs, kernel32.dll for ExitProcess and friends, some other DLL for exit, e.g. ucrtbase.dll. Press “New / Function breakpoint” in the Breakpoints window, type e.g. “ExitProcess”, press OK.

Friarbird

While this is a reasonable answer... it doesn't work for me (see comments on the question). – Ghee

Great Hint! Thanks! – Waggle

Answer 2

You can also try using gflags tool from Windows SDK.

If you’ll find (by reading Windows Logs > Application) the reason was self exit, you can check “Enable dump collection” in gflags, then you’ll be able to load the dump in WinDBG and get the complete call stack telling you who called what.

Unfortunately, the latest version of the tool is broken beyond repair.

But you can install older Windows SDK. You only need “Debugging tools for Windows” from there, no need to install the complete SDK.

Friarbird