Приложение C ++ DX11 работает только в Visual Studio IDE - PullRequest
4 голосов
/ 23 июня 2011

Хорошо, я представил этот вопрос на форумах MSDN, но пока не получил никакого ответа, поэтому я решил попробовать StackOverflow.

В настоящее время я разрабатываю приложение DirectX с использованием VS2008 наWin7.Недавно я столкнулся с неприятной ошибкой повреждения памяти, связанной с классом выделения памяти, который захватывал память с выравниванием байтов.Во время этой ошибки я все еще мог запустить исполняемые файлы отладки и выпуска, однако это могло произойти сбой из-за испорченных инструкций или чего-то еще, но это все еще выполнялось бы некоторое время до сбоя.

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

Обходчик зависимостей выдает «Предупреждение: по крайней мере один модуль зависимости задержки и нагрузки былне найдено. Предупреждение: по крайней мере один модуль имеет неразрешенный импорт из-за отсутствия функции экспорта в модуле, зависящем от задержки и загрузки. "ошибка и указывает, что GPSVC.dll и IESHIMS.DLL не могут быть найдены.Я читал, что это может вводить в заблуждение и просто указывает на потенциальную проблему где-то.И ходок Dependency не дал мне эту ошибку накануне.

Я не возился ни с одной из конфигураций или настроек проекта или добавил новый код.Любая идея о том, что может быть причиной такого поведения?

Также еще одно замечание, я установил Windows 7.1 SDK в тот же день.Думаешь, это может быть какая-то ошибка, связанная с компилятором?

На всякий случай, если на пост MSDN выскакивает полезная информация, вот ссылка http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019

Спасибо!

Редактировать -

Вот последние несколько строк вывода профилирования Dependency Walker

GetProcAddress (0x76CD0000 [c: \ windows \ syswow64 \ KERNEL32.DLL]], "DecodePointer") вызывается из "c: \ windows \ syswow64 \ NVWGF2UM.DLL" по адресу 0x6D8BAE4F и возвращает 0x77B59D65.GetProcAddress (0x76CD0000 [c: \ windows \ syswow64 \ KERNEL32.DLL], «DecodePointer») вызывается из «c: \ windows \ syswow64 \ NVWGF2UM.DLL» по адресу 0x6D8BAE4F и возвращает 0x77B59D65.GetProcAddress (0x76CD0000 [c: \ windows \ syswow64 \ KERNEL32.DLL], «EncodePointer») вызывается из «c: \ windows \ syswow64 \ NVWGF2UM.DLL» по адресу 0x6D8BAF60 и возвращает 0x77B60FDB.GetProcAddress (0x76CD0000 [c: \ windows \ syswow64 \ KERNEL32.DLL], «DecodePointer») вызывается из «c: \ windows \ syswow64 \ NVWGF2UM.DLL» по адресу 0x6D8BAF70 и возвращает 0x77B59D65.Второе случайное исключение 0xC0000005 (нарушение прав доступа) произошло в «c: \ users \ joel \ desktop \ DXAPP.EXE» по адресу 0x0110152E.Выход "c: \ users \ joel \ desktop \ DXAPP.EXE" (процесс 0x27D8) с кодом 255 (0xFF).

Имеется ли в виду, что DLL получает нулевой указатель или мои действительные инструкции?Я собираюсь прочитать о том, как использовать WinDbg очень быстро, и я опубликую его результаты, если это не проливает немедленный свет на проблему.

Edit 2 -

Простой запуск приложения и отладка для запуска Visual Studio последовательно привели меня туда, где я собираю свои шейдеры.Я предполагаю, что корень проблемы лежит в этом.Тем не менее, я все еще не понимаю изменения поведения во время выполнения между использованием IDE и не.

Решение!-

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

1 Ответ

0 голосов
/ 23 июня 2011

Стреляйте, извините, я хотел опубликовать это как комментарий ...

Я могу только предложить больше попыток диагностики.

Можно было бы профилировать приложение изнутри Зависит, это будеттакже показать динамические загрузки DLL и может показать что-то новое.Также это захватывает выходные данные отладки.Он может вести себя иначе, чем запуск в самом отладчике, и давать подсказку.Вы не упомянули фактическое профилирование, поэтому я подумал, что предложу это, если вы этого не сделали.Кроме того, обращайте очень пристальное внимание на пути для загруженных библиотек DLL - вы можете быть удивлены загрузкой DLL из местоположения, отличного от запланированного.

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

Наконец попробуйте подключить (или даже запустить из) WindDbg, а не IDE.Как и в профиле Depends, разница в поведении отладчика и в том, как приложение перехватывает приложение, может привести к сбою, предоставляя необходимые подсказки.

Удачи!

...