Проблемы чтения памяти при анализе аварийных дампов ядра Windows

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

Используйте !lmi <module name>и проверьте, есть ли в поле характеристик значение «perf», чтобы определить, оптимизирован ли код.

Как указано в Отладка оптимизированного по производительности кода Полученная в результате оптимизация уменьшает количество страниц (и ошибок страниц) и увеличивает пространственную локальность между кодом и данными. Он устраняет ключевое узкое место в производительности, которое может быть вызвано неправильным позиционированием исходного кода. Компонент, прошедший эту оптимизацию, может иметь свой код или блок данных внутри функции, перемещенный в другие места двоичного файла. В модулях, которые были оптимизированы с помощью этих методов, расположение блоков кода и данных часто будет находиться по адресам памяти, отличным от тех мест, где они будут находиться после обычной компиляции и компоновки. Кроме того, функции могут быть разделены на множество несмежных блоков, чтобы наиболее часто используемые пути кода могли располагаться рядом друг с другом на одних и тех же страницах. Следовательно, функция (или любой символ) плюс смещение не обязательно будут иметь то же значение, что и в неоптимизированном коде. Эмпирическое правило при работе с оптимизированными по производительности кодами заключается в том, что вы не можете выполнять надежную адресную арифметику в оптимизированном коде.

Вам нужно проверить вывод dv /V, чтобы определить, где отладчик на самом деле ищет местных жителей, и подтвердить, что это правильно.