Вопрос по – Как работает CorFlags.exe / 32BIT +?

11

Я думаю, мой вопрос оCLR Loader. Я хочу понять механику позадиCorFlags.exe /32BIT+ функциональность.

Мы знаем, что когда начинается сборка, скомпилированная сAny CPU Флаг установлен на 64-битной Windows, он запускается как 64-битный процесс. Если один прогонCorFlags /32BIT+ на этой сборке он запустится как 32-битный процесс. Я думаю, что это захватывающая особенность.

У меня так много вопросов по этому поводу:

How is it implemented? Does the OS Loader get involved? Is possible to build a custom application (I guess an unmanaged one) that loads 32-bit or 64-bit CLR at a wish?

Есть ли статья, книга, блог и т. Д., Которые объясняют внутреннюю работу этой функции?

Ваш Ответ

2   ответа
2

Добавить на Ганса & apos; ответ, есть также некоторый код режима ядра Windows, который отвечает на этот флаг. Каждый загруженный исполняемый файл имеет структуру ядра,SECTION_IMAGE_INFORMATION, связанный с этим. Вот его символьная информация:

 0: kd> dt nt!_SECTION_IMAGE_INFORMATION
           +0x000 TransferAddress           : Ptr64 Void
           +0x008 ZeroBits                  : Uint4B
           +0x010 MaximumStackSize          : Uint8B
           +0x018 CommittedStackSize        : Uint8B
           +0x020 SubSystemType             : Uint4B
           +0x024 SubSystemMinorVersion     : Uint2B
           +0x026 SubSystemMajorVersion     : Uint2B
           +0x024 SubSystemVersion          : Uint4B
           +0x028 GpValue                   : Uint4B
           +0x02c ImageCharacteristics      : Uint2B
           +0x02e DllCharacteristics        : Uint2B
           +0x030 Machine                   : Uint2B
           +0x032 ImageContainsCode         : UChar
           +0x033 ImageFlags                : UChar
           +0x033 ComPlusNativeReady        : Pos 0, 1 Bit
           +0x033 ComPlusILOnly             : Pos 1, 1 Bit
           +0x033 ImageDynamicallyRelocated : Pos 2, 1 Bit
           +0x033 ImageMappedFlat           : Pos 3, 1 Bit
           +0x033 BaseBelow4gb              : Pos 4, 1 Bit
           +0x033 Reserved                  : Pos 5, 3 Bits

ФлагиComPlusILOnly а такжеComPlusNativeReady связаны с .NET,ComPlusILOnly просто говорит, если сборкаCIL только (не смешанный или нативный - в этом случае сборка уже зависит от архитектуры), иComPlusNativeReady равен 1, только если / 32BIT + не установлен (32BITREQ или 32BITPREF в более новой версии CorFlags). Эти флаги проверяются во времяnt!PspAllocateProcess и на их основе32-bit или же64-bit процесс создан.

Я писал об этом с некоторыми деталями.

Большое спасибо!!! Я запутался в расчете некоторых смещений полей этой структуры, используя устаревшую информацию в Windows NT / 2000 Native API Reference.
5

Это не очень хорошо задокументировано в любом месте, о котором я знаю, я могу лишь указать вам на соответствующую статью MSDN. Да, ваше предположение верно, загрузчик в Windows XP и выше осведомлен об управляемых исполняемых файлах. Он автоматически загружает подкладку загрузчика .NET (c: \ windows \ system32 \ mscoree.dll), соответствующая точка входа_CorValidateImage (), Раздел «Примечания» в связанной статье MSDN описывает механизм, который превращает 32-разрядный файл .exe в 64-разрядный процесс:

In Windows XP and later versions, the operating system loader checks for managed modules by examining the COM Descriptor Directory bit in the common object file format (COFF) header. A set bit indicates a managed module. If the loader detects a managed module, it loads MsCorEE.dll and calls _CorValidateImage, which performs the following actions:

  • Confirms that the image is a valid managed module.
  • Changes the entry point in the image to an entry point in the common language runtime (CLR).
  • For 64-bit versions of Windows, modifies the image that is in memory by transforming it from PE32 to PE32+ format.
  • Returns to the loader when the managed module images are loaded.

For executable images, the operating system loader then calls the _CorExeMain function, regardless of the entry point specified in the executable. For DLL assembly images, the loader calls the _CorDllMain function.

_CorExeMain or _CorDllMain performs the following actions:

  • Initializes the CLR.
  • Locates the managed entry point from the assembly's CLR header.
  • Begins execution.

The loader calls the _CorImageUnloading function when managed module images are unloaded. However, this function does not perform any action; it just returns.

Это легко, Windows 2000 x64 в последний раз использовалась великим белым Yeti.
Вот это да. Интересно, есть ли способ воспользоваться этой «особой осведомленностью»? создать надлежащие толстые (нативный код) двоичные файлы для Windows.
Попробовал, не нашел ответа. Вероятно, эта магия вообще не сработает, если в ОС не установлено .NET. Что делает это бесполезным для нативных исполняемых файлов.
Спасибо за быстрый ответ. Это хорошая отправная точка. Я хотел узнать, как clr работает с разделами .reloc. Я копался в sscli, в основном в pedecoder.h / pewriter.cpp и нашел мои ответы. Тем не менее, есть много вопросов (например, как насчет Windows 2000 x64), но я думаю, что я найду ответы в sscli. Nullptr Dev

Похожие вопросы