Rick Byers

Leaving

Rick Byers - exMSFT — Fri, 19 Nov 2010 19:40:00 GMT

After 6 great years at Microsoft, my wife and I have decided it's time to spend some time living near our family in Ontario, Canada (we've got two young kids, and they're going to love seeing their grandparents and cousins more than twice a year). I've been having a great time on the CLR (working on all sorts of cool secret stuff I haven't been able to blog about), so it was a very tough decision. But anyway, I will no longer be able to post to this blog or reply to comments. If you'd like to contact me, you can e-mail me at rick-msblog at rbyers daughtnet.

Thanks!
Rick

Sample Reflection.Emit code for using exception filters from C#

Rick Byers - exMSFT — Sat, 30 Jan 2010 10:00:12 GMT

In this post, I mentioned that one way to use exception filters from C# code is to generate them with Reflection.Emit. Personally I usually prefer static compilation (even post-build assembly merging or rewriting) – there’s really nothing here that necessitates dynamic code generation, but I can understand the desire to avoid complicating the build process. I recently wrote up some code to do this and figured I’d share it here in case others find it useful.

Code Snippet
using System;
 using System.Reflection.Emit;
 using System.Reflection;
 using System.Diagnostics;
 using System.Runtime.CompilerServices;
 using System.Linq;
 
 namespace FilterTest
 {
     /// 
     /// This class provides some utilities for working with exceptions and exception filters.
     /// 
     /// 
     /// Code inside of exception filters runs before the stack has been logically unwound, and so the throw point 
     /// is still visible in tools like debuggers, and backout code from finally blocks has not yet been run.
     /// See https://blogs.msdn.com/rmbyers/archive/2008/12/22/getting-good-dumps-when-an-exception-is-thrown.aspx.
     /// Filters can also be used to provide more fine-grained control over which exceptions are caught.  
     /// 
     /// Be aware, however, that filters run at a surprising time - after an exception has occurred but before
     /// any finally clause has been run to restore broken invariants for things lexically in scope.  This can lead to 
     /// confusion if you access or manipulate program state from your filter.  See this blog entry for details
     /// and more specific guidance: https://blogs.msdn.com/clrteam/archive/2009/08/25/the-good-and-the-bad-of-exception-filters.aspx.
     /// 
     /// This class relies on Reflection.Emit to generate code which can use filters.  If you are willing to add some
     /// complexity to your build process, a static technique (like writing in VB and use ILMerge, or rewriting with CCI)
     /// may be a better choice (eg. more performant and easier to specialize).  Again see
     /// https://blogs.msdn.com/rmbyers/archive/2008/12/22/getting-good-dumps-when-an-exception-is-thrown.aspx for details.
     /// 
     public static class ExceptionUtils
     {
         /// 
         /// Execute the body with the specified filter.
         /// 
         /// The code to run inside the "try" block
         /// Called whenever an exception escapes body, passing the exeption object.  
         /// For exceptions that aren't derived from System.Exception, they'll show up as an instance of RuntimeWrappedException.
         /// Invoked (with the exception) whenever the filter returns true, causes the exception to be swallowed
         public static void ExecuteWithFilter(Action body, Func<Exception, bool> filter, Action<Exception> handler)
         {
             s_filter(body, filter, handler);
         }
 
         /// 
         /// Execute the body with the specified filter with no handler ever being invoked
         /// 
         /// 
         /// Note that this allocates a delegate and closure class, a small amount of overhead but something that may not be appropriate
         /// for inside of a tight inner loop.  If you want to call this on a very hot path, you may want to consider a direct call
         /// rather than using an anonymous method.
         /// 
         public static void ExecuteWithFilter(Action body, Action<Exception> filter)
         {
             ExecuteWithFilter(body, (e) => { filter(e); return false; }, null);
         }
 
         /// 
         /// Execute the body which is not expected to ever throw any exceptions.
         /// If an exception does escape body, stop in the debugger if one is attached and then fail-fast.
         /// 
         public static void ExecuteWithFailfast(Action body)
         {
             ExecuteWithFilter(body, (e) =>
             {
                 System.Diagnostics.Debugger.Log(10, "ExceptionFilter", "Saw unexpected exception: " + e.ToString());
 
                 // Terminate the process with this fatal error
                 if (System.Environment.Version.Major >= 4)
                 {
                     // .NET 4 adds a FailFast overload which takes the exception, usefull for getting good watson buckets
                     // This will also cause an attached debugger to stop at the throw point, just as if the exception went unhandled.
                     // Note that this code may be compiled against .NET 2.0 but running in CLR v4, so we want to take advantage of
                     // this API even if it's not available at compile time, so we use a late-bound call.
                     typeof(System.Environment).InvokeMember("FailFast",
                         BindingFlags.Static | BindingFlags.InvokeMethod,
                         null, null, new object[] { "Unexpected Exception", e });
                 }
                 else
                 {
                     // The experience isn't quite as nice in CLR v2 and before (no good watson buckets, debugger shows a 
                     // 'FatalExecutionEngineErrorException' at this point), but still deubggable.
                     System.Environment.FailFast("Exception: " + e.GetType().FullName);
                 }
 
                 return false;   // should never be reached
             }, null);
         }
 
         /// 
         /// Like a normal C# Try/Catch but allows one catch block to catch multiple different types of exceptions.
         /// 
         /// The common base exception type to catch
         /// Code to execute inside the try
         /// All exception types to catch (each of which must be derived from or exactly TExceptionBase)
         /// The catch block to execute when one of the specified exceptions is caught
         public static void TryCatchMultiple(Action body, Type[] typesToCatch, Action handler)
             where TExceptionBase:Exception
         {
             // Verify that every type in typesToCatch is a sub-type of TExceptionBase
 #if DEBUG
             foreach(var tc in typesToCatch)
                 Debug.Assert(typeof(TExceptionBase).IsAssignableFrom(tc), String.Format("Error: {0} is not a sub-class of {1}",
                     tc.FullName, typeof(TExceptionBase).FullName));
 #endif
 
             ExecuteWithFilter(body, (e) =>
             {
                 // If the thrown exception is a sub-type (including the same time) of at least one of the provided types then
                 // catch it.
                 foreach (var catchType in typesToCatch)
                     if (catchType.IsAssignableFrom(e.GetType()))
                         return true;
                 return false;
             }, (e) =>
             {
                 handler((TExceptionBase)e);
             });
         }
 
         /// 
         /// A convenience method for when only the base type of 'Exception' is needed.
         /// 
         public static void TryCatchMultiple(Action body, Type[] typesToCatch, Action<Exception> handler)
         {
             TryCatchMultiple<Exception>(body, typesToCatch, handler);
         }
         /// 
         /// Set to true to write the generated assembly to disk for debugging purposes (eg. to run peverify and
         /// ildasm on in the case of bad codegen).
         /// 
         private static bool k_debug = false;
 
         /// 
         /// Generate a function which has an EH filter
         /// 
         private static Action<Action, Func<Exception , bool>, Action<Exception>> GenerateFilter()
         {
             // Create a dynamic assembly with reflection emit
             var name = new AssemblyName("DynamicFilter");
             AssemblyBuilder assembly = AppDomain.CurrentDomain.DefineDynamicAssembly(name, k_debug ? AssemblyBuilderAccess.RunAndSave : AssemblyBuilderAccess.Run);
             ModuleBuilder module;
             if (k_debug)
                 module = assembly.DefineDynamicModule("DynamicFilter", "DynamicFilter.dll");
             else
                 module = assembly.DefineDynamicModule("DynamicFilter");
 
             // Add an assembly attribute that tells the CLR to wrap non-CLS-compliant exceptions in a RuntimeWrappedException object
             // (so the cast to Exception in the code will always succeed).  C# and VB always do this, C++/CLI doesn't.
             assembly.SetCustomAttribute(new CustomAttributeBuilder(
                 typeof(RuntimeCompatibilityAttribute).GetConstructor(new Type[] { }),
                 new object[] {},
                 new PropertyInfo[] { typeof(RuntimeCompatibilityAttribute).GetProperty("WrapNonExceptionThrows") },
                 new object[] { true }));
 
             // Add an assembly attribute that tells the CLR not to attempt to load PDBs when compiling this assembly 
             assembly.SetCustomAttribute(new CustomAttributeBuilder(
                 typeof(DebuggableAttribute).GetConstructor(new Type[] { typeof(DebuggableAttribute.DebuggingModes) }),
                 new object[] { DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints } ));
 
             // Create the type and method which will contain the filter
             TypeBuilder type = module.DefineType("Filter", TypeAttributes.Class | TypeAttributes.Public);
             var argTypes = new Type[] { typeof(Action), typeof(Func<Exception, bool>), typeof(Action<Exception>) };
             MethodBuilder meth = type.DefineMethod("InvokeWithFilter", MethodAttributes.Public | MethodAttributes.Static, typeof(void), argTypes);
             
             var il = meth.GetILGenerator();
             var exLoc = il.DeclareLocal(typeof(Exception));
 
             // Invoke the body delegate inside the try
             il.BeginExceptionBlock();
             il.Emit(OpCodes.Ldarg_0);
             il.EmitCall(OpCodes.Callvirt, typeof(Action).GetMethod("Invoke"), null);
 
             // Invoke the filter delegate inside the filter block
             il.BeginExceptFilterBlock();
             il.Emit(OpCodes.Castclass, typeof(Exception));
             il.Emit(OpCodes.Stloc_0);
             il.Emit(OpCodes.Ldarg_1);
             il.Emit(OpCodes.Ldloc_0);
             il.EmitCall(OpCodes.Callvirt, typeof(Func<Exception, bool>).GetMethod("Invoke"), null);
 
             // Invoke the handler delegate inside the catch block
             il.BeginCatchBlock(null);
             il.Emit(OpCodes.Castclass, typeof(Exception));
             il.Emit(OpCodes.Stloc_0);
             il.Emit(OpCodes.Ldarg_2);
             il.Emit(OpCodes.Ldloc_0);
             il.EmitCall(OpCodes.Callvirt, typeof(Action<Exception>).GetMethod("Invoke"), null);
 
             il.EndExceptionBlock();
             il.Emit(OpCodes.Ret);
 
             var bakedType = type.CreateType();
             if (k_debug)
                 assembly.Save("DynamicFilter.dll");
 
             // Construct a delegate to the filter function and return it
             var bakedMeth = bakedType.GetMethod("InvokeWithFilter");
             var del = Delegate.CreateDelegate(typeof(Action<Action, Func<Exception, bool>, Action<Exception>>), bakedMeth);
             return (Action<Action, Func<Exception, bool>, Action<Exception>>)del;
         }
 
         // Will get generated (with automatic locking) on first use of this class
         private static Action<Action, Func<Exception, bool>, Action<Exception>> s_filter = GenerateFilter();
     }
 }

There’s also a few helper methods there for common uses of exception filters. For example, to call code that you don’t expect to ever throw an exception you can just wrap it with ExecuteWithFailFast. If any exceptions escape it’ll immediately fail fast with a watson report and minidump (at the point of throw), or if a debugger is attached break at the throw point. The experience is better if running on CLR v4 – it makes use of the new FailFast API that takes an exception (eg. this will cause the debugger to break with the exception assistant, just as if the exception had gone unhandled). For example you can use this as follows:

// FailFast on throw
 ExceptionUtils.ExecuteWithFailfast(() =>
 {
     // Code you don't expect to throw exceptions
     throw new ApplicationException("Test unexpected exception");
 });

Sometimes it’s useful to be able to catch multiple distinct exception types with the same catch block (without unwinding the stack for other exceptions, so unexpected exceptions are easier to debug live or in a dump file). Here are two examples:

// Catching multiple exception types at once as SystemException
 ExceptionUtils.TryCatchMultiple<SystemException>(() =>
 {
     throw new ArgumentNullException();
 },
 new Type[] { typeof(InvalidCastException), typeof(ArgumentException), typeof(System.IO.FileNotFoundException) },
 (e) =>
 {
     Console.WriteLine("Caught: " + e.Message);
 });
 
 // Catching multiple exception types at once as System.Exception
 ExceptionUtils.TryCatchMultiple(() =>
 {
     throw new ArgumentNullException();
 },
 new Type[] { typeof(InvalidCastException), typeof(ArgumentException), typeof(System.IO.FileNotFoundException) },
 (e) =>
 {
     Console.WriteLine("Caught: " + e.Message);
 });

And here’s an example of a general-purpose exception filter:

// General-purpose filter
 ExceptionUtils.ExecuteWithFilter( () => {
     Console.WriteLine("In body");
     throw new ApplicationException("test");
 }, (e) => {
     Console.WriteLine("In filter, exception type: {0}", e.GetType().FullName);
     return true;
 }, (e) => {
     Console.WriteLine("In catch, exception type: {0}", e.GetType().FullName);
 });

Again, there are good reasons why C# doesn’t support exception filters directly. But there are a few cases where they can be really invaluable. I hope you find this useful.

Quickly seeing where an exception may land in the debugger

Rick Byers - exMSFT — Tue, 01 Sep 2009 01:08:52 GMT

A co-worker asked me recently how he could predict where an exception that was about to be thrown would land while debugging a managed application. The real answer to this question is “you can’t – step into the throw and see”. The EH system in the CLR has lots of complicated algorithms for determining this, and it needs to interact with other code on the stack (eg. there may be some native code with it’s own SEH filter that can do arbitrary logic). Luckily, unlike for native debugging, managed debugging can generally “step into” exception throws and reliably land in the handler.

But occasionally people still find themselves looking up the callstack, searching the code for ‘try’ blocks that are active. Surely there’s a way to automate that? Of course the debugger has all the information necessary to automate that, but unfortunately the VS debugger is not easily extensible in this way, so there’s not a lot you can do from the debugger process. However, as usual, func-eval offers a nice work-around for the lack of easy extensibility. Using the technique in my “Run-time exception checking” post, we can func-eval code which gets the EH handler info for the current stack and displays it nicely in the watch window. I’ve posted a sample (source and binary) which does that here. To use it, download ExceptionHandlerInfo.dll, and then while stopped in the debugger enter Assembly.LoadFrom(@"c:\mypath\ExceptionHandlerInfo.dll") into the immediate window to get it loaded into the debuggee process. Now, whenever you want to quickly see what handlers are active on the current stack, you can enter “Microsoft.Samples.ExceptionHandlerInfo.EHInfoCollector.GetActiveEHClauses()” into the watch window:

In this example, we can see that there is first a “catch System.ArgumentException” at Program.cs line 35 in method '”Program.Catcher” which is the 2nd (#1) frame on the current stack. Above that on the stack there is a “catch Exception” and a “Finally” block in the “Program.Main” method, and then a “Finally” block inside the VS hosting process code (for which we don’t have PDBs to provide a source location).

You can drill info EHInfo objects further if you want more details on a particular frame:

And if you want to automate scanning all the active EH clauses for the one most likely to catch the currently active exception (eg. when stopping on first-chance exceptions), you can enter “Microsoft.Samples.ExceptionHandlerInfo.EHInfoCollector.GuessCatchHander($exception.GetType())”:

Now someone just needs to integrate this with a VS macro so I can jump to the most likely catcher with a single keypress ;-)

