MSVC - Debugging the Static Initialization Order

Debugging static constructor crashes before main() in MSVC

18 December 2025

How the initialization works

When the program compiles and links, a table of function pointers to all the static methods which need to be called to initialize the static variables is created.
Then, the MainCRTStartup function loops over these pointers and calls them. Again, all this happens before main().

With this background info, we can be more specific in formulating the problem:

One of the constructors of a static variable leaves behind its side effects which leads to code in another constructor crashing.
We can see the outcome where its side effects cause problems in subsequent constructors/static methods.
- But we don't know how many constructors were called before "ours".
- We don't know which of those are causing it.
We need to know this to limit the scope.
The error must be somewhere in there.

What the underlying code looks like

Wouldn't it be great if we could examine the "MainCRTStartup"?

Microsoft actually supplies source code for this! It can be found in the file exe_common.inl which in my case was found at "C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.39.33519\crt\src\vcruntime\exe_common.inl"

The call to _initterm performs this initialization (line 17):

bool has_cbool has_ctor = false;  
__try  
{  
    bool const is_nested = __scrt_acquire_startup_lock();  
  
    if (__scrt_current_native_startup_state == __scrt_native_startup_state::initializing)  
    {  
        __scrt_fastfail(FAST_FAIL_FATAL_APP_EXIT);  
    }  
    else if (__scrt_current_native_startup_state == __scrt_native_startup_state::uninitialized)  
    {  
        __scrt_current_native_startup_state = __scrt_native_startup_state::initializing;  
  
        if (_initterm_e(__xi_a, __xi_z) != 0)  
            return 255;  
  
        _initterm(__xc_a, __xc_z);  // <--- THIS LINE (256)!
  
        __scrt_current_native_startup_state = __scrt_native_startup_state::initialized;  
    }  
    else  
    {  
        has_cctor = true;  
    }  
  
    __scrt_release_startup_lock(is_nested);

Debugging this with x64-debug

Depending on the debugger, this might be out of scope for your IDE. This was the case for me.

Prerequisites

It's assumed you can either use a regular debug build or a release build with generated PDB file (/Zi flag to generate separate PDB for MSVC compiler).

Ensure entry breakpoint is set in the options dialog:

This automatic breakpoint will pause the debugging at the program entry point - not main() but the actual entry point.

Stepping into the program

There is a lot to look at in this screenshot. The program is called gltf_render_pbr. Use the step-into button in the debugger until you reach the correct "file" - it will tell you on the right hand side. Look at the very right for exe_common.inl

Now you can find the correct line for the breakpoint. It is marked in red here. Also notice the __xc_z and __xc_a, those are the start and end pointers of the table where the static initializer function pointers are stored. Note the little red dot to the left of the red highlighted address? That means I have a breakpoint set on that instruction. The call <gltf_render_pbr._initterm> instruction. This is the one jumping into the actual performing code inside ucrtbased.dll.

ucrtbased.dll loop

When you step into that, you will end up here:

This is the loop which calls each initializer in the list.

The actual call into each initialization method is: call qword ptr ds:[7FFCD4B6BBA0].

Set a breakpoint there like I've done in the screenshot above.
Now, from there, step into 2 times more to reach the actual code.
When you've noted where you ended up, just press run and you should get back to the breakpoint. It's inside the loop after all.

Note that the first static method the "pre_cpp_initialization" step in the CRT code, exe_common.inl:216
It initializes exception handlers and other things.

The next call should be into actual C++ initializers. If you have debug symbols, you should be able to see where you end up. In the example program I used - fmt had a static method, and then the next after that was my test code.

When debugging the program next time

When you restart the program in the debugger, each DLL will also have its own CRT startup sequence. Thus:

disable the breakpoint inside the loop in ucrtbased.dll
run until the breakpoint for the _initterm call
re-enable the breakpoint inside the loop in ucrtbased.dll

Tags:

c++desktop windows

About KDAB

The KDAB Group is a globally recognized provider for software consulting, development and training, specializing in embedded devices and complex cross-platform desktop applications. In addition to being leading experts in Qt, C++ and 3D technologies for over two decades, KDAB provides deep expertise across the stack, including Linux, Rust and modern UI frameworks. With 100+ employees from 20 countries and offices in Sweden, Germany, USA, France and UK, we serve clients around the world.

1 Comment

Good one! Actually there is a way to do at least an attempt at ordering: C++20 constinit. It is initialized before the other static data, and it does not have to be constexpr.