dónde está ubicado o alojado exactamente

Es solo una DLL simple, encontrará la versión x86 en C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll. La versión x64 está en el directorio Framework64. La versión .NET v2 tenía un nombre diferente, mscorjit.dll, búsquelo en los directorios v2.0.50727.

No está "alojado" en absoluto, el sistema operativo ignora por completo que existe. El CLR sabe cómo localizarlo y cargarlo. Necesariamente, es el CLR el que decide cuándo iniciar un programa. Simplemente tiene el nombre DLL codificado y usa LoadLibrary("clrjit.dll") para cargarlo, GetProcAddress("getJit") para obtener la función de fábrica. Algo que puede ver en el código fuente de CoreCLR, aunque el jitter ya no es una DLL separada en esa versión de CLR.

También puede ver el CLR con Explorer, nuevamente solo un archivo DLL simple. Es clr.dll en las versiones v4, mscorwks.dll y mscorsvc.dll en las versiones v2. Dos diferentes en ese entonces con diferentes recolectores de basura, "wks" es la versión de la estación de trabajo, "svc" es la versión del servidor. Compare con la entrada del archivo de configuración <gcServer> .

Lo que mueve la pregunta a "¿cómo se carga el CLR?" Ese es el trabajo de c:\windows\syswow64\mscoree.dll, usará c:\windows\system32\mscoree.dll cuando apunte a x64 en su proyecto EXE. Cada ensamblado de .NET tiene 5 o 9 bytes de código no administrado, un salto a esa DLL. _CorExeMain o _CorDllMain, dependiendo de si el ensamblado se creó como un exe o una biblioteca. mscoree.dll echa un vistazo a los metadatos en el ensamblado y decide qué versión de CLR debe cargarse para que pueda ejecutarse correctamente.

Están sucediendo muchas más travesuras, acabo de publicar la vista de 10,000 pies que pediste. Si esto le interesa, probablemente desee obtener más información sobre el alojamiento CLR personalizado para ver al hombre detrás de la cortina.

¿Cómo el sistema operativo Windows activa/ejecuta las ejecuciones ejecutables de .NET dentro de .NET Runtime?

Cada ensamblado administrado o ejecutable de .NET tiene encabezados CLR especiales, que puede ver al ver el ensamblado en ILDASM. Estos encabezados apuntan a la versión del tiempo de ejecución que debe cargarse. Además, está la Sección de imagen con la Import Address Table , que indica lo que debe cargarse:

 ----- Image sections: Import Address Table DLL : mscoree.dll 0x00002000 Import Address Table 0x0000a37e Import Name Table 0 Time Date Stamp 0 Index of First Forwarder Reference 0x0000 _CorDllMain ----- CLR Header: Header size: 0x00000048 Major runtime version: 0x0002 Minor runtime version: 0x0005 0x00003184 [0x00007078] address [size] of Metadata Directory: Flags: 0x00000001 Entry point token: 0x00000000 0x00000000 [0x00000000] address [size] of Resources Directory: 0x00000000 [0x00000000] address [size] of Strong Name Signature: 0x00000000 [0x00000000] address [size] of CodeManager Table: 0x00000000 [0x00000000] address [size] of VTableFixups Directory: 0x00000000 [0x00000000] address [size] of Export Address Table: 0x00000000 [0x00000000] address [size] of Precompile Header:

Cuando lo ejecuta el sistema operativo, se mscoree.dll (o The Shim), y es el iniciador de clr.dll y clrjit.dll para .NET 4.0 y superior, o mscordacwks.dll y mscorjit.dll para .NET 2.0 o inferior, que son el tiempo de ejecución y el JIT, respectivamente. Puede ver que se indica que el punto de entrada nativo de dll es el método _CorDllMain para una biblioteca de clases y _CorExeMain para un ejecutable, que es responsable de la carga y el arranque del punto de entrada. Ellos, a su vez, llamarán al punto de entrada de sus aplicaciones, en el entorno administrado.

Esto se basa en mi comprensión y lo guiará hacia su respuesta, pero es posible que no se elimine por completo.

Los archivos EXE/DLL que componen DotNet Runtime (CLR, etc.) se encuentran en las siguientes ubicaciones:

 C:\Windows\Microsoft.NET\Framework // for the 32 bit runtime C:\Windows\Microsoft.NET\Framework64 // for the 64 bit runtime

Allí, tiene las diferentes ediciones, como 2.0.50727, 3.0, 3.5 y 4.0.30319 (versiones en mi sistema hoy).

Aquí es donde se encuentran y ejecutan MSBuild, así como los archivos que están registrados con IIS.

No sé si esto termina siendo alojado por Windows en tiempo de ejecución, o si hay un EXE real al que podría adjuntarse con un depurador y ver en el administrador de tareas.

Esperemos que esto le proporcione más información.