Падение приложения, crash без визуализации

← →
Es (2013-05-14 18:22) [0]

Есть приложение, работает на сервере (в смысле, что на Win server 2008), но не в виде сервиса, а как обычное GUI приложение + много потоков в виде обработчиков.

Беда в том, что иногда приложение просто исчезает. Смотрят - а его нету в процессах, никаких сообщений, ну как будто не было.
Приложение под еврикой, но никаких .elf отчетов рядом не обнаруживается.

Возникает вопрос - как копать и куда. В каких случаях windows вообще может терминировать процесс, причем так втихую? Как искать место затыка?

Если это исключение в главном потоке, то почему оно не перехватывается стандартным кодом VCL?

← →
Плохиш © (2013-05-14 18:34) [1]

Смотри логи виндовс.

← →
Дмитрий С © (2013-05-14 18:34) [2]

А в журнале про это что-нибудь написалось?

← →
Es (2013-05-14 18:35) [3]

как именно

← →
Rouse_ © (2013-05-14 18:39) [4]

> В каких случаях windows вообще может терминировать процесс,
> причем так втихую? Как искать место затыка?

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

← →
Es (2013-05-14 18:44) [5]

нашел один из крешей в eventvwr:

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2ae0, application start time 0x01ce4ed2616a69ba.

← →
Es (2013-05-14 18:48) [6]

Rouse_, а делать то что, как можно искать проблему? Приложение достаточно большое, чтобы каждую строчку просматривать, да и утопический это подход.

Как я понимаю, ставить try..except по коду и пытаться писать исключения в лог - это тоже не прокатит.

А куда копать тогда...

← →
Плохиш © (2013-05-14 18:50) [7]

> 0xc0000005

Access Violation

← →
clickmaker © (2013-05-14 18:51) [8]

> exception code 0xc0000005

Access denied
Смотри, куда твоя тулза просит доступ, и где ей может быть отказано.

← →
Rouse_ © (2013-05-14 18:52) [9]

c0000005 - AccessViolation
твой оффсет: 0х41440 + база загрузки
Запускай приложение и становись бряком на этот адрес - там уже и смотри.

← →
Rouse_ © (2013-05-14 18:54) [10]

А, кстати у тебя внятрях NTDLL падает, так что может вместо базы придется инстанс этой библиотеки добавлять.

← →
Rouse_ © (2013-05-14 19:02) [11]

зы: забыл, в случае ntdll адрес рассчитываешь $41440 + GetModuleHandle(ntdll32), переходишь в CPU View, ставиш бряк, запускаешь процесс, ждеш сработки - по стеку вызовов уточняешь что за функция расположена по данному адресу (в случае если в отладчике не размапятся имена, обычно они видны).
Потом переопределяешь ее на свой вызов (любым доступным способом) и логируешь вызовы, пока не упрешся в падение.
Если я прав и падает из-за порчи стека, то полагаться на try..finally смысла не имеет - они не сработают. В этом случае используй механизм VEH
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681420(v=vs.85).aspx

← →
Es (2013-05-14 19:15) [12]

Rouse_, нихрена не понял арифметики.

Вообще, если падает внутрях ntdll - по идее, причем тут мой модуль? Получается, код ntdll сделал нечто такое, что некорректно сработало с памятью, верно?

>fault offset 0x00041440

он пишется относительно чего? Если относительно "нуля" - то я так понимаю, просто по этому адресу и располагается Ntdll?

← →
Es (2013-05-14 19:16) [13]

Rouse_, а, кажется понял. Винда пишет адрес:

>fault offset 0x00041440

относительно начала модуля, который она указывает:

>faulting module ntdll.dll

?

← →
Rouse_ © (2013-05-14 19:18) [14]

угу

← →
Es (2013-05-14 19:23) [15]

все равно непонятно - а почему это исключение в ntdll не перехватывается программой?

Какой-то настолько глобальный трындец, что портится стек, а при этом в некую неизвестную функцию ntdll передаются параметры (ну собственно из-за стека), которые заставляют ntdll обратиться в непонятную область памяти?

← →
Es (2013-05-14 19:27) [16]

большая беда в том, что падения бывают раз в неделю при круглосуточной работе. А бывают и 3 раза в день...

И дело в том, что на девелоп-машине я не могу запустить программу с рабочими данными. А если я не запущу с рабочими данными - есть подозрение, что до вызова нужной функции вообще дело не дойдет.

Плюс программа крутится на windows server 2008, а у меня Win 7 рабочая.

Могу вытащить ntdll с той машины, но как по смещению понять функцию? ...

← →
Rouse_ © (2013-05-14 19:37) [17]

> а почему это исключение в ntdll не перехватывается программой?

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

Функция в NTDLL может работать с памятью, ну например какой-нить VirtualFree которому ты передал адрес страницы со стека или еще чего.

> Могу вытащить ntdll с той машины, но как по смещению понять
> функцию? ...

В любом отладчике открыть и посотреть что там расположено.

← →
Es (2013-05-14 21:51) [18]

воспользовался статьей: http://www.twintechs.com/2008/11/how-to-find-what-function-is-at-a-dll-offset-without-having-debug-symbols/

Запустил OllyDbg на искомой машине, подгрузил туда ntdll.dll
Он начинался с адреса: 76EE1000. В статье прочитал, что это значит базовый адрес: 76EE0000

Приплюсовал свое смещение 41440, получилось: 76F21440
Получилось такое:

http://img14.imageshost.ru/img/2013/05/14/image_51926b0405576.png

(инструкция MOV EDI, EDI - могло из-за этого?)

← →
Es (2013-05-14 21:51) [19]

