In C++, are global objects guaranteed to exist throughout the execution of a SetConsoleCtrlHandler() callback function?

Geoff Hale 0

In C++, are global objects guaranteed to exist throughout the execution of a SetConsoleCtrlHandler() callback function?

I'm wondering what would happen if both regular program execution (and the eventual destruction of global variables) and the HandlerRoutine() are racing to complete.

The reason I ask is that my HandlerRoutine() needs to use some global objects, though I'm not sure if they would still exist if regular program termination ended up completing before an invoked HandlerRoutine() call.

I haven't had any problems, though I'm not sure if this is guaranteed.

RLWA32 47,206 Reputation points

2025-02-05T14:22:19.63+00:00

It would be helpful if we knew what console signals were being handled and how they relate to a global object. For example, several of the console signals will cause process termination (ExitProcess function) and so the destructor of a global object will not be executed.

Darran Rowe 1,426

@RLWA32

My assumption is that it it is something akin to:

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

#include <atomic>
#include <format>
#include <string>
#include <cstdio>

std::atomic_bool g_exit_loop{ false };

static BOOL WINAPI CtlHandler(DWORD)
{
	g_exit_loop = true;
	return TRUE;
}

int main()
{
	bool work_complete = false;
	uint32_t count{};

	SetConsoleCtrlHandler(CtlHandler, TRUE);

	while (work_complete == false && g_exit_loop == false)
	{
		auto fmt_string = std::format("Working...\n");
		fputs(fmt_string.c_str(), stdout);
		Sleep(1'000);
		++count;

		if (count == 20)
		{
			work_complete = true;
		}
	}

	if (!work_complete)
	{
		auto fmt_string = std::format("Work cancelled\n");
		fputs(fmt_string.c_str(), stdout);
	}
	else
	{
		auto fmt_string = std::format("Work complete, count {}\n", count);
		fputs(fmt_string.c_str(), stdout);
	}

	return 0;
}

But perhaps the handler accesses an object. The fact that this handler returns TRUE means that the default handler doesn't get called and therefore ExitProcess isn't called. This handler will never be used for logoff or shutdown events, so the only time the process will be terminated after a timeout is for the close event. But the timeout for this is 5 seconds.

But anyway, with this, a badly timed event right when the process is exiting can cause a race condition.

RLWA32 47,206 Reputation points

2025-02-05T23:45:09.6466667+00:00

I was simply pointing out the impact of signal termination on the orderly destruction of global subjects for the Questioner's benefit. :)
Geoff Hale 0 Reputation points

2025-02-06T09:58:50.62+00:00

@Darran Rowe

My code is similar to your example. I have 1 workload thread, and 1 display thread. The handler routine uses an event (one of the globals I was using) to inform the display thread to terminate and do the necessary cleanup. The handler then waits for the display thread (another of the globals) to finish, as I want to make sure its cleanup gets done. Then the handler returns TRUE, and the system terminates the process.

It doesn't seem like I'll be able to rely on this handler approach though, as I don't want a race condition.

Darran Rowe 1,426

@Geoff Hale

It is possible to rely on it if you do it correctly. But it is important to understand how things fit together. Importantly, scalar values that don't have destructors hang around.

So as something quick and dirty,

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

#include <atomic>
#include <format>
#include <string>
#include <cstdio>

std::atomic_bool g_exit_loop{ false };

static bool process_exiting{};

static BOOL WINAPI CtlHandler(DWORD)
{
	auto exiting = static_cast<bool>(_InterlockedAnd8(reinterpret_cast<CHAR *>(&process_exiting), 0xFF));
	if (!exiting)
	{
		g_exit_loop = true;
	}

	return TRUE;
}

int main()
{
	bool work_complete = false;
	uint32_t count{};

	SetConsoleCtrlHandler(CtlHandler, TRUE);

	while (work_complete == false && g_exit_loop == false)
	{
		auto fmt_string = std::format("Working...\n");
		fputs(fmt_string.c_str(), stdout);
		Sleep(1'000);
		++count;

		if (count == 20)
		{
			work_complete = true;
		}
	}

	if (!work_complete)
	{
		auto fmt_string = std::format("Work cancelled\n");
		fputs(fmt_string.c_str(), stdout);
	}
	else
	{
		auto fmt_string = std::format("Work complete, count {}\n", count);
		fputs(fmt_string.c_str(), stdout);
	}

	CHAR pe_res = 0;
	while (pe_res == 0)
	{
		pe_res = InterlockedExchange8(reinterpret_cast<CHAR *>(&process_exiting), 1);
	}

	return 0;
}

It is a bit ugly, but this will work as a way to determine if the process is shutting down. It is also possible to then use something like a SRWLock after the check to synchronise the handler. This can be used as a means of making sure the main thread doesn't exit while the handler is doing its work.

It would also be during or after the process has been marked as exiting that the SetConsoleCtrlHandler function can be called again to disable any handlers. Basically, as long as synchronisation is used so that the main function isn't exited then the problematic objects will be fine. If there is still a badly timed signal then it will be relying on a scalar value which has static storage duration.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Roy Li - MSFT 33,931 Reputation points Microsoft Vendor

2025-02-13T07:05:00.2633333+00:00

Hope you've been well. Any updates about this issue?

1 answer

Darran Rowe 1,426 Reputation points

2025-02-05T02:16:16.6066667+00:00
Globals are guaranteed to exist from the moment the code enters main/wmain/WinMain/wWinMain/DllMain and are guaranteed to exist until the code exits the main function.

While it isn't accurate, the startup code essentially does:

void execute_main() { //Other stuff initialise_globals(); invoke_main(); cleanup_globals(); exit(); }

If there is a major concern that the handler may use something that gets destroyed, use SetConsoleCtlHandler again just before the main funtion returns to remove the handler. Passing in the same pointer to the handler function as was used when the handler was registered, but use FALSE for the second parameter should remove the handler.
Please sign in to rate this answer.
Geoff Hale 0 Reputation points

2025-02-05T12:18:26.5066667+00:00

Unless the remove portion of the SetConsoleCtrlHandler() implementation is synchronized with any of the corresponding already launched/launching HandlerRoutine() threads, they could still be active when the removing call to SetConsoleCtrlHandler() returns.

All the removing call to SetConsoleCtrlHandler() would accomplish is that no more HandlerRoutine() threads would be launched.

Darran Rowe 1,426 Reputation points

2025-02-05T16:42:21.6033333+00:00

Yup, but let's face it, it did give the answer of no, globals are not guaranteed to exist past the end of the main function if you let the handlers keep running past that point. You rarely have any handlers trigger in the life of the application, so the probability of the handlers causing problems is probably about the same as a handler being called at that point. But it is a race condition.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

In C++, are global objects guaranteed to exist throughout the execution of a SetConsoleCtrlHandler() callback function?

1 answer

Your answer