Сбой приложения говорит: Доступ к месту чтения нарушения

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

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

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

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

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

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

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

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

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

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

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

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

Является ли сбой воспроизводимым?

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

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

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

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

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

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

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

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

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

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

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

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

Этот вопрос довольно старый, и у меня была такая же проблема, но я быстро ее решил - все дело в цепочках:

Во-первых, обратите внимание, что обновление GUI можно выполнить только в основном потоке.

Моя проблема заключалась в том, что я пытался обрабатывать графический интерфейс из рабочего потока (а не из основного потока), и у меня была та же ошибка: 0xC0000005< /сильный>. Я решил это, разместив сообщение (которое выполняется в основном потоке) - и проблема была решена:

typedef enum {
  WM_UPDATE_GUI
}WM_MY_MSG

// register function callback to a message
BEGIN_MESSAGE_MAP(CMyDlg, CDlgBase)
  ON_MESSAGE(WM_UPDATE_GUI, OnUpdateGui)
END_MESSAGE_MAP()

// For this example - function that is not invoked in the Main Thread:
void CMyDlg::OnTimer() 
{ 
  CString str_to_GUI("send me to gui"); // send string to gui
  // Update_GUI(str_to_GUI); // crashed
  ::PostMessage(hWnd, MyMsg::WM_UPDATE_GUI, (WPARAM)&str_to_GUI, 0);
}

HRESULT CMyDlg::OnUpdateGui(WPARAM wParam, LPARAM lParam)
{
  CString str = *(CString*)wParam; // get the string from the posted message
  Update_GUI(str);
  return S_OK;
}