Просто удивительно, насколько опасной может быть функция Wow64DisableWow64FsRedirection. Эта функция позволяет временно отключить перенаправление файловой системы в Wow64. Еще более удивительно, что лишь малая доля разработчиков соглашается менять свой код, даже после подробного объяснения, в чем, собственно, проблема.
На днях свалился в inbox вопрос:
The documentation for QueueUserApc states "an APC cannot be queued from a 64-bit process to a 32-bit process or vice versa."
However on Vista Ultimate x64, we can queue a user APC from a 32-bit process to a 64-bit process. In our test application the 64-bit recipient crashes, we haven’t explored why just yet, but the point is that the operation should not succeed and the 64-bit application’s APC queue should never have the APC inserted.
Is it an OS bug?
Документация к функции QueueUserApc утверждает, что асинхронный вызов процедуры (APC) не может быть запрошен из 64-х битного процесса для выполнения в 32-х битном и наоборот.
Однако на Vista Ultimate x64 мы можем выполнить асинхронный вызов пользовательского режима из 32-х битного процесса в 64-х битном процессе. В нашем тестовом приложении 64-х битный получатель падает и мы еще не выяснили почему, но дело в том, что операция (QueueUserApc) не должна завершаться успешно и асинхронный вызов не должен вставляться в очередь вызовов 64-х разрядного процесса.
Это баг ОС?
Вопрос примечателен тем, что это уже третье письмо на эту тему за последние два месяца, хотя функция QueueUserApc далеко не самая широко используемая функция Win32. Не иначе какой настойчивый клиент эту функцию мучает. 
Вопрос:
32-х битный процесс запущен на 64-х битной системе. Почему для некоторых библиотек GetModuleFileName возвращает путь вида “%SystemRoot%\syswow64”, а для других – “%SystemRoot%\system32”, не смотря на то, что и первые, и вторые находятся в “%SystemRoot%\syswow64”?
Ответ:
Потому что загрузчик понятия не имеет о Wow64 и перенаправлении файловой системы в частности. Загрузчик просто сохраняет полное имя модуля во время загрузки и возвращает его копию в GetModuleFileName. Соответственно если библиотека была загружена как “%SystemRoot%\system32\foobar.dll”, то и GetModuleFileName вернёт эту строку.
Это же верно и для других Win32 функций.
В комментариях к загадке ответ был дан почти сразу. Действительно, обработчик отложенной загрузки DLL попытается загрузить «version.dll» по имени, а не по полному пути. В результате загрузчик будет искать библиотеку, пользуясь правилами по умолчанию. Номер два в этом списке поиск DLL в system32, что при отключенном перенаправлении файловой системы, равноценно попытке загрузить 64-х битную DLL в 32-х битный процесс. Бум.
Вот эта программа печатает номер версии указанного пользователем модуля, который она берет из поля “FileVersion” ресурса VS_VERSION_INFO этого модуля. Имя модуля передается как первый параметр командной строки. Для работы с VS_VERSION_INFO используется стандартная библиотека version.dll.
(далее идет много кода)
Скажите, а невозможность загрузки в 64bit-процесс 32bit DLL – фатальна, или же возможны какие-то хаки, недокументированные обходные пути?
Отвечаю здесь, так как ответ получился слушком длинным.
Во-первых, про любые недокументированные возможности меня спрашивать бесполезно. Даже если такая возможность существует, я всё равно о ней не расскажу. Этому есть несколько причин, включая очевидные вещи вроде NDA, законе об авторском праве и т.д. Еще одна причина, почему я не горю желанием это делать, – это то, что раскрывая детали реализации того или иного компонента, я тем самым лишаю этот компонент возможности развиваться и улучшатся в следующих версиях.
Наткнулся на вопрос на форуме iXBT. В Windows SDK помимо флагов KEY_WOW64_64KEY и KEY_WOW64_32KEY определена маска KEY_WOW64_RES. Зачем она нужна?
#ifndef KEY_WOW64_RES
#define KEY_WOW64_RES (KEY_WOW64_64KEY | KEY_WOW64_32KEY)
#endifОтвет: по большому счету она не нужна. В коде Wow64 она используется для выделения флагов KEY_WOW64_64KEY и KEY_WOW64_32KEY из маски доступа для дальнейшей обработки. Указывать оба флага (и KEY_WOW64_64KEY и KEY_WOW64_32KEY) при вызове RegCreateKeyEx, RegOpenKeyEx или RegDeleteKeyEx нельзя, так что приложениям эта маска ни к чему.
Recent Comments