My school assignment required parsing PDB files

Rick Byers - exMSFT — Tue, 09 Jun 2009 13:15:00 GMT

I'm just finishing up my Masters in Computer Science, and was surprised when I recently got an assignment that involved parsing PDB files. Over the years I've been involved in many discussions about why the Microsoft PDB format isn't public. John Robbins recently went as far as to say "The actual file format of a PDB file is a closely guarded secret", but that's probably and overstatement given that the CCI code which contains a C# managed-PDB reader has now been released on CodePlex. So needless to say, I didn't expect to be having to parse PDB files for school ... especially in a computational biology class.

Ok, so if you do a web-search now for "PDB file format", the first hit you get isn't for Microsoft's Program Database file format, but for the Protein Data Bank file format. Who ever came up with the idea that file types should be uniquely determined by a 3-letter extension that isn't coordinated by any central registry anyway? Now I've got to decide which way I want windows to treat PDB files (and both have been pretty important to me lately):

New interviews with my CLR team members up on Channel9

Rick Byers - exMSFT — Tue, 09 Jun 2009 00:19:00 GMT

There are a bunch of great new CLR v4-related video interviews up on Channel9. In particular:

Jon, Thomas and Dave from my team (CLR diagnostics) discuss the advancements in debugging and profiling APIs in v4
Simon and I discuss in-process SxS (ability to have multiple CLRs loaded in the same process). You may have noticed the lack of diagnostics blog entries from me lately - that's because I've mostly been spending my time helping out with this important feature.

