Hotfix-3139549 für .NET Framework 4.6.1 und 4.6 in Windows

Problem 1

Wenn eine WPF-Anwendung ein TreeViewItem-Element außerhalb des TreeView-Kontexts verwendet, kann die Anwendung auf eine InvalidCastException-Ausnahme stoßen, deren Stapelüberwachung wie folgt beginnt:
 

Hinweis Diese Ausnahme tritt auf, wenn sich das TreeViewItem-Element in einem virtualisierten Listensteuerelement befindet (z. B. einem ListBox-, DataGrid- oder ListView-Steuerelement), das versucht, den Bildlaufoffset des TreeViewItem oder eines seiner Nachfolgerelemente zu finden. Wenn Sie z. B. ein TreeViewItem-Steuerelement als Stamm eines DataTemplate-Steuerelements deklarieren und DataTemplate als CellTemplate einer DataGrid-Spalte verwendet wird, tritt diese Ausnahme auf.
 

Problem 2

Sowohl System.Web.Caching als auch System.Runtime.Caching melden die Größe des von der gesamten AppDomain verwendeten Arbeitsspeichers anstelle des von den Cacheelementen verwendeten Arbeitsspeichers.

Dies ist ein Regressionsproblem aus .NET Framework 4.5, bei dem eine Änderung der Timerimplementierung vorgenommen wurde. Zusätzlich zur Meldung einer falschen Größe können sich die zusätzlichen Objekte, auf die der Cache verwiesen hat, erheblich auf die Gen2-GG-Latenz auswirken. In ASP.NET-Hostingszenarien berechnet der Cache auch die Größe aller Caches in allen Anwendungsdomänen falsch (dies wird über den Speichergrenzwert für den Cache % Prozess verwendet ASP.NET Leistungszähler) gemeldet, wenn Anwendungsdomänen wiederverwendet werden.

Der Fix entfernt unbeabsichtigte Verweise aus dem Cache auf die restlichen Domänenobjekte der App, und anschließend wird die richtige Größe gemeldet. Dies umfasst auch Änderungen zur Verbesserung der Latenz von System.Runtime.Caching auf Multi-Core-Computern, die Server GC verwenden. Mit diesem Fix wird schließlich die Größe aller Caches in Szenarien zum Wiederverwiederverwendung von App-Domänen richtig berechnet.
 

Problem 3

Wenn Sie über eine Windows Presentation Foundation-Anwendung (WPF) verfügen, bei der das Verschieben einer Maus zum Behandeln einer Benutzerinteraktion per Fingerbewegung (anstelle von direkten Touchereignissen) von der Promotion für eine Mausbewegung erforderlich ist, kann es zu einem ungewöhnlich geringen Volumen von heraufgestuften Mausbewegungen kommt. 

In der Vergangenheit hat WPF die Mausaktion für Fingerbewegungen gedrosselt, da die Lautstärke der Touchbewegung den Verteiler überfordert hat. In .NET Framework 4.6.1 wurde ein Fix für dieses Verhalten vorgenommen. Der Fix drosselt die Anzahl der verarbeiteten Fingerbewegungen. Daher führte die Einschränkung von Mausaktionen zu einer weiteren Verringerung der generierten Mausbewegungen. In diesem Updaterollup wurde die Einschränkung von Mausaktionen entfernt, und die Übereinstimmung zwischen Fingerbewegungsereignissen und Ereignissen für das Verschieben der Maus sollte nun fast eine Übereinstimmung von 1 bis 1 haben. 
 

Problem 4

Gehen Sie davon aus, dass Sie mit einer WPF-Anwendung arbeiten, die auf .NET Framework 4.6 festgelegt ist. Nehmen Sie beispielsweise an, dass Sie versuchen, "CurrentThread.Current Eine" oder "CurrentThread.CurrentUI Eine" in einer beliebigen Methode (z. B. einem UI-Ereignishandler oder dem MainWindow-Konstruktor) zu setzen, die vom WPF-Verteiler mit einem DispatcherOperation aufgerufen wird. In diesem Fall werden die Current Eine- und CurrentUI Eine-Werte auf ihre jeweiligen früheren Werte am Ende der -Methode zurückgesetzt. Wenn eine Anwendung "CurrentUIWiederherstellen" im MainWindow-Konstruktor oder einem Click-Handler für die Schaltfläche legt, wird diese Einstellung auf die System-UI-Kultur zurückgesetzt.

Mit diesem Fix wird sichergestellt, dass die CurrentThread.Current Eine/n-Methode Die Werte, die in Methoden in einer WPF-Anwendung festgelegt werden können, wie vor der Version .NET Framework 4.6 beibehalten werden.


 

Problem 5

In der .NET Framework 4.6 wurde der Aufgabenbibliothek das neue Kennzeichen TaskContinuationOptions.RunContinuationsAsynchronly hinzugefügt. Wenn Sie dieses Kennzeichen jedoch in Verbindung mit Task.WhenAll, Task.WhenAny oder Task.Unwrap verwenden, hat es keine Auswirkung. Das Kennzeichen wurde eingeführt, um bestimmte Sperren zu vermeiden. Mit diesem Fix wird sichergestellt, dass alle Typen von Aufgabenfortsetzungen das neue Kennzeichen respektieren.

Problem 6

"AppContext" ist Teil der -Infrastruktur zum Reduzieren von Änderungsänderungen. Mithilfe von AppContext können Sie Kennzeichen festlegen und abrufen und entscheidungen in Ihrer Anwendung treffen, die auf diesen Daten basieren. In .NET Framework 4.6 gibt es einen Fehler in AppContext, in dem die Thead-Safety der AppContext-Methoden falsch implementiert wurde. 

Dieser Fix ermöglicht die richtige Threadsicherheit für die Methoden in "AppContext", die mit dem Festlegen und Abrufen von Switchwerten verknüpft sind.

Problem 7

Wenn Sie mit Ihrem Zuteilungs- und Überlebensmuster auf einen Randfall treffen und ein neues Segment auf dem verwalteten Heap benötigen, berechnet der Garbage Collector möglicherweise eine Commit-Größe, die kleiner als erwartet ist. Dies führt zu einer Zugriffsverletzung während der Komprimierungsphase, da der Garbage Collector versucht, in nicht auskommentierten Speicher zu schreiben. Mit diesem Fix wird die Größe korrekt berechnet.

Problem 8

Wenn Sie systemeigenen Code für bestimmte Methoden erstellen, können die .NET Framework und NN-Prozesse abstürzen.

Problem 9

RyuJit generiert falsche Anweisungen zum Vergleichen von nicht signierten 16-Bit-Ganzzahlen in Registern. Es führt zu falschen Ergebnissen, wenn Eingabewerte unterschiedliche MSB-Werte haben und daher Vergleichsanweisungen generieren, die nur Registeropernden verwenden. Dieser Fix generiert korrekte Anweisungen.