Лучшие способы отладки приложения в режиме выпуска

Question

Я уверен, что это случалось с людьми раньше, что-то работает в режиме отладки, вы компилируете в выпуске, а что-то ломается.

Это случилось со мной, когда я работал в среде Embedded XP, лучший способ сделать это - написать файл журнала, чтобы определить, где он будет работать неправильно.

Что вы испытываете / открывали, пытаясь устранить досадную ошибку в режиме выпуска?

Answer 1

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

Мой опыт показывает, что, как правило, ошибка связана с кодом, который находится рядом с областью поломки. То есть, если вы видите проблему, возникающую в функции «LoadConfigInfoFromFile», то, вероятно, вам следует начать с ее тщательного анализа, а не «DrawControlsOnScreen», если вы знаете, что я имею в виду. Жуки типа «жуткое действие на расстоянии» не часто возникают (хотя, когда они появляются, они, как правило, являются главным медведем).

Answer 2

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

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

ADPlus объясняется здесь: httx: //support.microsoft.com/ SCID = т.п.н.% 3Ben-нами% 3B286350 & х = 15 & у = 12

В основном вам нужно сделать следующее: 1. Загрузите и установите WinDbg в C: \ debuggers. httx: //www.microsoft.com/whdc/devtools/debugging/default.mspx

2. Запустите ваше приложение

3. открыть cmd и cd для c: \ debuggers

4. Запустите adplus следующим образом:

"adplus.bat -crash your_exe.exe"

5. воспроизвести сбой

6. проанализировать краш-дамп в vs2005 или в windbg

Answer 3

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

Answer 4

Вы также можете скопировать ваши символы отладки в производственную среду, даже если они скомпилированы в режиме реверсирования

Вот статья с дополнительной информацией

Answer 5

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

Answer 6

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

Answer 7

Я согласен на отладку файла журнала, чтобы сузить его.

Я использовал «Ввод имени функции», «Выход из имени функции» до тех пор, пока не смогу найти, в какой метод он входит до сбоя. Затем я добавляю больше сообщений журнала, перекомпилирую и повторно выпускаю.

Answer 8

Как насчет использования операторов трассировки. Они там для проверки значения режима выпуска.

Trace.WriteLine(myVar);

Answer 9

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