Cet article décrit le correctif cumulatif 3088956 disponible pour Microsoft .NET Framework 4.6. Pour plus d’informations sur les problèmes résolus par le correctif cumulatif, consultez la section « Problèmes résolus par ce correctif cumulatif ».
Résolution
Un correctif logiciel pris en charge est désormais disponible auprès de Microsoft. Toutefois, il est destiné à corriger uniquement le problème décrit dans cet article. Appliquez-la uniquement aux systèmes qui rencontrent ce problème spécifique.Pour résoudre ce problème, contactez les services de support technique Microsoft pour obtenir le correctif logiciel. Pour obtenir la liste complète des numéros de téléphone des services de support technique Microsoft et des informations sur les coûts de support, visitez le site web Microsoft suivant :
http://support.microsoft.com/contactus/?ws=supportRemarque Dans des cas particuliers, les frais habituellement engagés pour les appels de support peuvent être annulés si un Support Microsoft Professionnel détermine qu’une mise à jour spécifique résout votre problème. Les coûts de support habituels s’appliquent aux questions et problèmes de support supplémentaires qui ne sont pas éligibles pour la mise à jour spécifique en question.
Informations supplémentaires
Conditions préalables
Pour appliquer ce correctif, vous devez disposer du .NET Framework 4.6 installé.
Nécessité de redémarrer
Vous devez redémarrer l’ordinateur après avoir appliqué ce correctif logiciel si des fichiers affectés sont utilisés. Nous vous recommandons de fermer toutes les applications .NET Framework avant d’appliquer ce correctif logiciel.
Informations sur le remplacement de correctif logiciel
Ce package de correctif logiciel ne remplace pas un package de correctif logiciel publié précédemment.
Problèmes résolus par ce correctif cumulatif
Problème 1Si vous avez un site web ASP.NET s’exécutant sur une version 32 bits de .NET Framework 4.6 ou AMD64 de la plateforme .NET Framework 4.6 avec RyuJit désactivé, vous pouvez rencontrer un plantage w3wp en raison de ThreadAbortException non pris en charge. Lorsque l’incident se produit, vous pouvez voir le journal suivant dans le journal des événements Windows :
Une exception non prise en charge s’est produite et le processus a été arrêté.ID de l’application : [ApplicationID]ID de processus : [ProcessID]Exception : System.Threading.ThreadAbortExceptionMessage : Le thread a été abandonné.StackTrace : sur System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
Problème 2Supposons que vous disposez d’un client WCF qui se connecte au service WCF à l’aide du service de routage WCF. Si le service de fin génère une exception inattendue qui n’est pas un type de FaultException ou des modifications de configuration, le service de routage WCF peut ne pas router les demandes suivantes vers le service final.Lorsque ce problème se produit, vous recevez l’exception suivante :
System.ServiceModel.ProtocolException : ce canal ne peut plus être utilisé pour envoyer des messages, car la session de sortie a été fermée automatiquement en raison d’un arrêt initié par le serveur. Désactivez la fermeture automatique en définissant DispatchRuntime.AutomaticInputSessionShutdown sur false, ou envisagez de modifier le protocole d’arrêt avec le serveur distant.
Informations de trace de pile :à System.ServiceModel.Channels.ServiceChannel.PrepareCall(ProxyOperationRuntime operation, Boolean oneway, ProxyRpc& rpc)at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.Begin()at System.ServiceModel.Channels.ServiceChannel.BeginCall(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, TimeSpan timeout, AsyncCallback callback, Object asyncState)sur System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService(IMethodCallMessage, méthodeCall, ProxyOperationRuntime operation)at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)at System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(Message message, AsyncCallback callback, Object state)sur System.ServiceModel.Routing.ClientFactory.RequestReplyClient.OnBeginOperation(Message message, AsyncCallback callback, Object state)at System.ServiceModel.Routing.ClientFactory.RoutingClientBase'1.OperationAsyncResult.CallOperation()at System.ServiceModel.Routing.ClientFactory.RoutingClientBase'1.OperationAsyncResult.. ctor(RoutingClientBase'1 parent, Message requestMessage, Transaction transaction, AsyncCallback callback, Object state)at System.ServiceModel.Routing.ClientFactory.RoutingClientBase'1.BeginOperation(Message message, Transaction transaction, AsyncCallback callback, Object state)at System.ServiceModel.Routing.ProcessRequestAsyncResult'1.StartProcessing()sur System.ServiceModel.Routing.ProcessRequestAsyncResult'1..ctor(RoutingService service, Message message, rappel AsyncCallback, état de l’objet)at System.ServiceModel.Routing.RoutingService.BeginProcessRequest[TContract](Message message, AsyncCallback callback, Object state)at System.ServiceModel.RoutingService.System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(Message message, rappel AsyncCallback, Object state)dans AsyncInvokeBeginBeginProcessRequest(Object , Object[] , AsyncCallback , Object )at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeBegin(Object instance, Object[] inputs, AsyncCallback callback, Object state) Issue 3Il s’agit d’une mise à jour pour prendre en charge le nouveau symbole Lari géorgien. Le pays de la Géorgie a introduit un nouveau symbole monétaire pour le Lari, mais le nom de la devise n’a pas changé. Le nouveau symbole monétaire a également été ajouté à la norme Unicode. Cette mise à jour permet de s’assurer que le symbole monétaire correct est affiché par le .NET Framework en fonction des paramètres régionaux système.Problème 4Si une collection Gen2 se produit pendant les appels Parallel.ForEach, vous pouvez rencontrer de longs blocages après avoir installé Visual Studio 2015 ou .NET Framework 4.6 sans Visual Studio.Résolution : cette mise à jour met à jour le garbage collector en résolvant les blocages du système causés par ce problème.Problème 5Après avoir installé .NET Framework 4.6, les méthodes DateTime.Parse et Date.TryParse ne fonctionnent pas correctement. Ce problème peut se produire avec les paramètres de culture suivants :
-
fi-FI
-
nb-NO
-
nb-SJ
-
sr-Cyrl-XK
-
sr-Latn-ME
-
sr-Latn-RS
-
sr-Latn-XK
Résolution : cette mise à jour permet à DateTime.Parse et Date.TryParse de fonctionner correctement dans les cultures qui utilisent le même séparateur de date et d’heure.Problème 6Après avoir installé .NET Framework 4.6, le .NET Framework 4.6 utilise un nouveau compilateur 64 bits appelé RyuJIT. Dans certains cas, le nouveau compilateur génère un code incorrect qui provoque un comportement imprévisible ou des blocages. Résolution : Cette mise à jour résout de nombreux problèmes dans le compilateur RyuJIT. Si l’application se comporte toujours de façon imprévisible après l’installation de cette mise à jour, consultez des instructions de dépannage détaillées supplémentaires.Étapes supplémentaires : S’il est déterminé que RyuJIT peut être impliqué dans votre problème en suivant les étapes de résolution des problèmes sur le lien, veuillez consigner le problème à http://connect.microsoft.com. Incluez autant de détails que possible dans le rapport, ainsi que du code pour reproduire le problème.
