Pacote cumulativo de hotfixes 3139551 para o.NET Framework 4.6.1 e 4.6 no 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:

System.Windows.Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Observação: Essa exceção ocorre quando o TreeViewItem em um controle de lista virtualizado (por exemplo, um controle ListBox, DataGridou ListView ) que tenta encontrar o deslocamento da rolagem do TreeViewItem ou um de seus descendentes. Por exemplo, essa exceção ocorre se você declarar um TreeViewItem como raiz de um DataTemplatee o DataTemplate usado como CellTemplate de uma coluna DataGrid .

Problema 2

O tamanho da memória que é usado por todo o AppDomain, em vez de memória que é usada pelos itens de cache de relatório System.Web.Caching e System.Runtime.Caching .

Isso é 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 GC gen2. Em cenários de hospedagem de ASP.NET, o cache também calculados com erro o tamanho de todos os caches em todos os domínios de aplicativo (como foi relatado por meio de um contador de desempenho do ASP.NET "% de Cache usado de limite de memória do processo") quando os domínios de aplicativo foram reciclados.

Essa correção remove referências involuntárias do cache a outros objetos de domínio de aplicativo para que o tamanho correto é relatado. Essa correção também inclui alterações para melhorar a latência para System.Runtime.Caching em computadores de vários núcleos que estiver usando um servidor GC. Além disso, depois que essa correção for aplicada, o tamanho de todos os caches em cenários de reciclagem de domínio de aplicativo é calculado corretamente.

Problema 3

Quando você tiver um aplicativo do Windows Presentation Foundation (WPF) baseia-se na promoção de mouse de toque move para manipular a interação do usuário toque (em vez de diretamente usando toque eventos), você pode enfrentar um volume anormalmente baixo de movimentos do mouse promovida.

Anteriormente, promoção de mouse WPF acelerado de toque move para evitar a necessidade de que um grande volume de toque move sobrecarregar o dispatcher. 4.6.1 o.NET Framework, uma correção foi introduzida aos acelerador que o número de toque move que são processados. Após esta alteração a aceleração das promoções de mouse causadas uma redução adicional no número do mouse move que foram gerados. A aceleração das promoções de mouse é removida para que deve haver quase uma correspondência direta entre eventos de movimento do toque e eventos de movimento do mouse promovida.

Problema 4

Suponha que você esteja trabalhando em um aplicativo WPF que tem como alvo o.NET Framework 4.6. Você tenta definir o valor CurrentThread ou CurrentThread.CurrentUICulture em qualquer método que é chamado pelo Dispatcher WPF usando um DispatcherOperation. Por exemplo, tentar definir esse valor em um manipulador de eventos da interface do usuário ou o construtor de MainWindow. Nessa situação, os valores de CurrentCulture e CurrentUICulture são redefinidos para seus respectivos valores anteriores ao 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 será revertido para a cultura de interface do usuário do sistema.

Essa correção assegura que os valores de CurrentThread.CurrentCulture/CurrentUICulture são definidos nos métodos em um aplicativo WPF manter da mesma maneira como faziam antes do.NET Framework 4.6.

Problema 5

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

Problema 6

O.NET Framework 4.6, há um bug no AppContext que faz com que a segurança do thread dos AppContext métodos a serem implementados incorretamente. AppContext é parte da infra-estrutura para reduzir alterações significativas. Você pode usar AppContext para definir e recuperar sinalizadores e tomar decisões no seu aplicativo com base nesses dados.

Esta correção permite que a segurança do thread corretas para os métodos de AppContext relacionados à configuração e recuperar valores de switch.

Problema 7

Quando você encontrar um caso de borda que tenha sua alocação e padrão de sobrevivência e exigem um novo segmento em seu heap gerenciado, um coletor de lixo pode calcular um tamanho de confirmação é menor do que deveria. Isso causa uma violação de acesso durante a fase de compact, porque o coletor de lixo está tentando gravar em memória não confirmada.

Essa correção calcula o tamanho corretamente.

Problema 8

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

Problema 9

RyuJit gera instruções incorretas para comparar números inteiros sem sinal de 16 bits nas registradoras. Produz um resultado incorreto se valores de entrada têm diferentes valores MSB e comparar as instruções geradas usam operandos do registro.

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

Aplica-se a

Este artigo aplica-se ao seguinte:

• Microsoft.NET Framework 4.6.1

• Microsoft.NET Framework 4.6, quando usado com:
  
  

  • Windows 7 Service Pack 1

  • Windows Server 2008 R2 Service Pack 1

  • Windows Server 2008 Service Pack 2

  • Windows Vista Service Pack 2