Уважаемый zltigo! Ваша точка зрения ясна. Большое спасибо за помощь.

Для поиска таких ошибок удобно использовать Hardware Breakpoint (J-Link/MT-Link).
Ставишь брык на запись в область памяти и отладка остановится прямо на команде записи. Затем изучаешь Registers/Disassembler

Ну типа спасибо Поймите правильно, я некоторое представление об отладке программ имею. В моём случае нужен бряк по изменению содержимого памяти. Подскажите лучше, как RDI по такому условию настроить.

Как то раз были у нас в конторе заскоки со стеком у MB90, долго маялись, в конце концов написал калькулятор стека (кстати, глядя на который Andy Mozzhevilov и затевал разговор) - calc_stk, но и это не помогло, дальнейший тЩательный разбор полетов выявил наезд стека на переменную, теперь все гуд.

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

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



Получил подтверждение тому, что что-то лезет на стек: вставил задержку перед выводом в DebugUnit, и стек слетать перестал. Посему очень интересен Ваш способ выхода из данной ситуации.

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

Типа, всегда пожалуйста
Про RDI точно не знаю - работаю в режиме J-Link
Там в отладке появляется менюшка J-Link -> Watchpoints
Дальше все интуитивно понятно, кроме поля Mask - его, обычно, надо ставить 0xFFFFFFFF

Не я один такой.
Тут недавно тоже у себя обнаружил ошибку в ручном распределение внешней памяти LPC2292 на 4 кольцевых FIFO буфера.
Все 4 буфера пересекались и длины не соответствовали.

Когда нашёл волосы дыбом встали как я такое понаписать мог (в 3-х макросах запутался)!

А ведь как-то год работало.
Видимо потому как данные в буфер попадали на очень небольшое время.