Debugging Shutdown Finalization Timeout

August 27, 2008

I’ve written about the perils of non-deterministic finalization before: It is a guaranteed way to get yourself in trouble. One of the more-or-less known facts is that in the process shutdown scenario, finalizers are called for reachable objects as well.  The total allotted time for this operation is approximately 40 seconds, and each individual finalizer gets approximately 2 seconds to execute. It is extremely difficult to detect this scenario and debug it because we are talking about the CLR shutdown sequence. Fortunately, there’s a registry key you can set at HKLM\SOFTWARE\Microsoft\.NETFramework to...
no comments

New Silverlight SOS.DLL Commands: !FindRoots and !ListNearObj

In this entry, we will examine the last two interesting new commands bundled in the Silverlight SOS.DLL – namely !FindRoots and !ListNearObj.  (Previously in this series: Basic introduction to Silverlight SOS; The !AnalyzeOOM command; The !HeapStat and !GCWhere commands.) The !FindRoots command is specifically oriented at understanding memory leaks and object promotion scenarios.  It is a wrapper on top of existing functionality, making analysis more convenient. The key scenario to using !FindRoots is as follows: You’re noticing that some objects are not being collected even though you...
no comments

New Silverlight SOS.DLL Commands: !HeapStat and !GCWhere

Another SOS.DLL command new in Silverlight is !HeapStat, featuring statistics on the sizes and available space in the various GC heaps and generations.  (Previously in this series: Basic steps with Silverlight SOS; The !AnalyzeOOM command.) Because Silverlight applications run within a browser, there’s typically going to be a single GC heap because the browser’s CLR host uses workstation GC.  However, generations and the large object heap (LOH) are still of interest. The following is the (edited) output of executing the !HeapStat command a couple of times in a Silverlight application that...
no comments

New Silverlight SOS.DLL Command: !AnalyzeOOM

In the conclusion of my previous post on the Silverlight SOS.DLL, I’ve mentioned that some new commands (not present in the desktop CLR version) have been added. The first command we’ll talk about is !AnalyzeOOM, which (as its name implies) analyzes an out of memory condition and explains what went wrong.  There are various reasons for out of memory exceptions, and this command can help you to pinpoint exactly what went wrong. I’ve written a simple Silverlight application that allocates 1MB byte arrays in a loop and keeps them referenced forever.  After a few seconds the application...
2 comments

Managed Synchronization Primitives and Thread Apartment States

The managed synchronization mechanisms, including Monitor, WaitHandle.WaitAny, ManualResetEvent, ReaderWriterLock, Thread.Join, GC.WaitForPendingFinalizers and the rest of the family are not just a thin platform adaptation layer on top of the Win32 API. The CLR needs to know exactly which threads are currently waiting for a synchronization mechanisms for a variety of reasons.  To mention two of them: In hosting scenarios, the CLR host might want to limit the ability of application threads to perform synchronization at all (to ensure reliability and control over threads). A waiting thread (in the WaitSleepJoin thread state)...
no comments

Garbage Collection Notifications in .NET 3.5 SP1

August 25, 2008

One (or three) of the first questions native developers ask when learning about the .NET garbage collector is this: How do I control the garbage collector?  How do I get a notification when a garbage collection occurs?  What do I do to limit the garbage collector’s impact on my application’s performance? I would be shooting myself in the foot by saying that these questions should not be addressed with the seriousness they deserve.  The garbage collector is one of the primary factors affecting the performance of managed applications.  It is difficult to control...
3 comments

Debugging Silverlight Applications: SOS.DLL

I’ve written about SOS.DLL before – it is the ultimate Swiss-army knife for debugging managed applications.  Memory leaks, unexpected crashes, high-CPU scenarios, hangs and deadlocks can all be pinpointed using SOS. Silverlight 2.0 offers a model for managed code execution inside the browser, and that managed code will require the same debugging capabilities needed for standard managed applications.  The Silverlight CLR (coreclr.dll) is a subset of the desktop CLR, but fortunately it ships with a version of SOS that can be used to debug Silverlight applications in the browser. This special SOS is available as part of...
no comments

More on Converting Native Exceptions to Managed Exceptions

August 24, 2008

Shortly after publishing my last post on converting native (C++ or Win32) exceptions to managed exceptions, I realized that some clarifications are in place. Trapping every Win32 exception and indiscriminately translating it to a managed exception is extremely dangerous.  There are various scenarios in which a native exception is thrown to be caught, processed and handled – interfering with this process through a vectored exception handler might result in disastrous consequences. For example, when a managed application attempts to access an object through a null reference, the JIT-ted code causes a Win32 access violation by referencing a...
one comment

Converting Win32 and C++ Exceptions to Managed Exceptions

August 20, 2008

In a layered application consisting of managed upper layers and unmanaged lower implementation layers, you might frequently encounter the need to call unmanaged code, handle any exceptional conditions and reflect them to the upper layers as managed exceptions. This can be done manually, but fortunately as of Windows XP there is an approach that does not require wrapping every unmanaged call in an exception handler.  This approach is vectored exception handling. A vectored exception handler is stackless – it can be attached to an application and get a chance to process any exception before stack-based exception handlers...
no comments

Two-Phase Initialization

August 19, 2008

Two-phase initialization is an architectural pattern for artificially breaking and managing coupling between strongly coupled components.  The motivation and implementation of this pattern are not always obvious, so I will give a couple of examples to demonstrate. Let’s take an operating system as an example.  Some of the components involved in the initialization of the operating system are the I/O manager, the memory manager, the object manager and many others.  At runtime, the strong coupling between the various components is obvious and beneficial – they tend to use each other, all the time. However, during system startup,...
no comments