Correctif cumulatif 3139551 pour le.NET Framework 4.6.1 et 4.6 sous Windows

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3139551
Voir les produits et les systèmes d’exploitation que cet article s’applique à.

Cet article décrit le correctif cumulatif 3139551 qui est disponible pour le Microsoft.NET Framework 4.6.1 et le 4.6 du.NET Framework sur Windows Vista SP2, Windows Server 2008 SP2, Windows 7 Service Pack 1 (SP1) et Windows Server 2008 R2 SP1. Pour plus d’informations sur les correctifs inclus dans ce correctif cumulatif, voir le "Problèmes résolus dans ce correctif cumulatif.
Résolution

Informations sur le téléchargement

Le fichier suivant est disponible au téléchargement à partir du Microsoft Download Center :


Pour plus d’informations sur la façon de télécharger des fichiers de prise en charge de Microsoft, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
119591 Comment obtenir des fichiers de soutien technique Microsoft auprès des services en ligne
Microsoft a vérifié que ce fichier ne comportait pas de virus. Microsoft a utilisé les logiciels de détection de virus les plus récents disponibles à la date à laquelle le fichier a été validé. Le fichier est stocké sur des serveurs sécurisés, ce qui empêche toute modification non autorisée du fichier.
Plus d'informations

Conditions préalables

Pour appliquer ce correctif, vous devez disposer du.NET Framework 4.6.1 ou le 4.6 du.NET Framework installé.

Nécessite un redémarrage

Vous devez redémarrer l’ordinateur après avoir appliqué ce correctif logiciel si tous les fichiers affectés sont utilisés. Nous vous recommandons de fermer toutes les applications basées sur le.NET Framework avant d’appliquer ce correctif.

Informations de remplacement du correctif

Ce correctif logiciel ne remplace pas un package correctif publié précédemment.

Problèmes résolus dans ce correctif cumulatif

Problème 1

Lorsqu’une application WPF utilise un TreeViewItem en dehors du contexte d’un contrôle TreeView, l’application peut rencontrer une exception InvalidCastException dont trace de la pile commence comme suit :

System.Windows.Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)

Remarque Cette exception se produit lorsque l' élément TreeViewItem dans un contrôle de liste virtualisé (par exemple, un contrôle ListBoxou DataGridListView ) qui essaie de trouver la contrepartie de défilement de l' élément TreeViewItem ou un de ses descendants. Par exemple, cette exception se produit si vous déclarez un TreeViewItem comme la racine d’un DataTemplateet le DataTemplate est utilisé comme le CellTemplate d’une colonne du contrôle DataGrid .

Problème 2

System.Web.Caching et System.Runtime.Caching indiquent la taille de la mémoire qui est utilisée par l’AppDomain entier au lieu de la mémoire qui est utilisée par les éléments du cache.

C’est une régression depuis le 4.5 de.NET Framework en raison d’une modification de la mise en oeuvre de la minuterie. En plus des rapports de taille incorrecte, les objets supplémentaires référencés par le cache peuvent affecter considérablement les temps de latence GC gen2. Dans les scénarios d’hébergement de ASP.NET, le cache également calculé de la taille de tous les caches dans tous les domaines d’application (comme indiqué par un compteur de performance ASP.NET « % Cache sert de limite de mémoire de processus ») lorsque les domaines d’application ont été recyclés.

Ce correctif supprime toute référence non souhaitée à partir du cache pour les autres objets de domaine d’application afin que la taille correcte est signalée. Ce correctif inclut également des modifications pour améliorer le temps de latence pour System.Runtime.Caching sur les ordinateurs multicœurs qui utilisent Server GC. En outre, une fois ce correctif appliqué, la taille de tous les caches dans des scénarios de recyclage de domaine d’application est calculée correctement.

Problème 3

Lorsque vous avez une application Windows Presentation Foundation (WPF) qui s’appuie sur la promotion de la souris de tactile se déplace gérer l’interaction utilisateur tactile (et non à directement à l’aide d’événements tactiles), vous pouvez rencontrer un promu de souris se déplace anormalement faible volume.