Пошел вверх до значка "$" - написано, что так отладчик обозначает функции, получился адрес: 76F21349

http://img14.imageshost.ru/img/2013/05/14/image_51927c3d40728.png

Далее сказано идти в " Debug > Call DLL Export"... И офигеть, там функции отсортированы не по адресам... Просмотрел весь список!!! Убил глаза в хлам... Функции с началом адреса 76F21349 не нашел...

← →
Es (2013-05-14 21:55) [20]

на всякий случай выкладываю целевой ntdll.dll - http://webfile.ru/6519741 (526 кбайт, нужно выбрать "скачать напрямую"), может кто подсобит...

← →
clickmaker © (2013-05-14 22:04) [21]

> MOV EDI, EDI - могло из-за этого?)

вряд ли. Это просто NOP по сути

← →
clickmaker © (2013-05-14 22:13) [22]

может быть, дело в этом: http://habrahabr.ru/post/90377/

← →
Rouse_ © (2013-05-14 22:17) [23]

Из-за этого не могло.
MOV EDI, EDI - это пролог MS API использующих технологию HOT_PATCH.
В данном случае я опознаю данную функцию как RaiseException.
В итоге ты просто получил адрес вызова финального исключения в отсутствие обработчика оного.

Получается теперь у тебя только один способ и остался - использование VEH.
Установи VEH обработчик и попробуй логировать исключения через него, с целью получить адрес вылета.

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

← →
Rouse_ © (2013-05-14 22:22) [24]

> clickmaker © (14.05.13 22:04) [21]

Тезка, не болтайте ерундой :)
Изменение регистров в случае MOV отличается от штатного поведения NOP.

Ну и раз уж пошла ссылка на хабр, то для Delphi сообщества более адекватной и менее ошибочной (даже в плане изложения материала) будет данная ссылка :)
http://habrahabr.ru/post/178393/

← →
clickmaker © (2013-05-14 22:46) [25]

> Тезка, не болтайте ерундой :)

собственно, все ссылки в гугле по mov edi,edi и ведут на хот-патч

← →
Rouse_ © (2013-05-14 22:57) [26]

> clickmaker © (14.05.13 22:46) [25]
> > Тезка, не болтайте ерундой :)
>
> собственно, все ссылки в гугле по mov edi,edi и ведут на
> хот-патч

Сань, в приведенной тобой ссылке нет упоминания о хотпатче.
Более того есть куча ошибок, о части которых я уведомил автора статьи.
К примеру (даже не буду рассматривать пропуск стаба): "Кроме того, если размер функции меньше 5 байт, перехват просто невозможен."

Это есть неверно.

Ну либо:

"3. Скопировать туда первые 5 байт исходной функции до установки туда перехватчика."

С учетом что максимальный размер инструкции может быть равен 14-ти байтам, я не думаю что разрезание инструкции по ее середке будет оправдано :)

← →
clickmaker © (2013-05-14 23:13) [27]

> [26] Rouse_ © (14.05.13 22:57)

да хрен с ней, со статьей. Я предположил просто, не может ли попытка этого хот-патча привести к исключению...

← →
Rouse_ © (2013-05-14 23:29) [28]

> clickmaker © (14.05.13 23:13) [27]

Если правильно его использовать - то нет, тем-более данная метода обычно выполняется сторонним приложением, а не тем, которое падает.
При неправильном использовании можем вылезти на вот такие вот нюансы: http://alexander-bagel.blogspot.ru/2012/11/debuger-2.html#false_disasm

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

← →
Es (2013-05-15 00:08) [29]

> MOV EDI, EDI - это пролог MS API использующих технологию
> HOT_PATCH.
> В данном случае я опознаю данную функцию как RaiseException.
>
> В итоге ты просто получил адрес вызова финального исключения
> в отсутствие обработчика оного.

ох долго мне переваривать эти строки...

Насколько я понял, HOT_PATCH - это такая штука, что в начало функции вставляется двухбайтовая команда mov EDI, EDI (которая ничего по сути не делает), чтобы потом было легче начало функции перезатереть и переправить на свою функцию (аля перехват)?

Уже тут я не понял. Если рассмотреть вывод винды:

>fault offset 0x00041440

я так понимаю, относительно начало модуля ntdll.dll по указанному смещению находилась инструкция, выполнение которой и завершилось исключением? Обработка исключения при этом нифига не произошла, потому что к тому времени стек был нагло испохаблен.

Но по этому адресу, если я все сделал правильно, находится инструкция MOV EDI, EDI (безобидная). Означает ли это, что вместо данной инструкции на момент выполнения программы там находилась другая инструкция?

Может, тогда стоит запустить программу и просто считать какая реально команда находится в загруженном приложении по этому смещению?

Также я не понял фразу:

> В данном случае я опознаю данную функцию как RaiseException.

что имеется в виду под "данную функцию"? И каким образом произошло опознание, по представленной картинке?

← →
Es (2013-05-15 00:18) [30]

> Установи VEH обработчик и попробуй логировать исключения
> через него, с целью получить адрес вылета.

вот не понял опять :(
Я так попытался прочитать про VEH, как я понял это возможность перехватывать исключения. При этом я получу информацию о них, несмотря на то, что callstack разрушен. Но я не понял:

1) почему собственно обычные исключения перестают работать, если callstack испоганен? Исключения же не в стеке хранятся?

