Странное исключение 0x0eedfade в программе многопоточности Delphi

Question

У меня странная проблема с моим многопоточным сервером. Это служба Windows и работает аналогично FTP-серверу, управляющему сокет-соединением со многими клиентами. Он был создан с использованием Delphi 2006 (Turbo Delphi) и хорошо работает на большинстве машин. К сожалению, на некоторых машинах он иногда сбрасывается без каких-либо следов от себя (исключение должно быть сохранено в журнале, но нет). Иногда система показывает MessageBox (не MessageBox от службы, но я думаю, что это система MessageBox), но чаще всего я вижу такую ​​информацию в системе EventLog:

Application popup: ht_switch.exe - Application Error : The exception unknown software exception (0x0eedfade) occurred in the application at location 0x77e4bef7. 

В заявке EventLog можно увидеть:

Faulting application ht_switch.exe, version 1.2.0.2, faulting module kernel32.dll, version 5.2.3790.5069, fault address 0x0000bef7. 

Иногда такие записи в Application или System EventLog, но ничего не происходит - мой сервер работает, как обычно, но иногда просто исчезает. Затем Service Manager сообщает в EventLLog, что мой сервис неожиданно остановился.

Я не вижу «общего» сценария для такой проблемы. Он появляется на некоторых WinXP, Win2003 и Win2008. Все тестовые машины имеют все исправления MS.

Я прочитал ответы на: 0x0eedfade kernelbase.dll faulting module in d7 windows service, но я не пользуюсь Dialog единицей.

Что нужно сделать для его ремонта? Как отслеживать такое исключение 0x0eedfade?

EDIT

я тестировал в течение нескольких дней мой сервер как с EurekaLog и madExcept.

EurekaLog:

Сервер работает без проблем. Никакое исключение не сообщается в EventLog. Никакое исключение не сообщается в %AppData%\EurekaLab s.a.s\EurekaLog\Bug Reports\ (для моей программы должен быть каталог, но он не был создан - я не знаю, должно ли оно быть создано или если это ошибка EurekaLog).

У EurekaLog7 есть проблемы с настройкой «Тип приложения» на службу Windows. Это известная проблема, и авторы работают над этим. Мой сервис, скомпилированный с ним, работает на WinXP, но не смог работать с Win2003. Это просто не начинается.

madExcept:

Сервер работал в течение 4 часов и разбился. Я поймал это исключение в своей теме:

EAccessViolation: Access violation at address 7C90100B in module 'ntdll.dll'. Read of address 00000018!!! 

Я не заметил ни одного отчета madExcept об этом исключении. После этого исключения один поток был потерян с гнездом в состоянии CLOSE_WAIT (другое закрытое соединение). Затем я перезапустил свой сервис, и через несколько часов он работал без проблем.

инвалидов EurekaLog и madExcept:

После 10-30 минут я вижу MessageBox с ошибкой. Но ошибка 0x0eedfade является загадочной и не показывает мне никакого намека на источник проблемы. Это также очень странно, потому что после отображения такой службы сообщений работает без проблем (большую часть времени).

Резюме О.Д. перехватчики исключений:

EurekaLog и madExcept, вероятно, хорошо исключения, поднятых Delphi, но это, кажется, что изменение поведение моей службы и ошибки волшебно исчезли или они сообщают исключение поставить не можем найти.

EDIT: Проблема решена

После некоторой отладки, которые приводят меня в никуда (Call Stack с очень странными местами) я ушел из нее и начал проверять, наконец, совершили больше изменений. Одно изменение было строковой операцией, в которой строка (AnsiString) может иметь длину 64 или 128 (какая-то битовая маска). Я установил 70-й символ строки, ранее выделенной SetLength(buffer, 64). Это была проблема. Я думаю, что я бы сэкономил время, включив проверку диапазона.

Answer 1

Как проследить такое исключение 0x0eedfade?

Это код исключения для Delphi. Очевидно, что вы поднимаете исключение Delphi, которое не обрабатывается, и это приводит к снижению вашего процесса.

Вы должны добавить madExcept, EurekaLog, JCLDebug или аналогичный вашему процессу. Эти инструменты будут генерировать отчеты о диагностике, когда ваш процесс завершится с ошибкой. Наиболее полезной частью этих отчетов будет трассировка стека в момент сбоя. Тогда вы должны уметь работать там, где происходит сбой, по крайней мере, и этого обычно достаточно, чтобы понять, что не так с вашим кодом.