There are a bunch of other ones that look good (eg. "Type equivalence" and "No-PIAs" are closely related and an interesting discussion), but I haven't gotten a chance to watch them yet.

AnyCPU Exes are usually more trouble than they're worth

Rick Byers - exMSFT — Tue, 09 Jun 2009 00:13:00 GMT

Over the past few months I've had some interesting debates with folks here (and some customers) about the cost/benefit trade-off of "AnyCPU" (architecture-neutral) managed EXEs. I think we've converged on a consensus that most of the time they're not what you want and so shouldn't be the default in Visual Studio. I suspect this topic may interest (and even shock) some folks, so I thought I'd share the rationale with you here.

Background - .NET and 64-bit
With the introduction of Win64 (64-bit versions of Windows), PE files (EXEs and DLLs) can be marked either as 32-bit OR 64-bit. When a 32-bit EXE is launched on Win64, it runs in "the WOW" (Windows-32 on Windows-64) to present an illusion of a 32-bit operating system to the process. Generally only 32-bit DLLs can be loaded into a 32-bit process, and only 64-bit DLLs can be loaded into a 64-bit process. When the CLR added 64-bit support in version 2.0, we had an interesting decision to make. Should we mark our binaries as 32-bit or 64-bit by default? Techncally managed binaries had no hard CPU dependency, so they could be either (actually there is a small loader thunk, but that's unused on any newer OS including all the 64-bit ones since the OS loader knows about managed EXEs explicitly). Since we wanted people to be able to write .NET libraries that they could re-use from both 32-bit and 64-bit processes, we worked with Windows to extend the OS loader support to enable architecture-neutral ("AnyCPU") PE files.

Managed architecture-neutral DLLs are fairly straight-forward - they can be loaded into either 32-bit or 64-bit processes, and the (32-bit or 64-bit) CLR in the process will do the right thing with them. AnyCPU EXEs are a little more complicated since the OS loader needs to decide how to initialze the process. On 64-bit OSes they are run as 64-bit processes (unless the 'ldr64' master OS switch says otherwise), and on 32-bit OSes they are run as 32-bit processes. In Visual Studio 2008, AnyCPU is the default platform for C# and VB projects. This means that by default, applications you compile will run in 64-bit processes on 64-bit OSes and 32-bit processes on 32-bit OSes. This is fine and does often work alright, but there are a number of minor downsides.

The costs of architecture-neutral EXEs
There are a number of reasons to think that AnyCPU should not be the default for EXEs. Don't get me wrong, 64-bit hardware and OSes are definitely the way to go (in fact all 4 of my development machines have 64-bit OSes on them - I stopped bothering to install 32-bit OSes years ago). But that doesn't necessarily mean that most processes should be 64-bit. Here's the list I've been using in our discussions to justify making x86 the default for EXE projects in Visual Studio:

Running in two very different modes increases product complexity and the cost of testing
Often people don't realize the implications on native-interop of architecture-neutral assemblies. It means you need to ensure that equivalent 32-bit and 64-bit versions of the native DLLs you depend on are available, and (most significantly) the appropriate one is selected automatically. This is fairly easy when calling OS APIs due to the OS re-mapping of c:\windows\system32 to c:\windows\syswow64 when running in the WOW and extensive testing the OS team does. But many people who ship native DLLs alongside their managed app get this wrong at first and are surprised then their application blows up on 64-bit systems with an exception about their 32-bit DLL being in a bad format. Also, although it's much rarer than for native-code, pointer-size bugs can still manifest in .NET (eg. assuming IntPtr is the same as Int32, or incorrect marshalling declarations when interopping with native code).
Also, in addition to the rules you need to know to follow, there's just the issue that you've now really got twice as much code to test. Eg., there could easily be (and certainly have been many) CLR bugs that reproduce only on one architecture of the CLR, and this applies all the way across the stack (from OS, framework, 3rd-party libraries, to your code). Of course in an ideal world everyone has done a great job testing both 32-bit and 64-bit and you won't see any differences, but in practice for any large application that tends not to be the case, and (at Microsoft at least) we end up duplicating our entire test system for 32 and 64-bit and paying a significant ongoing cost to testing and supporting all platforms.
[Edit: Rico - of CLR and VS performance architect fame - just posted a great blog entry on why Visual Studio will not be a pure 64-bit application anytmie soon]
32-bit tends to be faster anyway
When an application can run fine either in 32-bit or 64-bit mode, the 32-bit mode tends to be a little faster. Larger pointers means more memory and cache consumption, and the number of bytes of CPU cache available is the same for both 32-bit and 64-bit processes. Of course the WOW layer does add some overhead, but the performance numbers I've seen indicate that in most real-world scenarios running in the WOW is faster than running as a native 64-bit process
Some features aren't avaiable in 64-bit
Although we all want to have perfect parity between 32-bit and 64-bit, the reality is that we're not quite there yet. CLR v2 only supported mixed-mode debugging on x86, and although we've finally added x64 support in CLR V4, edit-and-continue still doesn't support x64. On the CLR team, we consider x64 to be a first-class citizen whenever we add new functionality, but the reality is that we've got a complicated code-base (eg. completely separate 32-bit and 64-bit JIT compilers) and we sometimes have to make trade-offs (for example, adding 64-bit EnC would have been a very significant cost to the JIT team, and we decided that their time was better spent on higher priority features). There are other cool features outside of the CLR that are also specific to x86 - like historical debugging in VS 2010. Complicating matters here is that we haven't always done a great job with the error messages, and so sometimes people "upgrade" to a 64-bit OS and are then disgusted to see that some of their features no longer appear to work (without realizing that if they just re-targetted the WOW they'd work fine). For example, the EnC error in VS isn't very clear ("Changes to 64-bit applications are not allowed"), and has lead to some confusion in practice. I believe we're doing the right thing in VS2010 and fixing that dialog to make it clear that switching your project to x86 can resolve the issue, but still there's no getting back the time people have wasted on errors like this.

