Почему Мини-дампы не дают хорошие стеки вызовов?

Отключите оптимизацию указателя кадра, если вам нужны дампы стека. Указатели кадров используются для явного определения стека кадров. Без них отладчик должен определить местоположение каждого кадра.

Чего не хватает в вашем стеке вызовов? У вас есть несколько адресов, которые не разрешаются в допустимые имена функций (например, 0x8732ae00 вместо CFoo: Bar ())? Если это так, то вам нужно разместить свои .PDB там, где ваш отладчик может их найти, или настроить сервер символов и установить «Пути символов» в контекстном меню, вызываемом правой кнопкой мыши на панели модулей. .

Мы сохраняем каждый .PDB из каждого двоичного файла каждый раз, когда кто-то регистрирует новый список изменений Perforce, так что, когда дамп возвращается от кого-либо в офисе или от любого покупателя в розницу, у нас есть .PDB, соответствующий версии игры, которую они использовали. С установленным сервером символов и путями все, что мне нужно сделать, это просто дважды щелкнуть .mdmp, и он будет работать каждый раз.

Или у вас есть стек вызовов, в котором есть только одна функция? Например, 0x8538cf00 без чего-либо другого в стеке? Если это так, то ваш сбой на самом деле является повреждением самого стека. Если адреса возврата в backchain были перезаписаны, естественно, отладчик не сможет их разрешить.

Иногда вы также обнаруживаете, что поток, который на самом деле генерирует минидамп, не является тем, который сгенерировал исключение, вызвавшее сбой . Посмотрите в окне потоков, чтобы увидеть, есть ли в одном из других потоков неправильный код.

Если вы отлаживаете сборку «Release», то есть сборку, скомпилированную со всеми включенными флагами оптимизации, вам придется смириться с тем фактом, что отладчику будет сложно найти локальные переменные и некоторые другие данные. . Это связано с тем, что включение оптимизации означает разрешение компилятору хранить данные в регистрах, свертывания вычислений и, как правило, выполнять различные действия, предотвращающие фактическую запись данных в стек. Если это ваша проблема, вам нужно открыть окно дизассемблирования и вручную просмотреть данные или перестроить двоичный файл отладки и воспроизвести проблему там, где вы сможете ее увидеть.

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

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

Я не использую минидампы, а просто выгружаю стек "вручную" в файл журнала (см. www.ddj.com/cpp/185300443 и Как записывать кадры стека в Windows x64 ).

Я сталкиваюсь с аналогичным поведением, как и вы: иногда есть действительный стек вызовов, иногда нет. В незначительном количестве случаев стек может быть действительно поврежден. Возможно, в 1/3 всех случаев установленный обработчик исключений вообще не вызывается! Я предполагаю, что это почему-то проблема обработки исключений, структурированных в Windows.