<< NCrunch v1.43 Released! | NCrunch Easter Release >>

Windows Update KB2742616

by Remco 14. January 2013 07:53

A problem that I'm fairly certain almost every developer is familiar with: How to maintain security in software that isn't hosted under the control of the company developing it?

A well known solution to this problem in the world we live in is for the software to update itself automatically. The truely wonderful thing about this is that we don't need to think about needing to stop and think about installing security fixes - they just get rolled out automatically. Every week, Microsoft releases a fresh barrage of automatic updates to solve critical issues and reported security problems. For most of us that work on a Microsoft operating system, we're comfortably oblivious to the changes our systems are happily gobbling up and installing ... at least, until something goes wrong.

Windows update KB2742616 has been quietly making its way out over the last few days to address an issue with code access security (CAS) in v3.5 of the .NET framework. The update fixes a vulnerability that allows an attacker to by-pass CAS and potentially gain control of a system that they are intended to have restricted access to.

Unfortunately, the update makes a very fundamental change to the way in which the JIT compiler handles the IL within the constructors of generic types. After the update, certain IL sequences cause the application to throw InvalidProgramExceptions while attempting to JIT these constructor calls.

As far as I know, there isn't any way to create these IL sequences by using the C# compiler, so under normal circumstances there would be no problem here. Unfortunately, NCrunch doesn't write MSIL using C#, so its performance analysis instrumentation causes it to bomb out due to these new constraints.

So anyway, if you've just started seeing your tests throwing InvalidProgramException out of the blue without any apparent reason, then don't worry - you're not crazy. The following options are available to you:

1. Install NCrunch v1.44 (released specifically to solve this problem)

2. Turn off the 'Analyse line execution times' for all the v3.5 assemblies in your solution (though you'll lose inline hotspots and performance information if you do this)

3. Upgrade all your test projects to v4.0 of the .NET framework or higher (v4.0 and above use a different CAS model and aren't impacted by this update)

4. Find a way to uninstall KB2742616 (likely will require system restore. Pain pills recommended)

========= Important Update

If you are experiencing problems with missing coverage markers after upgrading to v1.44, try downloading and installing the latest version from the download page. I've just included a fix for an installer problem that was causing this issue.

0f9fb310-4bdc-4c4b-a1e5-087b550cd153|3|3.7

Tags:

Comments (2) -

Mick Wilson

1/15/2013 6:26:23 AM #

Can you share anything about your solution in 1.44? AutoMapper is having the same problem, I think.

Remco

1/15/2013 8:09:32 AM #

The problem involves a new set of constraints around the behaviour of the JIT compiler.  It now seems to have some kind of extra code verification step for the constructors of generic types in v3.5 of the .NET framework.  The following is an IL dump of the top of a normal constructor for a generic type:

  .method public hidebysig specialname rtspecialname
          instance void  .ctor() cil managed
  {
    // Code size       45 (0x2d)
    .maxstack  4
    .locals init (int32 V_0,
             uint32 V_1)
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  nop
    IL_0007:  nop
   ... etc

The first two instructions of this call are critical (ldarg.0 and call).  They load 'this' onto the evaluation stack and make a call to the base object constructor.  Prior to KB2742616, it was possible to insert additional instructions prior to the object constructor call, which is something that NCrunch does in order to analyse code coverage.  After KB2742616 is loaded, the nature of the instructions that can exist before the object constructor call is somehow constrained.  Some instructions are fine.  Others aren't.  I wasn't able to identify a clear pattern of what the additional verification step looks for, but I could conclude that the more complex the code, the lower the chance that KB2742616 would accept it.

The problem also spans beyond this.  Constructors are also used in the initialisation of member fields, and the IL for this initialisation also seems to be protected in the same way.  From the perspective of a profiler, it can be very hard to differentiate between code that is being placed by the compiler for field/object initialisation and code that is added to the constructor by the user.  The eventual solution for NCrunch was to simplify the instrumentation for generic constructors in such a way as to allow the JIT to accept the code.  This means that when running under v3.5 of the .NET framework, NCrunch will no longer capture performance information inside generic constructors - it will only capture code coverage.

I hope this helps you.  I presume that other tools are also likely to be affected by this.  I'm not sure if the constraints above were deliberately placed as part of KB2742616 or if they are a side-effect of some kind of deeper level problem.

Cheers,

Remco

Pingbacks and trackbacks (1)+

Comments are closed

News

Windows Update KB2742616

Comments (2) -

Pingbacks and trackbacks (1)+

Month List

RecentPosts