En este artículo se describe el paquete acumulativo de revisiones 3088956 que está disponible para Microsoft .NET Framework 4.6. Para obtener más información sobre los problemas que corrige el paquete acumulativo de revisiones, consulte la sección "Problemas que corrige este paquete acumulativo de revisiones".
Solución
Una revisión compatible ya está disponible en Microsoft. Sin embargo, su intención es corregir solo el problema que describe este artículo. Aplicarlo solo a los sistemas que experimentan este problema específico.Para solucionar este problema, ponte en contacto con los servicios de asistencia al cliente de Microsoft para obtener la revisión. Para obtener una lista completa de los números de teléfono de los servicios de asistencia al cliente de Microsoft e información sobre los costes de soporte técnico, visita el siguiente sitio web de Microsoft:
http://support.microsoft.com/contactus/?ws=supportNota En casos especiales, es posible que se cancelen los cargos habituales por las llamadas de soporte técnico si un Soporte técnico de Microsoft Profesional determina que una actualización específica solucionará el problema. Los costes de soporte técnico habituales se aplicarán a preguntas y problemas de soporte técnico adicionales que no reúnan los requisitos para la actualización específica en cuestión.
Más información
Requisitos previos
Para aplicar esta revisión, debes tener instalado .NET Framework 4.6.
Requisito de reinicio
Tiene que reiniciar el equipo después de aplicar esta revisión si se están usando los archivos afectados. Se recomienda cerrar todas las aplicaciones basadas en .NET Framework antes de aplicar esta revisión.
Información de la sustitución de revisión
Este paquete de revisiones no reemplaza un paquete de revisiones publicado anteriormente.
Problemas que corrige este paquete acumulativo de revisiones
Problema 1Si tienes un sitio web de ASP.NET que se ejecuta en una versión de 32 bits de la versión de .NET Framework 4.6 o AMD64 de la plataforma .NET Framework 4.6 con RyuJit deshabilitado, puede experimentar bloqueos w3wp debido a threadAbortException no controlada. Cuando se produzca el bloqueo, puede ver el siguiente registro de eventos de Windows:
Se produjo una excepción no controlada y se finalizó el proceso.Id. de aplicación: [ApplicationID]Id. de proceso: [ProcessID]Excepción: System.Threading.ThreadAbortExceptionMensaje: El subproceso se estaba anulando.StackTrace: en System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, Contexto HttpContext)en System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)en System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr rootObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData y marcas Int32)
Problema 2Suponga que tiene un cliente de WCF que se conecta al servicio WCF mediante el servicio de enrutamiento de WCF. Si el servicio final genera cualquier excepción inesperada que no sea un tipo de FaultException o la configuración de cambios, servicio de enrutamiento de WCF puede no redirigir las solicitudes posteriores al servicio final.Cuando se produzca este problema, recibirá la excepción siguiente:
System.ServiceModel.ProtocolException: Este canal ya no se puede usar para enviar mensajes ya que la sesión de salida se cerró automáticamente debido a un apagado iniciado por el servidor. Deshabilite el cierre automático estableciendo DispatchRuntime.AutomaticInputSessionShutdown en false o considere la posibilidad de modificar el protocolo de apagado con el servidor remoto.
Stack trace information: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(Acción de cadena, Boolean oneway, ProxyOperationRuntime operación, Object[] ins, timeSpan timeout, AsyncCallback callback, Object asyncState)at System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService(IMethodCallMessage methodCall, Operación ProxyOperationRuntime)en System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)en System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, tipo Int32) en System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(Message message, devolución de llamada de AsyncCallback, estado del objeto)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(elemento primario RoutingClientBase'1, Message requestMessage, transacción transaction, devolución de llamada AsyncCallback, estado de objeto) en System.ServiceModel.Routing.ClientFactory.RoutingClientBase'1.BeginOperation(Mensaje, transacción, devolución de llamada AsyncCallback, estado de objeto) en System.ServiceModel.Routing.ProcessRequestAsyncResult'1.StartProcessing()at System.ServiceModel.Routing.ProcessRequestAsyncResult'1..ctor(RoutingService service, Message, AsyncCallback callback, Object state)at System.ServiceModel.Routing.RoutingService.BeginProcessRequest[TContract](Message, AsyncCallback callback, Object state)at System.ServiceModel.Routing.RoutingService.System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(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) Issue 3Esta es una actualización para admitir el nuevo símbolo de Georgia Lari. El país de Georgia ha introducido un nuevo símbolo de moneda para el Lari, pero el nombre de la moneda no cambia. El nuevo símbolo de moneda también se ha agregado al estándar Unicode. Esta actualización garantiza que .NET Framework muestre el símbolo de moneda correcto en función de la configuración regional del sistema.Problema 4Si se produce una colección Gen2 durante las llamadas a Parallel.ForEach, es posible que experimente bloqueos largos después de instalar Visual Studio 2015 o .NET Framework 4.6 sin Visual Studio.Resolución:Esta actualización actualiza el recolector de elementos no utilizados resolviendo las inmovilizaciones del sistema causadas por este problema.Problema 5Después de instalar .NET Framework 4.6, los métodos DateTime.Parse y Date.TryParse no funcionan correctamente. Este problema puede ocurrir con la siguiente configuración de referencia cultural:
-
fi-FI
-
nb-NO
-
nb-SJ
-
sr-Cyrl-XK
-
sr-Latn-ME
-
sr-Latn-RS
-
sr-Latn-XK
Resolución:esta actualización permite que DateTime.Parse y Date.TryParse funcionen correctamente en referencias culturales que usan el mismo separador de fecha y hora.Problema 6Después de instalar .NET Framework 4.6, .NET Framework 4.6 usa un nuevo compilador de 64 bits denominado RyuJIT. En algunos casos, el nuevo compilador genera código incorrecto que provoca un comportamiento impredecible o bloqueos. Resolución:Esta actualización corrige muchos problemas en el compilador RyuJIT. Si la aplicación sigue comportando de forma impredecible después de la instalación de esta actualización, consulte instrucciones de solución de problemas detalladas adicionales.Pasos adicionales:Si se determina que RyuJIT puede estar involucrado en tu problema siguiendo los pasos de solución de problemas del vínculo, registra el problema en http://connect.microsoft.com. Incluye tantos detalles como sea posible en el informe y también código para reproducir el problema.
