Este artigo descreve o conjunto de correcções 3088955 que está disponível para o Microsoft .NET Framework 4.6. Para mais informações sobre os problemas corrigidos no conjunto de correcções, consulte a secção "problemas corrigidos por este conjunto de correcções".
Resolução
Agora tem uma correcção suportada disponível na Microsoft. No entanto, este tem por objectivo apenas a corrigir o problema descrito neste artigo. Aplique-a apenas em sistemas que tenham este problema específico.
Para corrigir este problema, contacte o suporte técnico da Microsoft para obter a correcção. Para obter uma lista completa dos números de telefone do suporte técnico da Microsoft e informações sobre os custos de suporte, visite o seguinte Web site da Microsoft:
http://support.microsoft.com/contactus/?ws=supportNota Em casos especiais, os custos normalmente inerentes às chamadas de suporte poderão ser anulados se um técnico de suporte da Microsoft determinar que uma actualização específica irá corrigir o problema. Os custos de normais do suporte serão aplicados a questões de suporte adicionais e problemas que não se enquadrem na atualização específica em questão.
Mais informações
Pré-requisitos
Para aplicar esta correcção, tem de ter o .NET Framework 4.6. instalado.
Requisito de reinício
Tem de reiniciar o computador depois de aplicar esta correcção se todos os ficheiros afectados que estão a ser utilizados. Recomendamos que feche todas as aplicações baseadas no .NET Framework antes de aplicar esta correcção.
Informações sobre substituição da correção
Este pacote de correcção não substitui um pacote de correcções disponibilizadas anteriormente.
Problemas corrigidos por este conjunto de correcções
Problema 1
Se tiver um Web site ASP.NET em execução numa versão de 32 bits do 4.6 de Framework .NET ou versão AMD64 da plataforma .NET Framework 4.6 com RyuJit desactivada, poderá detectar falhas de w3wp devido a ThreadAbortException não processada.
Quando a falha acontece, pode ver o registo seguinte no registo de eventos do Windows:
Ocorreu uma excepção não processada e o processo foi terminado.
ID da aplicação: [ApplicationID]
ID do processo: [idprocesso]
Excepção: System.Threading.ThreadAbortException
Mensagem: Thread abortado.
StackTrace: A System.Web.HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest de wr, contexto de HttpContext)
em System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 sinalizadores)
em System.Web.Hosting.PipelineRuntime.ProcessRequestNotification (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 sinalizadores)
Problema 2
Suponha que tem um cliente WCF ligar ao serviço WCF utilizando o serviço de encaminhamento do WCF. Se o serviço end levanta qualquer excepção inesperada que não é um tipo de FaultException ou as alterações de configurar, serviço de encaminhamento de WCF não poderá encaminhar os pedidos subsequentes para o serviço de fim.
Quando este problema ocorre, recebe a seguinte excepção:
System.ServiceModel.ProtocolException: Este canal já não pode ser utilizado para enviar mensagens porque a sessão de saída foi fechada automaticamente devido a um encerramento iniciado pelo servidor. Desactive o fecho automático, definindo o AutomaticInputSessionShutdown para false ou considere modificar o protocolo de encerramento com o servidor remoto.
Informações de rastreio de pilha:
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)
Problema 3
Esta é uma actualização para suportar o novo símbolo de Lari Georgiano. País da Geórgia tenha introduzido um novo símbolo de moeda para o Lari, mas não é alterado o nome de moeda. Também foi adicionado o novo símbolo de moeda para o padrão Unicode. Esta actualização efectua-se de que o símbolo monetário correcto é apresentado pelo .NET Framework com base nas definições de região do sistema.
Problema 4
Se ocorrer uma colecção de Gen2 durante as chamadas de Parallel.ForEach , poderá detectar longa deixa de responder depois de instalar o Visual Studio 2015 ou a 4.6. .NET Framework sem o Visual Studio.
Resolução:
Estas actualizações de actualização recolector de lixo, resolvendo o sistema bloqueia causadas por este problema.
Problema 5
Depois de instalar o 4.6. .NET Framework, os métodos de Data Time.Parse e Date.TryParse não funcionam correctamente. Este problema poderá ocorrer com as seguintes definições de idioma:
-
fi-FI
-
NB-NO
-
NB SJ
-
SR-Cyrl-XK
-
SR-Latn-ME
-
SR-Latn-r
-
sr-Latn-XK
Resolução:
Esta actualização permite DateTime.Parse e Date.TryParse para funcionar correctamente nas culturas que estão a utilizar a mesma data e o separador de hora.
Problema 6
Depois de instalar o 4.6. .NET Framework, 4.6 de Framework .NET utiliza um novo compilador de 64 bits que é designado por RyuJIT. Em alguns casos, o novo compilador gera código incorrecto que faz com que o comportamento imprevisível ou falha.
Resolução:
Esta actualização corrige vários problemas no compilador de RyuJIT. Se a aplicação ainda um comportamento imprevisível depois da instalação desta actualização, consulte adicionais directrizes de resolução de problemas.
Passos adicionais:
Se for determinado que RyuJIT poderão participar o problema seguindo os passos de resolução de problemas na ligação, inicie o problema em http://connect.microsoft.com. Mais pormenorizada quanto possível no relatório e também a reproduzir o problema de código.
