.NET 4.5.1 Preview now includes a new enumeration called GCLargeObjectHeapCompactionMode that has two fields:

• CompactOnce - The next time a full GC occurs the LOH will be compacted. Once done, it reverts back to the default behavior which is non compacting.
• Default - Default behavior is non compacting.

In order to set the LOH compaction mode using the enum above, simply use the GCSettings class and its corresponding LargeObjectHeapCompactionMode property:

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;

GC.Collect();     // This will cause the LOH to be compacted (once).

The .NET 4.5.1 Preview can be downloaded from: https://www.microsoft.com/visualstudio/eng/2013-downloads

 As always, please note that this is a Preview release and as such functionality and behavior is subject to change.

      MT    Count    TotalSize Class Name

...

...

737bc460       26          728 System.RuntimeType
737bca30       12          768 System.Int32[]
737bca68    51661       619932 System.Int32
7376b180       31       935720 System.Object[]
0055cf08    48361      1771906      Free
737bb2a8   151831      6022544 System.String

The highlighted line above tells us that we have roughly 150,000 instances of strings on the managed heap that occupies about 6MB of memory. Not a huge amount of memory but concerning nonetheless since in this particular application I don't expect it to ever have this many instances of a string type laying around. Hence, my conclusion is that we are somehow "leaking" (or rather, holding on to for far too long) 150,000 instances of strings when we shouldn't be. Now it's a simple matter of figuring out who references those instances and why. Or is it really that simple? If we step back and think about what !DumpHeap -stat is telling us - there are 150,000 instances of strings but it doesn't tell us anything whether those instances are still alive or not. For example, a good chunk of the above instances might not be referenced and are therefore eligible for garbage collection. In those cases, we're not really interested in investigating further since they are about to get cleaned up. How do we know which instances (out of the 150,000) are alive or dead? Well, we can certainly run !gcroot on all of them but chances that by the time you got to instance 10 you'd be falling asleep at the wheel. Luckily - in SOS 4.5 there are two additional switches to the !DumpHeap command:

• -live : Indicates that you only want !DumpHeap to output instances that are considered alive.
• -dead : Indicates that you only want !DumpHeap to output instances that are considered dead (and therefore eligible for garbage collection).

With those two switches, our exercise now goes from spending a ridiculous amount of time manually running !gcroot to simply adding the -live (or -dead) switch. In the example above, once I ran !DumpHeap -stat -mt 737bb2a8 -live I got the following output:

0:005> !DumpHeap -stat -mt 737bb2a8 -live
Statistics:
      MT    Count    TotalSize Class Name
737bb2a8   100167      4782606 System.String
Total 100167 objects

This means that out of the total of 150,000 instances 100,000 are considered alive and the rest will eventually be garbage collected.

The addition of -live/-dead switches to !DumpHeap can save a great deal of time when chasing down which objects on the managed heap are considered dead/alive and can dramatically reduce the amount of time spent on debugging excessive memory usage in .NET applications.

Happy Debugging!

At a high level, a watch window allows you to watch the results of expressions. The expressions can be as simple as the value of a local variable but can also be much more complicated. Imagine we have the following simple code that multiple threads execute concurrently:

private static void WorkThreadFunction()
{
    for (int i = 0; i < max_list_len; i++)
    {
        // Do work              
    }
}

Nothing too fancy – simply multiple threads iterating through a list of some sort. Now, lets say that 25 threads were currently executing the function above and we want to see at which iteration (‘i’) each of the threads is currently executing. Previously we would have to switch the active thread context 25 times and record the value of ‘i’ somewhere. Instead, with Visual Studio 2012 RC we can bring up the Parallel Watch Window as shown below:

Choosing Parallel Watch Window 1 (there are four to choose from) displays the Watch Window:

By default, the Parallel Watch Window brings up all the thread currently executing in the process. In order to add new watches, we need to click “<Add Watch>” column which allows us to enter an expression. In our case, the expression is as simple as showing the local variable ‘i’:

As soon as the watch is added we can now see the expression evaluated across all the different threads in the watch window:

Another interesting aspect of the Parallel Watch Window is that you can sort the columns as well as adding a filter to the watch (Filter by Boolean Expression).

This is a pretty powerful and time saving feature if you spend lots of time doing multithreaded debugging.

Until next time, happy debugging!

To start using the powerful WinDbg commands and extensions in Visual Studio 2012 it requires that you install the WDK on top of Visual Studio 2012. Once the install is completed you will notice a new transport as shown below:

In the transport dropdown there will be several new choices including Windows User Mode Debugger which is what you want to pick to enable the WinDbg experience. Once you select your process and click attach the debugger immediate window will be displayed and serves essentially the same purpose as the WinDbg command window:

You can now execute all the cool and powerful commands that you would otherwise do in WinDbg directly in the debugger immediate window! This is a great step forward to unifying the debugging experience and avoiding the need to learn two different tools.

Until next time, happy debugging!

UPDATE:

Some users are reporting that the Windows User Mode Debugger is not showing up as a transport option. On Visual Studio 2012 RC it looks like you must also install the Windows SDK for this option to appear.