2) каким все таки образом поможет VEH? Вот получу я управление после исключения.. а дальше? (

← →
Cobalt © (2013-05-15 01:23) [31]

может на серваке какая утилита криво перехватывает функции?
Сравни загруженные в АП длл-ки

← →
Es (2013-05-15 02:15) [32]

да не, исключено почти. Корпоративный сервер, особо никакого лишнего софта (хакерского).

Очень нагруженная программа, крутится неделями, может неделю работать, может за день два раза упасть... Кривой код и проблема с памятью во сто крат вероятнее...

← →
Германн © (2013-05-15 02:51) [33]

> ох долго мне переваривать эти строки...

> > Установи VEH обработчик и попробуй логировать исключения
> > через него, с целью получить адрес вылета.
>
> вот не понял опять :(
>

Ох действительно долго. Ну разве что Розыч почему-то захочет помочь. :)

← →
Германн © (2013-05-15 03:27) [34]

> Ну разве что Розыч почему-то захочет помочь. :)
>

Как-то иначе я его совет: "Установи VEH обработчик" я просто не воспринимаю. :)
Понимаю, что Саша живёт в своём мире. :)

← →
Dimka Maslov © (2013-05-15 08:28) [35]

В своё время я долго блися с подобной проблемой падения многопоточного сервера. Как я понял это происходит из-за плохой синхронизации потоков при обращении к менеджеру памяти. Причём, как на С++, так и на Delphi. Возможных решений два - написать свой менеджер памяти или сделать приложение службой, заставив систему перезапускать его в случае сбоя. Второе решение гораздо проще.

← →
Rouse_ © (2013-05-15 10:31) [36]

> что имеется в виду под "данную функцию"? И каким образом
> произошло опознание, по представленной картинке?

Немного промахнулся, это LdrInitializeThunk

.text:77F11440 ; __stdcall LdrInitializeThunk(x, x) .text:77F11440 public _LdrInitializeThunk@8 .text:77F11440 _LdrInitializeThunk@8 proc near .text:77F11440 .text:77F11440 arg_0 = dword ptr 8 .text:77F11440 arg_4 = dword ptr 0Ch .text:77F11440 .text:77F11440 mov edi, edi .text:77F11442 push ebp .text:77F11443 mov ebp, esp .text:77F11445 push [ebp+arg_4] .text:77F11448 push [ebp+arg_0] .text:77F1144B call _LdrpInitialize@8 ; LdrpInitialize(x,x) .text:77F11450 push 1 .text:77F11452 push [ebp+arg_0] .text:77F11455 call _ZwContinue@8 ; ZwContinue(x,x) .text:77F1145A push eax .text:77F1145B call _RtlRaiseStatus@4 ; RtlRaiseStatus(x) .text:77F11460 int 3 ; Trap to Debugger .text:77F11461 nop .text:77F11462 nop .text:77F11463 nop .text:77F11464 nop .text:77F11465 nop .text:77F11465 _LdrInitializeThunk@8 endp

Что впрочем тоже мало что нам дает.

> 1) почему собственно обычные исключения перестают работать,
> если callstack испоганен? Исключения же не в стеке хранятся?
>

Исключения нет, но в стеке размещаются SEH фреймы, которые и перехватывают исключения.

