2

Один из наших пользователей пытается запустить наше (с открытым исходным кодом) программное обеспечение на своей 64-битной машине Windows 7 на своей работе.

К сожалению, ни версия GUI, ни версия программы из командной строки не запускаются на его компьютере. Программа запускается, но ничего не делает, а версия с графическим интерфейсом даже не открывает окно.

Я не думаю, что процесс на самом деле идет очень далеко. Вот представления Process Explorer потоков процесса на его и моей машине:

На своем компьютере с Windows 7:

Темы процессов в Windows 7

На моей машине с Windows 10:

Темы процессов в Windows 10

Наше программное обеспечение было построено с Visual Studio 2013 в 64-битном режиме. Время выполнения MSVC включено. Он работал годами, возможно, на разных машинах.

Что возможно происходит?

Я рад добавить необходимые детали.

Обновление 1: у меня есть трассировки Process Monitor (* .pml файлы) для обеих машин, но, хотя я знаю, как их интерпретировать, я не уверен, какие выводы я могу из них сделать. Кто-нибудь заинтересован в том, чтобы посмотреть? Я не решаюсь размещать их здесь, поскольку подозреваю, что они могут содержать конфиденциальную информацию.

Обновление 2: проблема воспроизводима на всех компьютерах с Windows 7, к которым у нас есть доступ, но не на других версиях Windows.

Обновление 3. Сообщается, что предыдущая версия приложения работала нормально в Windows 7, а последняя - нет. Ничего не изменилось в том, как мы строим или упаковываем приложение.

2 ответа2

1

Вот некоторый вывод, когда я запускаю его в отладчике Microsoft WinDbg:

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)

Посмотрите StackOverflow, что такое блокировка загрузчика.

Это действительно происходит в самом начале процедуры запуска программы.

На стеках вызовов я вижу

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

Так что это может быть (но не обязательно) тупик: поток ранее заблокировал критическую секцию и теперь ждет чего-то другого. Трудно сказать о x64, поскольку получить аргументы не так просто. В противном случае мы могли бы пересечь цепь ожидания.

1

Причиной этой загадки оказалась комбинация подлинной ошибки в версии 1.61 библиотек Boost C++ и некоторых деталей реализации в Windows 7:

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

Предыдущий выпуск нашего приложения (1.4.0-бета) использует Boost 1.55 и не подвержен этой ошибке. В последнем выпуске используется Boost 1.61, в котором есть ошибка.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .