Jak działa CorFlags.exe/32BIT +?

Question

Domyślam się, że moje pytanie dotyczy ładowarek CLR. Chcę zrozumieć mechanizmy kryjące się za funkcją CorFlags.exe/32BIT+.

Wiemy, że po uruchomieniu zespołu skompilowanego z flagą Any CPU ustawioną na 64-bitowym systemie Windows, rozpoczyna się proces 64-bitowy. Jeśli wykonamy jeden wiersz CorFlags /32BIT+ na tym zestawie, zostanie on uruchomiony jako proces 32-bitowy. Myślę, że to fascynująca funkcja.

mam tak wiele pytań o tym:

1. Jak to jest realizowane?
2. Czy program ładujący system operacyjny jest zaangażowany?
3. Czy można zbudować niestandardową aplikację (chyba niezarządzaną), która ładuje na życzenie 32-bitowe lub 64-bitowe CLR?

Czy istnieje artykuł, książka, blog itp., Który wyjaśnia wewnętrzne działanie tej funkcji?

Answer 1

To nie jest dobrze udokumentowane w żadnym miejscu, które znam, mogę tylko wskazać ci odpowiedni artykuł MSDN. Tak, twoje założenie jest poprawne, program ładujący w systemie Windows XP i nowszym ma świadomość zarządzanych plików wykonywalnych. Automatycznie ładuje podkładkę ładującą .NET (c: \ windows \ system32 \ mscoree.dll), odpowiednim punktem początkowym jest _CorValidateImage(). Sekcja Uwagi w połączonym artykule MSDN opisuje mechanizm, który przekształca 32-bitowy plik .exe w proces 64-bitowy:

W systemie Windows XP i nowszych wersjach program ładujący system operacyjny sprawdza zarządzane moduły, analizując bit deskryptora COM w nagłówku wspólnego pliku obiektów (COFF). Ustawiony bit wskazuje zarządzany moduł. Jeśli ładowarka wykryje zarządzanego modułu ładuje Mscoree.dll i wzywa _CorValidateImage, który wykonuje następujące czynności:

• potwierdza, że ​​obraz jest poprawny moduł zarządzania.
• Zmienia punkt wejścia obrazu na punkt wejścia we wspólnym środowisku wykonawczym języka (CLR).
• W 64-bitowych wersjach systemu Windows modyfikuje obraz znajdujący się w pamięci, przekształcając go z formatu PE32 na PE32 +.
• Powraca do modułu ładującego po załadowaniu obrazów modułu zarządzanego.

W przypadku obrazów wykonywalnych program ładujący system operacyjny wywołuje funkcję _CorExeMain, niezależnie od punktu wejścia określonego w pliku wykonywalnym. W przypadku obrazów zespołu DLL program ładujący wywołuje funkcję _CorDllMain .

_CorExeMain lub _CorDllMain wykonuje następujące czynności:

• Inicjuje CLR.
• Lokalizuje zarządzany punkt wejścia z nagłówka CLR zespołu.
• Rozpoczyna wykonywanie.

Program ładujący wywołuje funkcję _CorImageUnloading po wyładowaniu obrazów z modułu zarządzanego .Jednak ta funkcja nie wykonuje żadnej akcji; to po prostu wraca.

Answer 2

Aby dodać do odpowiedzi Hansa, istnieje również kod trybu jądra systemu Windows, który odpowiada na tę flagę. Każdy załadowany plik wykonywalny ma powiązaną z nim strukturę jądra, SECTION_IMAGE_INFORMATION. Oto jego informacje symbol:

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 

Flagi ComPlusILOnly i ComPlusNativeReady są związane z .NET ComPlusILOnly po prostu mówi, jeśli zespół jest CIL tylko (nie mieszane lub Native - w tym przypadku montaż jest już architektura szczególnego), ComPlusNativeReady ma wartość 1 tylko wtedy, gdy parametr/32BIT + nie jest ustawiony (32BITREQ or 32BITPREF in newer CorFlags version). Te flagi są sprawdzane podczas nt!PspAllocateProcess i na ich podstawie tworzony jest proces 32-bit lub 64-bit.

I wrote about it z niektórymi szczegółami.