One of key things we are taught about lock constructs in general is that a thread will wait indefinitely on a lock to become available before being allowed to continue. Is that always true? Not quite. Let’s take a look at a simple piece of code:

private void webBrowser1_Navigating(object sender, WebBrowserNavigatingEventArgs e)
{

…

lock(someObj)

{

}

}

The intent behind the code is rather simple – protect the resources by using a .NET Monitor (under the covers, the lock keyword is just syntactic sugar for entering a Monitor). If a thread already holds the lock, all other threads will wait until it becomes available again before one of the waiting threads is awoken and allowed to continue.  Now, let’s assume that the code was running on the main UI thread and that the lock was already held by a non UI thread. Based on what we know about the Monitor, the UI thread would wait indefinitely for the lock to become available.  The net result must be a frozen UI (thread is blocked waiting and not pumping messages).

Almost – it turns out that in the case of a main UI thread (STA) the blocking thread can be woken up for another reason besides the lock becoming available. Let’s take a look at the (abbreviated) stack trace when this occurs to get a better idea of how it works internally:

System.Threading.Monitor.ReliableEnter
System.Threading.Monitor.Enter
BrowseApp.Form1.webBrowser1_Navigating
System.Windows.Forms.WebBrowser.OnNavigating
System.Windows.Forms.WebBrowser+WebBrowserEvent.BeforeNavigate2
System.RuntimeMethodHandle.InvokeMethod
System.Reflection.RuntimeMethodInfo.Invoke
System.Windows.Forms.UnsafeNativeMethods.CallWindowProc
System.Windows.Forms.NativeWindow.DefWndProc
System.Windows.Forms.WebBrowserBase+WebBrowserBaseNativeWindow.WndProc
System.Windows.Forms.NativeWindow.Callback
System.Threading.Monitor.ReliableEnter
System.Threading.Monitor.Enter
BrowseApp.Form1.webBrowser1_Navigating
System.Windows.Forms.WebBrowser.OnNavigating
System.Windows.Forms.WebBrowser+WebBrowserEvent.BeforeNavigate2
System.RuntimeMethodHandle.InvokeMethod
System.Reflection.RuntimeMethodInfo.Invoke
System.Reflection.RuntimeMethodInfo.Invoke
System.Windows.Forms.UnsafeNativeMethods.CallWindowProc
System.Windows.Forms.NativeWindow.DefWndProc
System.Windows.Forms.WebBrowserBase+WebBrowserBaseNativeWindow.WndProc
System.Windows.Forms.NativeWindow.Callback
System.Threading.Monitor.ReliableEnter
System.Threading.Monitor.Enter
BrowseApp.Form1.webBrowser1_Navigating
System.Windows.Forms.WebBrowser.OnNavigating
System.Windows.Forms.WebBrowser+WebBrowserEvent.BeforeNavigate2
System.RuntimeMethodHandle.InvokeMethod
System.Reflection.RuntimeMethodInfo.Invoke
System.Reflection.RuntimeMethodInfo.Invoke

<snip>

The highlighted frames seem to be repeating themselves a number of times. Our webBrowser1_Navigating method that should have been waiting on a lock to become available somehow was woken up. It’s clear from the call stack what caused it to be woken up was due to the thread continuously pumping window messages (and each message in turn caused the same navigation method to be executed). What is not clear though is how that actually happens. How can a thread that is blocking be woken up? The answer lies in the API that the CLR uses to perform the wait. Instead of using an API such as WaitForSingleObject it uses the API highlighted below:

USER32!InternalCallWinProc+0x23
USER32!UserCallWinProcCheckWow+0x109
USER32!DispatchMessageWorker+0x3bc
USER32!DispatchMessageW+0xf
ole32!CCliModalLoop::PeekRPCAndDDEMessage+0x4c
ole32!CCliModalLoop::BlockFn+0x6c
ole32!CoWaitForMultipleHandles+0xcd
clr!MsgWaitHelper+0x64
clr!Thread::DoAppropriateWaitWorker+0x21c
clr!Thread::DoAppropriateWait+0x65
clr!CLREventBase::WaitEx+0x128
clr!CLREventBase::Wait+0x1a

The API CoWaitForMultipleHandles is able to pump messages while it’s waiting and thereby make sure that the UI is responsive. What is the big fuzz then? This is great news! On a main UI thread we can block on a lock but also make sure the UI is responsive while blocking. The biggest problem with this approach is that you have to be extremely careful about what type and how many messages are pumped while you are in a blocked state. Imagine that the lock was held for quite some time and during that time 100’s of navigation events fired. What you would essentially see is a big call stack with the above frames repeating themselves. What is the problem with a big call stack? Stack space. If there are enough of these messages processed you will eventually run out of stack space and crash with a stack overflow exception:

(2eb0.1d88): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.

To get around this problem, you can relatively easily change the waiting/blocking behavior of the CLR by using the SynchronizationContext class. In a future blog post I will describe a reusable solution to does just this.

Until next time, happy debugging!