Ошибка Access Violation

[AHTuKiLLeR]

Такой вопрос. У меня в проекте, совершенно неопреоделимо возникает ошибка Access Violation. Программа представляет собой управление устройствами через СОМ порт. "Посылка сообщения - прием сообщения - анализ сообщения - посылка нового сообщения - " и т.д. Посылка и прием сообщений происходят в двух потоках.
Подскажите. Как выловить где возникает данная пакость?

[BaronTreep]

Сделай брекпойнты (левее кода нажимаешь, появлятся красные маркеры) на которых программа будет останавливаться, можно будет посмотреть значения всех переменных. Хотя иногда при Access Violation Delphi сам ставит синим на больную строку...

[AHTuKiLLeR]

эти красные точечки (омг) не помагают. И синеньким ничто не подсвечивается. (опять таки омг)

Программа бывает работает час, а бывает и пять минут. Поэтому мне как-то сложно классифицировать место сбоя.
Пытался ловить конструкцией try...except...end; Не помогло.

[Stilet]

Смотреть нужно программу и отлаживать.

[AHTuKiLLeR]

Ну а какие есть программные способы вылавливания этой ошибки?

[Квэнди]

они все программные, об аппаратных не слышал.
У встроенного дебагера есть вагон возможностей от watch lists до стандартных брейкпоинтов с просмотром состояний, стека, и т.д. 90% проблем решаеются клавишами F4,F7,F8

[AHTuKiLLeR]

Вот сейчас прога работает больше часа. Спецом сижу и жду возникновение ошибки. То есть если прикинуть то прога рабочая. Но по закону пакости стоит уйти и она крашнется, что вводит меня в некую прострацию. Спрашивается "какого...."? Прога работает по замкнутому циклу. И прошла его уже не раз. Но ошибка эта все равно возникает. Почему?
Есть какие-нибудь другие операторы наподобии try...except для локализации проблемного участка кода?

[Stilet]

Есть какие-нибудь другие операторы наподобии try...except для локализации проблемного участка кода?

Скажем так: try...except - их обертка )

[BaronTreep]

Есть какие-нибудь другие операторы наподобии try...except для локализации проблемного участка кода?

1.
Try
...
Except
On <Класс1> do <Обработчик1>
On <Класс2> do <Обработчик2>
Else <Обработчик0>

Используется для ЯВНОГО назначения обработчиков для каждого класса ошибок, при этом дожно быть соответствие классов ошибок и методов обработчика. Без блока обработчиков компилятор считает, что исключения могут быть любые.

2.
Try
...
Finally
...
End;

Используют если важно коректное завершение процесса с точки зрения ОС, а не с точки зрения процесса. Это протекция ресурсов при ошибочном выполнении.

Предполагается, что эти блоки "молчат" при успехе, и выдают сообщения если не могут обработать исключение.

3.
В связи с чем, просто вылет программы - это конфликты на уровне windows в памяти. Если драйверы (самописные?) ссорятся с программой, например.
Debug -> Modules занимается отладкой взаимодействия с модулями. Но я в этом не разбираюсь - там на низком уровне всё...

4.
Win-Api функции часто сигнализируют об успешном/провальном выполнении. Если есть цепочка таких функцый 1-2-3-4... и где нибудь не устроить проверку на успешное выполнение, то дальше будут тащится неполные данные и последующие функции могут несработать...

5. Еще: можно сделать приложение, которое в реальном времени вызывает GetLastError и на этой основе делает лог ошибок (есть ещё функция перевода ИД ошибки в текст, забыл).