Сейчас на форуме: jinoweb (+5 невидимых)

 eXeL@B —› Программирование —› Исключение 0x0eedfade - откуда ноги растут?
<< . 1 . 2 .
Посл.ответ Сообщение


Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 20 сентября 2009 18:13
· Личное сообщение · #1

Последнее время стал часто замечать, что мои некоторые проекты на Delphi вдруг начинают вызывать исключение 0x0eedfade. Проявляется это не всегда и не везде. То есть на стадии разработки работало, прошло время - не работает. Отлавливал ошибку путём выкидывания некоторых участков кода, выводил в лог места которые удавалось пройти до проблемного момента, отлаживал пошагово и много времени провёл в гугле. На основе своих изысканий сделал вывод, что от приложения к приложению места могут быть разные, то есть например я использую функцию подсчета контрольной суммы, код помещен не в библиотеку, а идёт в виде функции в теле проекта, это модуль, сделав один, я делаю ещё 3 копии и вношу изменения. Таким образом получаю 4 длл с частью похожего кода но с разным назначением, где в одной вдруг начинает слетать в недрах функции подсчёта CRC, в то время как в остальных трёх этот код работает без проблем... Стоит закомментировать вызов функции, как всё работает без ошибок... Я не готов выложить пример, а лишь пытаюсь докопаться до сути. Поиск в интернете показал, что это исключение появляется совершенно неожиданно во многих известных программах, можно дать в гугле 0x0eedfade и имя программы и скорее всего это исключение там появлялось...
На форумах по Delphi пытаются отловить проблемные места используя try except, кто-то переписывает проблемный код хотя в нём нет явных ошибок, на форуме по Sound Empire проблему решали отключением интегрированной звуковой карты и много разных вариантов решения предлагают в сети.
Единственное чего не удалось найти, так это внятного описания того из за чего и почему это появляется и как избежать подобного на стадии разработки. Ибо незнание и непонимание принципов возникновения этой проблемы не даёт гарантии, что отлично работающая и отлаженная программа будет работать на любом компьютере...
Ну правда, тем же винампом пользуется огромное кол-во народа и только один на форуме пишет, что у него возникло такое исключение...
Как быть? Прошу разбирающихся людей или встречавших подобную проблему просветить меня.



Ранг: 114.8 (ветеран), 41thx
Активность: 0.1↘0
Статус: Участник

 Создано: 24 сентября 2009 00:09 · Поправил: _ruzmaz_
· Личное сообщение · #2

Хм.. А ты же про функу говорил.

Вне какого-то контекста этот код не выглядит особенно бажным ни со знаковым longint, ни с беззнаковым dword. К тому же пробовал компилить и выполнять - все норм было (в обоих случаях).

Если это действительной из какой-то функции (а не процедуры), то здесь написан не весь ее код).
Еще неплохо было бы знать как и где она используется, что в нее передается и что она возвращает.




Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 24 сентября 2009 01:34
· Личное сообщение · #3

_ruzmaz_ пишет:
Хм.. А ты же про функу говорил.

Я уже всё исковеркал пока искал причину ошибки. Вообще ничего не пойму, сейчас другое место, в другой поделке глючит, но только на SP3. Код работает у меня на SP2 отлично, и если сделать отдельно от контекста - то и на SP3 глючное место работает. Это код завершения приложения который из длл вызывается, должен убить все треды и закрыть программу. Что интересно на этом месте и halt(1) заканчивается той же ошибкой... Может я некорректно завершаю приложения использующие треды? Сейчас качаю SP3 и буду смотреть на ошибку...
Вот код завершения, где спёр не помню:
Code:
  1. function killthreads:integer;
  2. const
  3. process_terminate=$0001;
  4. var
  5. continueloop: bool;
  6. fsnapshothandle: thandle;
  7. fprocessentry32: tprocessentry32;
  8. begin
  9. result := 0;
  10. fsnapshothandle := createtoolhelp32snapshot(th32cs_snapprocess, 0);
  11. fprocessentry32.dwsize := sizeof(fprocessentry32);
  12. continueloop := process32first(fsnapshothandle, fprocessentry32);
  13. while integer(continueloop) <> 0 do
  14. begin
  15. if ((uppercase(extractfilename(fprocessentry32.szexefile)) =
  16. uppercase(ExtractFileName(getmodulename(0)))) or (uppercase(fprocessentry32.szexefile) = uppercase(ExtractFileName(getmodulename(0))))) then
  17. result := integer(terminateprocess(openprocess(process_terminate, bool(0),fprocessentry32.th32processid), 0));
  18. continueloop := process32next(fsnapshothandle,fprocessentry32);
  19. end;
  20. closehandle(fsnapshothandle);
  21. Halt(1);
  22. end;