Auparavant, promotion de souris WPF accéléré de tactile se déplace éviter d’avoir qu'un volume important de tactile se déplace de submerger le répartiteur. Dans le.NET Framework 4.6.1, un correctif a été introduit à la limitation que du nombre de tactile se déplace qui sont traités. Après cette modification, la limitation des promotions de souris a provoqué une réduction supplémentaire du nombre de souris déplace qui ont été générés. La limitation des promotions de la souris est désormais supprimée afin qu’il convient presque une correspondance biunivoque entre les événements de déplacement tactiles et les événements de déplacement de la souris promu.

Problème 4

Supposons que vous travaillez sur une application WPF qui cible la 4.6 de.NET Framework. Vous essayez de définir la valeur CurrentThread.CurrentCulture ou CurrentThread.CurrentUICulture dans n’importe quelle méthode qui est appelée par le répartiteur de WPF à l’aide d’une événement DispatcherOperation. Par exemple, vous essayez de définir cette valeur dans un gestionnaire d’événements de l’interface utilisateur ou le constructeur MainWindow. Dans ce cas, les valeurs de CurrentCulture et CurrentUICulture sont réinitialisées à leurs valeurs précédentes respectifs à la fin de la méthode. Si une application définit CurrentUICulture dans son constructeur MainWindow ou dans un gestionnaire de clic de bouton, ce paramètre reprend le système culture d’interface utilisateur.

Ce correctif permet de s’assurer que les valeurs de CurrentThread.CurrentCulture/CurrentUICulture sont définis dans des méthodes dans une application WPF rendre persistante de la même manière, comme ils le faisaient avant le 4.6 de.NET Framework.

Problème 5

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

Problème 6

Dans le point 4.6 de.NET Framework, il existe un bogue dans AppContext qui provoque la sécurité des threads des méthodes AppContext pour être implémenté de manière incorrecte. AppContext est la partie de l’infrastructure afin de réduire les modifications avec rupture. Vous pouvez utiliser AppContext pour définir et récupérer les indicateurs et de prendre des décisions dans votre application basée sur ces données.

Ce correctif permet la sécurité des threads correct pour les méthodes de AppContext qui est lié à la définition et extraction des valeurs de commutateur.

Problème 7

Lorsque vous rencontrez un cas de bord présentant la répartition et la survie et le modèle vous besoin d’un nouveau segment sur le tas managé, un garbage collector peut calculer une taille de validation qui est plus petite qu’elle aurait dû. Cela provoque une violation d’accès lors de la phase compacte car le garbage collector tente d’écrire dans la mémoire non validée.

Ce correctif calcule la taille correctement.

Problème 8

Lorsque vous créez le code natif de certaines méthodes, les applications du.NET Framework et les processus NGEN peuvent rencontrer un arrêt inattendu.

Problème 9

RyuJit génère des instructions incorrectes pour comparer des entiers non signés 16 bits sur des caisses enregistreuses. Il produit un résultat incorrect si les valeurs d’entrée ont différentes valeurs d’octet le plus significatif et si des instructions de comparaison générés utilisent opérandes de Registre.

Ce correctif génère les instructions correctes.

S’applique à

Cet article s’applique à ce qui suit :
  • Microsoft.NET Framework 4.6.1
  • Microsoft.NET Framework 4.6, lorsqu’il est utilisé avec :
    • Windows 7 Service Pack 1
    • Windows Server 2008 R2 Service Pack 1
    • Windows Server 2008 Service Pack 2
    • Windows Vista Service Pack 2

Propriétés

ID d'article : 3139551 - Dernière mise à jour : 07/22/2016 05:47:00 - Révision : 2.0

Microsoft .NET Framework 4.6.1, Microsoft .NET Framework 4.6

  • kbfix kbqfe kbsurveynew kbexpertiseadvanced kbmt KB3139551 KbMtfr
Commentaires