Hotfix rollup 2996568 for the .NET Framework 4.5, 4.5.1, and 4.5.2 on Vista SP2, Windows Server 2008 SP2, Windows 7 SP1, and Windows Server 2008 R2 SP1

Issue 1

This hotfix resolves the following two threading issues in System.IO.Packaging when you use the .NET Framework 4.5, the .NET Framework 4.5.1, or the .NET Framework 4.5.2.

• A deadlock may occur when you use large packages on separate threads. System.IO.Packaging uses IsolatedStorage for packages that are larger than 10 megabytes (MB). When two or more threads use large packages, a deadlock may occur, even if the packages are independent. The deadlock involves two threads. One is waiting in IsolatedStorageFile.Lock while the other is waiting in another method of the IsoloatedStorageFile class. This issue is fixed by adding synchronization to System.IO.Packaging to avoid the problem in IsolatedStorageFile.

• Exceptions may occur when you retrieve PackageProperties from packages that are opened on separate threads, even if the packages are independent. The most common call stacks that arise from this are as follows:System.Xml.XmlException: Unrecognized root element in Core Properties part. Line 2, position 2. at
  MS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
  System.IO.Packaging.Package.get_PackageProperties() System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: id at
  MS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
  System.IO.Packaging.Package.get_PackageProperties() This issue is caused by contention on a shared internal resource, and is resolved by giving each package a copy of that resource.

Issue 2

A Windows Presentation Foundation (WPF) application may use a large amount of memory when it receives many requests for the UIAutomation service. The memory belongs to the objects that are from the System.Threading namespace. This includes System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timer, and several other related classes.

These are the objects that are allocated on behalf of WPF when WPF receives a request for the UIAutomation activity. They are eventually released until the time-out deadline for the request expires (typically three minutes). If the requests arrive quickly, the application seems to be leaking memory, or using more memory than what is reasonable (as much as 500 MB).

This issue is resolved by releasing the objects when the request is completed, instead of waiting for the time-out deadline.

Issue 3

In a WPF application, when you enter text by using the Korean Input Method Editor (IME), the Text property of an editable ComboBox is not changed correctly in some cases.

This issue may exhibit different symptoms, and that depends on how the application (or the control author) has configured the ComboBox. For example:

• After you type and tab away (or move the focus to another control), the displayed text of ComboBox reverts to the empty string, or to the value that it had before the typing.

• The TextSearch feature of ComboBox behaves incorrectly. It does not match the prefix that has been entered, or it matches an unrelated item.

This issue is resolved by amending logic to accommodate the timing of the Korean IME that differs slightly from other IMEs.

Issue 4

After you use a touch to perform a drag-and-drop operation in a WPF application, the next touch gesture is ignored.

This issue is resolved by restoring the internal state of the touch input handler when the drag-and-drop operation is complete. In this manner, it computes the position of the next touch gesture correctly.

Issue 5

A new AuthenticationManager implementation can be optionally enabled to gain significant performance when you work with custom IAuthenticationModules.

Note Major security risks appear if the code is not designed to be thread-safe. The major behavior change is located on the PreAuthenticate and Authenticate methods. Previously it was guaranteed that the code was executing serially (a global lock was taken). In the new implementation, no lock is taken, and the customer code must guarantee the thread safety.
Additionally, with the new implementation, the PrefixLookup cache size can be controlled through registry.

The following registry keys can be used to enable and configure the maximum length of PrefixLookup:

• Global configuration[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]
  "System.Net.AuthenticationManager.HighPerformance"=dword:00000001
  "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000

• Local application configuration[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.HighPerformance]
  "c:\myapp\myapp.exe"=dword:00000001
  [HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.PrefixLookupMaxCount]
  "c:\myapp\myapp.exe"=dword:00010000

Global settings have priority over local application settings. Global and local application settings can be mixed. PrefixLookupMaxCount will not be affected if the global or local application HighPerformance setting is set to DWORD 1.

Issue 6

Assume that you run an application that is based on the .NET Framework 4.5, the .NET Framework 4.5.1, or the .NET Framework 4.5.2. The application throws an exception in a managed method that was called from native code and was passed a COM interface by reference. In this situation, the application may crash.

For example: An application that is written in VB6 calls a C# DLL. If the application and DLL are compiled in release mode, when an exception is thrown in the C# code, an access violation occurs, and the application crashes.

Issue 7

When the workflow XAML-based projects take longer time than the default lease time (five minutes) of the remote objects that are defined by the tasks for building the XAML, you receive an error message that resembles the following:

After you apply this hotfix, you can define your own lease time (in minutes) by defining the environment variable that is named XamlBuildTaskRemotingLeaseLifetimeInMinutes.

To set the environment variable in a project file for MSBuild, you have to include the following information in your project file:<Project ...>
<UsingTask TaskName="MySetEnv" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
<ParameterGroup>
<Name Required="true" />
<Value Required="false" />
</ParameterGroup>
<Task>
<Code Type="Fragment" Language="cs">System.Environment.SetEnvironmentVariable(Name, Value);</Code>
</Task>
</UsingTask>
...
...
<Target Name="BeforeBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="1440" />
</Target>
<Target Name="AfterBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="" />
</Target>
</Project> The TaskName in this example is MySetEnv. It can be set to any string that is valid for task names. This example sets the lease time to 1,440 minutes (one day) before the building of the project, and sets it to null after the building. If there are multiple projects that requires to extend the lease time, each project needs this configuration.

Issue 8

When you use AJAX postback in a page, sometimes the postback is redirected to another URL. You can obtain the RedirectLocation in a HttpModule through HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].