Set de remedieri rapide 3139551 pentru .NET Framework 4.6.1 și 4.6 pe Windows

Problema 1

Atunci când o aplicație WPF utilizează o TreeViewItem în afara contextului unei TreeView, aplicația poate întâlni o excepție InvalidCastException al cărui stivei începe după cum urmează:

System.Windows.Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Notă Această excepție apare atunci când TreeViewItem este într-un control listă virtualizate (de exemplu, o casetă listă, DataGridsau ListView control) care încearcă să găsească deplasarea defilare TreeViewItem sau unul dintre urmaşii săi. De exemplu, această excepție se produce dacă se declara o TreeViewItem ca rădăcină a unei DataTemplateși DataTemplate este utilizat ca CellTemplate o coloană DataGrid .

Problema 2

Atât System.Web.Caching și System.Runtime.Caching raport dimensiunea de memorie care este utilizat de întreaga AppDomain în loc de memorie care este utilizat de elemente de cache.

Aceasta este o regresie din .NET Framework 4.5 din cauza o modificare în implementarea cronometru. În plus faţă de raportare dimensiunea greșit, obiectele suplimentare care se face referire în memoria cache poate afecta semnificativ gen2 GC latență. În ASP.NET scenarii de găzduire, memoria cache gresit de, de asemenea, dimensiunea cache toate în toate domeniile de aplicație (după cum este raportat printr-un contor de performanţă "Cache % procesul de memorie limită folosit" ASP.NET) atunci când aplicația domenii au fost reciclate.

Această remediere elimină neintenţionat referințe din memoria cache pentru alte aplicații domeniu obiectele, astfel încât dimensiunea corectă este raportată. Această remediere include, de asemenea, modificări pentru a îmbunătăți latenţă pentru System.Runtime.Caching multi-core pe computerele pe care se utilizează Server GC. În plus, după ce se aplică această remediere, dimensiunea cache toate în domeniu app scenarii de reciclare este calculată corect.

Problema 3

Atunci când aveți o aplicație Windows Presentation Foundation (WPF) care se bazează pe promovarea mouse-ul de atingere mută să se ocupe de interacțiune cu utilizatorul atingere (în loc de direct prin atingere evenimente), este posibil să apară un volum neobişnuit scăzut de mutări promovat mouse-ul.

Anterior, WPF limitate promovare mouse-ul de atingere se mută pentru a evita un volum mare de atingere mută distruge expeditor. În .NET Framework 4.6.1, o remediere a fost introdus throttle numărul de atingere mută care sunt procesate. După această modificare, limitare de mouse promotii provocată de o reducere suplimentară a numărului de mouse-ul se mută care s-au generat. Limitare a mouse-ului promotii acum este eliminat, astfel încât ar trebui să existe aproape o corespondență unu-la-între evenimente de mutare touch și evenimente de mutare promovat mouse-ului.

Problema 4

Să presupunem că sunteţi de lucru pe o aplicație WPF 4.6 .NET Framework care are drept țintă. Încercați să setați valoarea CurrentThread.CurrentCulture sau CurrentThread.CurrentUICulture în orice metodă care este invocat de expeditor WPF utilizând o DispatcherOperation. De exemplu, încercați să setați această valoare într-o rutină de tratare evenimente UI sau MainWindow constructor. În această situație, valorile CurrentCulture și CurrentUICulture se reinițializează la valorile anterioare respective la finalul metodei. Dacă o aplicație setează CurrentUICulture sa MainWindow constructor sau o rutină de tratare, faceți clic pe butonul, această setare revine la sistemul UI culture.

Această remediere asigură CurrentThread.CurrentCulture/CurrentUICulture valorile care sunt setate în metode într-o aplicație de WPF persiste la fel ca înainte de .NET Framework 4.6.

Problema 5

În .NET Framework 4.6, se adaugă un semnalizator noi, TaskContinuationOptions.RunContinuationsAsynchronously, biblioteca de activitate . Cu toate acestea, atunci când utilizați această semnalizare împreună cu Task.WhenAll, Task.WhenAny sau Task.Unwrap, semnalizatorul nu are efect. Pavilion s-a introdus pentru a evita anumite condiții de blocare. Această remediere asigură că toate tipurile de activitate continuări respectă semnalizatorul noi.

Problema 6

În .NET Framework 4.6, există o problemă în AppContext care provoacă siguranța fir metodele AppContext să fie aplicate incorect. AppContext face parte din infrastructura pentru a reduce modificările recente. Utilizați AppContext setarea și regăsirea semnalizările și să ia decizii într-o aplicație pe aceste date.

Această remediere permite siguranța fir corectă pentru metodele pe AppContext asociate cu setarea și regăsirea parametru valori.

Problema 7

Când întâlniți un caz edge care are de alocare și model de supraviețuire și necesită un nou segment pe grămadă de gestionat, un colector deșeuri calcula o dimensiune de confirmare care este mai mic decât ar trebui să. Acest lucru provoacă o violare de acces în timpul fazei de compactare deoarece colector deșeuri încearcă să scrie în memoria nevalidate.

Această remediere calculează dimensiunea corect.

Problema 8

Atunci când creați cod nativ pentru anumite metode, .NET Framework aplicații și procese NGEN pot apărea o cădere neașteptată.

Problema 9

RyuJit generează incorecte instrucțiunile pentru a compara 16 biți nesemnate întregi registre. Generează un rezultat incorect dacă valorile de intrare au valori diferite MSB și instrucțiunile de comparare, care sunt generate utilizează registrul operatorii.

Această remediere generează instrucțiunile corectă.

Se aplică la

Acest articol se aplică următoarele:

• Microsoft .NET Framework 4.6.1

• Microsoft .NET Framework 4.6, când se utilizează cu:
  
  

  • Windows 7 Service Pack 1

  • Windows Server 2008 R2 Service Pack 1

  • Windows Server 2008 Service Pack 2

  • Windows Vista Service Pack 2