This article describes a hotfix rollup that's available for the Microsoft .NET Framework 4.6.1 and 4.6. For more information about the issues that this hotfix rollup fixes, see the Issues that this hotfix rollup fixes section.
The hotfix that corresponds to KB3139549 has been superseded with the latest updates of .NET Framework, which contain all fixes that were previously included in KB3139549. It is recommended to install the latest updates of .NET Framework.
For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.
To apply this hotfix, you must have the .NET Framework 4.6.1 or the .NET Framework 4.6 installed.
You must restart the computer after you apply this hotfix if any affected files are being used. We recommend that you exit all .NET Framework-based applications before you apply this hotfix.
Hotfix replacement information
This hotfix package doesn't replace a previously released hotfix package.
Issues that this hotfix rollup fixes
When a WPF application uses a TreeViewItem element outside of the TreeView context, the application may encounter an InvalidCastException exception whose stack trace starts as follows:
Note This exception occurs when the TreeViewItem element is in a virtualized list control (for example, a ListBox, DataGrid, or ListView control) that tries to find the scroll offset of the TreeViewItem or one of its descendants. For example, if you declare a TreeViewItem as the root of a DataTemplate, and the DataTemplate is used as the CellTemplate of a DataGrid column, this exception occurs.
Both System.Web.Caching and System.Runtime.Caching report the size of memory used by the whole AppDomain instead of the size of memory used by the cache items.
This is a regression issue from the .NET Framework 4.5 in which a change in Timer implementation was made. In addition to reporting an incorrect size, the additional objects referenced by the cache may significantly affect Gen2 GC latency. In ASP.NET hosting scenarios, the cache also miscalculates the size of all caches in all application domains (reported through the Cache % Process Memory Limit Used ASP.NET performance counter) when application domains are recycled.
The fix removes unintended references from the cache to the rest of the app domain objects, and then the correct size is reported. It also includes changes to improve the latency for System.Runtime.Caching on multi-core computers that are using Server GC. Finally, this fix calculates the size of all caches in app domain recycling scenarios correctly.
When you have a Windows Presentation Foundation (WPF) application that relies on promotion to a mouse move in order to handle a touch move user interaction (instead of directly using touch events), you may experience an unusually low volume of promoted mouse moves.
In the past, WPF throttled mouse promotion of touch moves because the volume of touch moves overwhelmed the dispatcher. In the .NET Framework 4.6.1, a fix was made for this behavior. The fix throttles the number of touch moves processed. Therefore, the throttling of mouse promotions caused a further reduction in mouse moves being generated. In this update rollup, the throttling of mouse promotions has been removed, and there should now be close to a 1 to 1 correspondence between touch move events and promoted mouse move events.
Assume that you're working with a WPF application that targets the .NET Framework 4.6. For example, assume that you try to set CurrentThread.CurrentCulture or CurrentThread.CurrentUICulture in any method (such as a UI event handler or the MainWindow constructor) that is invoked by the WPF Dispatcher using a DispatcherOperation. In this situation, the CurrentCulture and CurrentUICulture values are reset to their respective earlier values at the end of the method. If an application sets CurrentUICulture in its MainWindow constructor or a Button Click handler, that setting reverts back to system UI culture.
This fix makes sure that the CurrentThread.CurrentCulture/CurrentUICulture values that can be set in methods in a WPF application persist as they did before the .NET Framework 4.6.
In the .NET Framework 4.6, a new flag, TaskContinuationOptions.RunContinuationsAsynchronously, was added to the Task library. However, when you use this flag in conjunction with Task.WhenAll, Task.WhenAny or Task.Unwrap, it doesn’t have any effect. The flag was introduced to avoid certain deadlock conditions. This fix makes sure that all types of Task continuations respect the new flag.
AppContext is part of the infrastructure to reduce breaking changes. You can use AppContext to set and retrieve flags and make decisions in your application that is based on that data. In the .NET Framework 4.6, there is a bug in AppContext in which the thead-safety of the AppContext methods is implemented incorrectly.
This fix enables correct thread safety for the methods on AppContext that are related to setting and retrieving switch values.
When you hit an edge case with your allocation and survival pattern, and you need a new segment on your managed heap, garbage collector may calculate a commit size that's smaller than it should be. This causes an access violation during the compact phase, as garbage collector is trying to write to uncommitted memory. This fix calculates the size correctly.
When you create native code for certain methods, the .NET Framework applications and NGEN processes may crash.
RyuJit generates incorrect instructions for comparing 16-bit unsigned integers on registers. It produces incorrect results if input values have different MSB values and therefore generate compare instructions that use only register operands. This fix generates correct instructions.