- Threading in .NET
- Exception Handling in .NET
- The MSIL Disassembler
- From Here
This chapter is from the book
This chapter is from the book
This chapter is from the book
The MSIL Disassembler
As discussed in Chapter 16 "The Common Language Runtime," managed code applications in Visual C++ .NET are compiled into an assembly of Microsoft Intermediate Language (IL) code and metadata about other .NET Framework assemblies or executables used in the application. This assembly is then compiled into native code by the JIT compiler and executed by the Common Runtime Language framework.
Because the structure of the managed code executables differs from native code applications, a new set of tools are required to build and examine them. One of these tools is the IL Disassembler or ILDASM.EXE. It shows you the internals of a managed code application so you can learn what namespaces, types and interfaces the code uses. Perhaps the most powerful use of the disassembler is the ability to examine the intermediate language of the code itself, thus giving you a glimpse into the workings of a particular class.
TIP
ILDASM is pronounced Eye Ell Dazzem.
The ILDASM.EXE tool can be used interactively, or to generate a file of disassembly information. This section will focus using ILDASM interactively to to browse the assembly and examine the internals. For information about generating a file of disassembly information from the command line, type ildasm /? or refer to the online documentation in the .NET Framework Tools under MSIL Disassembler.
To illustrate the use of this tool, this section refers to Managed C++ sample, Calc.exe, included with the samples that come with Visual Studio .NET. You should find and install the sample if you want to follow along with the instructions in this section.
The ILDASM tool can be used with any managed code assembly. This means that the tool can be used with Visual Basic, C#, Managed C++ or any language that can generate .NET Framework assemblies. ILDASM will work with any assembly that is on your hard drive or other media,m but not assemblies that are registered in the global assembly cache (GAC). If your Managed C++ includes some native code embedded in the IL code in the assembly. When this is the case, the ILDASM tool cannot display the embedded code in the same manner as the IL code.
Examining Managed Code Applications Using the ILDASM Tool
To begin using the tool you can execute it from the command line (make sure your path includes the .NET Frameworks tools directory, typically C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Bin) or create a shortcut to the tool on your desktop. To run it from the command line open a command console and then enter:
Ildasm {filename}
This will load the application and also open the file that you specified. You will need to provide the drive and path information if the assembly is not in the current directory. You can also start the tool without the filename and then use the File, Open command to locate and load the desired assembly. Once the tool starts you should see something similar to Figure 25.4.
Figure 25.4 The ILDASM tool.
I find it convenient to associate the ILDASM tool with the .dll extension, so I can right-click on a .dll file and choose Open With to open it with the ILDASM tool. On most machines, you will be offered the choice to open the DLL with Microsoft .NET Framework IL disassembler just by right-clicking and choosing Open With. If not, click Browse on the dialog that appears and browse to ILDASM.EXE to make this choice. Click Always Use the Selected Program to Open This Type of File to save time the next time you want to disassemble an assembly.
The main window of the ILDASM tool contains a hierarchical view of the assembly. The top level item is the name of the assembly, followed by the manifest of the assembly. In our example, the name of the application, Calc.exe is listed as the top node of the assembly. Under the manifest is the only class of the assembly, calc, and a static method called modopt. If you open the calc class by clicking on the plus box next to the name you will see the information contained in the class as shown in Figure 25.5.
Figure 25.5 Elements of the Calc class.
ILDASM shows you all of the different parts of the Calc class:
class information (red triangle)
fields (blue-green diamond)
methods (purple square)
Each symbol is superimposed with an S if it is static. The first two elements of the tree are under Calc provide more information about the class. The first item tells you that Calc is a private class. The second item tells you that it inherits from the System.Windows.Forms.Form class which is found in the System.Windows.Forms namespace.
How is this information important? Let's say that you are having trouble running an application on your computer and you suspect it is because there is a dependency that you are missing. In the case of the namespaces that come with the .NET Framework, if you have the Framework installed on your computer, those are probably installed correctly, but using this tool, you could determine if there are other 3rd party namespaces that are required by the program that you do not currently have installed. ILDASM is an excellent way to discover dependencies.
You can get similar information about other items that are shown in the tree. In the Calc example, there are many fields that are listed. The information about the field is easy to understand. Let's look at the m_Op1 field definition.
field m_Op1:private float64
This statement shows that this field is a private field of the Calc class and is a 64-bit floating point variable. This information can be helpful if you are trying to determine why there is a failure when certain values are being used. It could be that the value is not of the right type or too small or large.
If you move the cursor down to the class method call ctor and double click on this you will see a listing of the IL code used in the method ctor, which is the constructor for the Calc class. The listing for this function is found in Figure 25.6
Figure 25.6 The ctor method code listing in ILDASM.
This is where the ILDASM tool really becomes useful. It is possible to see the IL code that was generated from the source code that the JIT compiler will run when it is executed. This is not the same as having access to the source code -- a lot of human readable information is missing. However, it is somewhat similar in principle to assembly language, and can be understood.
The first line defines the ctor function, a public function that uses a special or reserved name in the IL and returns nothing (void return value).
After the brace bracket comes a comment showing the size of the IL code that was generated. This is not the same as the native code size that the JIT compiler will create when the application runs, and it is provided just for information.
The maxstack statement defines the maximum amount of stack that this function will use. The Common Language Runtime is stack based and all instructions either load parameter values onto the stack or pop them off the stack for processing. All return codes are then placed onto the stack for the next instruction. This function will never use more than 1 operand on the stack.
The next seven statements are the functioning portion of the ctor method. The first statement loads the argument passed to it onto the stack. In this case, it is the argument passed to the ctor method during execution. The next statement calls the constructor of the System.Windows.Forms.Form class and then returns. Following this the IL loads the parameter passed to the original ctor method calls the constructor of the System.Object. Finally the stack is loaded and a call to the Calc method InitForm is made. When this method returns then the code exits from the ctor function.
Examining the IL for a method allows you to understand what is taking place in the method. However, the full definition of the IL language is not within the scope of this discussion. Microsoft has documented the whole IL syntax in a document that can be found in the \FrameworkSDK\Tool Developers Guide\docs directory and is called Partition III CIL.doc. Using this documentation, you can read and understand any IL code that will be listed in the ILDASM tool.
The balance of our discussion of the ILDASM tool will focus on the filtering options, dumping features, and the uses of the dump file.
Filtering the Output of the ILDASM Tool
When examining a complex application with ILDASM, the display can become very full and cluttered with information that you may not be all that interested in. The ILDASM tool offers many levels of filtering so that you can concentrate on the relevant aspects of the code.
Figure 25.7 The View menu.
Figure 25.7 shows the contents of the View menu. The first menu item allows you to change the font of the Tree view and also the Disassembly displays in the tool.
The balance of the menu items in the View menu allows you to change the level of information in the tool. Each menu item turns on or off the display of one piece of information. Table 25.4 defines the various menu selections and the information associated with it
Table 25.4 Filters Available in the View Menu
|
Menu Item |
Description |
|
Sort by name |
Sort information in tree view by name |
|
Show Public |
Display/Dump items having only public accessibility |
|
Show Private |
Display/Dump items having only private accessibility |
|
Show Family |
Display/Dump items having family accessibility |
|
Show Assembly |
Display/Dump items having assembly accessibility |
|
Show FamANDAssem |
Display/Dump items having both family and assembly accessibility |
|
Show FamORAssem |
Display/Dump items having either family or assembly accessibility |
|
Show PrivateScope |
Display/Dump items having private scope accessibility |
|
Show member types |
Show types of class members in tree view. |
|
Show bytes |
Show the IL code in hexadecimal. |
|
Show token values |
Show token values in hexadecimal. |
|
Show source lines |
Show the original source code, as comments. Only displayed if source code is available on disk. |
|
Quote all names |
Show all names in quotes |
|
Expand try/catch |
Display all exception clauses in expanded form. |
Dumping IL Output to File
The ILDASM tool also allows you to dump the contents of the managed code application to a file. There are a couple of options for dumping information to disk as shown in Figure 25.8
Figure 25.8 The File menu.
The first option is the Open menu item. This allows the developer to open the desired .exe or .dll for examination. This menu option uses the standard File Open dialog to allow the user to browse to the appropriate location and select the file.
The Dump menu item will take the .exe or .dll and put the IL content into a .il dump file. This resulting .il file can be used by the ILASM tool as input and can be recompiled into an .exe or .dll to be used in the Common Runtime Language environment. A significant amount of information is in this file and it can be very useful when working with a complex or large applications.
The Dump tree view menu item takes the .exe or .dll and creates a text file that shows the tree view of the structure of the application with its classes and members of all of the classes in an output similar to the tree view that the tool shows.
The final menu item is Exit. This menu item will terminate the execution of the ILDASM tool and close any opened files.