Ранг: 114.8 (ветеран), 41thx
Активность: 0.1↘0
Статус: Участник

 Создано: 24 сентября 2009 19:17
· Личное сообщение · #4

ToBad пишет:
Это код завершения приложения который из длл вызывается, должен убить все треды и закрыть программу. Что интересно на этом месте и halt(1) заканчивается той же ошибкой...
Он же завершает текущий процесс еще до Halt(1). Каким образом у тебя дело до холта доходит?

Перелопачивать все и сразу не стоит - в дельфовом отладчике найди @RaiseExcept по байтам 68 DE FA ED 0E, ставь на ней бряк и посмотри откуда вызывается.




Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 24 сентября 2009 20:01
· Личное сообщение · #5

_ruzmaz_ пишет:
Он же завершает текущий процесс еще до Halt(1). Каким образом у тебя дело до холта доходит?

Я не про этот halt... Просто експерементировал с вариантами завершения приложения из dll. Эта процедура под СП3 - глючит, ExitProcess и Halt - тоже... Блин...



Ранг: 114.8 (ветеран), 41thx
Активность: 0.1↘0
Статус: Участник

 Создано: 24 сентября 2009 20:40
· Личное сообщение · #6

А с тредами как работаешь - через TThread или API?
Если через TThread, то лучше наверно завершать каждый по отдельности средствами класса.
Если через API, то посмотри, можт треды чонить общее юзают.




Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 24 сентября 2009 21:53
· Личное сообщение · #7

_ruzmaz_ пишет:
А с тредами как работаешь - через TThread или API?

Через API. Посмотрел примеры работы через TThread - понравилось, ночью переделаю и проверю... Может проблема в этом...




Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 25 сентября 2009 13:10
· Личное сообщение · #8

Что-то я вообще залез в дебри. Большие подозрения, что всё глюки именно из за тредов и неправильной работы с ними. Попробовал делать с нуля, по правильному и по примерам работы с TThread, но тут же столкнулся с проблемой. Из Dll импортирована функция X, OEP указывает на вызов функции, затем прыгаем на оригинальный. Вот, что происходит по логу:
Code:
  1. MAIN
  2. ATTACH
  3. MY FUNC
  4. THREAD EXECUTE
  5. DEATTACH


Вот собственно код:
Code:
  1. library test;
  2.  
  3. uses classes, windows, sysutils, myfunc;
  4.  
  5. {$R *.res}
  6.  
  7.   type
  8.    TMyThread1 = class(TThread)
  9.    private
  10.      { Private declarations }
  11.    protected
  12.      procedure DoWork;
  13.      procedure Execute; override;
  14.    end;
  15.  
  16. var T1:TMyThread1;
  17.  
  18. procedure TMyThread1.Execute;
  19. begin
  20. log('THREAD EXECUTE');
  21. while not Terminated do Synchronize(DoWork);
  22. end;
  23.  
  24. procedure TMyThread1.DoWork;
  25. begin
  26. log('IN THREAD PROC');
  27. sleep(500);
  28. end;
  29.  
  30. Function x:dword; stdcall;
  31. begin
  32. log('MY FUNC');
  33. T1:=TMyThread1.Create(False);
  34. result:=0;
  35. end;
  36.  
  37. procedure DLLHandler(Reason: Integer);
  38. begin
  39. case Reason of
  40.   DLL_PROCESS_ATTACH:log('ATTACH');
  41.   DLL_PROCESS_DETACH:log('DEATTACH');
  42. end;
  43. end;
  44.  
  45. exports x;
  46.  
  47. begin
  48. log('MAIN');
  49. DllProc := @DLLHandler;
  50. DLLHandler(DLL_PROCESS_ATTACH);
  51. end.


Чувствую лохонулся где-то на элементарном. По идее IN THREAD PROC должен каждые 500 мс в логи идти. Как сделать что бы длл не деаттачилась, а тред крутился? Наверное нужно выкидывать dll из импорта, а там где вызываю функцию предварительно грузить dll через loadlibrary? Сейчас попробую...




Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 25 сентября 2009 13:29
· Личное сообщение · #9

