Rick Byers : ICorDebug

Getting good dumps when an exception is thrown

rmbyers — Tue, 23 Dec 2008 09:03:00 GMT

Often, when an unexpected exception occurs in production code, applications want to generate (and potentially report) some sort of diagnostics information. Sometimes people just want to write to a log file (and perhaps pop some error dialog) for support purposes, but more sophisticated applications will want to have a mechanism to save a minidump of the crash (and perhaps report it back to the author of the software) so their developers can debug the problem. Windows Error Reporting is usually the best way to do this (the CLR v2 and above integrates with WER for all managed apps), but people also like to build their own custom solutions. By the way, if you want to build your own error-reporting mechanism that captures dump files, I suggest you use a helper process to suspend all your threads and call MiniDumpWriteDump, rather than calling it directly in-process (see this discussion for example).

As a very simple example, you may want to use the FailFast API to say "exceptions should never escape here, if it does present an error to the user and let them report the problem back through WER":

try
{
    MyCode();
}
catch (Exception ex)
{
    // We don't expect any exceptions - generate an error-report if we see one
    System.Environment.FailFast("Unexpected exception: " + ex.Message);
}

Unfortunately, this won’t give you a very useful dump in your error-report. The problem is that by the time the catch block has been started, the stack frames showing how the exception occurred are no longer available (see below for details). Managed exceptions are built on Windows Structured Exception Handling, and so have the same two-pass model. ‘catch’ blocks are executed on the second pass, but really what we want here is to generate our error-report on the first-pass (before EBP gets reset). You are probably used to seeing this when debugging your code. If you really want to see what caused an exception, you have to tell Visual Studio to stop on first-chance exceptions – by the time you stop in the catch block, the code that threw the exception is no longer visible on the callstack:

Luckily the CLR provides a way to do this called managed exception filters. Unfortunately C# doesn’t expose a way to use them. The simplest way to use a filter from C# code is to write a simple helper function in VB.Net. The ‘When’ portion of a ‘Catch’ clause in VB.Net is an exception filter. Here’s a simple helper I wrote for this that I can easily call from C#:

Public Class ExceptionUtils
    Public Shared Sub Filter(ByVal body As Action, ByVal filter As Func(Of Exception, Boolean), ByVal handler As Action(Of Exception))
        Try
            body()
        Catch ex As Exception When filter(ex)
            handler(ex)
        End Try
    End Sub
End Class

Now I can re-write my code that triggers error-reporting on exceptions as follows (referencing the VB assembly with the above code):

ExceptionUtils.Filter(() =>
{
    // This is the body of the 'try'
    MyCode();
}, (ex) =>
{
    // This is the body of the filter
    System.Environment.FailFast("Unexpected exception: " + ex.Message);
    return false; // don't catch - this code isn't reached
}, null); // no catch block needed

Now, running under the debugger I can see the original call-stack, and even inspect locals/args on it (note the ‘Throw’ frame in the callstack, and the visible arg value for a – I can also click on this frame and poke around as normal):

So that’s basically it. Now debugging at the point of the FailFast (whether live, or with a dump file) will let you see all the data on the stack leading up to the cause of the exception. Note that if exceptions are thrown and caught within the body they don’t trigger the filter, the filter is just like a catch block in that it cares about exceptions that “reach” it – which is usually what you want (eg. it’s not normally any of your concern if the implementation of some external API you call happens to throw and catch an exception – as long as it doesn’t propagate back to your code).

Additional Details

It might be a bit of a pain to have to deploy this extra assembly with your application, but there are other options for using an exception filter in your C# app:

Statically link the C# and VB code together into a single (single-file) assembly (eg. using ILMerge, Link.EXE, or a ILDasm/ILAsm round-trip)
Use a tool to re-write your assembly after it’s built to inject the filter. Gregg on the VS debugger team posted such a tool awhile back.
Use Reflection.Emit to dynamically generate the IL code for the filter at run-time.

