Отказ приложения говорит: «Место чтения нарушения доступа»

Question

Мое приложение падает после 18 часов работы. Я не могу отладить точку в коде, где он на самом деле падает. Я проверил стек вызовов - он не предоставляет никакой информации как таковой. Последние несколько вызовов в стеке вызовов выделены серым цветом - это означает, что я не вижу кода этой части - все они принадлежат библиотекам MFC.

Тем не менее, я получаю это всплывающее окно «MicroSoft Visual Studio» при сбое, которое говорит:

Необработанное исключение в 0x7c809e8a в NIMCAsst.exe: 0xC0000005: Место чтения нарушения доступа 0x154c6000.

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

Answer 1

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

Answer 2

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

Моим первым предположением будет проверка кода, вызывающего код, который вылетел, на предмет возможных проблем, которые могли его вызвать. Есть ли у вас какие-либо другие исключения или условия ошибки до сбоя? Может быть, вы игнорируете ошибку возврата? Вы пытались использовать Debug Heap ? Как насчет adplus ? Верификатор приложения для включения проверки кучи?

Другие возможности включают запуск инструмента, такого как pclint, над кодом для проверки очевидных проблем использования памяти. Вы используете темы? Может быть, есть условие гонки. Этот список может продолжаться вечно.

Answer 3

Четко ли воспроизводится авария?

Если да, используйте лог-файлы! Вы должны использовать файл журнала и добавить операторы номера, которые просто регистрируют номер исходного файла / переданный номер строки. Начните с нескольких операторов в точке входа (основной обработчик событий) и наиболее распространенных путей выполнения. После сбоя проверьте последнюю запись в лог-файле. Затем добавьте новые записи по пути / путям, которые должны быть пройдены и т. Д. Обычно после нескольких итераций этой работы вы найдете точку отказа. В случае вашего длительного времени ожидания файл журнала может стать огромным, и каждая итерация займет еще 18 часов. Возможно, вам придется добавить какую-то технику ротации лог-файлов и т. Д. Но с помощью этой техники я смог найти несколько сравнимых ошибок.

Еще несколько вопросов:

Является ли ваше приложение многопоточным?

Использует ли он какие-либо массивы, не управляемые stl или сопоставимыми контейнерами (использует ли он C-Strings, C / C ++ - массивы и т. Д.)?

Answer 4

Как говорит Патрик, именно ваш код дает MFC недопустимые значения. Можно предположить, что вы передаете неправильную длину, поэтому библиотека читает слишком далеко. Но на самом деле существует множество возможных причин.

Answer 5

Приведенная выше информация говорит только о том, к какой памяти обращались незаконно.

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

Вы говорите, что видите стек вызовов, что говорит о том, что вы используете отладчик. Исходный код MFC доступен (но, возможно, не во всех версиях vc ++), так что в принципе его можно отследить. Какую версию VC ++ вы используете?

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

Иногда «местоположение» может быть распознано как данные, и в этом случае у вас есть подсказка. F.E. если ошибка говорит:

Место чтения нарушения доступа 0x31323334

вы бы узнали это как часть строки ASCII "1234", и это может привести вас к виновнику.

Answer 6

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

Answer 7

Попробуйте подключить отладчик к процессу и отключите его при нарушениях прав доступа.

Если это невозможно, то мы используем инструмент под названием «Дампер процесса пользовательского режима», чтобы создать дамп памяти процесса в точке, где произошло нарушение доступа. Вы можете найти это для загрузки здесь:

http://www.microsoft.com/downloads/details.aspx?FamilyID=E089CA41-6A87-40C8-BF69-28AC08570B7E&displaylang=en

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

Обратите внимание, что ВСЕ нарушения доступа в вашем процессе фиксируются - даже те, которые впоследствии обрабатываются, также полный дамп может создать время для создания в зависимости от объема памяти, используемого приложением (10-20 секунд для процесса потребляет 100-200 МБ личной памяти). По этой причине, вероятно, не стоит включать его в масштабе всей системы.

Затем вы сможете проанализировать дамп с помощью таких инструментов, как WinDbg (http://www.microsoft.com/whdc/devtools/debugging/default.mspx), чтобы выяснить, что произошло - в большинстве случаев вы обнаружите, что вам нужен только мини-дамп, а не полный дамп (однако, если ваш приложение не использует много памяти, тогда нет большого количества недостатков наличия полного дампа, кроме размера дампа и времени, которое требуется для создания дампа).

Наконец, имейте в виду, что отладка нарушений прав доступа с помощью WinDbg может быть довольно сложным и сложным процессом - если вы можете получить трассировку стека другим способом, то вы можете попробовать это в первую очередь.