Cet article décrit le correctif cumulatif 3088956 qui est disponible pour le Microsoft.NET Framework 4.6. Pour plus d’informations sur les problèmes résolus dans le correctif cumulatif, reportez-vous à la section «problèmes résolus dans ce correctif cumulatif».
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, frais généralement encourus pour la prise en charge des appels peuvent être annulés si un technicien du support technique Microsoft détermine qu’une mise à jour spécifique résoudra votre problème. Les coûts habituels du support technique s’appliqueront aux questions supplémentaires et aux problèmes qui ne relèvent de la mise à jour spécifique en question.
Plus d'informations
Conditions préalables
Pour appliquer ce correctif, vous devez disposer du 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
Si vous avez un site Web d’ASP.NET en cours d’exécution sur une version 32 bits de la 4.6 de.NET Framework ou la version AMD64 de la plate-forme.NET Framework 4.6 avec RyuJit désactivé, vous pouvez rencontrer w3wp incident car ThreadAbortException non gérée.
Lorsque l’incident se produit, vous pouvez voir le journal suivant dans le journal des événements Windows :
Une exception non gérée s’est produite et le processus a été arrêté.
ID de l’application : [ApplicationID]
ID de processus : [ProcessID]
Exceptions : System.Threading.ThreadAbortException
Message : Le Thread a été abandonné.
StackTrace : À System.Web.HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest wr, HttpContext context)
à System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, indicateurs de Int32)
à System.Web.Hosting.PipelineRuntime.ProcessRequestNotification (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, indicateurs de Int32)
Problème 2
Supposons que vous disposez d’un client WCF se connectant au service WCF à l’aide du Service de routage de WCF. Si le service fin déclenche une exception inattendue qui n’est pas un type d’exception FaultException ou les modifications de configuration, WCF le Service de routage ne peut pas router les demandes suivantes au service de fin.
Lorsque ce problème se produit, vous recevez l’exception suivante :
System.ServiceModel.ProtocolException : Ce canal n’est plus utilisable pour envoyer des messages car la session de sortie a été fermée automatiquement en raison d’un arrêt exécutée par le serveur. Désactivez la fermeture automatique en définissant le DispatchRuntime.AutomaticInputSessionShutdown sur false ou envisagez de modifier le protocole d’arrêt avec le serveur distant.
Informations de trace de pile :
at 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)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService(IMethodCallMessage methodCall, 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)
at 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()
at System.ServiceModel.Routing.ProcessRequestAsyncResult`1..ctor(RoutingService service, Message message, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.RoutingService.BeginProcessRequest[TContract](Message message, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.RoutingService.System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(Message message, AsyncCallback callback, Object state)
at AsyncInvokeBeginBeginProcessRequest(Object , Object[] , AsyncCallback , Object )
at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeBegin(Object instance, Object[] inputs, AsyncCallback callback, Object state)
Problème 3
Il s’agit d’une mise à jour pour prendre en charge le nouveau symbole Géorgien Lari. Le pays de Géorgie a introduit un nouveau symbole de devise pour le Lari, mais le nom de la devise n’est pas modifié. Le nouveau symbole de devise 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 du système.
Problème 4
Si une collection de génération 2 se produit pendant les appels de Parallel.ForEach , vous pouvez rencontrer des blocages long après l’installation de Visual Studio 2015 ou le 4.6 de.NET Framework sans Visual Studio.
Résolution:
Cette mise à jour met à jour le Garbage Collector en résolvant le système se fige causés par ce problème.
Problème 5
Après avoir installé le 4.6 du.NET Framework, les méthodes de Date Time.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-élément
-
SR-Latn-ME
-
SR-Latn-r
-
sr-Latn-XK
Résolution:
Cette mise à jour permet de DateTime.Parse et Date.TryParse pour fonctionner correctement dans les cultures qui utilisent la même date et séparateur d’heure.
Problème 6
Après avoir installé le 4.6 du.NET Framework, le 4.6 de.NET Framework utilise un nouveau compilateur 64 bits qui est appelé RyuJIT. Dans certains cas, le nouveau compilateur génère un code incorrect qui provoque un comportement imprévisible ou tombe en panne.
Résolution:
Cette mise à jour corrige de nombreux problèmes dans le compilateur RyuJIT. Si l’application toujours se comporte de façon imprévisible après l’installation de cette mise à jour, consultez les conseils de dépannage détaillées supplémentaires.
Les étapes supplémentaires:
S’il est déterminé que les RyuJIT peut-être être impliquée dans votre problème en suivant les étapes de dépannage à l’adresse, veuillez vous connecter le problème à http://connect.microsoft.com. Incluez autant de détails que possible dans le rapport et d’indiquer également le code permettant de reproduire le problème.