Also, one note about using FailFast with managed error-reporting. Error-reports are grouped by their ‘bucket parameters’. The buckets generated for System.Environment.FailFast(string) are always the same for any given call-site (basically just the address of the call, and a the string ‘FatalError’ for the exception type. Ideally what you’d like to do here is use the buckets for the original exception (so that two different exceptions that trigger the same call to FailFast will show up as two different problems). We’ve added a FailFast overload that takes an Exception object in .NET 4.0 that does this.

All I’ve talked about so far are simple single exceptions. Exceptions can also be caught and re-thrown ('”throw;” in C#) or wrapped in an outer exception which is thrown (“nested exceptions”). Unfortunately if that happens within the body you pass to ExceptionUtils.Filter, by the time the filter is invoked, the first exception has already been thrown and caught and so the stack you see is at the point of rethrow. There’s no good way that I’m aware of to get the stack from the original throw point in this case (although it’s something I’d like to get added to the CLR in a future version). This is particularly troublesome when using .NET APIs that catch-and-rethrow like Reflection (which wraps all exceptions in a TargetInvocationException). The best thing I can suggest is to put filters inside any such point, so you filter sees the exception before it’s caught.

If you want to be really hard-core about exceptions, you could use some sort of exception monitoring solution that notices as soon as an exception is thrown. For example, you could generate a dump from a vectored exception handler, but you won’t have access to the managed System.Exception object here. Better yet, you could write a tool that uses the debugging APIs to watch for first-chance exceptions and log details about them (perhaps including dump files) such as Mike Stall’s MDbg exception harness.

Above I said that in a catch block the frames leading up to the throw are no longer available on the stack. Technically, they’re still on the stack (the stack isn’t really “unwound” until you leave the catch block), but the frame pointer has been reset to point to the frame of the catch block (so that locals are available, etc.). This is true for native code as well, but powerful low-level debuggers like WinDbg allow you to switch the current context to that where an exception was thrown (.cxr command in windbg) if you have the CONTEXT pointer (which might even be saved into the dump for you – which you can access with .ecxr). An additional complication with managed code is that once the frame pointer has been reset, we no longer report any “roots”on the stack to the GC, so if a collection occurs there may actually be garbage pointers on (or available from) that masked portion of the stack. So it’s not a simple feature to expose some way to see the callstack starting from the throw site (unless we disabled inspection all locals and arguments, or allowed it to fail unpredictably). We’ve toyed with ideas for relaxing this in the CLR, but there won’t be any improvements here in CLR v4.

At the PDC this year I learned that this general class of problems (error reporting / logging in the face of exceptions) is something that many customers are very interested in. I don’t think we’ve got a ton of great documentation on this today. Going forward, you should expect to see more documentation, blog entries and new features from the CLR team in this area. Feel free to let me know if there’s anything in particular you’d like to know more about.

CLR 4.0 advancements in diagnostics

rmbyers — Fri, 31 Oct 2008 00:30:00 GMT

We announced at PDC today that we're making some significant advances in diagnostics tool support for CLR v4! In particular, we've been investing heavily in improving our support for production diagnostics scenarios over the past couple years. I'm excited that we're finally able to start talking about it!

Here's a quick list of some of the things we're doing - stay tuned here, Dave's blog and Mike's blog for more details. Also feel free to ask questions about our strategy and specific plans for new features on our forum (of course we still have a few things we're not ready to talk about yet). Of course, all of the features below are only available when targetting a process that is running inside version 4 of the CLR.

Managed dump debugging
Finally you'll be able to open crash dump files in Visual Studio and see managed state (stacks, locals, etc.) without using SOS. The key scenario we want to enable here is taking a dump of an app/server in production (perhaps in an automated way like Windows Error Reporting) and opening that dump in Visual Studio on another machine at some point in the future. We have a big piece of this working in the VS 2010 CTP, but we still have some work to do before beta (eg. the CTP supports dumps with full heap memory). The experience in VS is very much like being stopped at a breakpoint in a live process, except you can't say "go". Of course production code tends to have JIT-optimizations enabled, so the normal caveats about debugging optimized code apply here too (eg. may not see all locals). Also, you can't evaluate arbitrary expressions since there is no target process to call functions in (but we have some ideas for how we might compensate for this). But despite the caveats, this is still a huge feature that should really help improve production diagnostics scenarios. This work is actually the main visible piece of a much larger "out-of-process debugging" re-architecture we've been working on for years. This re-arch deserves a post of it's own so stay tuned.
Profiler attach (and detach) for memory diagnostics and sampling
One of the most common feature requests we hear from profiling tools is to be able to attach to a target process (today you have to set some environment variables at process start which cause your profiler to be loaded). Before you get too excited - this doesn't have everything you want. In particular, the CLR still doesn't have the ability to change the code of a method once it's been JIT-compiled (EnC is a very special case - not really applicable here). This means that IL instrumentation isn't available on attach, as well as a few other features (like object allocated callbacks). But basic memory diagnostics scenarios where the profiler inspects the heap, and simple sampling-based CPU profiling will now work on attach. We anticipate this will be useful in production scenarios - you can walk up to a server behaving badly and attach a profiler, collect some data, and detach - leaving the process in basically the same state it was before you attached.
[Update: See Dave's blog entry here for additional details on profiling API improvements]
Registry-free profiler activation
One major impediment to the sort of production scenario I described above is that today you have to register your profiler in the registry. In many production scenarios, making some change to the machine-wide system registry is very unappealing (will the dev remember to undo the change when he's done with the server, etc?). So to really enable production scenarios, we've also supplied a mechanism for running a process under a managed profiler (or attaching) without having to make any changes to the registry.
x64 mixed-mode debugging
This isn't really a production diagnostics scenario (although you can do x64 mixed-mode dump debugging), but is one of the main debugging feature requests we've gotten. With this feature, "mixed-mode" (native+managed) debugging will work for x64 processes in basically the same way it works for x86 today.
lock inspection
We're adding some simple APIs to ICorDebug which allow you to explore managed locks (Monitors). For example, if a thread is blocked waiting for a lock, you can find what other thread is currently holding the lock (and if there is a time-out).
Corrupted-state exceptions
This feature doesn't come from our team (it's part of the core exception-handling sub-system in the CLR), but in my opinion it's a huge improvement for diagnostics scenarios. Basically it means that "bad" exceptions (like access violations) that propagate up the stack into manage code no longer (by default) get converted into normal .NET exceptions (System.AccessViolation) which you can accidentally catch in a "catch(Exception)" clause. Basically, haivng a catch(Exception) which swallows AVs coming from native code is a bad thing because you're unlikely to be able to reason about the consistency of your process after the AV. The default behavior for such "corrupted-state exceptions" is now to fail-fast and send an error-report (just like in normal C++ programming). Of course, you can override this if you REALLY need to catch such an exception.

That's the overview of the main CLR v4 features that affect diagnostics. Of course there are also lots of other great things coming in CLR v4 and the rest of .NET Fx 4.0.

ICorDebug re-architecture in CLR 4.0

rmbyers — Mon, 27 Oct 2008 22:08:00 GMT

In my previous post I mentioned that CLR 4.0 will support managed dump debugging through ICorDebug, and that to do this we had to re-architect the debugging support in the CLR. I want to give you a little more detail about what we've been doing here. I'm sure I (and others) will be discussing more details in the time leading up to CLR 4.0 RTM, so stay tuned and also feel free to ask questions on this in our forum.

History and background
First, if you haven't already, read Mike's blog entry describing the difference between "hard-mode" and "soft-mode" debugging, and his related entry describing the implication of relying on a helper thread. Mike has clearly been thinking about this for a long time, and the successes we announced at PDC are due in large part to Mike's dedication, vision, and hard-work on this project for the past several years. In fact, after reading this post, if you go back and read other ICorDebug-related entries on Mike’s blog you’ll find a lot of great details on the thinking that lead to the design points I discuss below. Drew Bliss (while he was on the WinDbg team) was also instrumental to the early vision, design and implementation of our re-architecture.

As you know from Mike's blog, there are clearly a number of advantages to being able to debug from out-of-process (not the least of which is support for dump debugging). The big challenge is how to implement this in a maintainable way for a complex system with lots of fancy data structures and algorithms for accessing them. We've actually been experimenting with prototypes for doing this for many years (since nearly the start of the CLR), and this is exactly what SOS relies on. But it's really only been in the past few years that we've developed the confidence to move ALL managed debugging towards an out-of-process model. A power-user tool like SOS has somewhat different requirements from a production-grade API used by millions of developers every day in their Visual Studio debugging sessions.

The way we attempt to address the maintenance issue is to build both the normal in-process CLR code (mscorwks.dll) and the out-of-process code (mscordacwks.dll) from the same code base. We use some fancy C++ templates to instrument all pointer dereferences so that we can read memory from the target process instead of the process in which the code is executing ("host process"). We call this, and it's related infrastructure, our "DAC" (data access component) technology. There are still a lot of challenges associated with DAC (eg. trying to help CLR developers reason about their code when there are two separate address spaces involved), but we've taken it far enough that we're willing to trust the approach. If people are interested, I'd be happy to go into more detail on this in the future, but let's move on now to what we're actually delivering in CLR v4.

Design points for ICorDebug v4.0
Here's a list of principles we followed in the design for debugging in CLR v4.0. There’s a lot of overlap here since these design points are all part of a single coherent vision. Just skimming this list should give you a pretty good idea of what our new architecture is all about. I’ll save going into the concrete details of the new API here (although you can grab the new cordebug.idl from the CTP VPC image and explore it yourself if you're really curious).

Debugging a 4.0 managed app requires a 4.0-aware debugger (i.e. we are making breaking changes)
It has always been our policy that a debugger needs to be designed to understand the major features of the run-time, and so with a major new release of the runtime (like 4.0) we will require updates to the debugger. This means that VS 2008 will not be able to debug code running in the V4 CLR (exaclty like VS 2003 couldn't debug code running in CLR v2) - but see below.
Migrating a 2.0 debugger to support 4.0 should be very easy
Although we want to hold a hard line on our compat policy above, we are working very hard to make it easy for debuggers to update their code to support CLR v4. In almost all cases, we're not removing / disabling or drastically changing the semantics of any existing APIs. We are adding a bunch of new APIs and re-implementing the existing APIs on top of them, thus giving you the choice of which to use (the new APIs tend to have a lower level of abstraction). In fact, you could install VS 2008 on the .NET 4.0 CTP image and debug code running in the 4.0 CLR. In adition to wanting to make it easy for debugger writers to migrate, we also didn't want to force everyone inside Microsoft using early CLR v4 builds to also use VS 2010 as their debugger until it reaches beta quality. By the time we ship the beta, we'll explicitly break this to ensure we're not setting any unrealistic expectations.
Re-architecture is incremental instead of a complete rewrite
We (mainly, to his credit, Mike) decided early on that we should transition to this new architecture incrementally while keeping our system working throughout. This was done partly for pragmatic reasons, for example that we wanted to always have a working Visual Studio without having to wait for them to update to our new architecture in lock-step with us. This also enabled us to react to changes in the business plan. For example, when we decided to ship Silverlight 2 based on the latest CLR code base (i.e. the V4 branch) rather than based on the CLR v2 codebase, we were pretty-much prepared to ship the current state of our re-architecture even though we weren't yet "done" (we did have to spend a month or so adding Mac support to our new architecture - but that was a relatively isolated new feature, as opposed to a race to productize an unfinished codebase).
Maintain a single, self-consistent debugging API based on ICorDebug
Despite the huge fundamental changes we needed to make, we decided we needed to maintain consistency with the existing ICorDebug APis as much as possible. Again, this helps ensure that existing managed debuggers can take advantage of our new functionality as easily as possible. In fact, the VS debugger team spent only a few weeks adding the initial dump debugging support to VS 2010 because we made all the inspection operations behave exactly the same as for live debugging (we even had a hacked-up demo of dump-debugging working with VS 2008 without ANY VS changes at all!).
All access to the target is abstracted through a callback interface
In V2, ICorDebug used a number of different Win32 APIs to interact with the target process (eg. using ReadProcessMemory, GetThreadContext, shared-memory blocks, and named events). In V4, the core of ICorDebug uses a simple abstraction we call the "data target" (ICorDebugDataTarget) that a debugger implements. This basically just has methods like 'ReadVirtual' (read some memory) and 'GetThreadContext' (get CPU state).
ICorDebug can operate in two difference modes - "pure out-of-process v4" and "v2 compatibility"
Again, this is related to everything we've been discussing above. In v2 compat mode, you create an ICorDebug instance in a similar way to V2, and use that to, for example, attach to a process given a PID to get an ICorDebugProcess that can do everything the one in V2 could do. In this case, we implement the ICDDataTarget object ourselves. In pure v4 mode, you use an alternate "open virtual process" creation API that basically just takes an ICDDataTarget and returns an ICorDebugProcess whose connection to the target is completely abstracted. Today, a pure v4 ICDProcess only has the ability to do inspection operations (i.e. mainly just dump debugging), but we'll be enabling more out-of-process functionality (like stepping) in future releases.
In v4-mode, ICorDebug acts just as a utility library for existing native debuggers
In V2 and before, ICorDebug really behaves as if it owns the target process. This has a lot of negative implications, most significantly that it makes mixed-mode debugging extremely difficult and brittle. It also means that when debuggers want to add features, they often need to come to us (this is especially problematic for us given that the Visual Studio debugger team has a lot more people than the CLR debugger team <grin>). Really we want to enable debuggers to implement their own policy and control of the target process rather than imposing a lot of policy ourselves. This means we're lowering the level of abstraction of ICorDebug in some places. SOS, as an extension that runs on top of a native debugger like WinDbg, clearly already follows this principle. An example benefit is that native debuggers like Visual Studio and WinDbg already have some policy and mechanism for skipping over breakpoints, and now in v4-mode we no longer have to have a completely different policy and mechanism for managed breakpoints. This principle leads directly to the following design decision.
Under the hood we're built on the native debugging pipeline
In v2-compat mode, ICD continues to own the pipeline to the target process (since that was the V2 model), but that pipeline is no longer a collection of shared IPC objects with the target process, but is instead the same pipeline a native debugger uses. Specifically, we attach to a process by calling kernel32!DebugActiveProcess, and get our managed events (things that result in calls to ICorDebugManagedCallback) using kernel32!WaitForDebugEvent. This also means that kernel32!IsDebuggerPresent now returns true when doing managed-only debugging. This also has the nice side-effect of avoiding the problem with doing managed-only debugging when a kernel debugger is enabled (the OS assumes any breakpoint instructions that occur when a debugger isn't attached should cause a break in the kernel debugger).

Ok, I think those are the most important design points. Sometime later I'll start going into more of the concrete details. Post a comment if you have any specific things you'd like to hear about.

Func-eval can fail while stopped in a non-optimized managed method that pushes more than 256 argument bytes

rmbyers — Sun, 17 Aug 2008 02:55:00 GMT

In this blog entry, Mike describes that func-eval will fail when not a GC-safe point. In VS this results in the error "Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized". Typically non-optimized (debuggable) managed code is compiled as "fully-interruptible" which means every point is a GC-safe point. However, occasionally I hear complaints that VS is giving the error even when in non-optimized code.

In CLR 2.0, the x86 JIT has a limitiation where it will fall back to partially-interruptible code if more than 256 bytes of arguments are pushed onto the stack (which is normally very rare). [Update: corrected claim that the limitation was introduced in 2.0, .NET 1.1 actually had an even smaller limit of 128 bytes]. For example, the code below passes two 128 byte structures by-value to the function 'BigFunc', and so is compiled as partially-interruptible which means FuncEval isn't necessarily possible at all points in the method.

In the above case, we can verify that the method Main is not fully-interruptible by using the GCInfo command in SOS:

.load sos
extension C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll loaded

!GCInfo 003A00A4
entry point 003a0070
Normal JIT generated code
GC info 11e8a09800121a98
Method info block:
    method      size   = 0167
    prolog      size   = 32
    epilog      size   = 8
    epilog     count   = 1
    epilog      end    = yes
    callee-saved regs = EDI ESI EBX EBP
    ebp frame          = yes
    fully interruptible= no
    double align       = no
    arguments size     = 0 DWORDs
    stack frame size   = 44 DWORDs
    untracked count    = 1
    var ptr tab count = 1
    security check obj = yes
    exception handlers = yes
    edit & continue    = yes
    epilog        at   015F
    argTabOffset = 5

First we load sos in the immediate window, then get an address in the method of interest (eg. by looking at the value of the EIP register while we're stopped there) and pass it to the !GCInfo command. The "fully intteruptible=no" line is unusual for debuggable code (one way you can tell it's indeed debuggable is the "edit & continue = yes" which isn't normally the case in optimized code).

The other, more common, case where this happens is when calling a method with at least 64 arguments (each of 4 bytes). Having a method that takes 64 arguments seems poor style to me (hard to read), but I've seen such code from code-generation tools. Either way, passing 256 bytes by-value on the stack is generally a bad idea from a performance perspective anyway (it's a fair amount of copying of data). It's usually better to group the data into a class and pass that, and/or pass large value-types by reference (eg. with the 'ref' keyword in C#).

We're looking into relaxing this restriction in a future version of the CLR, but in the meantime if you run into problems with this, I suggest you refactor your code to avoid having methods that take 256 bytes or more in arguments. Perhaps somebody should write an FxCop rule for this.

Invoking a virtual method non-virtually

rmbyers — Sun, 17 Aug 2008 02:11:00 GMT

Method calls using the C# ‘base’ keyword get compiled to an IL ‘call’ instruction, rather than the ‘callvirt’ that is normally used. This is the one case in C# where a virtual method can be invoked without virtual dispatch. The CLR allows it to be used generally for non-virtual calls, but it’s unverifiable in other cases (see section 3.19 of the CLI specification partition III for the full definition).

One place this causes some pain is with func-eval. Func-Eval always does a virtual dispatch on virtual methods, which is why the ‘base’ keyword doesn’t work properly in the watch/immediate window in VS 2008. Mike Stall has a blog entry on this topic here: http://blogs.msdn.com/jmstall/archive/2006/06/29/funceval-does-virtual-dispatch.aspx

What Mike doesn’t mention is there is actually a work-around for this. First we need some mechanism to invoke a virtual method non-virtually, and the only one I could find was using Reflection.Emit / lightweight-codegen to emit a ‘call’ instruction. For example, the following method can be used to invoke any virtual method non-virtually:

/// <summary>
/// Call a virtual method non-virtually - like Reflection's MethodInfo.Invoke, 
/// but doesn't do virtual dispatch.
/// </summary>
/// <param name="method">The method to invoke</param>
/// <param name="args">The arguments to pass (including 'this')</param>
/// <returns>The return value from the call</returns>
static object InvokeNonVirtual(MethodInfo method, object[] args)
{
    // Reflection doesn't seem to have a way directly (eg. custom binders are 
    // only used for ambiguities).  Using a delegate also always seems to do 
    // virtual dispatch.

    // Use LCG to generate a temporary method that uses a 'call' instruction to
    // invoke the supplied method non-virtually.
    // Doing a non-virtual call on a virtual method outside the class that 
    // defines it will normally generate a VerificationException (PEVerify 
    // says "The 'this' parameter to the call must be the callng method's 
    // 'this' parameter.").  By associating the method with a type ("Program") 
    // in a full-trust assembly, we tell the JIT to skip this verification step.
    // Alternately we might want to associate it with method.DeclaringType - the
    // verification might then pass even if it's not skipped (eg. partial trust).
    var paramTypes = new List<Type>();
    if (!method.IsStatic)
        paramTypes.Add(method.DeclaringType);
    paramTypes.AddRange(method.GetParameters().Select(p => p.ParameterType));
    DynamicMethod dm = new DynamicMethod(
        "NonVirtualInvoker",    // name
        method.ReturnType,      // same return type as method we're calling 
        paramTypes.ToArray(),   // same parameter types as method we're calling
        typeof(Program));       // associates with this full-trust code
    ILGenerator il = dm.GetILGenerator();
    for (int i = 0; i < paramTypes.Count; i++)
        il.Emit(OpCodes.Ldarg, i);             // load all args
    il.EmitCall(OpCodes.Call, method, null);   // call the method non-virtually
    il.Emit(OpCodes.Ret);                      // return what the call returned

    // Call the emitted method, which in turn will call the method requested
    return dm.Invoke(null, args);
}

With a method like the above available, we can use statements like the following (in the program or in the immediate window) to invoke a method non-virtually (i.e. to simulate the ‘base’ keyword):

// Foo is some class that overrides ToString
Foo f = new Foo();
MethodInfo m = typeof(object).GetMethod("ToString", 
    BindingFlags.Instance | BindingFlags.Public);

// s1 will be the same as f.ToString - whatever Foo.ToString returns
string s1 = (string)m.Invoke(f, 
    BindingFlags.Instance | BindingFlags.InvokeMethod, null, null, null);

// s2 will be the return value from Object.ToString
string s2 = (string)InvokeNonVirtual(m, new object[] {f});

We can also avoid having to get the ‘InvokeNonVirtual’ method into the target program at all by entering code like the following into the immediate window (depending on what method you want to invoke, eg. this invokes 'ToString' non-virtually on object 'o').:

MethodInfo m1 = typeof(object).GetMethod("ToString", 
    BindingFlags.Instance | BindingFlags.Public);
DynamicMethod dm = new DynamicMethod("ToStringInvoker", 
    typeof(string), new Type[] { typeof(object) }, typeof(Program));
ILGenerator il = dm.GetILGenerator();
il.Emit(OpCodes.Ldarg_0);
il.EmitCall(OpCodes.Call, m1, null);
il.Emit(OpCodes.Ret);
string s3 = (string)dm.Invoke(null, new object[] { o });

Yes, I realize typing this into the immediate window whenever you want to say ‘base’ is kind of a pain (perhaps completely impractical). But the interesting thing here is that it means a debugger could build support for the ‘base’ keyword without any additional work from ICorDebug or the CLR! Of course, I still agree with Mike that it’s a reasonable feature-request to have func-eval support an option for non-virtual dispatch. I just don’t see it making its way to the top of our wish-list anytime soon (unless we get strong customer feedback of course).

This also raises an interesting question about the design of func-eval. Should we have just supported calling a few key reflection APIs and made all evals go through reflection? This certainly would have been simpler and more reliable for the CLR – otherwise we have to duplicate a lot of the logic about how to marshal values and call methods that Reflection already needs to have. Then again, there’s always going to be the challenge of marshalling between ICorDebugValue instances and objects in the target, and that’s a pretty big chunk of what’s required to make func-eval work.