The .NET GC Heap and Drill-down Operations
A small window like the one shown in Figure 10 should now be present somewhere on your desktop.
Figure 10
Obviously there is not too much to the application and little to do except to press the "Lonely Mountain" button. (See the JIT Thunk article for more information about the Hobbit/Tolkien references.) After you press the lonely button, the debugger should now be stopped in a disassembly window with a caption like "Disassembly of JITTED Wilderland.WilderlandForm::Hobbiton_Button_Click (06000007) at..." Do you remember setting a breakpoint for this method a short while ago? Well, the CLR in response to the button click event has collaborated with the JIT compiler to create a pile of managed x86 code behind the scenes. Refreshing the JIT Events window will give you an idea of this activity -- my system counts 1266 (1252 on SP2) JIT events now! Perhaps more interesting are the additions to the .NET GC small object heap. Refresh (or reopen) that display as well (View/.NET GC Heap). If you expand the "Wilderland.exe" node and then the "Wilderland.WilderlandForm" node, you should be viewing something like what is shown in Figure 10.
Figure 11
For that image I have also captured the results after double-clicking on the single node under "Wilderland.WilderlandForm". Scroll down the memory display and you will find the field for "Wilderland.WilderlandForm::Hobbiton_Button" which is one of the member fields for the WilderlandForm class. The fields like "System.MarshalByRefObject" up at the top of the display can be explained by returning back to the Index and expanding the ".NET MetaData" and "TypeDefs" nodes under "Wilderland.exe" and selecting View/Detail on the "Wilderland.WilderlandForm" node. Since the Wilderland form is derived from System.Windows.Forms.Form, we can find out more about the base class this way. Select "system.windows.forms.dll" in the Index to load the .NET symbols. Then, expand its ".NET MetaData" node. Select the command View/Search From and type in the text, "System.Windows.Forms.Form" and you will now be placed on the metadata node for this typedef. In the Details window, select Edit/Extends Details and a new details window is opened. If you keep repeating this operation, eventually you will hit a reference to "System.ComponentModel.Component" which is located in a different assembly, system.dll. Find its node in the Index (after first loading the metadata), and you will see that its base is "System.MarshalByRefObject" which is in mscorlib's metadata. Eventually you will find that this typeDef has a field (in the "Fields" node) for something called "__identity" (Remember that you will need to expand the .NET MetaData nodes for each new assembly reference. PEBrowse Interactive will perform "lazy" or just-in-time expansion for heavy-duty nodes like these). Let's do some "drilling-down" in the memory window. Select the line just below the text, "System.Windows.Forms.Control::window" and with the popup menu, choose Search GC Heap. Double-click on the result and you will find the instance values for this object. Pretty cool, huh? But, wait, there is even more! Can you find the value for the field "System.Windows.Forms.NativeWindow::handle" in the memory display? Open up a process information (View/Process Information) window and switch to the User Objects tab sheet. You should be able to find in the list of items an Hwnd object (a window handle) matching the display in the memory dump field. Finally, with the process information display activated, select Edit/Dump on this item and you will now be viewing a snapshot of the kernel memory that backs the window object! Fortunately for you, you cannot modify this memory. But, you can change the other memory addresses by selecting Edit/Modify and entering a new value. (These last operations with the window handle might be unavailable to you if the User Objects tab sheet has been disabled. There is an explanation for that: PEBrowse Interactive employs another heuristic to find the global user objects table which sometimes fails depending on the version of the operating system one is running. Alas -- only the kernel and GDI tables can be found reliably, this one cannot.)
Return back to the disassembly window for the Hobbiton_Button_Click method. A number of nodes in the Index might now be expanded making it more difficult to scroll up and down -- you might want to refresh the Index in order to quickly collapse it. And, you may have a large number of child windows open at this point, so close them as needed except for the Fab Four -- Debugger Log, Disassembly, Registers, and Stack Frame -- and keep the GC Heap window open (One of the drawbacks and strengths of the MDI interface -- large numbers of child windows. If you inadvertently close one or more of the Fab Four, there will be a reunion (unlike the originals) when you step to the next instruction or hit the next breakpoint.) Now, run until the line labeled "end of prologue" -- did you see changes in the registers windows? There now should be a number of references in the general-purpose registers to the objects we are seeing in the GC Heap window. You can also start your drill-down exercises from the registers window by selecting Edit/Search GC Heap. When trying to open new memory windows from the registers display or another memory dump display, you might want to check if there is a "+", i.e., plus-sign, in the first column. Whenever you see one of these, PEBrowse Interactive is nicely informing you that the address is "available", i.e., no more guessing if a value is a valid address reference or not. If you decide to step into some the code behind the call to the Wilderland.WilderlandForm::LonelyMountain method, you first might want to check out my article about the JIT thunk layer at www.codeproject.com/ or at my website for how this can be done without entangling yourself in jungle of the JIT compiler.
 prev page | 1st page | next page  |