2

One of our users is trying to run our (open source) software on his Windows 7 64-bit machine at his work.

Unfortunately, neither the GUI version nor the command line version of the program run on his machine. The program appears to start but doesn't do anything, and the GUI version does not even open a window.

I don't think the process actually goes very far. Here are Process Explorer views of the process' threads on his and my machine:

On his Windows 7 machine:

Process' threads on Windows 7

On my Windows 10 machine:

Process' threads on Windows 10

Our software was built with Visual Studio 2013 in 64-bit mode. The MSVC runtime is included. It has been working for years, probably on a variety of machines.

What's possibly going on?

I'm happy to add the required details.

Update 1: I have Process Monitor traces (*.pml files) for both machines, but while I know how to interpret them, I'm not sure what conclusions I can draw from them. Anyone interested in having a look? I'm a bit hesitant to post them here as I suspect they could contain sensitive information.

Update 2: The problem is reproducible on all Windows 7 machines we've got access to, but on no other Windows versions.

Update 3: The previous release of the application is reported to work fine on Windows 7, while the latest release doesn't. Nothing has changed in the way we build or package the application.

Improve this question
19
  • @Thomas I got a Process Monitor trace from our user. Is it safe to post it here, or does it potentially contains sensitive information?
    – François Beaune
    Sep 14, 2016 at 11:32
  • Depends on the filters. It may expose paths, IP addresses and even user name. I'd not post a full capture here
    – Thomas Weller
    Sep 14, 2016 at 12:26
  • If you right click on the Result column on a line which contains SUCCESS, select "Exclude" from the context menu. This should result in a list of potential problems only.
    – Thomas Weller
    Sep 14, 2016 at 12:28
  • A missing DLL problem might be detected by debugging.wellisolutions.de/procmonanalyzer (although usually a program will crash while yours seems to continue running.
    – Thomas Weller
    Sep 14, 2016 at 12:29
  • Thanks @Thomas. It's almost certainly not a missing DLL problem as Windows would usually complain about it (missing component etc.) and anyway we've been deploying this software in the wild for many years without issues. I'd vote for some kind of antivirus problem. I can provide you the trace if you're willing to have a look.
    – François Beaune
    Sep 14, 2016 at 12:38

2 Answers 2

Reset to default
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.

Improve this answer
1
  • It's no wonder why you see "no longer supporting upgrades". It's when I give the finger to "depricated" errors. It's like, oh so you are new to th he club and decided to change compiling and now the world is depricated according to you?!
    – ejbytes
    Sep 21, 2016 at 16:33
1

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.

Improve this answer
1
  • 1
    Wow, thanks for finding it. We had a similar issue and I woul've never found it without this hint!
    – PhilLab
    Feb 7, 2018 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.