Есть прога написанная на шестом билдере, немаленькая. Борландовских компонентов применено по минимуму: таймер, кнопки, таблицы, меню, картинки. Программа работает с RS-232 через WINAPI и активно выводит информацию в различные таблицы и сохраняет её на диск. Суть в том, что проекту 4 года, он постоянно растёт и видоизменяется, но всё это время в нём живёт досадная беда: переодически (не чаще чем раз в день, иногда раз в неделю) прога падает с стандартной ошибкой: "программа выполнила недопустимую операцию бла бла бла". Виндовский отчёт говорит следующее: исключение произошло в модуле kernel32, по смещению 0x01EB33. Соответственно выяснить что-то средствами билдера или обычными отладчиками - сложно. С ядерными отладчиками я не знаком. Идей несколько: 1) какой-то из компонентов билдера, используемых мной, косячит, но какой?. 2) проблемы в моём коде (и я их не могу найти уже 4 года). Место падения я более-менее локализовал (с точностью до 3 тысяч строк кода, хаха)))) там идёт активная работа с памятью, указателями и выводом в небольшую TStringGrid. сначала там была динамическая память, в целях эксперимента поменял всё на статические массивы - результата это не дало =\. Состояние всех указателей проверил - всё железно. Никто ни куда не вываливается. Что делать?
Для начала надо проанализировать сообщение винды об ошибке (там должен быть код ошибки или краткое описание). Затем локализуйте функцию из kernel32, в которой происходит исключение (утилита типа Dependency Walker) - дальше уже попроще будет.
>> Виндовский отчёт говорит следующее: исключение произошло в модуле kernel32, по смещению 0x01EB33 Взять отладчик, поддерживающий символы, загрузить последние с сайта ms, приаттачиться к процессу, посмотреть в стек.
Завернуть подозрительные процедуры в try/except и для каждой из них выводить уникальное сообщение. Ну и поставить OllyDebug в качестве тотального отладчика и посмотреть, что валяется на стеке. Какой-то из адресов вида 4хххххх скорее всего являются адресом возврата в твою программу. Предварительно нужно попросить Билдер сделать тебе map-файл, по этому map-файлу можно раскопать, в какую функцию этот адрес возврата ведёт.
на сколько я понял - билдеровский трай/эксепт распространяется только на код основного модуля. на системные библиотеки ему фиалетово =\ естественно, что я пробовал сомнительные функции заключить в try, однако они никаких сообщений не выдавали. программа продолжала падать ругаясь на кернел.
код ошибки вроде 1000 показывает, что адрес 1EB33 в kernet32 - это где-то в середине CreatPipe (который я явно не вызываю. только если сам билдер)
tru в винде использует seh, а системные функции часто поверх него ставят свой seh, который и роняет прог не передавая твоему управления, хотя по хорошему должны бы. Для решения этой проблемы как раз и придуман veh, попробуй сам обернуть им не надеясь на компилятор.
Arisu тебе уже сказали ответ выше, дамп сгенерировать, и колстек получить, проанализировать, исправить
