Вызывать `cdb.exe` (windbg), чтобы он не работал интерактивно, и генерировать обратную трассировку в случае сбоя?

У меня есть проект C ++, который я использую с travis-ci. Прямо сейчас я создаю его с помощью boost.build, и на travis, когда я запускаю модульные тесты, я делаю это через gdb, так что я получаю обратную трассировку в случае аварии.

Делать gdb сделать это неинтерактивно, я вызываю это так в командной строке:

gdb -return-child-result -batch -ex "run" -ex "thread apply all bt" -ex "quit" --args ./${file}

где ${file} мой исполняемый файл

Это говорит это:

• начать процесс
• применять bt ко всем потокам, которые генерируют обратную трассировку в случае сбоя, а также ничего не делают, если сбоя не было.
• наконец это вызывает gdb выйти и выйти с кодом выхода ребенка.

Теперь я хотел бы сделать то же самое на appveyor.

Boost build, кажется, отлично работает из коробки в виртуальной машине appveyor, поэтому снимаю шляпу перед ними.

Тем не менее, я изо всех сил пытаюсь выяснить, как настроить cdbконсольный кузен windbg, Кажется, он висит в моих журналах сборки. Большинство примеров, которые я нахожу в сети, связано с проверкой файлов мини-дампов, а не с запуском процесса и его отладкой во время работы.

Я сейчас вызываю cdb вот так (из скрипта appveyor powershell):

cdb -c "$$><cdb_script.txt" -o $file.fullName

И мой cdb_script.txt похоже

.sympath srv*C:\Windows\Symbols*http://msdl.microsoft.com/download/symbols;
.reload;
~* k 99;
q

Я в основном собираю это вместе из разных вещей, которые я гуглил, в том числе

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff560096(v=vs.85).aspx
• http://www.sandboxie.com/index.php?HowToUseWinDbg

Я действительно надеялся найти лучший документ или примеры о том, как сделать это конкретно.

Ошибка, которую я получаю прямо сейчас:

Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\projects\primer\test\stage\api.exe
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 009a0000 00a27000   api.exe
ModLoad: 76fb0000 7711f000   ntdll.dll
ModLoad: 76520000 76660000   C:\windows\SysWOW64\KERNEL32.DLL
ModLoad: 75fb0000 76087000   C:\windows\SysWOW64\KERNELBASE.dll
ModLoad: 74350000 743f0000   C:\windows\SysWOW64\apphelp.dll
SHIMVIEW: ShimInfo(Complete)
ModLoad: 73b20000 73bd9000   C:\windows\SysWOW64\MSVCP140D.dll
ModLoad: 741b0000 741cc000   C:\windows\SysWOW64\VCRUNTIME140D.dll
ModLoad: 71bd0000 71d46000   C:\windows\SysWOW64\ucrtbased.dll
(294.49c): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
eax=00000000 ebx=00000000 ecx=19a00000 edx=00000000 esi=7ecdf000 edi=00000000
eip=77063c7d esp=0110f8d4 ebp=0110f900 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!LdrInitShimEngineDynamic+0x6dd:
77063c7d cc              int     3
0:000> cdb: Reading initial command '><cdb_script.txt'
^ Syntax error in '><cdb_script.txt'

Некоторые варианты, которые я попробовал:

• С помощью $$<cdb_script.txt вместо $$><cdb_script.txt,
• Ввод точки с запятой после последней команды в файле скрипта

Изменить: я также нашел этот ответ, который снова объясняет, как это сделать с мини-дампами, но показывает файл сценария более подробно.

Я действительно не знаю, что такое минидамп, так что -o вариант звучит более привлекательно, по крайней мере, больше похоже gdb, Но, может быть, я в конечном итоге попытаюсь сделать это с мини-дампами, если я не могу понять это.