Tech talk: CLR Memory Diagnostics

Today’s tech talk we discussed the recent release from Microsoft of ClrMD that lets you attach and debug processes using an exposed API. You used to be able to do this in WinDbg using the SOS plugin, but now they’ve wrapped SOS in a managed dll that you can use to inspect CLR process information. The nice thing about this is you can now automate debugging inspections. It’s now as easy as

int pid = Process.GetProcessesByName("TestApplication")[0].Id;

using (DataTarget dataTarget = DataTarget.AttachToProcess(pid, 5000))
    string dacLocation = dataTarget.ClrVersions[0].TryGetDacLocation();
    ClrRuntime runtime = dataTarget.CreateRuntime(dacLocation);

    ClrHeap heap = runtime.GetHeap();

    foreach (ulong obj in heap.EnumerateObjects())
         ClrType type = heap.GetObjectType(obj);
         ulong size = type.GetSize(obj);
         Console.WriteLine("{0,12:X} {1,8:n0} {2}", obj, size, type.Name);

ClrMD lets you take stack snapshots of running threads, iterate through all objects in the heap and get their values out, show all loaded modules and more. If you combine it with ScriptCSRead more

, ,

Debugging Serialization Exception: The constructor to deserialize an object was not found.

Today I was debugging an exception that was occuring when remoting a data object between two .NET processes. I kept getting

System.Runtime.Serialization.SerializationException: The constructor to deserialize an object of type 'com.TheSilentGroup.Fluorine.ASObject' was not found.

The issue I had was that there was a .NET object that looked like this

public class ItemDto{
  public object Item { get;set; }

Which was used as a covariant store for any item (because everything is an object). This was needed because the code I was working in leveraged reflection to pull out certain fields at runtime depending on whatever this object type really was.

But, at some point the ItemDto object was sent to an ActionScript frontend. Later, the same object came back to .NET and the property Item was now a ASObject type due to Fluorine‘s serialization process. Next, this object had to be serialized to another .NET process, and … Read more


Debugging piped operations in F#

This article was originally published at

A little on the pipe operator

In F# you can create piped operations using the |> operator. This takes the output of the previous statement and funnels it as the input to the next statement. Using the pipe operator, a statement like this:

x |> f |> g |> h

Means having functions nested like this:


So a piece of code like this:

let print item = Console.WriteLine(item.ToString)

let seqDebug =
                |> (fun i -> i + 1)
                |> List.filter (fun i -> i < 5)
                |> List.head
                |> print

Decompiles into this (formatting added):

internal static Unit seqDebugu00407;

public static void mainu0040()
            ListModule.Filter((FSharpFunc<int, bool>) new Program.seqDebugu004010(),
                ListModule.Map<int, int>((FSharpFunc<int, int>) new Program.seqDebugu00409u002D1(),
                        Operators.OperatorIntrinsics.RangeInt32(0, 1, 1000)))))));

    u0024Program.seqDebugu00407 = (Unit) null;

Which really boils down to:

seqDebug = Print(Head(Filter(Map(sequence))))

The F# syntax is nice because it … Read more