The hero behind the dotnet: MSCOREE.DLL

There are more and more friends who are now developing the. NET framework, but perhaps not everyone knows MSCOREE.DLL very well. And in fact, it's no exaggeration to say that MSCOREE. DLL is one of the most core DLLs in the. NET Framework, and without this DLL, the managed program simply cannot start executing, but since this DLL is hidden in the System32 directory, it is a bit of an injustice to the. Net The behind-the-scenes heroes in the framework. This paper mainly discusses several functions of MSCOREE.DLL and the compatibility problem of MSCOREE.DLL.

Mscoree is the entry point for the managed programLet's do a little experiment:

First write a Most simple Hello World program, compile with CSC (of course you use vs I have no problem):

Public Class program { public static void Main (string[] args) { System.Console.WriteLine ("Hello world!");        }}

Then, on the command line, type:

C:/windows/system32> Ren mscoree.dll mscoree_.dll

Please note that you need to elevate permissions on the Vista system, otherwise renaming fails. After that, run the EXE program that you just compiled. Windows Direct error:

Then, change the Mscoree.dll name back, run A.EXE again, this time the correct print out Hello world.

So why can't the simplest Hello World run without MSCOREE.DLL?

Friends who are programmed with C + + in Windows should be familiar with the meaning of the above error dialog box, which usually occurs when the program cannot find the required DLL. We can view A.EXE's dependencies on DLLs by running Depends.exe in Visual Studio:

You can see that A.EXE only has a dependency on a DLL, which is MSCOREE.DLL. And A.EXE only used a function in the MSCOREE.DLL, namely _CorExeMain. The MSCOREE.DLL itself, however, outputs more than 137 functions. From the name of this function you can guess that this function is an entry point for EXE. To confirm this, we can use DUMPBIN to look at the content:

Microsoft (R) coff/pe dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved.   Dump of File A.exe PE Signature found File type:executable IMAGE FILE HEADER VALUES14C Machine (x86)3 Number of sections 46c83e12 Time Date stamp Sun 19 20:56:50 2007 0 file pointer to symbol table0 Number of symbolsE0 size of optional header10E CharacteristicsexecutableLine numbers stripped Symbols Stripped + bit word machine OPTIONAL HEADER VALUES10B Magic # (PE32)8.00 Linker VersionSize of codesize of initialized data0 Size of uninitialized data 23DE entry point (004023DE) Base of code4000 base of data 400000 image Base (00400000 to 00407FFF)

Note that the RVA of this EXE's entry point is 23DE. Then use WinDbg to load the A.EXE, and use the LMM (List module match) command to see the first address of the A.EXE load:

0:000> lmm a Start End Module Name 00de0000 00de8000 A (deferred)

Can see is 0x00de0000, then add 23DE this RVA value, is the entry point of the program. Take a look at the disassembly with u command:

0:000> u de23dea+0x23de: 00de23de ff250020de00 jmp DWORD ptr [a+0x2000 (00de2000)]

You can see that this is a simple jump instruction that jumps to where 0x00de2000 is pointing, so what is the function of this position? We can view it through the DDS command:

0:000> DDS 2000+de000000de2000 5b034e50 mscoree!_corexemain

The fact is clear that the entry point in any managed EXE program is a JMP instruction that jumps directly to MSCOREE.DLL's _CorExeMain function execution. The _CorExeMain address (that is, the 0x5b034e50 saved by 00de2000) is filled in by the OS loader, because this location is the location of the import table. For a managed DLL, the situation is very similar, and the entry point is _CorDllMain:

As you can imagine, if you do not have the. NET Framework installed in your system, executing a managed program will also immediately be the same dialog box. Obviously according to this information the user itself is hard to infer what has happened. One possible scenario is that Windows always comes with a MSCOREE.DLL, and this MSCOREE.DLL will give a clearer error message if no. NET framework is found. However, since all versions of Windows from Windows 2003, including Vista, will come with the. Net Framework, the problem is largely non-occurring.

Mscoree is responsible for selecting the. NET Framework version

MSCOREE. DLL has a very special place, that is, it is located in the C:/windows/system32 directory, in other words, no matter how many different versions of the. NET framework are installed on your system, this DLL can only have a maximum of 2 copies (32 bits/64 bits each), and in C :/windows/microsoft.net/framework or C:/windows/microsoft.net/framework64 below, there will be multiple different. NET frameworks present at the same time. So, how does this MSCOREE.DLL correspond to different versions of the. NET framework? The answer is simple: MSCOREE.DLL uses the registry information to determine the. NET Framework version number installed on the system, and then chooses an appropriate version of the. NET Framework to perform according to the required version of the application itself. The real work is given to a certain version of the actual. NET DLL, under normal circumstances, this DLL is the work station version of the CLR, named MSCORWKS.DLL, and the server version of the CLR corresponds to MSCORSVR.DLL

programs can invoke the CLR's provided functionality via Mscoree or customize the CLR