> 2) каким все таки образом поможет VEH? Вот получу я управление
> после исключения.. а дальше? (

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

← →
Плохиш © (2013-05-15 10:36) [37]

Вроде в Delphi тоже Remote Debugger есть.

← →
Es (2013-05-15 12:15) [38]

> Немного промахнулся, это LdrInitializeThunk

классно. А как ты узнал, что это LdrInitializeThunk?

У меня адрес исключения - 76F21440, на твоей системе в той же DLL я так понял это 77F11440, но откуда столько строк под этим адресом? Если был бы приведен листинг:

.text:77F11440 mov edi, edi .text:77F11442 push ebp .text:77F11443 mov ebp, esp .text:77F11445 push [ebp+arg_4] .text:77F11448 push [ebp+arg_0] .text:77F1144B call _LdrpInitialize@8 ; LdrpInitialize(x,x) .text:77F11450 push 1 .text:77F11452 push [ebp+arg_0] .text:77F11455 call _ZwContinue@8 ; ZwContinue(x,x) .text:77F1145A push eax ... ...

то это прям совпадало бы с тем, что я видел. Но откуда эта надстройка:

.text:77F11440 ; __stdcall LdrInitializeThunk(x, x) .text:77F11440 public _LdrInitializeThunk@8 .text:77F11440 _LdrInitializeThunk@8 proc near .text:77F11440 .text:77F11440 arg_0 = dword ptr 8 .text:77F11440 arg_4 = dword ptr 0Ch .text:77F11440

Это говорит о том, что по адресу 77F11440 находится непосредственно точка входа в LdrInitializeThunk?

А как он может быть точкой исключения? Управление передано по этому адресу... и тут же исключение? Там же никакого кода, первая команда же MOV EDI, EDI - она же ничего не делает!
Не понимаю... Что за адрес исключения тогда в журнале винды? (

← →
Rouse_ © (2013-05-15 12:20) [39]

> классно. А как ты узнал, что это LdrInitializeThunk?

Ты открывал в OllyDebug, а у меня лицензионная IDA Pro + установленные символы, поэтому информации выдается в разы больше.

> Там же никакого кода, первая команда же MOV EDI, EDI - она
> же ничего не делает!

Ну вариантов на самом деле много, самый простой - по данному адресу были выставлены неверные аттрибуты страницы, что и привело к падению.
Либо второй вариант, из-за срыва стека получить точный адрес ошибки не удалось и вылез вот этот вот оффсет.

← →
Es (2013-05-15 12:22) [40]

> Ты поймаешь точный адрес исключения и сможешь вытащить всю
> цепочку вызовов, чтобы определить какой именно код вызвал
> падение.

а что значит точный адрес исключения? Почему адрес исключения винды не точный? Она ведь по идее должна отловить именно указатель на ту инструкцию, которая вызвала исключение?

> и сможешь вытащить всю цепочку вызовов, чтобы определить
> какой именно код вызвал падение.

а как я вытащу цепочку вызовов, если callstack"у хана на тот момент уже? (

← →
Inovet © (2013-05-15 12:24) [41]

> [38] Es (15.05.13 12:15)
> Но откуда эта надстройка:

Это псевдонимы, или как их там называют. В машинном коде их нет.

← →
Rouse_ © (2013-05-15 12:25) [42]

> а что значит точный адрес исключения?

тот в котором действительно происходит AV

> а как я вытащу цепочку вызовов, если callstack"у хана на
> тот момент уже? (

Двойным проходом. В первый раз запоминаешь условия, при которых произошло падение.
Перезапускаешь приложение с установкой бряка по пойманному адресу и снимаешь стек вызовов до разрушения стека.

← →
Es (2013-05-15 12:26) [43]

> самый простой - по данному адресу были выставлены неверные
> аттрибуты страницы

а почему могут быть выставлены неверные атрибуты страницы на область памяти, где содержится код _очень_ системной DLL ?!

> из-за срыва стека получить точный адрес ошибки не удалось
> и вылез вот этот вот оффсет.

странно... Я не спорю, понимаю мало... Но ведь вроде есть указатель такой - какой код по какому адресу сейчас исполняется, он ведь не в стеке хранится... Происходит исключение доступа - винда его перехватывает и просто должна (по идее) записать в журнал адрес той инструкции, которая выполнялась... как она тут может ошибиться?

← →
Rouse_ © (2013-05-15 12:28) [44]

> а почему могут быть выставлены неверные атрибуты страницы
> на область памяти, где содержится код _очень_ системной
> DLL ?!

Обычно при перехвате меняются атрибуты страницы. Но причин на самом деле может быть море.

> как она тут может ошибиться?

Это даже не ошибка, это скорее следствие разрушения памяти приложения.

← →
Es (2013-05-15 12:30) [45]

правильно ли я понял вывод, что поскольку адрес у меня указывает на LdrInitializeThunk - то на 99% адрес исключения неверный в журнале записан?

Имеет смысл посмотреть в журнале адреса других падений?

← →
Rouse_ © (2013-05-15 12:35) [46]

Ну опять-же если адрес верный, то тогда напрашивается вывод о неверном атрибуте защиты страницы, либо мусорном коде, записанном по данному адресу.

Лучше просмотреть все логи и проанализировать их данные, чтобы удостоверится в правильности адреса.

← →
Es (2013-05-15 14:27) [47]

Вытащил известные мне падения.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2af8, application start time 0x01ce4589a1c25b76.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2924, application start time 0x01ce4e0dda13f4ba.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x29fc, application start time 0x01ce4e33437990ba.

Faulting application ESOfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00065cd4, process id 0x2a98, application start time 0x01ce4eca05cbb5fe.

Faulting application ESOfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2ae0, application start time 0x01ce4ed2616a69ba.

Везде 0x00041440, только в одном случае: 0x00065cd4

чтобы это значило всё...

← →
Es (2013-05-15 14:29) [48]

Прога одна и таже, версия тоже. Недоформатировал, вот так:

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2af8, application start time 0x01ce4589a1c25b76.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2924, application start time 0x01ce4e0dda13f4ba.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x29fc, application start time 0x01ce4e33437990ba.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00065cd4, process id 0x2a98, application start time 0x01ce4eca05cbb5fe.

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00041440, process id 0x2ae0, application start time 0x01ce4ed2616a69ba.

← →
Rouse_ © (2013-05-15 14:34) [49]

Второй оффсет, это KiFastSystemCallRet

.text:77F35CD4 ; __stdcall KiFastSystemCallRet() .text:77F35CD4 public _KiFastSystemCallRet@0 .text:77F35CD4 _KiFastSystemCallRet@0 proc near .text:77F35CD4 C3 retn .text:77F35CD4 _KiFastSystemCallRet@0 endp

то-же не информация ни о чем...

Так что эксперементируй с VEH

← →
Es (2013-05-15 14:54) [50]

Rouse_, а есть что-то вменяемое про готовку VEH с помощью delphi? Если еще и на рускком, так ваще...

← →
Es (2013-05-15 14:57) [51]

кстати, так как в большинстве случаев смещение 0x00041440 - не означает ли это что-то? Ну если бы там портилось все - это смещение должно было носить рандомный характер?

← →
Es (2013-05-15 15:01) [52]

Кстати, еще один момент есть. Именно эта программа запущена с другими настройками совершенно, но программа такая же. В таком варианте она падала один раз я вижу:

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ESOfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, exception code 0xc0000005, fault offset 0x00030abb, process id 0x2ec4, application start time 0x01ce4e20a8871e66.

Может, тут что полезного...

← →
Плохиш © (2013-05-15 15:15) [53]

Надо проверить куда пишут ваши потоки и как реализовано разруливание конфликтных ситуаций.

← →
Es (2013-05-15 15:48) [54]

Плохиш, как все просто оказывается)

← →
Rouse_ © (2013-05-15 16:18) [55]

> Rouse_, а есть что-то вменяемое про готовку VEH с помощью
> delphi? Если еще и на рускком, так ваще...

На дельфи нет, но есть вот такой примерчик:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681411

> faulting module ESOfflineServer.exe, version 1.0.1.103,
> time stamp 0x2a425e19, exception code 0xc0000005, fault
> offset 0x00030abb,

Вот это уже адрес внутри твоего модуля, тут только ты сам можешь сказать что у тебя.

← →
Es (2013-05-15 17:07) [56]

Блин, точно! :) Что-то я пропустил этот момент, подумал, что опять ntdll.dll
Взял map-файл от этой версии... Гы:

0001:000305A8 TEurekaModuleOptions.LoadFromStream 0001:00031328 TEurekaModuleOptions.StoreSharedData

Видимо, произошло исключение, еврика его перехватила, попыталась отправить отчет, начала считывать свои настройки.. и тут все умерло. Ну у меня такая версия.

← →
Es (2013-05-15 19:06) [57]

нашел в: http://www.f1-delphi.ru/books/sistemnoe_programmirovanie_v_s/vektornaya_obrabotka_isklyu4en/

"От функции VEH-обработчика требуется, чтобы она выполнялась быстро и никогда не получала доступа к объектам синхронизации, таким как мьютекс"

а почему это? У меня нет идей, как писать исключения в файл какой-нибудь что ли... Чтобы потом понять на каком этапе исключения "прервались" в логе - и последнее записанное исключение и есть искомое?
Но для записи нужно синхронизировать...

MSDN статья что-то не сильно помогла, там какие-то низкоуровневые операции, да и написано, что работает только для 32-ух бит, а у меня машина 64-битная (
И где взять заголовки все эти, описание рекордов в дельфи-синтаксисе, может есть у кого?
Я так понял, мне то нужно только дотянуться до адреса исключения в функции обратного вызова, вытащив его из структуры ExceptionInfo, да и все собственно...

← →
Es (2013-05-15 19:17) [58]

о, нашел вроде то, что нужно, вот эти два вопроса:

http://stackoverflow.com/questions/2628751/is-it-possible-to-have-a-global-exception-hook
и
http://stackoverflow.com/questions/14857106/how-to-get-the-exception-pointers-during-an-eexternal-exception

Если:

EXCEPTION_POINTERS = record ExceptionRecord : PExceptionRecord; ContextRecord : PContext; end;

PExceptionRecord - подойдет описание из SysUtils?
Где бы взять еще PContext... И вроде так все уже проще выглядит...

← →
Rouse_ © (2013-05-15 19:32) [59]

> да и написано, что работает только для 32-ух бит, а у меня
> машина 64-битная (

Но код-то у тебя 32 битный :)

> Где бы взять еще PContext... И вроде так все уже проще выглядит.
> ..

PExceptionRecord и PContext в Windows должны быть обьявлены.

← →
Es (2013-05-15 21:26) [60]

так так... Туман рассеивается)
А не прокомментируешь:

"От функции VEH-обработчика требуется, чтобы она выполнялась быстро и никогда не получала доступа к объектам синхронизации, таким как мьютекс"

?

← →
Rouse_ © (2013-05-15 21:39) [61]

Исключения могут происходить в различных нитях - можем выйти на дедлок из-за особенностей механизма реализации VEH. Но правда это нужно очень сильно постараться, если честно...
Делай логирование через журнал событий http://rouse.drkb.ru/winapi.php#evntlog проблем быть не должно.

← →
Es (2013-05-16 10:56) [62]

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

← →
Cobalt © (2013-05-16 11:12) [63]

Если у тебя случился AV, это вовсе не значит, что он обязательно в этом месте.
Даже скорее всего, ошибка в другом месте, где не обнулилась ссылка.
Но найдя первый адрес, ты начнешь раскручивать цепочку событий:
- почему в нужном месте нет данных
- кто подсунул этот адрес
- что там должно было быть, по этому адресу
- где могло затереть данные/адрес

← →
Es (2013-05-16 11:35) [64]

> Даже скорее всего, ошибка в другом месте

очень даже возможно, что ошибка в другом месте, допустим, перетерта память. Но если бы там возникло исключение - то еврика все бы залогировала. А поскольку не залогировала - значит, исключения при данной неправильной операции не было, а значит и VEH не сработает. Вот и теперь не очень понимаю, чем мне VEH поможет...

← →
Плохиш © (2013-05-16 11:40) [65]

> Cobalt © (16.05.13 11:12) [63]

Не мешай вумным искать ошибки у мелкого софта :-)

