Pour appliquer ce correctif cumulatif, consultez l’article suivant de la base de connaissances et télécharger le correctif approprié :

2925383 2925383 de correctif cumulatif est disponible pour le.NET Framework 4.5.1 dans Windows

Introduction

Cet article décrit le correctif 2908385 disponible pour le Microsoft.NET Framework 4.5.1. Pour plus d’informations sur le problème résolu par le correctif, reportez-vous à la section « Informations complémentaires ».

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

  • Windows 8

  • Windows Server 2012


Plus d'informations

Informations sur le correctif

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.

Conditions préalables

Pour appliquer ce correctif, vous devez disposer du.NET Framework 4.5.1 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.


Ce correctif cumulatif résout les problèmes

Problème 1

Symptoms

Supposons que vous appelez la méthode Application.DoEventsà partir du Gestionnaire de l’événement ValueChanged du contrôle NumericUpDown . Par exemple, vous utilisez le code suivant :private void numericUpDown1_ValueChanged(object sender, EventArgs e){
for (int i = 0; i < 10; i++)
{
Application.DoEvents();
Thread.Sleep(10);
}
}
Lorsque le haut ou le bouton flèche bas est enfoncé pendant quelques secondes, le contrôle crée une minuterie pour générer répétées incrémente ou décrémente. Dans Application.DoEvents la graduation de la minuterie est traitée à nouveau. Cela provoque un événement ValueChanged . Ensuite, vous entrez de nouveau le Gestionnaire d’événements tick timer. Lorsque le bouton de la souris est relâché, la minuterie est détruite dans le gestionnaire au bas de la pile, mais il est ensuite réutilisée à nouveau que la pile n’est pas vidée par les autres gestionnaires. Cela provoque une exception de référence null et un blocage.



Solution de contournement

Pour contourner ce problème, utilisez BeginInvoke pour appeler de façon asynchrone Application.DoEvents() après le traitement de l’événement timer. Par exemple, utiliser la classe suivante pour substituer le comportement par défaut :public class MyNumericUpDown : System.Windows.Forms.NumericUpDown{
public NumericUpDown() : base()
{
}
protected override void OnValueChanged(EventArgs e)
{
// run the handler as a separate event to prevent re-entrance to prevent a NullRef when hitting.
if (IsHandleCreated)
BeginInvoke(new Action(() => base.OnValueChanged(e)));
else
base.OnValueChanged(e);
}
}
Remarque En général, nous ne recommandons pas que vous entrez dans une boucle de message (Application.DoEvents) à partir d’un gestionnaire de messages (ValueChanged est déclenché à partir du Gestionnaire de message Timer.OnTick ), car cela peut conduire à un débordement de pile. Par exemple, la plage du contrôle NumericUpDown est grande, et l’utilisateur appuie sur le bouton de direction pendant un certain temps. Utiliser BeginInvoke pour éviter le dépassement de capacité de la pile. Ce correctif logiciel ne résout pas ce problème.

Problème 2

Symptômes

Copie de texte mis en forme à partir d’un long document XPS peut prendre de quelques minutes, en fonction de la position du texte dans le document et peut entraîner l’application à figer.

Cause

Ce problème se produit car certaines déclarations de mise en forme requièrent analyse le document à partir du début jusqu'à la sélection désirée. Ces déclarations sont rares (qu’elles proviennent d’éléments personnalisés qui ont un attribut TextElementEditingBehaviorAttribute qui n’est pas marqué comme IsTypographicOnly).

La logique est modifiée dans ce correctif afin d’éviter l’analyse coûteux lorsqu’aucune de ces déclarations s’affichent dans la sélection désirée.

Problème 3

Symptômes

Un TextBlock de Windows Presentation Foundation (WPF) peut ne pas affiche un ou plusieurs caractères à la fin de son texte. Ce problème se produit lorsque les conditions suivantes sont remplies :

  • TextWrapping ou TextTrimming est activée.

  • Le remplissage est différente de zéro, ou TextFormattingMode est « Affichage ».

  • Largeur n’est pas définie ou a la valeur « Auto ».

  • Le FontFamily, FontSize et des caractères spécifiques dans le texte de conduire à une largeur défavorable.

Cause

Ce problème se produit en raison des imprécisions numériques (une erreur d’arrondi) qui peuvent se produire lors du calcul de la largeur du texte, convertir la largeur entre les systèmes de coordonnées internes, comptables et de remplissage, aligner le texte sur les limites en pixels pour le mode d’affichage.

Protection contre ces types d’inexactitudes a été ajoutée pour les calculs, afin de vous assurer que tous les caractères qui doivent être affichées seront affichées.

Problème 4

Épinglage d’objets peuvent provoquer des tas mémoire une fragmentation trop importante, à l’origine d’une baisse des performances. Ce correctif fournit une réutilisation plus efficace de la mémoire tampon, qui permet de réduire la fragmentation de segment de mémoire.

