Logga in med Microsoft
Logga in eller skapa ett konto.
Hej,
Välj ett annat konto.
Du har flera konton
Välj det konto som du vill logga in med.

Gå till följande knowledge base-artikel och hämta rätt snabbkorrigering om du vill använda det här snabbkorrigeringspaketet:

2925383 snabbkorrigering 2925383 finns för.NET Framework 4.5.1 i Windows

Introduktion

Den här artikeln beskrivs Samlad snabbkorrigering 2908385 som är tillgänglig för Microsoft.NET Framework 4.5.1. Mer information om snabbkorrigeringen löser problemet finns i avsnittet "Mer information".

Denna samlade snabbkorrigering är tillgänglig för följande operativsystem:

  • Windows 8

  • Windows Server 2012


Mer Information

Information om snabbkorrigeringen

En snabbkorrigering är nu tillgänglig från Microsoft. Den är emellertid avsedd att åtgärda det problem som beskrivs i den här artikeln. Använd den bara på datorer där detta problem uppstår.

Lös problemet genom att kontakta Microsoft support för att få snabbkorrigeringen. En fullständig lista över telefonnummer till Microsoft Customer Support Services och information om supportkostnader finns på följande Microsoft-webbplats:

http://support.microsoft.com/contactus/?ws=supportObs! I särskilda fall avbryts de avgifter som är normala för supportsamtal om en supporttekniker anser att en särskild uppdatering kan lösa ditt problem. De vanliga supportkostnaderna gäller för övriga supportfrågor och problem som inte berör den särskilda uppdateringen.

Förutsättningar

Om du vill installera den här snabbkorrigeringen måste du ha.NET Framework installerat 4.5.1.

Krav på omstart

Du måste starta om datorn när du har installerat den här snabbkorrigeringen om alla berörda filer används. Vi rekommenderar att du stänger alla.NET Framework-baserade program innan du installerar den här snabbkorrigeringen.

Ersättningsinformation för Hotfix

Det här snabbkorrigeringspaketet ersätter inte en tidigare utgiven snabbkorrigering.


Den här samlade uppdateringen löser problem

Problem 1

Symptoms

Anta att du anropar metoden Application.DoEvents() från hanterare av ValueChanged -händelse för en kontroll av NumericUpDown . Till exempel kan du använda följande kod:private void numericUpDown1_ValueChanged(object sender, EventArgs e){
for (int i = 0; i < 10; i++)
{
Application.DoEvents();
Thread.Sleep(10);
}
}
När den upp eller ned pilknappen trycks ned under flera sekunder, kontrollen skapar en timer för att generera upprepade steg eller minskningar. I Application.DoEvents hanteras timer tick igen. Detta medför att en ny ValueChanged -händelse. Sedan ange du timer tick-händelsehanteraren. När musknappen släpps timern förstörs på hanteraren längst ned i stapeln, men sedan återanvänds igen när stacken är att frigöras av andra hanterare. Detta medför ett null-referensundantag och en krasch.



Temporär lösning

Undvik det här problemet genom att använda BeginInvoke för att anropa Application.DoEvents() asynkront efter timer-händelsen bearbetas. Använd till exempel följande klass för att åsidosätta standardbeteendet: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! I allmänhet rekommenderar vi inte igen en meddelandeloop (Application.DoEvents) från en meddelandehantering (ValueChanged höjs från meddelandehantering Timer.OnTick ), eftersom detta kan leda till stackspill. Till exempel NumericUpDown -kontrollen är stor och användaren håller ned på pilknappen under lång tid. Använd BeginInvoke för att undvika stackspill. Den här snabbkorrigeringen åtgärdar inte problemet.

Problem 2

Symptom

Kopiera formaterad text från ett långt XPS-dokument kan ta flera minuter beroende på placeringen av texten i dokumentet och kan medföra att programmet låser.

Cause

Det här problemet uppstår eftersom vissa formatering deklarationer kräver skanna dokument från början fram till det önskade valet. Dessa förklaringar är sällsynta (de kommer från egna objekt som har ett TextElementEditingBehaviorAttribute -attribut som inte är markerad IsTypographicOnly).

Logiken har ändrats i den här snabbkorrigeringen för att undvika dyra genomsökningen när inga sådana deklarationer som visas i det önskade valet.

Problem 3

Symptom

