In diesem Artikel wird das Hotfixrollup 3088956 beschrieben, das für Microsoft .NET Framework 4.6 verfügbar ist. Weitere Informationen zu den Problemen, die durch das Hotfixrollup behoben werden, finden Sie im Abschnitt "Probleme, die dieses Hotfixrollup behebt".
Lösung
Ein unterstützter Hotfix ist jetzt bei Microsoft verfügbar. Es soll jedoch nur das In diesem Artikel beschriebene Problem behoben werden. Wenden Sie sie nur auf Systeme an, bei denen dieses spezifische Problem auftritt.Um dieses Problem zu beheben, wenden Sie sich an den Microsoft-Kundendienst, um den Hotfix zu erhalten. Eine vollständige Liste der Telefonnummern von Microsoft Customer Support Services und Informationen zu Supportkosten finden Sie auf der folgenden Microsoft-Website:
http://support.microsoft.com/contactus/?ws=supportHinweis In besonderen Fällen können Gebühren, die normalerweise für Supportanrufe anfallen, storniert werden, wenn ein Microsoft-Support Professional feststellt, dass ihr Problem durch ein bestimmtes Update behoben wird. Die üblichen Supportkosten gelten für zusätzliche Supportfragen und Probleme, die nicht für das jeweilige Update in Frage kommen.
Weitere Informationen
Voraussetzungen
Um diesen Hotfix anwenden zu können, muss der .NET Framework 4.6 installiert sein.
Neustartanforderung
Sie müssen den Computer neu starten, nachdem Sie diesen Hotfix angewendet haben, wenn betroffene Dateien verwendet werden. Es wird empfohlen, alle .NET Framework-basierten Anwendungen zu schließen, bevor Sie diesen Hotfix anwenden.
Ersetzte Hotfixes
Dieses Hotfixpaket ersetzt kein zuvor veröffentlichtes Hotfixpaket.
Probleme, die mit diesem Hotfixrollup behoben werden
Problem 1Wenn Eine ASP.NET Website auf einer 32-Bit-Version der .NET Framework 4.6- oder AMD64-Version der .NET Framework 4.6-Plattform mit deaktiviertem RyuJit ausgeführt wird, kann es aufgrund von threadAbortException zu einem W3WP-Absturz kommt. Wenn der Absturz auftritt, wird das folgende Protokoll im Windows-Ereignisprotokoll angezeigt:
Es ist eine Ausnahme aufgetreten, die nicht behandelt wurde, und der Prozess wurde beendet.Anwendungs-ID: [ApplicationID]Prozess-ID: [ProcessID]Ausnahme: System.Threading.ThreadAbortExceptionMeldung: Thread wurde abgebrochen.StackTrace: at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtrrootObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtrrootObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
Problem 2Angenommen, Sie verfügen über einen WCF-Client, der mithilfe des WCF-Routingdiensts eine Verbindung mit dem WCF-Dienst herstellt. Wenn der Enddienst eine unerwartete Ausnahme auslöst, die keine Art von FaultException oder die Konfigurationsänderungen ist, leitet der WCF-Routingdienst nachfolgende Anforderungen möglicherweise nicht an den Enddienst weiter.Wenn dieses Problem auftritt, erhalten Sie die folgende Ausnahme:
System.ServiceModel.ProtocolException: Dieser Kanal kann nicht mehr zum Senden von Nachrichten verwendet werden, da die Ausgabesitzung aufgrund eines vom Server initiierten Herunterfahrens automatisch geschlossen wurde. Deaktivieren Sie entweder das automatische Schließen, indem Sie DispatchRuntime.AutomaticInputSessionShutdown auf false festlegen, oder erwägen Sie, das Herunterfahren-Protokoll mit dem Remoteserver zu ändern.
Informationen zur Stapelüberwachung:at System.ServiceModel.Channels.ServiceChannel.PrepareCall(ProxyOperationRuntime-Vorgang, 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-Vorgang)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, Nachrichtennachricht, AsyncCallback-Rückruf, Objektstatus)at System.ServiceModel.Routing.RoutingService.BeginProcessRequest[TContract](Nachrichtennachricht, AsyncCallback-Rückruf, Objektstatus)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) Issue 3This is an update to support the new Georgian Lari symbol. Das Land Georgien hat ein neues Währungssymbol für den Lari eingeführt, aber der Währungsname wird nicht geändert. Das neue Währungssymbol wurde auch dem Unicode-Standard hinzugefügt. Dieses Update stellt sicher, dass das richtige Währungssymbol vom .NET Framework basierend auf den Systemgebietsschemaeinstellungen angezeigt wird.Problem 4Wenn eine Gen2-Sammlung während Parallel.ForEach-Aufrufen auftritt, kann es nach der Installation von Visual Studio 2015 oder dem .NET Framework 4.6 ohne Visual Studio zu langen Hängen kommen.Lösung: Mit diesem Update wird der Garbage Collector aktualisiert, indem systembedingte Einfrierungen behoben werden.Problem 5Nach der Installation der .NET Framework 4.6 funktionieren die Methoden DateTime.Parse und Date.TryParse nicht ordnungsgemäß. Dieses Problem kann bei den folgenden Kultureinstellungen auftreten:
-
fi-FI
-
nb-NO
-
nb-SJ
-
sr-Cyrl-XK
-
sr-Latn-ME
-
sr-Latn-RS
-
sr-Latn-XK
Lösung: Mit diesem Update können DateTime.Parse und Date.TryParse in Kulturen, die dasselbe Datums- und Uhrzeittrennzeichen verwenden, ordnungsgemäß funktionieren.Problem 6Nach der Installation des .NET Framework 4.6 verwendet der .NET Framework 4.6 einen neuen 64-Bit-Compiler namens RyuJIT. In einigen Fällen generiert der neue Compiler falschen Code, der unvorhersehbares Verhalten oder Abstürze verursacht. Lösung: Dieses Update behebt viele Probleme im RyuJIT-Compiler. Wenn sich die Anwendung nach der Installation dieses Updates immer noch unvorhersehbar verhält, finden Sie weitere ausführliche Anleitungen zur Problembehandlung.Weitere Schritte: Wenn festgestellt wird, dass RyuJIT möglicherweise an Ihrem Problem beteiligt ist, indem Sie die Schritte zur Problembehandlung unter dem Link ausführen, protokollieren Sie das Problem unter http://connect.microsoft.com. Fügen Sie so viele Details wie möglich in den Bericht und code ein, um das Problem zu reproduzieren.
