Hotfix rollup 3139550 para o .NET Framework 4.6.1 e 4.6 em Windows

Problema 1

Quando um aplicativo WPF usa um TreeViewItem fora do contexto de um TreeView, o aplicativo pode encontrar uma exceção InvalidCastException cujo rastreamento de pilha começa da seguinte forma:

Sistema. Windows. Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Observação Esta exceção ocorre quando o TreeViewItem está em um controle de lista virtualizado (por exemplo, um controle ListBox, DataGrid ou ListView) que tenta encontrar o deslocamento de rolagem do TreeViewItem ou um de seus descendentes. Por exemplo, essa exceção ocorrerá se você declarar um TreeViewItem como a raiz de um DataTemplate e DataTemplate for usado como CellTemplate de uma coluna DataGrid.


 

Problema 2

Both System.Web. Caching System.Runtime. Caching relatar o tamanho da memória usada pelo AppDomain inteiro em vez da memória usada pelos itens de cache.

Esta é uma regressão do .NET Framework 4.5 devido a uma alteração na implementação do Timer. Além de relatar o tamanho errado, os objetos adicionais referenciados pelo cache podem afetar significativamente a latência gen2 GC. Em ASP.NET cenários de hospedagem, o cache também calculou mal o tamanho de todos os caches em todos os domínios do aplicativo (conforme relatado por meio de um contador de desempenho "Cache % Process Memory Limit Used" ASP.NET) quando os domínios do aplicativo foram reciclados.

Essa correção remove referências não intencionais do cache para os outros objetos de domínio do aplicativo para que o tamanho correto seja relatado. Essa correção também inclui alterações para melhorar a latência para System.Runtime. Caching em computadores multi-core que estão usando o GC do Servidor. Além disso, após a aplicação dessa correção, o tamanho de todos os caches em cenários de reciclagem de domínio de aplicativos é calculado corretamente.


 

Problema 3

Quando você tem um aplicativo Windows Presentation Foundation (WPF) que depende da promoção do mouse de movimentações por toque para manipular a interação do usuário de toque (em vez de usar diretamente eventos de toque), você pode experimentar um volume incomummente baixo de movimentações de mouse promovidos.

Anteriormente, a promoção de movimento por toque do mouse com aceleração do WPF para evitar um grande volume de movimentações por toque sobrecarrega o despachante. No .NET Framework 4.6.1, uma correção foi introduzida para acelerar o número de movimentações por toque processadas. Após essa alteração, a diminuição das promoções do mouse causou uma redução adicional no número de movimentações do mouse geradas. A throttling of mouse promotions now is removed so that there should be almost a one-to-one correspondence between touch move events and promoted mouse move events.


 

Problema 4

Suponha que você esteja trabalhando em um aplicativo WPF destinado ao .NET Framework 4.6. Tente definir o valor CurrentThread.CurrentCulture ou CurrentThread.CurrentUICulture em qualquer método invocado pelo Dispatcher WPF usando um DispatcherOperation. Por exemplo, você tenta definir esse valor em um manipulador de eventos da interface do usuário ou no construtor MainWindow. Nessa situação, os valores CurrentCulture e CurrentUICulture são redefinidos para seus respectivos valores anteriores no final do método. Se um aplicativo definir CurrentUICulture em seu construtor MainWindow ou em um manipulador de clique de botão, essa configuração reverte para a cultura da interface do usuário do sistema.

Essa correção garante que os valores CurrentThread.CurrentCulture/CurrentUICulture definidos em métodos em um aplicativo WPF persistam da mesma maneira que antes do .NET Framework 4.6.


 

Problema 5

No .NET Framework 4.6, um novo sinalizador, TaskContinuationOptions.RunContinuationsAsynchronously, é adicionado à biblioteca de tarefas. No entanto, quando você usa esse sinalizador junto com Task.WhenAll, Task.WhenAny ou Task.Unwrap, o sinalizador não tem efeito. O sinalizador foi introduzido para evitar determinadas condições de bloqueio. Essa correção garante que todos os tipos de continuações de tarefas respeitem o novo sinalizador.


 

Problema 6

No .NET Framework 4.6, há um bug no AppContext que faz com que a segurança do thread dos métodos AppContext seja implementada incorretamente. AppContext faz parte da infraestrutura para reduzir alterações significativas. Você pode usar AppContext para definir e recuperar sinalizadores e tomar decisões em seu aplicativo com base nos dados.

Essa correção habilita a segurança correta do thread para os métodos no AppContext que estão relacionados à configuração e recuperação de valores da opção.


 

Problema 7

Quando você encontra uma caixa de borda que tem seu padrão de alocação e sobrevivência e exige um novo segmento em sua pilha gerenciada, um coletor de lixo pode calcular um tamanho de confirmações menor do que deveria. Isso causa uma violação de acesso durante a fase compacta porque o coletor de lixo está tentando gravar na memória não comprometida.

Essa correção calcula o tamanho corretamente.


 

Problema 8

Quando você cria código nativo para determinados métodos, os .NET Framework aplicativos e processos NGEN podem ter uma falha inesperada.

Problema 9

O RyuJit gera instruções incorretas para comparar inteiros não assinados de 16 bits em registros. Ele produz um resultado incorreto se os valores de entrada têm valores MSB diferentes e se comparar as instruções geradas usam os operands de registro.

Essa correção gera instruções corretas.
 

Aplicável a

Este artigo se aplica ao seguinte:
 

• Microsoft .NET Framework 4.6.1

• Microsoft .NET Framework 4.6, quando usado com:
   

  • Windows 8.1

  • Windows RT 8.1

  • Windows Server 2012 Datacenter R2

  • Windows Server 2012 R2 Essentials

  • Windows Server 2012 R2 para Sistemas Incorporados

  • Windows Server 2012 R2 Foundation

  • Windows Server 2012 R2 Standard