← →
Плохиш © (2013-05-16 11:47) [66]

Кстати Rouse_ уже в [23] посте "опознавал", всё-равно скатился к дебагу системной библиотеки.

← →
Rouse_ © (2013-05-16 15:02) [67]

> Интересно, если уж сама винда при крахе не может вытащить
> "нормальный" адрес исключения - как же может его указать
> некая технология винды при этом...

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

> Кстати Rouse_ уже в [23] посте "опознавал", всё-равно скатился
> к дебагу системной библиотеки.

Ну это я себя перепроверял, дома то на глаз примерно прикинул опираясь на вызов _RtlRaiseStatus

← →
Es (2013-05-16 15:30) [68]

блин у меня паранойя началась. Rouse_, а вот получу я управление в обработчике VectoredHandler, но ведь стек то уже поломан как ты полагаешь, я ж даже в лог записать не смогу, видимо...

← →
Rouse_ © (2013-05-16 17:28) [69]

> а вот получу я управление в обработчике VectoredHandler,
> но ведь стек то уже поломан

здесь гадание на кофейной гуще, поломка стека - это только одно из предположений.
Во вторых, даже если он у тебя поломан, что тебе помешает выставить свои значения регистрам EBP+ESP чтобы спокойно выполнить работу по сохранению информации?

← →
Es (2013-05-16 18:27) [70]

> даже если он у тебя поломан, что тебе помешает выставить
> свои значения регистрам EBP+ESP

то, что я только что узнал, что можно что-то выставить. И один фиг не понял, что нужно выставлять)

