Грабли и клешни связанные с удалённой отладкой

Тут недавно задачку подкинули, написать читалку логов другой программы. Ну на код ушло времени в принципе не много, а вот отловить баги оказалось задачей той ещё. Святые угодники, ну как так.

Запускаю программу, она следит за сервисом с GSM модемами, если какая беда, то должна выключить сервис и сказать администратору что кирдыкнулся сервис потому-что. Первый косяк с которым столкнулся это был ifstream, он на блокированном файле тупо падал и грохал приложение. Ну что-же не долго думая переписал приложение на чистенький родименький WINAPI и тут началось нечто. Программа падает, хоть ты её удави. На клиентский сервак нечего лишнего ставить нельзя, ну типо студию залепить, и Visual-Studio Remote Debug Tools.exe тоже поставить не получиться во первых закрыт порт, во вторых ну не по феншую это. Пришлось методом тыка тыкать. В конце концов уже на моменте епанутой истерии нахожу забавную тулзу от SysInternals называется ProcDump v8.2. Ну что-же тулза консольная, качаем, смотрим ключики. Есть пару интересных аргументов - -e дампить память только на захваченном exception и ключик -w ждать процесса с определённым именем.

Запускаем :

procdump.exe -e -w "logworker.exe"

После запускаем сервис, шаманим наше приложение пока не упадёт. И получаем на выходе вот такой вот полезный файлчик а-ля «logworker.exe_161219_141739.dmp». Даблкликаем на него студией, и что мы видим.

После тыкаем Debug Symbols Path, там выбираем базовые и наши.

И запускаем режим отладки.

Снизу слева будет у нас CallStack, Watches, Locals и Autos. Где у нас параметры переданные функции и всё окружение на момент смерти нашей программы.

И тут я готов был разебать C++ ко всем чертям, эта свинья падала нк конверсии BYTE* в wstring потому что в логе был ебанный символ 0x08 (BELL)

wstring_convert<codecvt_utf8_utf16<wchar_t>> converter; // file BYTE* line => wstring
wsline = converter.from_bytes(lines);

Кто-бы мог подумать ёпрст!

Вообщем хорошо что хорошо кончается. Баг нашелся и исправился.