Поточні виправлення 3139550 для .NET Framework 4.6.1 і 4.6 в Windows

Проблема 1

Коли WPF-програма використовує TreeViewItem поза контекстом TreeView, у програмі може виникати виняток InvalidCastException, чиї трасування стека починається таким чином:

"Система". Windows. Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Примітка. Цей виняток виникає, якщо елемент керування TreeViewItem розташовано в віртуалізованому елементі керування списком (наприклад, ListBox, DataGrid або ListView), який намагається знайти зсув прокручування TreeViewItem або елемента керування TreeViewItem чи одного з його спадання. Наприклад, цей виняток виникає, якщо ви оголошувати treeViewItem як корінь данихTemplate, а стовпець DataTemplate використовується як значення стовпця DataGrid.


 

Проблема 2

System.Web.Caching і System.Runtime.Caching повідомляють про розмір пам'яті, який використовується в цілому appDomain, а не пам'яті, яка використовується в елементах кеша.

Це регресія в .NET Framework 4,5 через зміни в упровадженні таймера. На додачу до неправильного розміру, додаткові об'єкти, на які посилається кеш, можуть суттєво вплинути на затримку gen2 GC. У ASP.NET сценаріях розміщення кеш також неправильно обчислював розмір усіх кешів у всіх доменах програм (як повідомляється під час використання граничної пам'яті кеша % процесу ASP.NET лічильника продуктивності) під час видалення доменів програм.

Це виправлення вилучає ненавмисні посилання з кеша до інших об'єктів домену програми, щоб повідомити про правильний розмір. Крім того, це виправлення містить зміни, які покращують затримку для System.Runtime.Caching на багатоядрних комп'ютерах, де використовується Server GC. Крім того, після застосування цього виправлення розмір усіх кешів у сценаріях видалення домену програми обчислюється правильно.


 

Проблема 3

Якщо у вас є програма Система подання графіки (WPF), яка просуває рухи сенсорного керування мишею, переміщується для обробки взаємодії користувача із сенсорним екраном (а не безпосередньо за допомогою сенсорних подій), може виникати дуже низька гучність підвищеного рівня руху миші.

Раніше рухається дроселяція миші WPF, що дроселюється, щоб запобігти надмірній об'ємі сенсорного керування. У .NET Framework версії 4.6.1 упроваджено виправлення, яке реагує на кількість оброблених рухів дотиків. Після цієї зміни збільшення кількості промоакцій миші призвело до додаткового зменшення кількості створених переміщень миші. Тепер правила підвищення якості миші видаляються, тому між подіями сенсорного переміщення та підвищеними подіями переміщення мишею має бути майже одноразово.


 

Проблема 4

Припустімо, що ви працюєте у WPF-програмі, яка орієнтує .NET Framework 4.6. Ви намагаєтеся встановити значення CurrentThread.CurrentCulture або CurrentThread.CurrentUICulture будь-яким методом, викликаним dispatcher WPF за допомогою DispatcherOperation. Наприклад, ви намагаєтеся встановити це значення в обробнику подій інтерфейсу користувача або конструкторі MainWindow. У такому випадку значення CurrentCulture і CurrentUICulture скидаються до попередніх значень наприкінці методу. Якщо програма призначає currentUICulture конструктору MainWindow або в обробнику кнопки, цей параметр відновлюється до системної культури інтерфейсу користувача.

Це виправлення гарантує, що значення CurrentThread.CurrentCulture/CurrentUICulture, установлені в методах у програмі WPF, мають такий самий час, як раніше, ніж .NET Framework 4.6.


 

Проблема 5

У .NET Framework 4.6 нова позначка TaskContinuationOptions.RunContinuationsAsynchronously додається до бібліотеки завдань. Однак, якщо позначити цю позначку разом із полем Завдання.Коли Вся, Завдання.Коли Лишаються або Обходити завдання, позначка не діє. Позначка представлена, щоб уникнути певних крайніх умов. Це виправлення гарантує, що всі типи продовження завдань поважають нову позначку.


 

Проблема 6

У .NET Framework 4.6 в AppContext сталася помилка, через яку неправильно впроваджуються методи ланцюжка AppContext. AppContext – це частина інфраструктури, яка зменшує невиконання змін. За допомогою AppContext можна встановлювати й отримувати позначки, а також приймати рішення в програмі на основі даних.

Це виправлення забезпечує правильну безпеку потоків для методів у AppContext, пов'язаних із налаштуванням і отриманням значень перемикачів.


 

Проблема 7

Якщо ви стикнулися з краєм випадок, у якого є шаблон виділення та виживання, і вам потрібен новий сегмент у керованому розділі, збирач смітника смітника може обчислити розмір комбінату, розмір якого менший за нього. Це спричиняє порушення доступу на компактному етапі, тому що збирають смітник, який намагається записати в незахищену пам'ять.

Це виправлення правильно обчислює розмір.


 

Проблема 8

Якщо створити власний код для певних методів, програми .NET Framework та процеси NGEN можуть призвести до неочікуваного завершення роботи.

Проблема 9

Щоб порівняти 16-розрядні непідписані цілі числа в реєстрах, RyuJit створює неправильні інструкції. Він дає неправильний результат, якщо вхідні значення мають різні значення MSB, і якщо створені інструкції порівнюються за допомогою реєстраційних операндів.

Це виправлення генерує правильні інструкції.
 

Застосовується до

Ця стаття стосується таких користувачів:
 

• Microsoft .NET Framework 4.6.1

• Microsoft .NET Framework 4.6 у разі використання з:
   

  • Windows 8.1

  • Windows RT 8.1

  • Windows Server 2012 R2 Datacenter

  • Windows Server 2012 R2 Essentials

  • Windows Server 2012 R2 для вбудованих систем

  • Windows Server 2012 R2 Foundation

  • Windows Server 2012 R2 Standard