Eсть библиотека которая подгружаеться при помощи Rundll32 и вызывает указаную функ. которая должна через ShellExecute открыть b explorer каталог. Но проблема в том что если два раза(но при этом первая еще не выгрузилась) так подгрузить библиотеку то при втором вызове ShellExecute происходит подвисание на ShellExecute....до тех пор пока не заkрить первый запусченый Rundll32. Можна как то сделать так чтоб такого подвисания не было и при этом открывался второй католог в explorer? Bариант с CreateProcess не подходить так как оболчка может быть и не explorer. И еще вопрос что делает ctfmon.exe ? Вот так я подгружаю библ. rundll32.exe F:\project\project2.dll, MainFunc Код (Text): library Project2; uses shellapi,messages,windows; {$R *.res} procedure mian; begin ShellExecute(0,'open','f:\',nil,'f:\', SHOW_OPENWINDOW); sleep(1000000); end; exports mian name 'MainFunc'; begin end.
Доставь дампы rundll – выполняющегося и "подвисшего на ShellExecute". Может быть кто-нибудь посмотрит. Один может и сам посмотреть – нужно взять DTW, запустить "WinDbg -p RundllPID" и посмотреть стектрейс – команда "k". Будет видно, где остановлено выполнение. В общем-то можно и через Olly посмотреть, и через ProcessExplorer. (Дамп можно сделать с помощью WinDbg – ".dump /ma dumpfile.dmp", или через procdump.exe с параметром -ma, либо TaskManager'ом).
Остановки нету...там где тов ShellExecute происходит подвисание как будто она висит на WaitForSingleObject или тому подобному...при запуске через Olly, ни каких остановов нету...
Sol_Ksacap Какие есчо дампы, это ведь юзермодный функционал, а есчо мне говорили не стрелять по воробьям из пушки Ничего удивительного нет что виснет, вероятно обычная синхронизация, скомпиленный тестовый модуль в студию, сурцы не нужны.
Clerk Ага, юзермодный. Мы и просим юзермодный минидамп – там информация о потоках (в т.ч. время выполнения и контексты), стеки потоков, инфа о хендлах, полное адресное пространство приложения (в т.ч. скомпиленный модуль, ага). Кстати, вроде ни слова не говорили по поводу твоих методов – это дают о себе знать наши множественные склерозы или кто-то таки пользует Sol-ID без лицензии? ) XshStasX Остановка, "подвисание" – одно и то же в нашем контексте. Мы не просто так сказали про дампы, кстати. Несколько минут парсили. Ставь тире или хотя бы пробелы, чёрт побери.
Sol_Ksacap Расскажите-ка как сдампить процесс Диспетчером задач. Может спит очень долго? Оставь просто - end;
Sol_Ksacap Смысла нет дампить адресное пространство, ибо есть рабочий процесс на рабочей системе. Я бы выполнил суспенд треда который висит и бактрейс. Тогда увидим где тред подвис, а для чего раскажут отладочные символы.
Clerk В общем-то да, пожалуй многомегабайтный дамп здесь – излишество. С другой стороны, если нет прямого доступа к процессу, то, нам кажется, проще выполнить те же действия с дампом и потом показать\прокомментировать лог, нежели пытаться по шагам объяснить что и как. AndreyMust19 Task Manager Dump
Sol_Ksacap Не понимаю зачем чтото дампить, не защита ведь вскрывается. Олю подключить и посмотреть чего виснет, пару минут займёт. А что дамп даст, в нём контекста треда не будет и есчо много чего, да и вручную многое проблемно определить без реалтайма, как например из дампа определить адрес страницы TEB треда.. Анализ полных дампов(ядра в частности) на своей системе вобще не нужен, это используется для анализа крэшдампов с других машин.
Clerk Мы предложили получить дами исключительно из-за того, что не нашли простого пути для формулировки исчерпывающего и понятного ОПу описания шагов по поиску и устранению бага. Фразу "выполни 'procdump.exe -ma rundll_PID'", с другой стороны, очень легко и собрать, и распарсить. Проще, чем любое предложение в этом посте. Clerk Это не тот тип дампа, где только кусок адресного пространства же. Например, дамп "application1.dmp" был получен с помощью Task Manager: Код (Text): cmd> windbg -z C:\Users\John\AppData\Local\Temp\application1.DMP Дамп открылся в windbg: <..> 0:000:x86> .dumpdebug ----- User Mini Dump Analysis MINIDUMP_HEADER: Version A793 (6903) NumberOfStreams 11 Flags 1826 0002 MiniDumpWithFullMemory 0004 MiniDumpWithHandleData 0020 MiniDumpWithUnloadedModules 0800 MiniDumpWithFullMemoryInfo 1000 MiniDumpWithThreadInfo <..> 0:000:x86> ~ . 0 Id: d18.108c Suspend: 0 Teb: 7efdb000 Unfrozen 1 Id: d18.1258 Suspend: 0 Teb: 7efd8000 Unfrozen 2 Id: d18.e38 Suspend: 0 Teb: 7efaa000 Unfrozen 0:000:x86> ~1s user32!NtUserGetMessage+0x15: 763a65b7 c21000 ret 10h 0:001:x86> ? @$teb Evaluate expression: 2130542592 = 7efd8000 0:001:x86> ?? @$teb->NtTib struct _NT_TIB +0x000 ExceptionList : 0x7efda000 _EXCEPTION_REGISTRATION_RECORD +0x008 StackBase : 0x00a5fd20 +0x010 StackLimit : 0x00a5a000 +0x018 SubSystemTib : (null) +0x020 FiberData : 0x00001e00 +0x020 Version : 0x1e00 +0x028 ArbitraryUserPointer : (null) +0x030 Self : 0x7efd8000 _NT_TIB Пойми нас правильно – мы не агитируем кого-либо для каждой ситуации создавать дамп и анализировать уже его. Просто в данном случае именно это действие для нас выглядело наиболее простым.
XshStasX Тред висит в SendMessageTimeout(), вызывает функа из Shell32.dll с именем GetConversationWindow(). Как верно заметил AndreyMust19 следует убрать задержку, дабы не нарушать синхронизацию и сообщение отослалось(видимо далее какаято работа происходит, смотреть в сурцах там есть указанная функция.) Sol_Ksacap Пара кликов мышем в оле и не нужны никакие ядерные дебуггеры и дампы.
Приаттачься отладчиком к зависнувшему процессу и посмотри - что в нем происходит. Или включи лог с записью вызываемых API-функций.
Мы таки скомпилили код из этих двух строчек, запустили, и... И ничего не висит, всё верно выполняется. Лол. zet Детектируй по UAC-иконке В XP sp2 ещё не было, в висте sp1 уже было.