Те же яйца, что происходит? Как заставить тред работать, а длл не деаттачится?




Ранг: 681.5 (! !), 405thx
Активность: 0.42↘0.21
Статус: Участник
ALIEN Hack Team

 Создано: 25 сентября 2009 13:39
· Личное сообщение · #10

ToBad
Попробуй сделать так, чтоб DllEntryPoint возвращала TRUE, а не что-нибудь. Т.е.:
Code:
  1. function DLLHandler(Reason: Cardinal):Cardinal;stdcall;
  2. begin
  3.  case Reason of
  4.   DLL_PROCESS_ATTACH:log('ATTACH');
  5.   DLL_PROCESS_DETACH:log('DEATTACH');
  6.  end;
  7.  Result := TRUE;
  8. end;


-----
Stuck to the plan, always think that we would stand up, never ran.


Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 25 сентября 2009 14:17 · Поправил: ToBad
· Личное сообщение · #11

ARCHANGEL пишет:
Попробуй сделать так, чтоб DllEntryPoint возвращала TRUE, а не что-нибудь

Ага. Спасибо! Код поправил, попробовал true для возврата boolean и 1 для cardinal, уже не деаттачится!
Теперь вторая проблема в неработающем треде:
Code:
  1. MAIN
  2. ATTACH
  3. MY FUNC
  4. THREAD EXECUTE


И сразу ещё один вопрос. Когда я выхожу из основной программы по Alt-F4 разве в мою длл не должен приходить деаттач? Или это только если я выгружаю с помощью FreeLibrary?



Ранг: 114.8 (ветеран), 41thx
Активность: 0.1↘0
Статус: Участник

 Создано: 26 сентября 2009 16:04
· Личное сообщение · #12

ToBad пишет:
Когда я выхожу из основной программы по Alt-F4 разве в мою длл не должен приходить деаттач?
А разве в логе у тебя нет DEATTACH? У мну есть.) Правда у меня вместо лога месажбокс.

ToBad пишет:
Теперь вторая проблема в неработающем треде
Пробовал разные варианты - работает либо без Synchronize, либо с Synchronize, но если TMyThread1 в том же проекте, в котором он используется.
Если DoWork использует только своё, то забей)) на Synchronize.




Ранг: 450.3 (мудрец), 13thx
Активность: 0.2↘0
Статус: Участник

 Создано: 27 сентября 2009 11:39
· Личное сообщение · #13

_ruzmaz_ пишет:
А разве в логе у тебя нет DEATTACH?

Неа.
Вернулся к варианту тредов на API. Сейчас глюкает в момент убиения основной программы из треда функцией killthreads которую прилагал выше. Причём если в треде написать запуск другого EXE который и сделает killthreads для программы жертвы, то ошибки не возникает... Вот так вот через ж - работает.
Пробовал останавливать треды и замораживать - те же яйца. Кстати не всё время это происходит, а раз на 3-5 выходов.

p.s. Прошу не закрывать тему, к вопросу вернусь через неделю после командировки.



Ранг: 5.2 (гость), 1thx
Активность: 0=0
Статус: Участник

 Создано: 25 января 2016 23:23
· Личное сообщение · #14

К вопросу не вернулся, или из командировки не вернулся?
Проблема актуальна.



Ранг: 95.1 (постоянный), 247thx
Активность: 0.26↘0.01
Статус: Участник

 Создано: 26 января 2016 01:41
· Личное сообщение · #15

Vostol пишет:
К вопросу не вернулся, или из командировки не вернулся?
Проблема актуальна.
Шутники так и прут.Через 10 лет было бы еще актуальней.Для этого личка придумана.Не можете выйти на контакт - поспрашайте админов.
Пора бы заняться уже древними тредами, чтобы археологов не смущать.

-----
TEST YOUR MIGHT
<< . 1 . 2 .
 eXeL@B —› Программирование —› Исключение 0x0eedfade - откуда ноги растут?
:: Ваш ответ
Жирный  Курсив  Подчеркнутый  Перечеркнутый  {mpf5}  Код  Вставить ссылку 
:s1: :s2: :s3: :s4: :s5: :s6: :s7: :s8: :s9: :s10: :s11: :s12: :s13: :s14: :s15: :s16:


Максимальный размер аттача: 500KB.
Ваш логин: german1505 » Выход » ЛС
   Для печати Для печати