En tecknens Windows Presentation Foundation (WPF) kanske inte visas ett eller flera tecken i slutet av texten. Det här problemet uppstår när följande villkor är uppfyllda:

  • TextWrapping eller TextTrimming är aktiverad.

  • Cellutfyllnad är skilt från noll eller TextFormattingMode "Visa".

  • Bredden är inte inställd eller är inställd på "Auto".

  • Leda till en negativ bredd FontFamily, teckenstorlek och särskilda tecken i texten.

Cause

Det här problemet uppstår på grund av numeriska felaktigheter (en runda av fel) som kan uppstå vid datoranvändning bredden på text, konvertera bredd mellan interna koordinatsystem, redovisning av utfyllnad och justerar text mot pixelgränserna för visningsläge.

Skydd mot dessa typer av felaktigheter har lagts till beräkningar, för att säkerställa att visas alla tecken som ska visas.

Problemet 4

Anslå objekt kan orsaka för mycket minne fragmentering av heap, orsakar en försämring av prestanda. Denna korrigeringsfil innehåller mer effektiv återanvändning av minnesbuffertar, vilket minimerar fragmentering av heap-minne.

Problemet 5

Ett program kan ibland uppstå ett åtkomstfel under AppDomain stängs efter en bakgrund skräpinsamling åtgärden.

Problemet 6

Diagnostikverktyg som gör IL instrumentation med hjälp av profilering API kan orsaka följande undantag av common language runtime (CLR) att:

0X80131401 "= SECURITY_E_INCOMPATIBLE_SHARE. Inläsning av den här sammansättningen skulle skapa en annan tilldelningsgrupp från andra instanser.


Dessutom kan kraschar processen. Det här problemet uppstår bara när du använder diagnosverktyg.

Problemet 7

När du använder Windows Communication Foundation (WCF) 4.5 HttpMessageHandler utökningsbarhet punkt (kallas även WCF HTTP rörledningen) kan WWW-Authenticate-huvud inte anges på HttpRequestMessage eller HttpResponseMessage. Detta beror på att den nya HttpMessageHandler utökningsbarhet punkten används en annan mekanism för hantering av huvuden.

När du har installerat den här snabbkorrigeringen kommer två mekanismer för att lägga till rubriker till paritet och en ska kunna lägga till WWW autentisera rubriker igen.

Problem 8

Ett NullReferenceException -undantag ges från metoden SqlInternalConnectionTds.BreakConnection . Den här snabbkorrigeringen löser problemet med tidsinställningen som leder till NullReferenceException -undantag.

Problemet 9

Symptom

Anta att du har ett WCF-program som använder klassen BinaryMessageEncoder och kodaren använder UTF-8-baserad textpost per [MC-NBFX]. Eller anta att du har ett WCF-program som använder metoden System.ServiceModel.Channels.Message.CreateBufferedCopy . Meddelandet bearbetas som innehåller tecken i intervallet U + 10000 till U + 10FFFF (partiell) som representeras i UTF-8 som ett 4-byte-ordning. I det här fallet kodade binära meddelanden kan gå förlorade och du får följande felmeddelande:

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 problemet uppstår klienten timeout utan svar om WCF-program är egenföretagare värd. Om WCF-program är webbaserat (ASP.NET), får klienten en 500 serverfel.

Orsak

Det här problemet uppstår på grund av ett internt genomförande detaljer som ibland allokerar tillräckligt utrymme när 4-byte UTF-8 teckensekvenser avkodas.

Lösning

Lös problemet genom att installera snabbkorrigeringen. När du har installerat snabbkorrigeringen väntar WCF-program på att nästa
Metoden Read att avkoda tecken om det inte finns tillräckligt med utrymme i utdatabufferten att avkoda multibyte Unicode-tecken.

Behöver du mer hjälp?

Vill du ha fler alternativ?

Utforska prenumerationsförmåner, bläddra bland utbildningskurser, lär dig hur du skyddar din enhet med mera.

Communities hjälper dig att ställa och svara på frågor, ge feedback och få råd från experter med rika kunskaper.

Hade du nytta av den här informationen?

Hur nöjd är du med språkkvaliteten?
Vad påverkade din upplevelse?
Genom att trycka på skicka, kommer din feedback att användas för att förbättra Microsofts produkter och tjänster. IT-administratören kan samla in denna data. Sekretesspolicy.

Tack för din feedback!

×