Junfeng Zhang's Windows Programming Notes : .NetFramework

Getting where the exception is thrown in Windows Error Report for managed application without a dump

junfeng — Mon, 27 Jul 2009 18:00:00 GMT

A while ago, an internal thread shows how to get where the exception is thrown in Windows Error Report for managed application without a dump. The thread is very insightful. Shared below:

Subject: RE: How to investigate Windows Error Report from managed app?

FYI

I actually found that there is way to find what method caused this error and where without the dump. See below:

Problem signature

Problem Event Name: CLR20r3

Problem Signature 01: consoleapplication35.exe

Problem Signature 02: 1.0.0.0

Problem Signature 03: 48ed4a20

Problem Signature 04: ConsoleApplication35

Problem Signature 05: 1.0.0.0

Problem Signature 06: 48ed4a20

Problem Signature 07: 1

Problem Signature 08: 2e

Problem Signature 09: System.InvalidOperationException

OS Version: 6.0.6001.2.1.0.272.7

Locale ID: 1033

The Problem Signature 07 is MethodDef token. And SOS provides !Token2EE command to find the token. The trick here is that it trimmed “06” from the top, so its original value should be 0600000 + the value you see from Problem Signature 07 which is 06000001 in this example.

Now use !Token2EE to figure out the method:

0:003> !Token2EE ConsoleApplication35 06000001

Module: 00112c5c (ConsoleApplication35.exe)

Token: 0x06000001

MethodDesc: 00112ff0

Name: ConsoleApplication35.Program.Main(System.String[])

JITTED Code Address: 001b0070

Now you use !dumpil to list all IL for the method and check the IL offset to find which line actually failed.

0:003> !dumpil 00112ff0

ilAddr = 00ee2050

IL_0000: nop

IL_0001: ldstr "notepad.exe"

IL_0006: ldnull

IL_0007: call System.Diagnostics.Process::Start

IL_000c: stloc.0

.try

{

IL_000d: nop

IL_000e: ldloc.0

IL_000f: callvirt System.Diagnostics.Process::WaitForExit

IL_0014: nop

IL_0015: nop

IL_0016: leave.s IL_0028

} // end .try

.finally

{

IL_0018: ldloc.0

IL_0019: ldnull

IL_001a: ceq

IL_001c: stloc.1

IL_001d: ldloc.1

IL_001e: brtrue.s IL_0027

IL_0020: ldloc.0

IL_0021: callvirt System.IDisposable::Dispose

IL_0026: nop

IL_0027: endfinally

} // end .finally

IL_0028: nop

IL_0029: newobj System.InvalidOperationException::.ctor

IL_002e: throw

That’s it.

Be careful about exception after resource allocation

junfeng — Mon, 02 Feb 2009 19:00:00 GMT

The following is a common code pattern

Resource resource = GetResource();

DoWork();

return resource;

If DoWork() throws exception, the resource will be leaked. We need to guard against this.

For example

bool success = false;

Resource resource = GetResource();

try

{

DoWork();

success = true;

return resource;

}

finally

