I denne artikel beskrives en hotfix-opdateringspakke, der er tilgængelig til Microsoft .NET Framework 4.6.1 og 4.6. Du kan finde flere oplysninger om de problemer, som denne hotfixopdatering løser, i afsnittet Problemer, som denne hotfixopdatering løser .
Løsning
Overførselsoplysninger
Det hotfix, der svarer til KB3139549, er blevet ændret med de seneste opdateringer af .NET Framework, som indeholder alle rettelser, der tidligere blev inkluderet i KB3139549. Det anbefales at installere de seneste opdateringer af .NET Framework.
Du kan finde flere oplysninger om, hvordan du henter Microsoft-supportfiler, ved at klikke på tallet i følgende artikel for at få vist artiklen i Microsoft Knowledge Base:
119591 Sådan får du Microsoft-supportfiler fra onlinetjenester, som Microsoft har scannet denne fil for virus. Microsoft brugte den nyeste antivirussoftware, der var tilgængelig på den dato, hvor filen blev publiceret. Filen er placeret på servere med udvidet sikkerhed, der bidrager til at forhindre uautoriserede ændringer af filen.
Flere oplysninger
Forudsætninger
For at anvende dette hotfix skal du have .NET Framework 4.6.1 eller .NET Framework 4.6 installeret.
Krav om genstart
Du skal genstarte computeren, når du har anvendt dette hotfix, hvis der bruges påvirkede filer. Vi anbefaler, at du afslutter alle .NET Framework-baserede programmer, før du anvender dette hotfix.
Oplysninger om udskiftning af hotfix
Denne hotfixpakke erstatter ikke en tidligere udgivet hotfixpakke.
Problemer, som denne opdateringspakke til hotfixet løser
Problem 1
Når et WPF-program bruger et TreeViewItem-element uden for TreeView-konteksten, kan programmet støde på en InvalidCastException-undtagelse, hvis staksporing starter, som følger:
System. Windows. Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Bemærk! Denne undtagelse opstår, når TreeViewItem-elementet er i et virtualiseret listekontrolelement (f.eks. et ListBox-, DataGrid- eller ListView-kontrolelement), der forsøger at finde rulleforskydningen af TreeViewItem eller en af dets programmer. Hvis du f.eks. erklærer et TreeViewItem som roden af en DataTemplate, og DataTemplate bruges som CellTemplate for en DataGrid-kolonne, sker denne undtagelse.
Problem 2
Både System.Web.Caching og System.Runtime.Caching rapporterer størrelsen på den hukommelse, der bruges af hele AppDomain i stedet for størrelsen af hukommelse, der bruges af cacheelementerne.
Dette er et regressionsproblem .NET Framework 4,5, hvor der er foretaget en ændring i implementeringen af Timer. Ud over at rapportere en forkert størrelse kan de ekstra objekter, der refereres til i cachen, påvirke Gen2-STØRSTE-ventetiden betydeligt. I ASP.NET hostingscenarier fejlberegner cachen også størrelsen af alle cacher i alle programdomæner (rapporteres via grænsen for cache % proceshukommelse brugt ASP.NET ydeevnetæller), når programdomæner genbruges.
Rettelsen fjerner utilsigtede referencer fra cachen til resten af appdomæneobjekterne, og derefter rapporteres den korrekte størrelse. Den indeholder også ændringer til at forbedre ventetiden for System.Runtime.Caching på kernecomputere, der bruger Server GC. Endelig beregner denne rettelse størrelsen på alle cacher i appdomænets genbrugsscenarier korrekt.
Problem 3
Når du har et Windows Presentation Foundation (WPF)-program, der afhænger af promovering til flytning af en mus for at kunne håndtere en touch flytte brugerinteraktion (i stedet for direkte ved hjælp af berøringshændelser), kan du opleve en usædvanlig lav lydstyrke af forfremmede musebevægelser.
Tidligere blev WPF-begrænseret musekampagne for touchbevægelser, fordi lydstyrken af touch flytter sig overvældende afsender. I .NET Framework 4.6.1 blev der foretaget en rettelse for denne funktionsmåde. Rettelsen begrænser antallet af berøringsbevægelser, der behandles. Begrænsningen af musekampagner medførte derfor en yderligere reduktion i antallet af musebevægelser, der blev genereret. I denne opdateringsopdatering er begrænsningen af musekampagner blevet fjernet, og der bør nu være tæt på en 1 til 1-korrespondance mellem touch move-hændelser og promoverede musemarkeringshændelser.
Problem 4
Antag, at du arbejder med et WPF-program, der .NET Framework 4.6. Antag f.eks., at du forsøger at indstille CurrentThread.CurrentCulture eller CurrentThread.CurrentUICulture i en hvilken som helst metode (f.eks. en BRUGERGRÆNSEFLADE-hændelseshandler eller MainWindow-konstruatoren), der er aktiveret af WPF Dispatcher ved hjælp af en DispatcherOperation. I denne situation nulstilles værdierne CurrentCulture og CurrentUICulture til deres respektive tidligere værdier i slutningen af metoden. Hvis et program indstiller CurrentUICulture i sin MainWindow-konstruator eller en Knapklikbehandler, vender denne indstilling tilbage til systemets brugergrænsefladekultur.
Denne løsning sikrer, at værdierne CurrentThread.CurrentCulture/CurrentUICulture, der kan angives i metoder i et WPF-program, bevares, som de gjorde før .NET Framework 4.6.
Problem 5
I .NET Framework 4.6 blev et nyt flag, TaskContinuationOptions.RunContinuationsAsynchronously, føjet til opgavebiblioteket. Men når du bruger dette flag sammen med Task.WhenAll, Task.WhenAny eller Task.Unwrap, har det ingen virkning. Flaget blev introduceret for at undgå visse fastlåste forhold. Denne løsning sikrer, at alle typer opgave fortsættelser overholder det nye flag.
Problem 6
AppContext er en del af infrastrukturen for at reducere de seneste ændringer. Du kan bruge AppContext til at angive og hente flag og træffe beslutninger i dit program, der er baseret på disse data. I .NET Framework 4.6 er der en fejl i AppContext, hvorad-sikkerhed for AppContext-metoderne er implementeret forkert.
Denne rettelse aktiverer korrekt trådsikkerhed for metoderne på AppContext, der er relateret til indstilling og hentning af parameterværdier.
Problem 7
Når du rammer en kantsag med din tildelings- og overlevelsesmønster, og du har brug for et nyt segment på din administrerede heap, beregner skraldespandsindsamleren muligvis en størrelse, der er mindre end den burde være. Dette medfører en adgangskrænkelse i løbet af den komprimerede fase, da skraldespandsindsamleren forsøger at skrive til ikke-allokeret hukommelse. Denne rettelse beregner størrelsen korrekt.
Problem 8
Når du opretter en lokal kode for visse metoder, kan .NET Framework-programmer og NGEN-processer gå ned.
Problem 9
RyuJit genererer forkerte instruktioner til sammenligning af 16-bit usignerede heltal i registre. Den frembringer forkerte resultater, hvis inputværdierne har forskellige MSB-værdier og derfor genererer sammenligningsinstruktioner, der kun bruger registrer operander. Denne rettelse genererer korrekte instruktioner.