← →
Es (2013-05-16 18:30) [71]

> поломка стека - это только одно из предположений.

а что же еще может быть? Ведь вроде как очевидно, что винда в журнале выдает неправильный адрес исключения - в каких еще случаях это может быть?

А если адрес правильный - то каким образом MOV EDI, EDI может привести к исключению? (

← →
Плохиш © (2013-05-16 18:47) [72]

> Ведь вроде как очевидно, что винда в журнале выдает неправильный
> адрес исключения

Kак всегда винда виновата. Кто бы сомневался.

В журнале стоит адрес последней выполненной функции, в [23] даже название её опознано.
Винда не виноваты, что ты в своём коде не желаешь обрабатывать исключения, а т.к. нет обработки, винда со спокойной совестью убивает поделку.
Я советую ещё пару раз перечитать [53].

← →
Es (2013-05-16 18:59) [73]

> В журнале стоит адрес последней выполненной функции

а разве не адрес машинной инструкции, которая привела к исключению?

> в [23] даже название её опознано.

верно. Откуда можно сделать вывод, что опознано неверно. Ибо там находится инструкция mov EDI, EDI, которая не может вызвать исключения, кроме случая, как я понял, когда неправильно установлены атрибуты защиты страницы памяти.

> Винда не виноваты, что ты в своём коде не желаешь обрабатывать
> исключения

винда убивает процесс только когда не обработано исключение ГЛАВНОГО потока. Ты, я думаю, прекрасно понимаешь, что в стандартном GUI приложении дельфи все исключения обрабатываются.

> Я советую ещё пару раз перечитать [53].

абсолютно очевидно, что ты обиделся на [54], после чего не нашел ничего лучшего, как начать подкалывать. Не хочу отвечать тебя тем же и устраивать срач. Оно нужно?

Rouse_ видно - профи в таких делах отличный, вот я и пытаюсь как-то разобраться в проблеме, высказывая свои предположения нубские, может меня поправят нормально. А рекомендация из [53] аналогична словам "Там где-то ошибка в программе, посмотри внимательнее". Толку от этого - ноль, я и так понимаю. Программа большая, обслуживает информацию с тысячи физических точек, куда она только чего не пишет, чего только не делает и такие рекомендации - как об стену горох. А была бы она из 30-ти строчек - так и проблему бы почти наверняка не было бы.

> Ты, я думаю, прекрасно понимаешь, что в стандартном GUI
> приложении дельфи все исключения обрабатываются.

Да неужели. И кем?

> абсолютно очевидно, что ты обиделся на [54], после чего
> не нашел ничего лучшего, как начать подкалывать.

Капитан очевидность?

> аналогична словам "Там где-то ошибка в программе, посмотри
> внимательнее". Толку от этого - ноль, я и так понимаю.

Но предпочитаешь искать в другом месте.

← →
Es (2013-05-16 19:31) [75]

> Да неужели. И кем?

методом HandleException.

> то, что я только что узнал, что можно что-то выставить.
> И один фиг не понял, что нужно выставлять)

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

← →
Es (2013-05-16 19:43) [77]

эх, надеюсь Rouse_ не положил на нуба с прибором))

Добил я VEH, но результаты странные. Сделал тестовое приложение, сделал там:

> > raise EDivByZero.Create("test");

мой обработчик VectoredHandler выдал следующее:

hInstance (приложения): 4194304 ExceptionCode: $0EEDFADE ExceptionAddress: $76CEC41F

По ExceptionAddress с помощью
> GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS

определил базовый адрес модуля: ModuleAddress: 76CE0000

Через GetModuleName имеем: ModuleName: C:\Windows\syswow64\KERNELBASE.dll

Вложенных исключений нету.

Что-то я не понимать... По итогу, получается VEH фигню какую-то выдал...
Или я не до конца понимаю механизм...

> Плохиш © (16.05.13 18:47) [72]
> Винда не виноваты, что ты в своём коде не желаешь обрабатывать
> исключения, а т.к. нет обработки, винда со спокойной совестью
> убивает поделку.

Это из серии, если у тебя колесо лопнуло, сам виноват что ехать не можешь.
Как он обрабатывать то будет если SEH фреймы уплыли?

← →
Es (2013-05-16 19:51) [79]

привожу все в HEX.

> raise EDivByZero.Create("test");

в логе от VEH получается:

hInstance: $00400000 ExceptionCode: $0EEDFADE ExceptionAddress: $76CEC41F (ModuleAddress: 76CE0000, ModuleName: C:\Windows\syswow64\KERNELBASE.dll) No nested except

0EEDFADE - это код дельфийского исключения. т.е. штатный raise

cDelphiException = $0EEDFADE;

Теперь тебе нужно расрутить цепочку SEH фреймов в обратном порядке. Первый фрейм находится в FS:[0].

Скачай Jedy Library там в папке Debug кажется был пример кода, который выполняет данные действия. (потребуется MAP файл чтобы получить нечно читабельное).
Когда выствоишь цепочку - все сам увидишь...

← →
Es (2013-05-16 21:32) [81]

так... начинаются чудеса...

Я так понял, что все это результат искусственно вызванного исключения. Сделал такой код:

var i: integer; begin i := 0; ShowMessage(FloatToStr(5 / i)); end;

Запускаю... Обработчик VEH у меня так вот начинается:

function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; begin result := EXCEPTION_CONTINUE_SEARCH; Mes := "hInstance: $"+IntToHex(HInstance, 8); ...

В переменной Mes я планирую собирать нужную строку для вывода в лог.
Так вот... После начала исключения попадаю в VectoredHandler. Присваивается Result, дальше отладчик переходит на строку:

