Это длинный ответ, но вкратце: на PDB x86 содержится информация FPO, которая позволяет отладчику надежно раскручивать стек вызовов. Это требуется в случае кадров FPO, где EBP не используется в качестве указателя кадра. В отсутствие PDB отладчик предполагает, что каждый кадр является кадром EBP, и будет просто проходить цепочку EBP, пока не достигнет конца (то есть нечитаемого значения EBP).
Для получения более подробной информации о кадрах FPO и EBP, есть хорошая статья здесь:
http://www.nynaeve.net/?p=91
Теперь перейдем к вашей проблеме. Первый стек вызовов, который вы показали, абсолютно корректен. Некоторые модули вызвали исключение, поэтому O / S начал раскручивать фреймы вызовов в поисках обработчика исключений. К сожалению, никто не обработал ошибку, поэтому запустился обработчик исключений по умолчанию, что привело к сбою приложения. Поскольку стек вызовов нарушающего кода был размотан, вы не видите ничего, кроме компонентов, поставляемых O / S, в стеке.
Во втором случае у вас нет символов, и поэтому O / S обрабатывает каждый кадр вызова, как будто это EBP. В этом случае вам повезло, и вы взяли сборщик мусора, который начал раскручивать старый стек вызовов. Хотя в данном случае он указывает на правильную вещь, это своего рода красная сельдь, которая может привести к тому, что вы начнете свой анализ с неверными данными и потратите МНОГО времени (было там, сделали это!).
Команда .excr всегда правильная вещь в случае исключения. Это работает, потому что O / S сохраняет состояние регистра процессора во время исключения, прежде чем раскручивать кадры вызова, ища обработчик исключения. Команда .excr использует это состояние, чтобы вернуть вас во времени к моменту обнаружения плохого состояния, а не после того, как O / S пытался его обработать.
-Скотт