Correctif cumulatif 2996568 pour le.NET Framework 4.5, 4.5.1 et 4.5.2 sur Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 et Windows Server 2008 R2 SP1

Introduction

Cet article décrit le correctif 2996568 disponible pour le Microsoft.NET Framework 4.5, le.NET Framework 4.5.1 et le point 4.5.2 de.NET Framework. Pour plus d’informations sur le correctif logiciel cumulatif résout les problèmes, consultez la section « Informations complémentaires ».

Ce correctif cumulatif est disponible pour les systèmes d’exploitation suivants :

  • Windows Server 2008 R2 SP1

  • Windows 7 SP1

  • Windows Server 2008 SP2

  • Le Service Pack 2 de Windows Vista


Résolution

Un correctif pris en charge est désormais disponible auprès de Microsoft. Toutefois, il est conçu pour résoudre uniquement le problème décrit dans cet article. Il s’applique uniquement aux systèmes rencontrant ce problème spécifique.

Pour résoudre ce problème, contactez les Services de Support technique Microsoft pour obtenir le correctif. Pour obtenir une liste complète des numéros de téléphone des Services de Support technique Microsoft et des informations relatives aux frais de support technique, visitez le site Web Microsoft suivant :

http://support.microsoft.com/contactus/?ws=supportRemarque Dans des cas particuliers, des frais généralement encourus pour les appels au support technique peuvent être annulés si un technicien du support technique Microsoft détermine qu'une mise à jour spécifique peut résoudre votre problème. Les coûts habituels du support technique s’appliqueront aux autres questions et problèmes qui ne relèvent pas de la mise à jour spécifique en question.

Plus d'informations

Conditions préalables

Pour appliquer ce correctif, vous devez disposer du 4.5 de.NET Framework, le.NET Framework 4.5.1 ou le point 4.5.2 de l’installation du.NET Framework.

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.


















Ce correctif cumulatif résout les problèmes

Problème 1

Ce correctif résout les problèmes de threads deux suivants dans System.IO.Packaging lorsque vous utilisez le 4.5 de.NET Framework, le.NET Framework 4.5.1 ou le point 4.5.2 de.NET Framework.

  • Un blocage peut se produire lorsque vous utilisez des packages volumineux sur des threads séparés. System.IO.Packaging utilise IsolatedStorage pour les packages qui sont supérieures à 10 mégaoctets (Mo). Lorsque deux threads ou plus utilisent les packages de grande taille, un blocage peut se produire, même si les lots sont indépendants. Le blocage implique les deux threads. Un est en attente de IsolatedStorageFile.Lock tandis que l’autre est en attente dans une autre méthode de la classe IsoloatedStorageFile . Ce problème est résolu par ajout de la synchronisation à System.IO.Packaging pour éviter le problème dans un IsolatedStorageFile.

  • Les exceptions peuvent se produire lorsque vous récupérez PackageProperties à partir de packages qui sont ouverts sur des threads séparés, même si les lots sont indépendants. Les piles d’appels courants survenant à partir de ce sont les suivantes :System.Xml.XmlException: Unrecognized root element in Core Properties part. Line 2, position 2. atMS.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 atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
    System.IO.Packaging.Package.get_PackageProperties()
    Ce problème est dû à un conflit sur une ressource partagée d’interne et est résolu en donnant à chaque package une copie de la ressource.


Problème 2

Une application Windows Presentation Foundation (WPF) peut-être utiliser une grande quantité de mémoire lorsqu’il reçoit beaucoup de demandes pour le service UIAutomation . La mémoire appartient aux objets qui se trouvent dans l’espace de noms System.Threading . Ainsi, System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timeret plusieurs autres classes connexes.

