CODEWITHSUNDEEP
c++windowsvisual-studio
Kamil Zubair
Kamil Zubair

Reputation: 229

What to do when your program crash before entering main?

I have a very strange problem. Our company application is a desktop app written in C++ and compile with Visual Studio 2017. For the last several weeks sometimes the app will crash before entering main. I know it because I put break point in the first line in main and it never get called. The crash doesn't happen quickly, so I have time to press break all in diagnostic tool. But I only got a message 'Your app has entered a break state, but there is no code to show because all thread were executing external code (typically system or framework code)'. Sometimes cleaning everythings and doing rebuild make the code works, but sometimes not.

I don't even know how to start investigeting this, the code is several years old and never had this problem.

Any idea what to do ?

Edit

As suggested, I set breakpoint in WinMainCRTStartup and I trace the problem to line 224 function __scrt_common_main_seh() in exe_common.inl:

if (_initterm_e(__xi_a, __xi_z) != 0) return 255;

that line failed so the function is returning 255 and my main never get called. Any further idea ?

Upvotes: 3

Views: 2723

Answers (3)

doug
doug

Reputation: 4299

I recently ran across the same crash on VS 15.9.4 and it seems related to setargv.obj which expand command line wildcards. It affected x64 release builds but not debug or x86 builds and depends on the argument format. My program uses only standard C++ with no external libraries. It has no global or static variables outside of a few PODs.

I have a local directory solarcaptures with a 0 length file named out_0001_21605508221437 w/o a suffix. Running the collatepackets exe expands the command line arguments:

collatepackets solarcaptures\*

However, changing the command line to the following causes an access violation in the same initialization code on x64 Release builds.

collatepackets solarcaptures\out*

UPDATE: I made a minimal program with a main using printf to list the arguments. It crashes on x64 Release builds. Tested it on the two most recent Windows 10 with clean installs of VS2017. Very repeatable but is sensitive to the specific names being expanded. Shortening the directory name sometimes makes it work.

Upvotes: 0

Kamil Zubair
Kamil Zubair

Reputation: 229

I finally get my program to works again. The reason is the program is now compiled using Visual Studio 2017 but some of the library that link statically with my program is build using previous visual studio, after I recompile them using Visual Studio 2017 my program run just fine.

So, if you program is crash before exit one of things to check is to make sure all your library is build using the same compiler and using the same compiler switches.

Upvotes: 4

R2RT
R2RT

Reputation: 2146

Assuming that debugger has problem with catching that I've an idea which only might work. How about setting your own terminate function via set_terminate? http://www.cplusplus.com/reference/exception/set_terminate/ You could do it in constructor of static global variable, which might get called before the thing that crashes your software. Unfortunatelly order of initialization of static variables is undefined. Try to set breakpoint inside of it.

int main()
{
    throw 0;
    return 0;
}

 struct reterminator
{
    static void myterminate() {
        std::cerr << "terminate handler called\n";
        abort();  // forces abnormal termination
    }

    reterminator()
    {
        std::set_terminate(myterminate);
    }
} static reterminator_;

Upvotes: 3

Related Questions