Problème 5

Parfois, une application peut rencontrer une exception de violation d’accès lors de l’AppDomain s’arrête après un opération de Garbage Collection d’arrière-plan.

Problème 6

Les outils de diagnostic qui effectuent l’instrumentation de langage intermédiaire à l’aide des API de profilage peuvent provoquer l’exception non gérée suivante doit être levée par le common language runtime (CLR) :

0X80131401 » = SECURITY_E_INCOMPATIBLE_SHARE. Chargement de cet assembly produirait un jeu accordé différent des autres instances.


En outre, le processus se bloque. Ce problème se produit uniquement lorsque vous utilisez des outils de diagnostic.

Problème 7

Lorsque vous utilisez le point d’extensibilité HttpMessageHandler Windows Communication Foundation (WCF) 4.5 (également appelé le Pipeline HTTP WCF), l’en-tête WWW-Authenticate ne peut pas être définie sur HttpRequestMessage ou HttpResponseMessage. C’est parce que le nouveau point d’extensibilité HttpMessageHandler utilise un mécanisme différent pour le traitement des en-têtes.

Après avoir appliqué ce correctif, les deux mécanismes pour ajouter des en-têtes sont remis à la parité et une doit être en mesure d’ajouter à nouveau les en-têtes WWW-Authenticate.

Problème 8

Une exception NullReferenceException est levée à partir de la méthode SqlInternalConnectionTds.BreakConnection . Ce correctif résout le problème de synchronisation qui conduit à l’exception NullReferenceException .

Problème 9

Symptômes

Supposons que vous disposez d’une application WCF qui utilise la classe BinaryMessageEncoder , et que le codeur utilise un enregistrement de texte UTF-8 en fonction par [MC-NBFX]. Ou bien, supposons que vous possédez une application WCF qui utilise la méthode System.ServiceModel.Channels.Message.CreateBufferedCopy . Un message est traité qui contient des caractères de la plage de U + 10000 et U + 10FFFF (inclus) qui sont représentés au format UTF-8 sous la forme d’une séquence de 4 octets. Dans ce cas, le message binaire codé risquent d’être perdu, et vous recevez le message d’erreur suivant :

System.ArgumentException: The output char buffer is too small to contain the decoded characters, encoding 'Unicode (UTF-8)' fallback 'System.Text.DecoderExceptionFallback'.Parameter name: chars
at System.Text.Encoding.ThrowCharsOverflow()
at System.Text.Encoding.ThrowCharsOverflow(DecoderNLS decoder, Boolean nothingDecoded)
at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, DecoderNLS baseDecoder)
at System.Text.DecoderNLS.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, Boolean flush)
at System.Text.DecoderNLS.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex, Boolean flush)
at System.Text.DecoderNLS.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex)
at System.Xml.ValueHandle.TryReadChars(Char[] chars, Int32 offset, Int32 count, Int32& actual)
at System.Xml.XmlBaseReader.ReadValueChunk(Char[] chars, Int32 offset, Int32 count)
at System.Xml.XmlBinaryWriter.WriteTextNode(XmlDictionaryReader reader, Boolean attribute)
at System.Xml.XmlDictionaryWriter.WriteNode(XmlDictionaryReader reader, Boolean defattr)
at System.ServiceModel.Channels.ReceivedMessage.OnWriteBodyContents(XmlDictionaryWriter writer)
at System.ServiceModel.Channels.Message.OnWriteMessage(XmlDictionaryWriter writer)
at System.ServiceModel.Channels.Message.OnCreateBufferedCopy(Int32 maxBufferSize, XmlDictionaryReaderQuotas quotas)
at System.ServiceModel.Channels.StreamedMessage.OnCreateBufferedCopy(Int32 maxBufferSize)
at System.ServiceModel.Channels.Message.CreateBufferedCopy(Int32 maxBufferSize)
at ConsoleApplication1.BufferRequestChannel.WrappingRequestContext.BufferMessage()

Lorsque ce problème se produit, le client arrive à expiration sans réponse si l’application WCF est auto-hébergé. Si l’application WCF est hébergé par le web (ASP.NET), le client recevra une erreur 500 serveur.

Cause

Ce problème se produit en raison d’un détail d’implémentation interne qui alloue parfois pas suffisamment d’espace lorsque les séquences de caractères de 4 octets UTF-8 sont décodés.

Résolution

Pour résoudre ce problème, appliquez le correctif. Après avoir appliqué le correctif, l’application WCF attendra le prochain
Méthode de lecture pour décoder les caractères si l’espace est insuffisant dans la mémoire tampon de sortie pour décoder des caractères Unicode codés sur plusieurs octets.

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 ?

Dans quelle mesure êtes-vous satisfait(e) de la qualité de la langue ?
Qu’est-ce qui a affecté votre expérience ?

Nous vous remercions de vos commentaires.

×