Вопрос из почты:
The question is really simple: could we use RtlCaptureContext on X86? The MSDN (http://msdn.microsoft.com/en-us/library/ms680659(v=VS.85).aspx) says it’s only for 64 but the bug is for X86 and I see some kernel code are using it on x86.
Вопрос на самом деле очень прост: можем ли мы использовать функцию RtlCaptureContext на x86? MSDN говорит, что эта функция только для 64-х бит но баг-репорт (имеется ввиду баг-репорт, ранее упомянутый в письме) воспроизводится для x86 и я вижу, что код в ядре использует эту функцию на x86.
Ответ: можно. Действительно, упомянутая страница MSDN утверждает, что:
The following functions are used only on 64-bit Windows.
Следующие функции используются только в 64-х разрядных версиях Windows.
Однако, страница, описывающая саму функцию RtlCaptureContext() указывает Windows XP и Windows Server 2003 в качестве минимальных версий клиента и сервера. Сравните с функцией RtlAddFunctionTable(), действительно не реализованной на x86. Минимальные версии клиента и сервера для неё – Windows XP Professional x64 Edition и 64-bit editions of Windows Server 2003 соответственно.
Другой способ удостовериться в этом – проверить таблицу экспорта NTDLL. Хотя такой способ, конечно, не дает никакой информации о том, документирована функция (иными словами – поддерживается ли обратная совместимость для неё) или нет.
C:\>link /dump /exports c:\Windows\SysWOW64\ntdll.dll | findstr RtlCaptureContext
667 28D 00046B2B RtlCaptureContext
C:\>link /dump /exports c:\Windows\SysWOW64\ntdll.dll | findstr RtlAddFunctionTable
C:\>
Win32 API предоставляет «Ex» варианты функций ReadFile и WriteFile, в то время как «Ex» варианта функции DeviceIoControl не предлагается. Исправить этот недостаток очень просто, так как соответствующая функция Native API документирована в MSDN: NtDeviceIoControlFile (хотя и помечена как «Deprecated»). Прототип новой функции будет выглядеть вот так:
Read more…
Пришло письмо с вопросом:
Обнаружилась следующая проблема:
Наша программа сохраняет и считывает последнюю открытую ею директорию в разделе реестра, где сохраняют последние посещенные ими директории и другие программы, а именно в ветке «HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU». Это в 32-х разрядной версии. Но оказывается, что в 64-х разрядной версии данной ветки реестра в узле HKCU не существует, а она находится в «HKEY_USERS\<некий идентификатор пользователя>\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidlMRU».
Так вот вопрос: как мне программно доступиться к этой ветке, если идентификатор пользователя неизвестен? Или, может, есть способ узнать этот идентификатор каким-то образом? А может где-то есть в реестре зеркало этой ветки, к которой можно получить доступ более простым способом?
Read more…
Подсмотрел у коллеги простой и довольно удобный способ держать список состояний/событий конечного автомата в одном месте. А то обычно они норовят расползтись по разным углам: enum, объявляющий соответствующие константы, массив имен состояний для отладки, большой switch, выбирающий что делать, в зависимости от состояния…
Read more…
Меня пригласили выступить на конференции РИТ++ 2011, которая пройдет в Москве в конце апреля. Предварительная тема доклада: «Сетевая подсистема Windows глазами разработчика. Краткий, неполный и, в основном, неверный обзор. 
» Я собираюсь рассказать о том, как работает ядерная часть сетевой подсистемы, как данные попадают в user mode и что с ними происходит по пути. Заходите на огонёк.
Главная проблема с хуками состоит не в том, как зацепиться, а в том, как отцепиться и ничего не порушить. К примеру, приходит недавно письмо:
We recently saw an AV in stress where our vectored exception handler was called after our dll was unloaded. After investigating the issue, it seems like removing the vectored exception handler does not wait for all users of that exception handler to finish (and does not even remove the exception handler from list for future users if there is one current user). So, there seems to be no way to synchronize removing the exception handler and the dll unloading – any synchronization within the exception handler is useless since the exception thread may be about to call the exception handler.
Недавно мы наблюдали падение приложения во время стрессового тестирования, вызванное тем, что векторный обработчик исключения был вызван после того, как наша DLL была выгружена из памяти. В процессе расследования выяснилось, что, похоже, снятие векторного обработчика исключения не ожидает, пока все пользователи этого обработчика закончат работу (и даже не удаляет обработчик для будущих пользователей, если обработчик в данный момент используется). Так, похоже, что не существует способа синхронизировать снятие векторного обработчика и выгрузку DLL – любая синхронизация в пределах обработчика исключения бесполезна, поскольку поток, в котором произошло исключение, может только готовится вызвать обработчик исключения.
Read more…
Функция DebugBreak() объявлена вот таким образом:
void WINAPI DebugBreak(void);
Если подумать, то это не очень удачный вариант объявления. Гораздо более удобным вариантом был бы:
void __cdecl DebugBreak(...);
Почему? В такую функцию можно передать любой набор параметров. Например, значения переменных интересующих нас в данной точке останова. Или значение нетривиального выражения. А затем в отладчике посмотреть уже готовый результат вместо утомительных попыток понять, куда наш неутомимый компилятор опять заоптимизировал переменную.
Recent Comments