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

Introduction

This article describes hotfix rollup 2996568 that is available for the Microsoft .NET Framework 4.5, the .NET Framework 4.5.1, and the .NET Framework 4.5.2. For more information about the issues that the hotfix rollup resolves, see the "More Information" section.

This hotfix rollup is available for the following operating systems:
  • Windows Server 2008 R2 SP1
  • Windows 7 SP1
  • Windows Server 2008 SP2
  • Windows Vista SP2

Resolution

A supported hotfix is now available from Microsoft. However, it is intended to correct only the problem that this article describes. Apply it only to systems that are experiencing this specific problem.

To resolve this problem, contact Microsoft Customer Support Services to obtain the hotfix. For a complete list of Microsoft Customer Support Services telephone numbers and information about support costs, visit the following Microsoft website:Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

More Information

Prerequisites

To apply this hotfix, you must have the .NET Framework 4.5, the .NET Framework 4.5.1, or the .NET Framework 4.5.2 installed.

Restart requirement

You have to restart the computer after you apply this hotfix if any affected files are being used. We recommend that you close all .NET Framework-based applications before you apply this hotfix.

Hotfix replacement information

This hotfix package does not replace a previously released hotfix package.


















Issues that this hotfix rollup resolves

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:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Xaml.targets(193,5): error XC1000: XC1020: Build error occurred in the XAML MSBuild task: 'Object '/cc8d6dcf_823f_4ce0_aaad_fb1d3f85e42b/mzr1is8dfgy6yqtpnhegu6pt_4.rem' has been disconnected or does not exist at the server.'
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"].
Eigenschaften

Artikelnummer: 2996568 – Letzte Überarbeitung: 15.10.2014 – Revision: 1

Feedback