MSCOREE. DLL exports a large number of functions, are these functions public and can be called? The answer is yes. Almost all of these functions can be found in the corresponding document in MSDN, and there is a corresponding mscoree.h in the Include directory of the. NET Framework SDK, which provides the prototype for these functions. Through these functions, the application can access the various functions provided by the CLR, such as:

Name of function	Use
GetCORSystemDirectory	Get the installation directory of the CLR loaded in the process
GetCORVersion	Gets the version of the CLR that is loaded in the process West Nxi
GetFileVersion	Get CLR version information for the specified file
GetRequestedRuntimeInfo	Get information about the specified version of the CLR
GetRequestedRuntimeVersion	Get CLR version information required for the application to run
ClrCreateManagedInstance	Create a. NET object and returns the specified interface, using this function to access a large number of the existing functions of the. NET Framework
CorBindToRuntime	Loading the specified version of the CLR
CorBindToRuntimeHost	Used when loading the specified version in host Clr,hosting
CreateDebuggingInterfaceFromVersion	Get the ICorDebug interface for the corresponding version of the CLR for writing debuggers (such as visual Studio)
Corlaunchapplication	Start the managed program with the specified parameters

There are many more, but here are just a few of the more commonly used functions. You can see these features are very useful, especially worth proposing are corbindtoruntimehost and createdebugginginterfacefromversion. The former provides custom functionality for all aspects of the CLR, and is very powerful, and interested friends can refer to the MSDN or customizing the Common Language Runtime book. The latter provides debugging support for managed programs through the ICorDebug interface.

Mscoree provides support for COM

Unmanaged code can directly call the managed object in the. NET assembly through COM. Take this object as an example, the CLSID of this object is {0029598f-26fa-46f7-953b-86e2947ab19f}, The type is Microsoft.SqlServer.Replication.ComErrorRecord, and the threading model is both,assembly named Microsoft.SqlServer.Replication, Version =9.0.242.0, Culture=neutral, publickeytoken=89845dcd8080cc91, the required CLR version is v2.0.50727 (2.0 RTM). Most notably, the entry point is Mscoree.dll.

For COM, com's only known clsid=0029598f-26fa-46f7-953b-86e2947ab19f} COM object is in MSCOREE.DLL. And in fact, This type is located in the Microsoft.SqlServer.Replication.dll, but COM does not know, com just need to know from MSCOREE.DLL can get the corresponding classfactory, and then COM will be connected through IClassFactory Port to create an instance of this managed object and return the corresponding interface. Assuming an unmanaged program tries to create such an object through COM, the following things happen:1.      program calls CoCreateInstance notify COM to create such an object, the CLSID =0029598f-26fa-46f7-953b-86e2947ab19f, need to return IDispatch interface 2.      COM calls the CoGetClassObject function to find the corresponding entry dll3.     com find the corresponding registry, found that the corresponding DLL is mscoree.dll4.      com loads the MSCOREE.DLL, calls the DllGetClassObject function, and passes in the Clsid5.     mscoree. The DllGetClassObject function in the DLL reads the CLSID, finds the corresponding registry, gets the object's type name, assembly name, CLR version, and other information 6.      DllGetClassObject loading the corresponding version of Clr7.     dllgetclassobject returns a temporary class The IClassFactory interface of the factory object 8.     com calls the IClassFactory of this class factory object:: The CreateInstance method 9.      the class factory to load the corresponding CLR and creates the object, returningBack to an object of the CCW (Com callable Wrapper), and the CCW's return to the specified IDispatch interface can be seen, in this case the most critical function is the DllGetClassObject function provided by MSCOREE.DLL.

In addition to providing COM support for user-defined managed objects, MSCOREE. DLL itself also supports a small number of COM objects, so MSCOREE.dll supports DllGetClassObject, DllRegisterServer, DllUnregisterServer, DllCanUnloadNow these com The standard function that the DLL needs to support.

MSCOREE. DLL compatibility issues

We can consider that if we now have the. NET Framework 1.0 and then installed the. NET Framework 2.0, then MSCOREE.DLL will change. The answer is that if a change to 2.0 to 1.0 is required to modify the MSCOREE.DLL (such as adding a function), then it is important to update MSCOREE.DLL, but this MSCOREE.DLL must fully support all the. NET Framework 1.0 in the MSCOREE.DLL function, otherwise you can imagine that all dependent on these changes in the MSCOREE.DLL function program will be error. Therefore MSCOREE.DLL must be fully forward compatible.

Consider the unloading situation, if the. NET Framework 2.0 is unloaded at this time, will the MSCOREE.DLL be reverted to the. NET Framework 1.0? The answer is no. Since the 2.0 MSCOREE.DLL itself supports the. NET Framework 1.0, there is no need to replace it. This is the simplest.

In fact, CLR team generally rarely changes MSCOREE.DLL to avoid compatibility issues, so it is foreseeable that MSCOREE.DLL will be the least varied DLL in. NET framework/clr. In other words, the content of this article, in the foreseeable future several versions basically will not be outdated. OK, for the discussion of MSCOREE.DLL here is over, interested friends can write some of their own small programs, the actual experience of MSCOREE.DLL provided by the various functions.

The hero behind the dotnet: MSCOREE.DLL