Correctif 3139549 correctif pour les .NET Framework 4.6.1 et 4.6 Windows

Problème 1

Lorsqu’une application WPF utilise un élément TreeViewItem en dehors du contexte TreeView, l’application peut rencontrer une exception InvalidCastException dont le suivi de pile commence comme suit :
 

Remarque Cette exception se produit lorsque l’élément TreeViewItem se trouve dans un contrôle de liste virtualisé (par exemple, un contrôle ListBox, DataGrid ou ListView) qui tente de trouver le décalage de défilement de l’élément TreeViewItem ou de l’un de ses descendants. Par exemple, si vous déclarez un TreeViewItem comme la racine d’un DataTemplate et que DataTemplate est utilisé comme CellTemplate d’une colonne DataGrid, cette exception se produit.
 

Problème 2

System.Web.Caching et System.Runtime.Caching signalent la taille de la mémoire utilisée par l’ensemble de l’AppDomain au lieu de la taille de mémoire utilisée par les éléments de cache.

Il s’agit d’un problème de régression .NET Framework 4.5 dans lequel une modification de l’implémentation du timer a été effectué. En plus de signaler une taille incorrecte, les objets supplémentaires référencés par le cache peuvent considérablement affecter la latence de PGC Gen2. Dans les scénarios d’hébergement de ASP.NET, le cache calcule également mal la taille de tous les caches dans tous les domaines d’application (signalés par l’intermédiaire du compteur de mémoire de processus du cache % utilisé ASP.NET) lorsque les domaines d’application sont réutilisés.

Le correctif supprime les références inattendues du cache au reste des objets de domaine de l’application, puis la taille correcte est signalée. Il inclut également des modifications pour améliorer la latence pour System.Runtime.Caching sur les ordinateurs multi-cœurs qui utilisent Server GC. Enfin, ce correctif calcule correctement la taille de tous les caches dans les scénarios de recyclage de domaines d’application.
 

Problème 3

Si vous avez une application Windows Presentation Foundation (WPF) qui repose sur la promotion sur un déplacement de souris afin de gérer une interaction tactile de l’utilisateur (au lieu d’utiliser directement des événements tactiles), vous pouvez faire face à un volume anormalement faible de déplacements promus de souris. 

Dans le passé, WPF limitée la promotion des déplacements tactiles de souris, car le volume des gestes tactiles était dépassé par l’régulateur. Dans la .NET Framework 4.6.1, un correctif a été apporté pour ce comportement. Le correctif permet de limiter le nombre de déplacements tactiles traiters. Par conséquent, la limitation des promotions de souris a entraîné une réduction supplémentaire des déplacements de souris générés. Dans ce rollup de mise à jour, la limitation des promotions de souris a été supprimée et il doit maintenant y avoir près d’une correspondance de 1 à 1 entre les événements de déplacement tactile et les événements de déplacement promus. 
 

Problème 4

Supposons que vous travailliez avec une application WPF qui cible le .NET Framework 4.6. Par exemple, supposons que vous essayiez de définir CurrentThread.Current Base ou CurrentThread.CurrentUI Qu’il utilise une méthode (telle qu’un responsable d’événements de l’interface utilisateur ou le constructionur MainWindow) qui est appelé par le régulateur WPF à l’aide d’un DispatcherOperation. Dans ce cas, les valeurs Current Bouton et CurrentUI Initial sont réinitialisées à leurs valeurs antérieures respectives à la fin de la méthode. Si une application définit CurrentUI Bouton dans son construction MainWindow ou un poignée clic de bouton, ce paramètre revient à la culture de l’interface utilisateur système.

Ce correctif permet de s’assurer que les valeurs CurrentThread.Current Base/CurrentUIUiS qui peuvent être définies dans des méthodes dans une application WPF sont persistantes comme avant la .NET Framework 4,6.


 

Problème 5

Dans la .NET Framework 4.6, un nouvel indicateur, TaskContinuationOptions.RunContinuationsAsynchronously, a été ajouté à la bibliothèque de tâches. Toutefois, lorsque vous utilisez cet indicateur conjointement avec Task.WhenAll, Task.WhenAny ou Task.Unwrap, il n’a aucun effet. L’indicateur a été introduit pour éviter certaines conditions de verrouillage. Ce correctif permet de s’assurer que tous les types de continuations de tâche respectent le nouvel indicateur.

Problème 6

AppContext fait partie de l’infrastructure pour réduire la rupture des modifications. Vous pouvez utiliser AppContext pour définir et récupérer des indicateurs et prendre des décisions dans votre application basées sur ces données. Dans la .NET Framework 4.6, il existe un bogue dans AppContext dans lequel la sécurité des méthodes AppContext est implémentée de façon incorrecte. 

Ce correctif permet une sécurité de thread correcte pour les méthodes sur AppContext qui sont liées à la définition et la récupération de valeurs de commutateur.

Problème 7

Lorsque vous avez atteint un cas particulier avec votre modèle d’attribution et de survie, et que vous avez besoin d’un nouveau segment sur votre budget géré, un collecteur de poubelle peut calculer une taille de validation plus petite que nécessaire. Cela entraîne une violation d’accès au cours de la phase compactée, car un collecteur de poubelle tente d’écrire à une mémoire non supprimée. Ce correctif calcule la taille correctement.

Problème 8

Lorsque vous créez du code natif pour certaines méthodes, les .NET Framework et les processus NGEN peuvent se crasher.

Problème 9

QuetJit génère des instructions incorrectes pour comparer les registres non signés 16 bits. Elle produit des résultats incorrects si les valeurs d’entrée ont des valeurs MSB différentes et génèrent par conséquent des instructions de comparaison qui n’utilisent que des opérandes de registre. Ce correctif génère des instructions correctes.