Demo showing how to dump .NET object using !do command

(We will provide the demo application (simulatebox) available for download to do this demo)

!do (!dumpobj) command demo steps

Output: This command prints the state of an object which is supplied as parameter

Usage:  !do {object address}

When to use ( A sample demo scenario)

 Consider A .NET application processes many patient input records. Users started identifying that the application crashes occasionally while processing records.  A debugger collected the crash dump, he wanted to examine the process state during the application crash.  He wanted to check any invalid data caused the application crash.

He found that two patient records were under processing during the time of crash. He wanted to inspect both these records

He printed the object state of these records using dump object (!do) command.

Let’s do this demo. Here is the demo steps.

(Instead of a dump analysis we shall do a live debugging by attaching the process. But the troubleshooting approach is similar in both cases)

We also have a demo video demonstrating the steps

   

1.       Open Simulatebox application  on (Win 7/8/10) machines

2.       Select !dumpObject demo

3.       Apply button [create patients] . Observe message “two patient objects created”

4.       We need to inspect these two objects in a debugger. Open WinDBG (x86 version)

5.       Attach the simulatebox app with debugger

       Open File -> Attach to a process menu in debugger

6.       Search and select Simulatebox application in the dialog box,  Apply [ok]

7.       The  application is attached with debugger. Load SOS dll to debugger

(SOS dll contains .NET debugging commands. So this is an important step  to do while debugging a  .NET application using WinDBG)

8.        Apply command     .loadby sos clr

9.       Now we need to search the patient records existing in the Application’s memory (heap). So to get all patient objects from heap ,  Use this command

10.    Apply the command  !dumpheap -type Patient  ( see result snapshot below)

11.       We can see two patient objects. Debugger want to check the state ( values of its data members) of these  patient records. He suspects these objects may be corrupted that led to application crash.

12.       Copy the first object. Dump the object .Apply !do {object address}

13.       The object state printed. Observe its data member values

       Patiant ID = 1

       There is History data member of type String. We need to print its values. Since string is also a .NET object we can use !do command on its address. Copy its address available in the Value column.

14.       Apply !do {string address} and observe the result

15.        Debugger is able to see the string content “ Patiant A Case history” . Debugger reasonably believes that it is a good record. he wanted to check the other patient record.

16.       Copy the second  patient object address { result from step 10) and repeat the steps (11 –

17.       Observe the second object data member (history ) content. There are junk values. The record is corrupted. (figure below)

       So debugger determines whenever such invalid are getting processed, Application unable to process them and crashes.  He forwards his findings to respective dev groups to check the possibilities of pushing invalid data.

So by this example, we wanted to show the usability of !do command.  Pretty useful command to check the internal state of .NET objects .

Demo :Learn !dumpdomain command

Process boundary

Applications running on windows are protected by each other. Each application has a process and they are separated (isolated) by their process boundary. So if an application crashes due to some issues, its process gets killed, but the other applications are unaffected.

The process boundary provides great security benefits. It also adds few restrictions when processes communicates each other. This is because memory addresses on one process has no meaning for the  other application. The components within an application communicate (transfer data) freely but the data transfer between the processes would require additional work like marshaling (copy data from one  process , pass the data and place it to meaningful address location of other process)

Application domains

App domains carry the same concept of providing isolation and security but they are within the process. By default , .NET CLR create three application domains to any .NET application with names (System ,Shared and default) .User can programmatically add new domains to applications.   The cross-domain communication requires marshaling. 

Hosting applications (Ex: IIS processes) utilizes multiple .NET app domains to load web applications in separate app domain so that applications behave so distinct and isolated each other. 

The brief description of CLR created domains for an application is listed below.

System domain : The first application domain created on the application. It is responsible for creating other two domains ( Shared and default). This domain loads mscorlib dll to shared application domain.

Shared Domain: This is the place where the shared code exists . There is a type of assemblies called domain neutral assemblies(their code can be accessible in all app domains). They are getting loaded to this app domain.

Default domain:  The domain where application specific data and assemblies resides.