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 4After 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 5A 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 6Assume 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 7When 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 8When 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"].