When do 64-bit processes make sense?
The biggest benefit of 64-bit processes is obivously the increased address-space. Many programs are bumping up against the 2GB limit of traditional 32-bit processes (even though they may not be using anywhere near 2GB of RAM). One thing that can be done for such programs is to have them opt-into 4GB mode so that they can get a full 4GB of address space when running in the WOW on a 64-bit OS [Edit: softened wording here due to some guidance to the contrary]. If more address space would be useful, than sometimes the right thing to do is to decide to target JUST x64 and avoid the cost of supporting two platforms (Exchange Server has done this for example). But often the right trade-off is to support both 32-bit and 64-bit processes, so that you can still run on 32-bit OSes, but take advantage of the large address space when running on 64-bit OSes.

This is where architecture-neutral assemblies make a lot of sense. If you're a library vendor, then building as AnyCPU and testing on all supported architectures absolutely makes sense. If you are producing an application EXE and have reason to believe your application may need more than 4GB of address space, then switching to AnyCPU may be a good idea. But, as for native, really needing this much address space is still pretty rare and usually only necessary for large complex applications, and so opting-in to AnyCPU should really not be a burden. You've got to think about what you want your testing strategy to be anyway, so making this step explicit seems to make sense.

Another argument for AnyCPU being the default which I think deserves serious thought is the impact on the Windows ecosystem and desire to move to a pure 64-bit world someday. No doubt the WOW adds extra complexity and confusion and it would be great to just kill it as quickly as we can. I definitely agree with that sentiment, and we should work to get to that place. But realistically, we're a long way from being able to seriously consider killing the WOW from Client OSes (it is already optional on Server Core - but how many EXE projects are really server apps?). Here are some things that need to happen before we can seriously consider killing the WOW: Windows needs to stop shipping new 32-bit-only client OSes, most new native applications need to fully support 64-bit, all popular existing apps need to move to 64-bit (including VS), etc. I'm sure we'll get there some day (as we did with the 16-bit to 32-bit transition), but I don't think defaulting to x86 in Visual Studio is going to be a major barrier here. When it starts looking like killing the WOW may be a feasible option in the near-future, then perhaps we should probably just switch the default to be x64-only, and let people opt-in to supporting 'legacy' 32-bit platforms.

