[ 3/11/2008 – updated with links to the KB articles 957541/2/3 ]
Now that the dust has settled a little bit I thought I would bring together a list of what’s in it, good, bad and ugly..
Changes to the ThreadPool class
JIT, NGEN, other code generation changes and application startup improvements
Managed code now allowed to run direct from a network share, just like Win32
Garbage collection notifications
A whole load of fixes that were previously released individually as hotfixes
Sadly also there were some bugs slipped in which Scott Hanselman has discussed.
In fact, quite a bit of my time recently has been taken up assisting some customers (that’s my core job, in case you are not a regular follower of my blog) with addressing three particular regression issues. Fixes for these three are now available.
To get any of these fixes, you need to contact Microsoft Product Support and quote the Knowledge Base (KB) reference number. You will not have to pay for this. We do not charge for support in relation to hotfix delivery. PLEASE don’t contact me directly. At time of writing this blog post the actual KB articles are not yet published (that takes a little longer). But that should not stop you calling support and requesting the fix if you need it.
Issue 1) This is an issue that broke Rhino Mocks and was also reported to the connect site. The symptom is a Fatal Execution Engine Exception when calling GetOptionalCustomModifiers or GetRequiredCustomModifiers.
A hotfix is now available. The KB reference is KB957541.
Issue 2) This is an issue with the optimizer in the 32 bit JIT compiler that was also reported on connect. Due to the nature of the bug, you should only see this one with managed C++ and as I indicated, only in 32-bit.
A hotfix is now available. The KB reference is KB957542.
Issue 3) This is an issue that was reported in relation to Sitecore. This is a nasty issue that can impact any code that deserializes generic types which have at least one static and one non-static member. For example it could affect an ASP.NET application that uses such types in conjunction with viewstate. The symptom will vary depending on the bitness of the application. 32-bit applications will enter an infinite loop. With one thread hitting the bug on a single CPU system this will mean 100% CPU. With one thread hitting the bug on a dual processor system that would mean 50% CPU. If two threads were to hit the same code path (not sure if that is actually possible as I think we are hitting this on a one-time-per-type code path) it would again mean 100% CPU on a two processor system. Etc. You get the picture. Lots of CPU. 64-bit applications are likely to experience a TargetInvocationException wrapping an OutOfMemoryException (even though you are not out of memory).
A hotfix is now available. The KB reference is KB957543.
All three of these fixes will be included in the General Distribution Release (GDR) update for .NET Framework 3.5 SP1 that is being worked on right now, as described by Scott.