Место чтения нарушения доступа перед входом в основной

После обновления с Visual Studio 2012 до Visual Studio 2015 мой проект получает повреждение кучи и ошибки нарушения доступа, даже не достигнув основной функции. Там просто нет кода, который я могу отлаживать. Я проверил статические переменные и все, что может быть создано в стеке, но у меня их нет. Я попытался запустить программу с пустой основной функцией:

int main(){return 0;};

но я все еще получаю ошибку нарушения доступа. Программа представляет собой форму GUI со смешанным кодом C ++ / CLI. Я удостоверился, что восстановил сторонние библиотеки (curl) из исходного кода с VS2015 и использую правильные библиотеки DLL. Понятия не имею, откуда эти ошибки — раньше все работало нормально. Как я могу это исправить / отладить? Я много гуглил и пытался даже запустить gflags, но отладчик не останавливается на каком-либо читаемом человеком коде. Ошибка гласит:

Возникло исключение 0x5A4C7988 (verifyier.dll) в MyProgramName.exe: 0xC0000005: Место чтения нарушения доступа 0xA46FEC13.

РЕДАКТИРОВАТЬ 1:
verifyier.dll не имеет ничего общего с ошибкой. Оказывается, эта библиотека загружается, когда я добавляю файл изображения в gflags.exe при попытке отладки программы. После отмены этих изменений я вернулся к исходному сообщению об ошибке, которое является повреждением кучи, вызванным ntdll.dll.

РЕДАКТИРОВАТЬ 2:
Я сократил код до минимума, удалив все файлы .h и .cpp, пока ошибка не исчезнет. Это очень неэффективный способ отладки, но так как я не знал ничего лучшего, я все равно сделал это.

#include "MyGUI.h"#include <boost/date_time/posix_time/posix_time.hpp>

[STAThread]
void main(array<String^>^ args) {
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew MyProject::MyGUI);
}

Если я тогда уберу строку

#include <boost/date_time/posix_time/posix_time.hpp>

затем проблема исчезает, и графический интерфейс запускается без ошибок.

Причина, по которой я получил ошибку нарушения доступа, заключается в том, что библиотека posix_time молча связывает файл .lib. Когда я перешел с VS2012 на VS2015, я перестроил все библиотеки наддува в нескольких вариантах, и дополнительные каталоги библиотек были правильно указаны в проекте и содержали правильные варианты библиотек. Я использовал библиотеку posix_time в других проектах без проблем, однако другие проекты были нацелены на x64 бит, но у меня возникла проблема с x32 бит. Я связывал x32-битный проект с директорией lib32 моей надстройки, и это правильно. Оказывается, причиной сбоя моего приложения стала ошибка в 32-битной версии библиотеки posix_time. Даже связывание моего 32-битного приложения с папкой x64 решает проблему. Тем не менее, так как я не использовал микросекунды,

BOOST_DATE_TIME_NO_LIB

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

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

Последняя цитата и тот факт, что 64-битная библиотека работает нормально, заставляют меня думать, что 32-битная реализация библиотеки является ошибочной.

Для тех, кто может найти это полезным — это было причиной. Что касается моего первоначального вопроса как отладить такой сбой когда куча повреждается даже до того, как точка входа достигнута (и, следовательно, нет никакого исходного кода или отладочной информации) не тратя 7 часов на разбор проекта, пока не останется только одна строка — Я оставляю вопрос открытым.

Если кто-то может указать на лучший подход, чтобы найти такие ошибки — это будет очень поучительно.

РЕДАКТИРОВАТЬ 3:
Видимо, это не конец. После исправления буст-библиотек и возврата к полному коду я снова получил ошибку. Проблема вызвана использованием статической переменной в обратном вызове метода формы окна GUI:

System::Void comboBoxStart_SelectionChangeCommitted(System::Object^  sender,
System::EventArgs^  e) {

static wstring LastChoice; //This line is enough to reproduce the crash

}

Может кто-нибудь объяснить, почему это приводит к место чтения нарушения прав доступа? Подобные симптомы описаны в этот сообщение.

3

Решение

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

Ваше сообщение об ошибке упоминает, что verifier.dll является источником проблемы. Вы должны исследовать эту DLL в первую очередь. Вы построили это сами? Есть ли у него все необходимые зависимости для запуска?

2

Другие решения

Нарушение прав доступа было вызвано использованием статических переменных в управляемом коде. Я использовал статическую переменную wstring тип (нативный тип C ++!) внутри окна формы обратного вызова GUI (управляемый код). Я предполагаю, что программа пыталась инициализировать переменную до завершения инициализации управляемого кода, вызывая ошибку еще до того, как она достигла точки входа в программу.

После удаления всех статических переменных из управляемого кода проблема исчезла.

0

По вопросам рекламы [email protected]