Program starts but does nothing on Windows 7

Solution 1:

Here's some output when I run it in the Microsoft WinDbg debugger:

Break-in sent, waiting 30 seconds...
WARNING: Break-in timed out, suspending.
         This is usually caused by another thread holding the loader lock
(36a4.2fc8): Wake debugger - code 80000007 (first chance)

See StackOverflow what a loader lock is.

This really happens very early in the startup procedure of the program.

On the callstack I see

0:000> k
 # Child-SP          RetAddr           Call Site
00 00000000`0020e9f8 00000000`771eaa78 ntdll!ZwWaitForKeyedEvent+0xa
01 00000000`0020ea00 00000000`771eabe2 ntdll!TppWaitpSet+0x1f1
02 00000000`0020eaa0 00000000`771ed0c4 ntdll!TppSetWaitInterrupt+0xa2
03 00000000`0020eb90 00000000`770bee49 ntdll!RtlRegisterWait+0x1e4
04 00000000`0020ec60 000007fe`d7252e98 kernel32!RegisterWaitForSingleObject+0x59
[...]
MSVCR120!Concurrency::critical_section::lock+0x2a [f:\dd\vctools\crt\crtw32\concrt\rtlocks.cpp @ 1031]
[...]
17 00000000`0020f790 00000000`00000000 ntdll!LdrInitializeThunk+0xe

So this could be (but needn't be) a deadlock: the thread has locked a critical section before and is now waiting for something else. It's hard to say on x64 since getting the arguments is not so easy. Otherwise we could traverse the wait chain.

Solution 2:

The cause of this mystery turned out to be the combination of a genuine bug in version 1.61 of the Boost C++ Libraries and some implementation details in Windows 7:

https://svn.boost.org/trac/boost/ticket/12475

The previous release of our application (1.4.0-beta) is using Boost 1.55 and it isn't affected by the bug. The latest release is using Boost 1.61 which has the bug.