Il s’agit d’objets qui sont affectés au nom WPF lorsque WPF reçoit une demande pour l’activité de UIAutomation . Ils sont finalement publiées avant l’expiration de l’échéance du délai d’attente de la demande (trois minutes). Si les requêtes arrivent rapidement, l’application semble présenter une fuite de mémoire, ou à l’aide de plus de mémoire que ce qui est raisonnable (jusqu'à 500 Mo).

Ce problème est résolu en libérant les objets lorsque la demande est terminée, au lieu d’attendre l’échéance du délai d’attente.

Problème 3

Dans une application WPF, lorsque vous entrez du texte à l’aide de l’éditeur de méthode d’entrée coréen (IME, Internet Connection Firewall), la propriété Text d’un contrôle ComboBox de modifiable n'est pas modifiée correctement dans certains cas.

Ce problème peut présenter différents symptômes, et qui dépend de la façon dont l’application (ou l’auteur du contrôle) a configuré le contrôle ComboBox. Par exemple :

  • Une fois que vous tapez et onglet absent (ou déplacez le focus vers un autre contrôle), le texte affiché du contrôle ComboBox rétablit la chaîne vide, ou la valeur qu’il avait avant la saisie.

  • La fonction TextSearch du contrôle ComboBox se comporte correctement. Le préfixe a été saisi ne correspond pas, ou qu’il correspond à un élément indépendant.

Ce problème est résolu en modifiant la logique pour prendre en charge de la synchronisation de l’éditeur IME coréen qui diffère légèrement des autres éditeurs.

Problème 4

Après avoir utilisé une pression tactile pour effectuer une opération de glisser-déplacer dans une application WPF, le mouvement tactile suivant est ignoré.

Ce problème est résolu en restaurant l’état interne du Gestionnaire d’entrée tactile lors de l’opération de glisser-déplacer est terminée. De cette manière, il calcule la position du mouvement tactile suivant correctement.

Problème 5

Une nouvelle implémentation de la classe AuthenticationManager peut être éventuellement activée pour obtenir des performances lorsque vous travaillez avec personnalisé IAuthenticationModules.

Remarque Risques majeurs de sécurité s’affichent si le code n’est pas conçu pour être thread-safe. Les modifications majeures du comportement se trouve sur les méthodes PreAuthenticate et authentifier . Précédemment, il est garanti que le code est en cours d’exécution en série (un verrouillage global a été pris). Dans la nouvelle implémentation, aucun verrou n’est effectuée, et le code client doit garantir la sécurité des threads.
En outre, avec la nouvelle implémentation, la taille du cache de PrefixLookup peut être contrôlée par l’intermédiaire du Registre.

Les clés de Registre suivantes peuvent être utilisés pour activer et configurer la longueur maximale de PrefixLookup:

  • Configuration globale[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]"System.Net.AuthenticationManager.HighPerformance"=dword:00000001
    "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000

  • Configuration de l’application locale[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

Les paramètres globaux ont priorité sur les paramètres de l’application locale. Paramètres d’application globaux et locaux peuvent être mélangés. PrefixLookupMaxCount ne pas être affecté si l’application globale ou locale ultraperformante est défini sur DWORD 1.

Problème 6

Supposons que vous exécutez une application qui repose sur le 4.5 de.NET Framework, le.NET Framework 4.5.1 ou le point 4.5.2 de.NET Framework. L’application lève une exception dans une méthode managée qui a été appelée à partir de code natif et d’une interface COM passée par référence. Dans ce cas, l’application peut se bloquer.

Par exemple : une application qui est écrit dans VB6 appelle une DLL C#. Si l’application et la DLL sont compilés en mode release, lorsqu’une exception est levée dans le code C#, une violation d’accès se produit et l’application se bloque.

Problème 7

Lorsque les projets workflow basée sur XAML prennent plus de temps que la durée de bail par défaut (cinq minutes) des objets distants qui sont définies par les tâches pour générer le code XAML, vous recevez un message d’erreur semblable au suivant :

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Xaml.targets(193,5) : erreur XC1000 : XC1020 : erreur de génération s’est produite dans la tâche MSBuild de XAML : ' objet ' / cc8d6dcf_823f_4ce0_aaad_fb1d3f85e42b/mzr1is8dfgy6yqtpnhegu6pt_4.rem' a été déconnecté ou n’existe pas sur le serveur. »

Après avoir appliqué ce correctif logiciel, vous pouvez définir votre propre durée (en minutes) en définissant la variable d’environnement nommée XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Pour définir la variable d’environnement dans un fichier projet MSBuild, vous devez inclure les informations suivantes dans votre fichier projet :<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>
Le nom de la tâche dans cet exemple est MySetEnv. Elle peut être définie à n’importe quelle chaîne qui est valide pour les noms de tâche. Cet exemple définit la durée du bail à 1 440 minutes (1 jour) avant la génération du projet et lui affecte null après la génération. S’il existe plusieurs projets qui nécessite de prolonger la durée du bail, chaque projet a besoin de cette configuration.

Problème 8

Lorsque vous utilisez un postback AJAX dans une page, la publication (postback) est parfois redirigé vers une autre URL. Vous pouvez obtenir le RedirectLocation dans un HttpModule via HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×