Visual Studio отладка ошибок в C ++

Question

По какой-то причине встроенный отладчик вызывает ошибку, как только я делаю ссылку на класс dll стороннего поставщика. Этот же код выполняется, когда он собран и запущен как релиз, отдельно. Два свойства для отладки и выпуска должны быть такими же, как я на самом деле не изменил их. Я добавил файл lib в путь для обеих сборок. У меня просто есть:

ClassNameFromDll blah;

Когда до меня доходит, я получаю следующее исключение:

Необработанное исключение в 0x78a3f623 (mfc90ud.dll) в MTGO SO Bot.exe: 0xC0000005: Место чтения нарушения доступа 0xf78e4568.

Встречается в: afxtls.cpp, строка 252.

Это приложение MFC, но я на самом деле не использую никакой MFC, кроме очень простого графического интерфейса, который запускает событие, которое все win32. Я использую Visual Studio 2008 Express.

Answer 1

Глядя на файл atltls.cpp из моей установки VC9, происходит сбой здесь:

inline void* CThreadSlotData::GetThreadValue(int nSlot)
{
    EnterCriticalSection(&m_sect);
    ASSERT(nSlot != 0 && nSlot < m_nMax);
    ASSERT(m_pSlotData != NULL);
    ASSERT(m_pSlotData[nSlot].dwFlags & SLOT_USED);   // <== crash
    // ...
}

Таким образом, причина сбоя не возникает в сборке релиза, потому что ASSERT () не используется в этой сборке. Я не знаком с использованием ATL потокового локального хранилища, но это утверждение указывает, что что-то запрашивает значение в слоте, где еще ничего не было сохранено.

Является ли инициализация этого слота TLS вашей обязанностью или ответственностью сторонней DLL, я не знаю.

Похоже, GetThreadValue() имеет некоторые дополнительные средства защиты, так что он будет возвращать указатель NULL в сборке релиза для неинициализированного слота (хотя я не уверен, что это будет гарантировано) - держу пари, что Сторонние библиотеки DLL полагаются на это поведение (т. Е. Проверяют наличие NULL-возврата), поэтому в сборках выпуска не происходит сбоев. Обратите внимание, что поставщик может использовать класс CThreadSlotData косвенно (трассировка стека даст подсказку об этом), поэтому он может не знать о его ожиданиях.

Answer 2

занимаясь психической отладкой

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

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

Answer 3

Есть ли у вас трассировка стека, которую вы можете опубликовать? Это может иметь некоторую полезную информацию.

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

Если поставщик не доступен или недостаточно отзывчив:

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

Даже если у вас нет источника для сторонней библиотеки DLL, я думаю, что лучший способ действий - это проследить через конструктор для ClassNameFromDll, чтобы попытаться выяснить, что происходит не так. Это может помочь сравнить путь инструкций в сборке Debug с сборкой Release.

Источник MFC распространяется вместе с MSVC (возможно, не с версией Express, но я думаю, что со всеми другими версиями), поэтому, когда вы войдете в код библиотеки MFC DLL, вы можете найти источник, который будет полезен для выяснения того, что происходит на.