Забавно, что перед релизом всегда всплывают какие-то фундаментальные проблемы, видимо, это закон природы…

Сейчас случилось “страшное” - используемая при сборке Navi-Sailor система сборки дошла до своего технологического предела…

Возможно, я как-нибудь напишу об этой системе сборки (только не нужно в меня ничем кидаться и навешивать ярлык INH - когда она разрабатывалась в …

Частенько оказывается, что дамп памяти, приносимый со стенда на анализ (если не удалось посмотреть проблему “вживую” нуждается в достаточно объемной пост-обработке, чтобы продолжить исследование :-(

Как оказалось, жизнь себе можно существенно облегчить…

В подключенной к процессу копии WinDbg/ntsd можно выполнить следующую последовательность команд:

.dump /ma <путь к первичному дампу (*.dmp …

Как оказалось, документацию я, как и большинство разработчиков, читаю по диагонали… а зря…

При отладке значения локальных переменных функции или метода нужно смотреть достаточно часто, в тяжелых ситуациях их нужно использовать в сценариях, а вычислять смещения относительно базы фрейма всегда как-то лениво….

На самом деле, в WinDbg есть команда dv …

Недавно отлаживал один алгоритм, делал это “вживую”, в частности, используя контрольную печать ;-) В какой-момент сработал ::OutputDebugStringA(“WTF??!”), вот только в отладочный поток вывелось неожидаемое “WTF|”…

На первый взгляд случилось Что-то Ужасное, правда, после некоторого скрипения мозгами я все-таки вспомнил про дела “давно минувших дней” - это триграфы :-)

Собственно, причина их появления …

Когда в процессе отладки появляется сообщение “Unhandled exception at 0x00416d9f in sailor.exe: 0xC0000005: Access violation reading location 0xfeeefeee.” разработчики, бывают, начинают нервничать. Между тем, шестнадцатеричные коды, как минимум, в Debug-версии приложения, собранном MSVC, уже могут кое о чем рассказать…

Например, после чтения документации совершенно очевидно, что: - программа попыталась использовать …