O programa inicia, mas não faz nada no Windows 7

Question

Um de nossos usuários está tentando executar o software em seu computador com o Windows 7 de 64 bits em seu trabalho. p>

Infelizmente, nem a versão da GUI nem a versão da linha de comando do programa são executadas em sua máquina. O programa parece começar, mas não faz nada, e a versão GUI nem abre uma janela.

Eu não acho que o processo realmente vá muito longe. Aqui estão as exibições do Process Explorer dos threads do processo na sua e na minha máquina:

Na sua máquina com Windows 7:

NaminhamáquinacomoWindows10:

NossosoftwarefoicriadocomoVisualStudio2013nomodode64bits.OtempodeexecuçãodoMSVCestáincluído.Elevemtrabalhandoháanos,provavelmenteemumavariedadedemáquinas.

Oquepossivelmenteestáacontecendo?

Estoufelizemadicionarosdetalhesnecessários.

Atualização1:tenhorastreamentosdoProcessMonitor(arquivos*.pml)paraambasasmáquinas,masemboraeusaibacomointerpretá-los,nãoseiquaisconclusõespossotirardeles.Alguéminteressadoemdarumaolhada?Estouumpoucohesitanteempublicá-losaqui,poissuspeitoqueelespossamconterinformaçõesconfidenciais.

Atualização2:OproblemaéreproduzívelemtodasasmáquinascomWindows7àsquaistemosacesso,masemnenhumaoutraversãodoWindows.

Atualização3:o lançamento anterior do aplicativo é relatado como funcionando bem Windows 7, enquanto o lançamento mais recente não o faz. Nada mudou na forma como criamos ou empacotamos o aplicativo.

    

Answer 1

A causa deste mistério acabou por ser a combinação de um bug genuíno na versão 1.61 das Boost C ++ Libraries e alguma implementação detalhes no Windows 7:

link

A versão anterior do nosso aplicativo (1.4.0-beta) está usando o Boost 1.55 e não é afetado pelo bug. A última versão está usando o Boost 1.61 que tem o bug.

    

Answer 2

Aqui estão algumas saídas quando eu o executo no depurador do 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)

Veja StackOverflow o que é um bloqueio de carregador .

Isso realmente acontece muito cedo no procedimento de inicialização do programa.

Na pilha de chamadas, vejo

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

Então, isso pode ser (mas não precisa ser) um impasse: o segmento bloqueou uma seção crítica antes e agora está aguardando outra coisa. É difícil dizer no x64, já que obter os argumentos não é tão fácil. Caso contrário, poderíamos atravessar a cadeia de espera.