{

if (!success)

{

DisposeResource(resource);

}

Exception Filter

junfeng — Mon, 08 Dec 2008 19:00:00 GMT

C# does not support exception filter. However, VB and IL support it. To add exception filter to C#, we can build a function in VB or IL, then call it in C#.

The example below is one way we may implement the function to support exception filter. It asks the caller to provide four delegates, and call them at the right places.

Imports Microsoft.VisualBasic

Namespace Utility

Public Delegate Sub TryDelegate()

Public Delegate Function FilterDelegate(ByVal exception As System.Exception) As Boolean

Public Delegate Sub CatchDelegate(ByVal exception As System.Exception)

Public Delegate Sub FinallyDelegate()

Public Class ExceptionFilter

Inherits System.Object

Public Shared Sub TryFilterCatch(ByVal tryDelegate As TryDelegate, ByVal filterDelegate As FilterDelegate, ByVal catchDelegate As CatchDelegate, ByVal finallyDelegate As FinallyDelegate)

Try

tryDelegate()

Catch ex As System.Exception When catchDelegate <> Nothing And filterDelegate(ex)

catchDelegate(ex)

Finally

If (finallyDelegate <> Nothing) Then

finallyDelegate()

End If

End Try

End Sub

End Class

End Namespace

In C# we can call Utility.TryFilterCatch as the following:

using System;

using Utility;

namespace ExceptionFilterUsage

{

class Program

{

static void Main(string[] args)

{

TryDelegate tryDelegate = delegate()

{

Console.WriteLine("In try.");

throw new ApplicationException();

};

FilterDelegate filterDelegate = delegate(Exception e)

{

Console.WriteLine("In exception filter.");

if (e is ApplicationException)

{

Console.WriteLine("ApplicationException is thrown, which should never happen.");

return false;

}

return true;

};

CatchDelegate catchDelegate = delegate(Exception e)

{

Console.WriteLine("In Catch: Exception: {0}", e);

};

FinallyDelegate finallyDelegate = delegate()

{

Console.WriteLine("In finally.");

};

ExceptionFilter.TryFilterCatch(tryDelegate, filterDelegate, catchDelegate, finallyDelegate);

}

ThreadPool.BindHandle

junfeng — Mon, 01 Dec 2008 19:00:00 GMT

I mentioned that we can use ThreadPool.BindHandle to implement asynchronous IO. Here are roughly the steps necessary to make it happen:

1. Create an overlapped file handle

SafeFileHandle handle = CreateFile(

filename,

Win32.GENERIC_READ_ACCESS,

Win32.FILE_SHARE_READ | Win32.FILE_SHARE_WRITE | Win32.FILE_SHARE_DELETE,

(IntPtr)null,

Win32.OPEN_EXISTING,

Win32.FILE_FLAG_OVERLAPPED,

new SafeFileHandle(IntPtr.Zero, false));

[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]

private static extern SafeFileHandle CreateFile(

string lpFileName,

uint dwDesiredAccess,

uint dwShareMode,

//SECURITY_ATTRIBUTES lpSecurityAttributes,

IntPtr lpSecurityAttributes,

uint dwCreationDisposition,

int dwFlagsAndAttributes,

SafeFileHandle hTemplateFile);

2. Bind the handle to thread pool.

if (!ThreadPool.BindHandle(handle))

{

Console.WriteLine("Fail to BindHandle to threadpool.");

return;

}

3. Prepare your asynchronous IO callback.

byte[] bytes = new byte[0x8000];

IOCompletionCallback iocomplete = delegate(uint errorCode, uint numBytes, NativeOverlapped* _overlapped)

{

unsafe

{

try

{

if (errorCode == Win32.ERROR_HANDLE_EOF)

Console.WriteLine("End of file in callback.");

if (errorCode != 0 && numBytes != 0)

{

Console.WriteLine("Error {0} when reading file.", errorCode);

}

Console.WriteLine("Read {0} bytes.", numBytes);

}

finally

{

Overlapped.Free(pOverlapped);

}

};

4. Create a NativeOverlapped* pointer.

Overlapped overlapped = new Overlapped();

NativeOverlapped* pOverlapped = overlapped.Pack(iocomplete, bytes);

pOverlapped->OffsetLow = (int)offset;

5. Call the asynchronous IO API and pass the NativeOverlapped * to it.

fixed (byte* p = bytes)

{

r = ReadFile(handle, p, bytes.Length, IntPtr.Zero, pOverlapped);

if (r == 0)

{

r = Marshal.GetLastWin32Error();

if (r == Win32.ERROR_HANDLE_EOF)

{

Console.WriteLine("Done.");

break;

}

if (r != Win32.ERROR_IO_PENDING)

{

Console.WriteLine("Failed to read file. LastError is {0}", Marshal.GetLastWin32Error());

Overlapped.Free(pOverlapped);

return;

}

[DllImport("KERNEL32.dll", SetLastError = true)]

unsafe internal static extern int ReadFile(

SafeFileHandle handle,

byte* bytes,

int numBytesToRead,

IntPtr numBytesRead_mustBeZero,

NativeOverlapped* overlapped);

Your IO callback will be invoked by CLR thread when the IO completed.

So when should you use ThreadPool.BindHandle? The answer is almost *Never*. .Net Framework's FileStream class internally uses ThreadPool.BindHandle to implement the async IO. You should always use FileStream if possible.

ThreadPool.UnsafeQueueNativeOverlapped

junfeng — Mon, 24 Nov 2008 19:00:00 GMT

CLR’s thread pool has two pools of threads. The first pool is used by ThreadPool.QueueUserWorkItem. The second pool is an IoCompletionPort thread pool used by ThreadPool.BindHandle and ThreadPool.UnsafeQueueNativeOverlapped.

ThreadPool.BindHandle is used by CLR to implement asynchronous IO. For example, FileStream uses it to implement BeginRead/BeginWrite. Developers can take advantage of it too. We will talk about that in a separate article.

ThreadPool.UnsafeQueueNativeOverlapped can be used to queue a non IO work item to the IoCompletionPort thread pool, just like ThreadPool.QueueUserWorkItem.

Why will you want to use ThreadPool.UnsafeQueueNativeOverlapped instead of ThreadPool.QueueUserWorkItem?

In our development, we discover an inefficiency of ThreadPool.QueueUserWorkItem. If we have some alternate high and low number of work items, some of the threads may do busy waiting, artificially increase the CPU usage of our application.

If you have the same pattern, and you have observed high CPU usage when it should not, you can try ThreadPool.UnsafeQueueNativeOverlapped.

The following is an example how to ThreadPool.UnsafeQueueNativeOverlapped.

using System;

using System.Runtime.InteropServices;

using System.Threading;

namespace UQNO

{

internal class AsyncHelper

{

WaitCallback callback;

object state;

internal AsyncHelper(WaitCallback callback, object state)

{

this.callback = callback;

this.state = state;

}

unsafe internal void Callback(uint errorCode, uint numBytes, NativeOverlapped* _overlapped)

{

try

{

this.callback(this.state);

}

finally

{

Overlapped.Free(_overlapped);

}

class Program

{

static void Main(string[] args)

{

ManualResetEvent wait = new ManualResetEvent(false);

WaitCallback callback = delegate(object state)

{

Console.WriteLine("callback is executed in thread id {0} name {1}", Thread.CurrentThread.ManagedThreadId, Thread.CurrentThread.Name);

ManualResetEvent _wait = (ManualResetEvent)state;

_wait.Set();

};

AsyncHelper ah = new AsyncHelper(callback, wait);

unsafe

{

Overlapped overlapped = new Overlapped();

NativeOverlapped* pOverlapped = overlapped.Pack(ah.Callback, null);

ThreadPool.UnsafeQueueNativeOverlapped(pOverlapped);

wait.WaitOne();

}

Conversion between System.String and char *

junfeng — Mon, 11 Aug 2008 18:00:00 GMT

We can convert a char * to System.String with System.String’s constructor

string str = new string((char*)p);

And for the reverse:

fixed(char *p = str){}

Why do we care about conversion between System.String and char *?

From this article, this is the fastest way to marshal strings between managed and native boundary.

Managed ThreadPool vs Win32 ThreadPool (pre-Vista)

junfeng — Mon, 21 Jul 2008 18:00:00 GMT

The following is a conversation between me and a CLR dev. The conversation is very informative so I quote it here.

From:
Sent:
To:
Subject: RE: ThreadPool.QueueUserWorkItem

There might be some confusion here around the meaning of the term "I/O Thread." In the Windows thread pool (the old one, not the new Vista thread pool), an "I/O thread" is one that processes APCs queued by other threads, or by I/O initiated from the I/O threads. The "non-I/O" threads get their work from a completion port, either as a result of QueueUserWorkItem, or I/O initiated on a handle bound to the threadpool with BinIoCompletionCallback. So they are both geared toward processing I/O completions, but they just use different mechanisms.

In the managed ThreadPool, we use the terms "worker thread" and "I/O thread." In our case, an I/O thread is one that waits on a completion port; i.e., it's exactly equivalent to Windows' non-I/O thread. How confusing! Our "worker threads" wait on a simple user-space work queue, and never enter an alertable state (unless user code does so), and so explicitly do not process APCs. Managed "worker threads" have no equivalent in the Windows thread pool, just as Windows "I/O threads" have no managed equivalent.

The managed QueueUserWorkItem queues work to the "worker threads" only. UnsafeQueueNativeOverlapped queues to the I/O threads, as do completions on handles that have been bound to the ThreadPool via BindHandle.

Why don't we support APCs as a completion mechanism? APCs are really not a good general-purpose completion mechanism for user code. Managing the reentrancy introduced by APCs is nearly impossible; any time you block on a lock, for example, some arbitrary I/O completion might take over your thread. And they don't scale well, except in certain very constrained scenarios, because there's no load-balancing of completions across threads. You can, of course, implement your own load balancing, but you'll never do better in user-space than the kernel does with completion ports. So we provide a rich async I/O infrastructure based on completion ports, and nothing else.

From:
Sent:
To:
Subject: RE: ThreadPool.QueueUserWorkItem

With ThreadPool.QueueUserWorkItem, the callback is not called on an I/O thread. You might be looking for ThreadPool.UnsafeQueueNativeOverlapped.

http://msdn.microsoft.com/en-us/library/system.threading.threadpool.unsafequeuenativeoverlapped.aspx

From: Junfeng Zhang
Sent:
To:
Subject: ThreadPool.QueueUserWorkItem

The native kernel32 QueueuserWorkItem has a flag to indicate to schedule the callback in I/O thread or not. The flag is missing in the managed ThreadPool.QueueUserWorkItem.

Why is so? Is it because the callback is always scheduled on a I/O thread?

Event Handles “leak”

junfeng — Mon, 28 Apr 2008 18:00:00 GMT

On our stress run, we saw our process’ handle count steadily increases until certain point, then it stabilizes. However the number of handles is high. Most of those handles are Event handles. We are concerned about it. So we went off and did some investigation.

Turns out the Event handles are coming from the use of Monitor.

When there is contention on the lock object, CLR internally creates an Event handle, presumably to facilitate the thread scheduling. The event handle is not cleaned up until the object is garbage collected.

It appears we were using Monitor in a lot of places, and we had lock contentions, which triggers CLR to allocate a lot of Event handles.

So if you have a lot of long lived objects, be careful about the usage of Monitor.

Consider Creating a new class for locking

junfeng — Mon, 14 Apr 2008 18:00:00 GMT

C# provides keyword lock for synchronized access.

A good practice is to create a private object for locking purpose. For example,

public class LockExample

{

private object syncObject = new object();

public void SynchronizedMethod()

{

lock (syncObject)

{

}

}
}

It may make sense to create a class just for locking purpose:

using System;

class LockClass : object { };

public class LockExample

{

private object syncObject = new LockClass();

public void SynchronizedMethod()

{

lock (syncObject)

{

}

The advantage of the second approach, is that you can easily tell how many lock objects you have used in your project using SOS command “!dumpheap -mt”.

A case study of a NullReferenceException

junfeng — Mon, 07 Apr 2008 18:00:00 GMT

We are seeing a NullReferenceException in our stress program. The investigation process may be helpful to some folks.

Thread 22 is showing a Watson dialog.

This is a register corruption.

0:022> kp

ChildEBP RetAddr

091bc9a0 76961220 ntdll!ZwWaitForSingleObject(void)+0x15

091bca10 76961188 kernel32!WaitForSingleObjectEx(void * hHandle = 0x00001034, unsigned long dwMilliseconds = 0x4e20, int bAlertable = 0)+0xbe

091bca24 7bb1fca4 kernel32!WaitForSingleObject(void * hHandle = 0x00001034, unsigned long dwMilliseconds = 0x4e20)+0x12

091bca54 7bb202b4 mscorwks!ClrWaitForSingleObject(void * handle = 0x00001034, unsigned long timeout = 0x4e20)+0x24

091bcf10 7bb23570 mscorwks!RunWatson(void * hWatsonSharedMemory = 0x000015f4, void * hEventAlive = 0x00001034, void * hEventDone = 0x00000d7c, void * hMutex = 0x00001378)+0x18f

091bd658 7bb23b43 mscorwks!DoFaultReportWorker(struct _EXCEPTION_POINTERS * pExceptionInfo = 0x091bd7ac, class TypeOfReportedError tore = class TypeOfReportedError, class Thread * pThread = 0x09b1d0b0, unsigned long dwThreadID = 0x300)+0xb52

091bd6a0 7bb317d3 mscorwks!DoFaultReport(struct _EXCEPTION_POINTERS * pExceptionInfo = 0x091bd7ac, class TypeOfReportedError tore = class TypeOfReportedError)+0x13d

091bd6c8 7bb361fb mscorwks!WatsonLastChance(class Thread * pThread = 0x09b1d0b0, struct _EXCEPTION_POINTERS * pExceptionInfo = 0x091bd7ac, class TypeOfReportedError tore = class TypeOfReportedError)+0x51

091bd728 7bb36387 mscorwks!InternalUnhandledExceptionFilter_Worker(struct _EXCEPTION_POINTERS * pExceptionInfo = 0x091bd7ac)+0x179

091bd734 7bb7578c mscorwks!ThreadBaseExceptionAppDomainFilter(struct _EXCEPTION_POINTERS * pExceptionInfo = 0x091bd7ac, void * pvParam = 0x091bf0f4)+0x1a

091bd76c 7baf167a mscorwks!ThreadBaseRedirectingFilter(struct _EXCEPTION_POINTERS * pExceptionInfo = 0x091bd7ac, void * _pCallState = 0x00000002)+0x7b

091bd774 7b9d2540 mscorwks!ManagedThreadBase_DispatchOuter(struct ManagedThreadCallState * pCallState = 0x091bf0f4)+0x38

091bd788 7ba6bf39 mscorwks!_EH4_CallFilterFunc(void)+0x12

091bd7b0 77e6b6d1 mscorwks!_except_handler4(struct _EXCEPTION_RECORD * ExceptionRecord = <Memory access error>, struct _EXCEPTION_REGISTRATION_RECORD * EstablisherFrame = <Memory access error>, struct _CONTEXT * ContextRecord = <Memory access error>, void * DispatcherContext = <Memory access error>)+0x8e

091bd7d4 77e6b6a3 ntdll!ExecuteHandler2(void)+0x26

091bd87c 77e4ee57 ntdll!ExecuteHandler(void)+0x24

091bd87c 06b2d7f3 ntdll!KiUserExceptionDispatcher(void)+0xf

091bea00 06b2d796 mscorlib!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(<HRESULT 0x80004001>)+0x43

091bea38 06b2d6b6 mscorlib!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Contains(<HRESULT 0x80004001>)+0x6

The first thing we should do is to find the right exception context. As pointed out in this article, we should look for _EXCEPTION_POINTERS, and the frame mscorwks!DoFaultReport gives us that (and along with many other frames). Let’s use it.

0:022> dc 0x091bd7ac

091bd7ac 091bd894 091bd8e4 77e6b6d1 091bd894 ...........w....

091bd7bc 091beed4 091bd8e4 091bd870 091bdc64 ........p...d...

091bd7cc 77e6b6e5 091beed4 091bd87c 77e6b6a3 ...w....|......w

091bd7dc 091bd894 091beed4 091bd8e4 091bd870 ............p...

091bd7ec 7ba6beb4 00000000 091bd894 091beed4 ...{............

091bd7fc 77e6b648 091bd894 091beed4 091bd8e4 H..w............

091bd80c 091bd870 7ba6beb4 00000002 091bd894 p......{........

091bd81c 091be6e8 7bb83bd0 035db834 00000004 .....;.{4.].....

The highlighted DWORD is the exception context. Let’s move to it.

0:022> .cxr 091bd8e4

eax=00000000 ebx=03339044 ecx=033310a8 edx=00000000 esi=00000001 edi=03312bc0

eip=06b2d7f3 esp=091be9f0 ebp=091bea00 iopl=0 nv up ei ng nz ac pe cy

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010297

mscorlib!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon)+0x43:

06b2d7f3 8b5610 mov edx,dword ptr [esi+10h] ds:002b:00000011=????????

So this is access invalid memory. This is very strange. LinkedList is pure managed code. I have never seen manage code accessing invalid memory.

Let’s look at the assembly code and see what happened.

0:022> !u 06b2d7f3

Normal JIT generated code

System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon)

Begin 06b2d7b0, size 83

06b2d7b0 55 push ebp

06b2d7b1 8bec mov ebp,esp

06b2d7b3 57 push edi

06b2d7b4 56 push esi

06b2d7b5 53 push ebx

06b2d7b6 50 push eax

06b2d7b7 8bf9 mov edi,ecx

06b2d7b9 8bda mov ebx,edx

06b2d7bb 8b7704 mov esi,dword ptr [edi+4]

06b2d7be 8b0f mov ecx,dword ptr [edi]

06b2d7c0 8b4120 mov eax,dword ptr [ecx+20h]

06b2d7c3 8b10 mov edx,dword ptr [eax]

06b2d7c5 83c208 add edx,8

06b2d7c8 8b02 mov eax,dword ptr [edx]

06b2d7ca 85c0 test eax,eax

06b2d7cc 7513 jne mscorlib!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon)+0x31 (06b2d7e1)

06b2d7ce 6a00 push 0

06b2d7d0 52 push edx

06b2d7d1 51 push ecx

06b2d7d2 bae900001b mov edx,1B0000E9h

06b2d7d7 b9f0047e02 mov ecx,27E04F0h (MD: System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon))

06b2d7dc e8e271fb74 call mscorwks!JIT_GenericHandle (7bae49c3)

06b2d7e1 8bc8 mov ecx,eax

06b2d7e3 e810a078f9 call mscorlib!System.Collections.Generic.EqualityComparer`1[[System.__Canon, mscorlib]].get_Default() (002b77f8)

06b2d7e8 8945f0 mov dword ptr [ebp-10h],eax

06b2d7eb 85f6 test esi,esi

06b2d7ed 743c je mscorlib!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon)+0x7b (06b2d82b)

06b2d7ef 85db test ebx,ebx

06b2d7f1 7422 je mscorlib!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon)+0x65 (06b2d815)

>>> 06b2d7f3 8b5610 mov edx,dword ptr [esi+10h]

06b2d7f6 53 push ebx

06b2d7f7 8b4df0 mov ecx,dword ptr [ebp-10h]

06b2d7fa 8b01 mov eax,dword ptr [ecx]

06b2d7fc ff5038 call dword ptr [eax+38h]

0:022> r

Last set context:

eax=00000000 ebx=03339044 ecx=033310a8 edx=00000000 esi=00000001 edi=03312bc0

eip=06b2d7f3 esp=091be9f0 ebp=091bea00 iopl=0 nv up ei ng nz ac pe cy

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010297

Microsoft_Live_Moe_Runtime!System.Collections.Generic.LinkedList`1[[System.__Canon, mscorlib]].Find(System.__Canon)+0x43:

06b2d7f3 8b5610 mov edx,dword ptr [esi+10h] ds:002b:00000011=????????

0:022> dc @edi+4

03312bc4 136deb74 00000000 00000008 00000000 t.m.............

03312bd4 00fe553c 03312be8 00000258 00000000 <U...+1.X.......

03312be4 00020000 00fe56b0 00000258 00000004 .....V..X.......

The highlighted code at 06b2d7f3 is where the exception happened. If we read the assembly code, register @esi is assigned to the value at address @edi+4 at offset 06b2d7bb, and not changed afterwards. Register @edi is assigned at offset 06b2d7b7, and not changed afterwards. This means @esi should be the same as the value at memory @edi+4.

However, @esi = 1, while the memory at @edi+4 is 136deb74. Apparently, one of them is wrong. Telling from the value, it looks like the register @esi is corrupted.

We still don’t know why the register is corrupted. But at least we are confident that this is not a bug in LinkedList.

App Config’s root element should be namespace-less

junfeng — Mon, 24 Mar 2008 18:00:00 GMT

The root element for Application config file is <configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration >
</configuration>

The application config file is shared with CLR and Windows SxS.

SxS dictates that the root element is <configuration>, and it should be without namespace. If the application config file does not follow the rule, SxS will refuse to start the process.

Calculating the size of each GC generation

junfeng — Mon, 25 Feb 2008 19:00:00 GMT

Sos.dll does not have a command to tell the size of each GC generation. However, you can calculate the size based on the output of !eeheap -gc.

For example,

0:000> !eeheap -gc

Number of GC Heaps: 1

generation 0 starts at 0x1da6c430

generation 1 starts at 0x1da5c240

generation 2 starts at 0x01a41000

ephemeral segment allocation context: none

segment begin allocated size

01a40000 01a41000 02a1cc4c 0x00fdbc4c(16628812)

0c7f0000 0c7f1000 0d7e9fc8 0x00ff8fc8(16748488)

12170000 12171000 13164488 0x00ff3488(16725128)

13170000 13171000 14117640 0x00fa6640(16410176)

10170000 10171000 1115b134 0x00fea134(16687412)

14170000 14171000 1516fdec 0x00ffedec(16772588)

1e030000 1e031000 1eff9970 0x00fc8970(16550256)

0e6e0000 0e6e1000 0f6dce50 0x00ffbe50(16760400)

15170000 15171000 160f7a60 0x00f86a60(16280160)

16170000 16171000 170f7bc0 0x00f86bc0(16280512)

17170000 17171000 180ffefc 0x00f8eefc(16314108)

18170000 18171000 191144dc 0x00fa34dc(16397532)

19170000 19171000 1a167e84 0x00ff6e84(16739972)

1a170000 1a171000 1b166a68 0x00ff5a68(16734824)

1b170000 1b171000 1c115a9c 0x00fa4a9c(16403100)

1d030000 1d031000 1db35130 0x00b04130(11551024)

Large object heap starts at 0x02a41000

segment begin allocated size

02a40000 02a41000 03a07fc8 0x00fc6fc8(16543688)

072c0000 072c1000 082b6608 0x00ff5608(16733704)

11170000 11171000 11325aa0 0x001b4aa0(1788576)

Total Size 0x11961cdc(295050460)

------------------------------

GC Heap Size 0x11961cdc(295050460)

Gen2 size = 0x1da5c240 - 1d031000 + 16628812 + 16748488 + 16725128 + 16410176 + 16687412 + 16772588 + 16550256 + 16760400 + 16280160 + 16280512 + 16314108 + 16397532 + 16739972 + 16734824 + 16403100.

Gen1 size = 0x1da6c430 - 0x1da5c240.

Gen0 size = 0x1db35130 - 0x1da6c430

Figuring out object allocation graph from a managed memory dump

junfeng — Thu, 21 Feb 2008 19:00:00 GMT

when debugging a managed memory dump, we can use Sos.dll to inspect managed objects inside the dump.

for example, we can do !dumpheap to list the managed objects in GC Heap, we can also use !gcroot to figure out the reference path to a particular object.

However, if we want to understand the whole picture, !gcroot isn't going to cut it.

Then we can do !traverseheap. It writes the GC information to a format understood by CLR Profiler. We can then use CLR Profiler to inspect the object allocation graph.

http://msdn2.microsoft.com/en-us/library/bb190764(VS.80).aspx

TraverseHeap [-xml] <filename>

Writes heap information to the specified file in a format understood by the CLR Profiler. The -xml option causes the TraverseHeap command to format the file as XML.

You can download the CLR Profiler from: http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en

Reverse P/Invoke and exception

junfeng — Mon, 28 Jan 2008 19:00:47 GMT

P/Invoke is managed code executing a native function pointer. And Reverse P/Invoke is native code executing a managed delegate as a function pointer, mostly as a callback.

When the native code executes the managed delegate function pointer, the call really calls into a CLR thunk. The thunk will do an AppDomain transition to the correct AppDomain, then invoke the delegate. If the managed delegate throws an unhandled exception in the callback, the exception will be raised as cross context exception at the base of the AppDomain transition, and will likely cause a Dr.Watson error report.

If we don't want the managed exception to trigger Watson report, there are two things we could do.

1) have a top level try/catch block in the managed delegate and catch all exceptions. Yes we need some mechanism to convey the error information to the native code. We can either have the managed delegate return an HRESULT, or have it as one of the out parameter.

2) use ICLRRuntimeHost::ExecuteInAppDomain. CLR will catch any unhandled exception and convert it to an HRESULT to return to the caller.

Assembly Loading and Authorization

junfeng — Mon, 12 Nov 2007 19:00:00 GMT

CLR does not do anything special regarding authorization during assembly loading. It will try to access the file under the current user. However, if an assembly is already loaded, next time when the assembly is requested, CLR will return the assembly from the cache without hitting the file.

When the application impersonates a user, things get a little bit interesting. Sometimes the impersonated user does not have access to the assembly. Sometimes the impersonated user has read access to the assembly, but the appdomain has shadow copy enabled, and the impersonated user does not have write access to the shadow copy location. All those cases will result in access denied when the application tries to load the assembly.

In most cases, this access deny is perfectly acceptable. However, in some cases, you may want the user to be able to use the assembly. For example, you developed a web application. You would like to run the web application under the user accessing the web application, but the user does not necessarily have the right to write to "Temporary ASP.NET files" location where ASP.NET stores the shadow copied assembly.

You can workaround this problem by pre-loading the assemblies using a high privileged user. Since CLR does not touch the file after the assembly is loaded, you can sidestep the access deny problem.

(This technique does not work for Assembly.LoadFrom/LoadFile, for obvious reason.)

However, there is apparent security implications, and you have to evaluate it carefully.