> Mes := "hInstance: $"+IntToHex(HInstance, 8);

При ее выполнении... Попадаю опять в начало VectoredHandler, поток тот же! То есть, как я понимаю, в IntToHex возникло исключение! Если его убрать - проходит дальше нормально... Оч. интересно, почему IntToHex начал вызывать исключение...

При тестовом генерировании исключения raise EDivideByZero ничего такого не было...

> Rouse_ © (16.05.13 19:46) [78]

А, понял, если лопнуло колесо, надо начать с переборки двигателя.

PS. Искать надо там, где потерял, а не в соседних кустах. И не надо усложнять простое.

> Плохиш © (17.05.13 01:06) [82]
>
>
> > Rouse_ © (16.05.13 19:46) [78]
>
> А, понял, если лопнуло колесо, надо начать с переборки двигателя.
>
>

Не все исключения можно обработать стандарно-простым способом.
Блок
try ... except
не всегда сможет отловить исключение. Да и поскольку в проекте ТС используется Эврика и поскольку Эврика тоже ничего не ловит, то значит проблема гораздо глубже.
P.S.
Я лично сомневаюсь, что ТС сможет сам найти причину проблемы. Про SEH фреймы он знает только по наслышке (Про VEH я уже молчу. Я и сам только в этой ветке про него узнал :). Разворачивать стек не умеет. А нанять Розыча платно не потянет. :)

Плохиш © (17.05.13 01:06) [82] А, понял, если лопнуло колесо, надо начать с переборки двигателя.
Это ты предлагаешь перебирать движок, пытаясь анализировать код наобум.
Ошибка в 17-ой строке, можно начать прямо с нее.

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

Знаю одного человека, он до сих пор, вместо того чтобы воспользоваться отладчиком, предпочитает по два три часа вычитывать код, пытаясь найти место ошибки. Очень высокопроизводительный и профессиональный подход, знаете-ли...

> Rouse_ © (17.05.13 10:26) [85]
> Знаю одного человека, он до сих пор, вместо того чтобы воспользоваться
> отладчиком

Хм, воспользоваться отладчиком, я здесь тоже уже предлогал. Но что-то не видно здесь использования отладчика.

PS. У меня тоже есть пример любителя копи-паста. Одинаковый код копируется n-раз, после чего в нём находится ошибка, исправляется в m-раз. После чего периодически выскакивает ошибка в ситуациях n-m. Вывод гениальный "Визуальная студия компилирует один и тот же код по разному."

PPS. А тут, судя по условиям в [0] и адресе в исключении, проблемы с синхронизацией обращений к одним переменным из разных потоков. И я не удивлюсь, если автор считает, что это должен разруливать компилятор, виндовс или пушкин.

> Одинаковый код копируется n-раз, после чего в нём находится
> ошибка, исправляется в m-раз.

Хе :)

> PPS. А тут, судя по условиям в [0] и адресе в исключении,
> проблемы с синхронизацией обращений к одним переменным
> из разных потоков

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

← →
Es (2013-05-17 11:00) [88]

Удалено модератором

← →
Es (2013-05-17 11:03) [89]

Rouse_, а ты не прокомментируешь [81] ? (

Не понимаю... Такое ощущение, что после возникновения исключения я попадаю в функцию обработки VEH в каком-то "не очень" правильном состоянии, что обычная IntToHex приводит, видимо, также к исключению.

> Es (17.05.13 11:00) [88]

Кстати он может быть не так уж и не прав, вариант с кривой синхронизацией тоже достаточно похож на причину.

> Es (17.05.13 11:03) [89]
> Rouse_, а ты не прокомментируешь [81] ? (

нужно код смотреть целиком, но это не раньше понедельника-вторника, сейчас завал...

> [86] Плохиш © (17.05.13 10:40)
> выскакивает ошибка в ситуациях n-m

Особенно интересен эффект, когда n<m. Тогда виноват уже сам Билл Гейтс.

← →
Es (2013-05-17 11:38) [92]

> Кстати он может быть не так уж и не прав

да кто же спорит! Но этот совет - утопия, если хотя бы как-то сузить место поиска хотя бы до одного модуля - еще что-то можно смотреть наобум. Но в таком виде "У тебя где-то ошибка" - что толку от этого. Я и сам понимаю, что где-то что-то не так написано. А учитывая что под нагрузкой от нескольких тысяч источников программа падает раз в неделю, а иногда в две (а вот иногда два раза в день)...Конечно, отладчик тут в помощь...

← →
Es (2013-05-17 13:35) [93]

Упростил исходники как только смог. Вот выложил:

http://yadi.sk/d/_pflEa3b4v2I5 (нужно нажать "Скачать", 17 Кбайт)

Вкратце:

1) ставим обработчик:

gExceptHandler := AddVectoredExceptionHandler(0, @VectoredHandler);

2) вот текст handler"а:

function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; ss: TStringStream; begin result := EXCEPTION_CONTINUE_SEARCH; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; Mes := "hInstance: $"; Mes := Mes + IntToHex(HInstance, 8)+#13#10; Mes := Mes +"ExceptionCode: $"+IntToHex(ExceptionInfo.ExceptionRecord.ExceptionCode, 8)+#13#10 +"ExceptionAddress: $"+IntToHex(Integer(ExceptionInfo.ExceptionRecord.ExceptionAddress), 8) ; ss := TStringStream.Create(Mes); PostMessage(Form1.Handle, WM_USER+1, 3345690, Integer(Pointer(ss))); end;

3) делаем такое исключение:

raise EDivByZero.Create("test");

все отлично перехватывается, логируется

4) делаем вот так:

var i: integer; begin i := 0; ShowMessage(FloatToStr(5 / i));

И тут все уже не очень. Выполняется строчка:

> result := EXCEPTION_CONTINUE_SEARCH;

Потом выполняется строчка:

>if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then
> beep;

можно её убрать - толку нет, я просто экспериментировал - если убрать обработчик - пофигу.

Далее исполняется удачно:

> Mes := "hInstance: $";

А вот тут фейл:

> Mes := Mes + IntToHex(HInstance, 8)+#13#10;

После предыдущей строчки отладчик опять прыгает в начало на:

> result := EXCEPTION_CONTINUE_SEARCH;

и так в бесконечный цикл. Так или иначе в результате программа сваливается в AV...
Очень плохо знаю ассемблер, а IntToHex написана на асме, видимо в ней дело... очень интересно что за нафиг...

> Es (17.05.13 13:35) [93]

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

Кстати получился достаточно интересный механизм переполнения. Раньше с именно такой ошибкой я не сталкивался, так что тебе спасибо за данный вариант кода.
Хорошее пополнение моей коллекции :)

← →
Es (2013-05-18 00:58) [96]

Rouse_, очень рад, что повеселил :)

Также рад, что в общем правильно догадался:

1) происходит исключение в IntToHex, поэтому опять попадаем в обработчик VectoredHandler
2) в VectoredHandler мы попадаем в очень как бы сказать "сыром" состоянии, что многие телодвижения также приводят к повторным исключениям.

Отсюда вопросы:

а) но ведь я компилил код и со строчкой:

... result := EXCEPTION_CONTINUE_SEARCH; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; ...

При этом видно, что RemoveVectoredExceptionHandler отрабатывает! Почему же повторное исключение в IntToHex приводит опять к вызову VectoredHandler, по идее "хук" уже должен быть снят?

б) и что же блин делать? Ведь в контексте решаемой задачи я понятия не имею какое исключение там у меня вызывается и вообще в чем проблема. Даже если я получу доступ в VectoredHandler, то мне я так понимаю нужно написать мега безопасный код, который с максимум вероятности сможет вывести в лог хоть что-то. Мои знания на этом точно закончились (

> Es (18.05.13 00:58) [96]
>
> Rouse_, очень рад, что повеселил :)

Ты не совсем правильно понял его смайлик. Про пополнение своей коллекции он сказал на полном серьёзе.

> и что же блин делать? Ведь в контексте решаемой задачи я
> понятия не имею какое исключение там у меня вызывается и
> вообще в чем проблема. Даже если я получу доступ в VectoredHandler,
> то мне я так понимаю нужно написать мега безопасный код,
> который с максимум вероятности сможет вывести в лог хоть
> что-то. Мои знания на этом точно закончились (

Что делать? "Трясти" как говорил Василий Иванович (с) в известном анекдоте. Не пытайся сразу написать "супер-мега-безопасный" универсальный код, который сразу поможет узнать "Кто виноват?" и "Что делать?". Если бы такой код можно было бы написать, авторы Эврики давно бы его написали.

← →
Es (2013-05-19 21:16) [98]

> Ты не совсем правильно понял его смайлик. Про пополнение
> своей коллекции он сказал на полном серьёзе.

это ты не совсем верно понял меня)

> При этом видно, что RemoveVectoredExceptionHandler отрабатывает!
> Почему же повторное исключение в IntToHex приводит опять
> к вызову VectoredHandler, по идее "хук" уже должен быть
> снят?

По идее должен, но он снимется только после корректного завершения обработчика.

Можешь проверить с первым вариантом исключения, изменив код обработчика вот так:

function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; ss: TStringStream; begin result := EXCEPTION_CONTINUE_SEARCH; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; raise EDivByZero.Create("test");

← →
Es (2013-05-20 11:29) [100]

Rouse_, что делать то? ((

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

Что значит что делать? Логировать :)

var InVectoredHandler: Boolean = False; function VectoredHandler(ExceptionInfo: PEXCEPTION_POINTERS): LongInt; stdcall; var Mes: string; ss: TStringStream; begin if InVectoredHandler then Exit; InVectoredHandler := True; try result := EXCEPTION_CONTINUE_SEARCH; // выполняем подготовительные действия, по аналогу с _HandleOnException asm CLD FNINIT FWAIT FLDCW Default8087CW end; if RemoveVectoredExceptionHandler(gExceptHandler) > 0 then beep; Mes := "hInstance: $"; Mes := Mes + IntToHex(HInstance, 8)+#13#10; Mes := Mes +"ExceptionCode: $"+IntToHex(ExceptionInfo.ExceptionRecord.ExceptionCode, 8)+#13#10 +"ExceptionAddress: $"+IntToHex(Integer(ExceptionInfo.ExceptionRecord.ExceptionAddress), 8) ; ss := TStringStream.Create(Mes); PostMessage(Form1.Handle, WM_USER+1, 3345690, Integer(Pointer(ss))); finally InVectoredHandler := False; end; end;

← →
Es (2013-05-22 13:49) [102]

Еще раз упало:

Faulting application OfflineServer.exe, version 1.0.1.103, time stamp 0x2a425e19, faulting module ntdll.dll, version 6.0.6002.18541, time stamp 0x4ec3e3d5, exception code 0xc0000005, fault offset 0x00065cd4, process id 0x2bd8, application start time 0x01ce52d60ab69ee2.

Вот я думаю, если бы так все портилось - разве не были бы смещения отфонарные абсолютно? А тут так стабильно наблюдается или 0x00041440 или 0x00065cd4... неужели совпадение.

Падение приложения, crash без визуализации Найти похожие ветки