Hvis du vil bruke denne samleoppdateringen, kan du gå til følgende knowledge base-artikkel og laste ned riktig samleoppdateringen:
2925383 samleoppdateringen 2925383 er tilgjengelig for .NET Framework 4.5.1 i Windows
Introduksjon
Denne artikkelen beskriver samleoppdatering 2908385 som er tilgjengelig for Microsoft .NET Framework 4.5.1. Hvis du vil ha mer informasjon om som hurtigreparasjonen løser problemet, kan du se delen "Mer informasjon".
Denne samleoppdateringen er tilgjengelig for følgende operativsystemer:
-
Windows 8
-
Windows Server 2012
Hvis du vil ha mer informasjon
Informasjon om hurtigreparasjon
En støttet hurtigreparasjon er nå tilgjengelig fra Microsoft. Det er imidlertid ment å løse problemet som beskrives i denne artikkelen. Bruk den bare på systemer som har dette bestemte problemet.
Hvis du vil løse dette problemet, kontakter du Microsoft Kundestøtte for å få hurtigreparasjonen. For en fullstendig liste over telefonnumre for Microsofts kundestøttetjenester og informasjon om støttekostnader, kan du gå til følgende Microsoft-webområde:
http://support.microsoft.com/contactus/?ws=supportObs! I spesielle tilfeller kan avgifter som vanligvis påløper for oppringinger til kundestøtte avbrutt hvis en Microsoft-tekniker avgjør at en bestemt oppdatering løser problemet. Vanlige kundestøttekostnader gjelder for ytterligere kundestøttespørsmål og problemer som ikke dekkes av den gjeldende oppdateringen.
Forutsetninger
Hvis du vil bruke denne hurtigreparasjonen, må du ha .NET Framework installert 4.5.1.
Krav om omstart
Du må starte datamaskinen etter at du har installert denne hurtigreparasjonen, hvis alle berørte filer er i bruk. Vi anbefaler at du lukker alle .NET Framework-baserte programmer før du installerer denne hurtigreparasjonen.
Informasjon om erstatning av hurtigreparasjoner
Denne hurtigreparasjonspakken erstatter ikke tidligere utgitte-hurtigreparasjonspakken.
Problemene som samleoppdateringen løser
Problem 1
Symptoms
Anta at du starte Application.DoEvents()-metoden fra behandlingen av ValueChanged -hendelse for en kontroll for NumericUpDown . For eksempel kan du bruke følgende kode:private void numericUpDown1_ValueChanged(object sender, EventArgs e){
for (int i = 0; i < 10; i++)
{
Application.DoEvents();
Thread.Sleep(10);
}
}
Når den opp eller pil ned trykkes i flere sekunder, oppretter en tidtaker for å generere gjentatte intervaller eller reduserer for kontrollen. Tidtaker-tikk håndteres på nytt i Application.DoEvents . Dette fører til en ny hendelse for ValueChanged . Deretter angir du hendelsesbehandlingen tidtaker-tikk. Når du slipper museknappen, tidtakeren er ødelagt i handler nederst i stabelen, men deretter brukes på nytt igjen når stakken er blir nøstes ved de andre behandlere. Dette fører til et nullreferanseunntak og krasj.
Løsningen
Hvis du vil omgå dette problemet, kan du bruke BeginInvoke til å kalle Application.DoEvents() asynkront etter hendelsen timer er behandlet. Bruk for eksempel følgende klassen til å overstyre standard virkemåte:public class MyNumericUpDown : System.Windows.Forms.NumericUpDown{
public NumericUpDown() : base()
{
}
protected override void OnValueChanged(EventArgs e)
{
// run the handler as a separate event to prevent re-entrance to prevent a NullRef when hitting.
if (IsHandleCreated)
BeginInvoke(new Action(() => base.OnValueChanged(e)));
else
base.OnValueChanged(e);
}
}
Obs! Generelt anbefaler vi ikke at du angir en meldingsløkke (Application.DoEvents) fra en meldingshåndtereren (ValueChanged er hevet fra Timer.OnTick -meldingshåndtereren), fordi dette kan føre til stakkoverflyt. For eksempel NumericUpDown -kontrollen er stor, og brukeren holder pil ned i lang tid. Bruk BeginInvoke for å unngå stack-overflyt. Denne hurtigreparasjonen løser ikke problemet.
Problem 2
Symptomer
Kopiering av formatert tekst fra et langt dokument for XPS kan ta flere minutter, avhengig av plasseringen av teksten i dokumentet, og kan føre til at programmet å fryse.
Cause
Dette problemet oppstår fordi noen formatering deklarasjoner krever skanning av dokumenter fra begynnelsen til det aktuelle området. Disse deklarasjonene er sjeldne (de kommer fra egendefinerte elementer som har et TextElementEditingBehaviorAttribute -attributt som ikke er merket IsTypographicOnly).
Logikken er endret i denne hurtigreparasjonen for å unngå dyre skanningen når ingen slike oppgaver vises i det aktuelle området.
3-problem
Symptomer
En Windows Presentation Foundation (WPF) TextBlock vises kanskje ikke ett eller flere tegn på slutten av teksten. Dette problemet oppstår når følgende betingelser er oppfylt:
-
TextWrapping eller TextTrimming er aktivert.
-
Utfylling er null, eller TextFormattingMode er "Skjerm".
-
Bredde er ikke angitt eller er satt til "Auto".
-
FontFamily, FontSize og bestemte tegn i teksten føre til en unfavorable bredde.
Cause
Dette problemet oppstår på grunn av numeriske unøyaktigheter (en avrunding av feil) som kan oppstå under databehandling bredden på tekst, konvertere bredden mellom interne koordinaten-systemer, regnskap for utfylling og justere tekst til piksel grenser for visningsmodus.
Beskyttelse mot slike unøyaktigheter er lagt til i beregninger, må du kontrollere at alle tegn som skal vises, vises.
Problemet 4
Feste objekter kan forårsake for mye heap-minne fragmentering, forårsaker en nedgang i ytelsen. Denne løsningen gir mer effektiv gjenbruk av minnebuffere, noe som minsker heap-minne fragmentering.
Problemet 5
Et program kan noen ganger oppstå et access brudd på unntak under AppDomain avsluttes etter en bakgrunn Garbage Collection operation.
Problemet 6
Diagnoseverktøyene som gjør IL instrumentation ved hjelp av profilering API kan føre til følgende ubehandlet unntak å være forårsaket av common language runtime (CLR):
0X80131401 "= SECURITY_E_INCOMPATIBLE_SHARE. Innlasting av denne samlingen vil gi et annet tillatelsessett enn andre forekomster.
I tillegg krasjer prosessen. Dette problemet oppstår bare når du bruker diagnoseverktøy.
Problemet 7
Når du bruker Windows Communication Foundation (WCF) 4.5 HttpMessageHandler extensibility punktet (også kjent som WCF HTTP rørledningen), kan du ikke angi WWW-Authenticate-topptekst på HttpRequestMessage eller HttpResponseMessage. Dette er fordi det nye HttpMessageHandler extensibility punktet bruker en annen mekanisme for håndtering av overskrifter.
Når du har installert denne hurtigreparasjonen, de to mekanismene for å legge til meldingshoder hentes til paritet og én skal kunne legge til WWW-godkjenning meldingshoder på nytt.
Problemet 8
En NullReferenceException unntak fra SqlInternalConnectionTds.BreakConnection -metoden. Denne hurtigreparasjonen løser tidsberegningsproblem som fører til NullReferenceException -unntak.
Problemet 9
Symptomer
Anta at du har en WCF-program som bruker BinaryMessageEncoder -klassen og koderen bruker en UTF-8-basert tekst post per [MC-NBFX]. Eventuelt kan du anta at du har en WCF-program som bruker metoden System.ServiceModel.Channels.Message.CreateBufferedCopy . En melding blir behandlet som inneholder tegn i området med U + 10000 til U + 10FFFF (inkluderende) som er representert i UTF-8 som en sekvens med 4 byte. I dette tilfellet kodede binære meldingen går tapt, og du får følgende feilmelding:
System.ArgumentException: The output char buffer is too small to contain the decoded characters, encoding 'Unicode (UTF-8)' fallback 'System.Text.DecoderExceptionFallback'.Parameter name: chars
at System.Text.Encoding.ThrowCharsOverflow()
at System.Text.Encoding.ThrowCharsOverflow(DecoderNLS decoder, Boolean nothingDecoded)
at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, DecoderNLS baseDecoder)
at System.Text.DecoderNLS.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, Boolean flush)
at System.Text.DecoderNLS.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex, Boolean flush)
at System.Text.DecoderNLS.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex)
at System.Xml.ValueHandle.TryReadChars(Char[] chars, Int32 offset, Int32 count, Int32& actual)
at System.Xml.XmlBaseReader.ReadValueChunk(Char[] chars, Int32 offset, Int32 count)
at System.Xml.XmlBinaryWriter.WriteTextNode(XmlDictionaryReader reader, Boolean attribute)
at System.Xml.XmlDictionaryWriter.WriteNode(XmlDictionaryReader reader, Boolean defattr)
at System.ServiceModel.Channels.ReceivedMessage.OnWriteBodyContents(XmlDictionaryWriter writer)
at System.ServiceModel.Channels.Message.OnWriteMessage(XmlDictionaryWriter writer)
at System.ServiceModel.Channels.Message.OnCreateBufferedCopy(Int32 maxBufferSize, XmlDictionaryReaderQuotas quotas)
at System.ServiceModel.Channels.StreamedMessage.OnCreateBufferedCopy(Int32 maxBufferSize)
at System.ServiceModel.Channels.Message.CreateBufferedCopy(Int32 maxBufferSize)
at ConsoleApplication1.BufferRequestChannel.WrappingRequestContext.BufferMessage()
Når dette problemet oppstår, klienten tidsavbrudd uten et svar hvis WCF-applikasjonen er selvstendig vert. Hvis WCF-programmet er web-vert (ASP.NET), mottar klienten et 500 serverfeil.
Årsak
Dette problemet oppstår på grunn av en intern implementering detaljer som tildeler nok noen ganger når 4-bytes UTF-8 tegnsekvenser dekodes.
Oppløsning
Hvis du vil løse dette problemet, kan du bruke hurtigreparasjonen. Når du har installert hurtigreparasjonen, vente WCF-programmet til neste
Read -metoden til å dekode tegnene Hvis det ikke er nok plass i utdatabufferen til å dekode multibyte Unicode-tegn.