So how is Visual Studio 2010 and .NET 4.0 changing?
We are not changing anything here in the CLR or compilers - they continue to support both modes. However, after discussing these issues, VS project system team has agreed to make EXE projects default to the x86 platform in VS 2010. Unfortunately there is a bug in Beta1 where ALL managed project types default to x86 (I take the blame for this - I didn't think to check DLL projects when validating the changes were in). AnyCPU is still incredibly valuable for DLLs (you may not always know what processes it will be loaded into), and since it just enables a DLL to be used in more places without actually affecting the bitness of the process, there isn't sufficient justification to disable AnyCPU by default. This bug has been fixed, and so the plan is to ship Beta2 with just the EXE projects defaulting to x86, and all DLL projects remaining as AnyCPU.

That said, there's still time to get customer feedback and so this could change for VS2010 RTM. We've already heard a lot of surprised reactions where people seem to think we're treating x64 as second-class, or otherwise resisting the natural evolution to 64-bit systems. Many people have mentioned that 32-bit hardware and 32-bit OSes are quickly becoming a thing of the past. I agree completely and this is a good trend, but it's completely orthogonal. 64-bit hardware and OSes give us the ability to run processes with 64-bit address spaces, but they by no means make using them a requirement or necessarily even preferable to using the WOW. The Windows folks did such a good job building the WOW, and the CPU designers did a good job supporting 32-bit modes (for x64 at least, ia64 is a different story), so there aren't a lot of downsides to relying on them. Someday I'm sure we'll decide the WOW has outlived it's useful lifetime and Windows should kill it rather than maintain it, but I'm sure that day is a LONG way off (eg. when did Windows finally remove support for 16-bit processes, and did anyone really notice?).

When I actually get into debating this issue on it's merrits, almost everyone I've talked to has agreed that making x86 the default seems to be the best choice - at least for the next several years. This, by no means signifies decreased support for 64-bit OSes and frameworks. I can tell you that most CLR developers work almost exclusiviely on x64 OSes, and do much of their testing and development with 64-bit processes. Our testing (like most teams at Microsoft) treats x86 and x64 as first-class and generally equal-priority (except for products like Silverlight of course that are still x86-only). But when we put ourselves in the shoes of our users and study this issue on it's merrits, it just makes practical sense for x86 to be the default for EXE projects.

Let me know if you agree or disagree. Regardless, I hope you enjoy using VS2010 - it's really shaping up to be a great release!

[Edit - added section about helping the ecosystem move to all 64-bit]

CCI is public on Codeplex

Rick Byers - exMSFT — Wed, 15 Apr 2009 12:07:00 GMT

Herman Venter has just released his Common Compiler Infrastructure as an OpenSource project on Codeplex. CCI is a GREAT set of libraries for building, analyzing, and modifying .NET assemblies and PDB files - written entirely in C#. Several Microsoft projects have been using it internally for years. Most notably, it's the engine behind FxCop. If you've written your own custom rule for FxCop, you've used an earlier genreation of CCI. I'm thrilled that the latest CCI is finally public in full source form. This makes it easy to write all sorts of cool .NET tools.

I've been playing with custom FxCop rules for awhile. I'm getting close to releasing an FxCop rule that warns about invalid format strings (rather than waiting until runtime to get an annoying FormatException), and I've got a half-finished prototype of adding C++-style 'const' to C# (not that I think it's the best solution for adding immutability - just that it's a model lots of C# developers are already familiar with, and so a good one to experiment with). Now that the full CCI is out there, my mind is racing with all the cool tools I could release. I can't wait too see what else the community uses CCI for!

Getting good dumps when an exception is thrown

Rick Byers - exMSFT — Mon, 22 Dec 2008 22: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. Update: I posted some sample code to do this here.

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.

[Update] One other detail to be aware of with this approach is that the StackTrace in the Exception object is filled in by the CLR on the first pass, and so when your filter is hit the Exception's stack trace will only contain the frames above the function with the try block on the stack (just as if the exception had been caught at that point). If you're replacing catch blocks with filters then this shouldn't be surprising. But if you're sprinking filters in places that used to just let exceptions bubble up, then you might be surprised that there's not more details in the Exception's StackTrace. But the most important thing is that the full stack trace (with access to locals, etc.) is available on the thread, so in most situations what's stored inside the Exception object in a dump shouldn't really matter.

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

Rick Byers - exMSFT — Thu, 30 Oct 2008 17: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

Rick Byers - exMSFT — Mon, 27 Oct 2008 15: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 ). 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.