За да приложите този пакет с актуални корекции, посетете следната статия от базата знания и изтеглите кумулативен правилната оперативна корекция:
2925383 2925383 сборния пакет за корекция е налична за .NET Framework 4.5.1 в Windows
Въведение
В тази статия спешна корекция сборни 2908385 за Microsoft .NET Framework 4.5.1. За повече информация за актуалната корекция отстранява проблем вижте раздела "Допълнителна информация".
Този пакет с актуална корекция е налична за следните операционни системи:
-
Windows 8
-
Windows Server 2012
Допълнителна информация
Информация за актуалната корекция
Вече се предлага от Microsoft предоставя поддържана актуална корекция. Но тя е предназначена да коригира само проблема, тази статия. Прилагайте корекцията само към системи, изпитващи този конкретен проблем.
За да разрешите този проблем, се обърнете към услугите за поддръжка на клиенти на Microsoft да получите актуалната корекция. За пълен списък на телефонните номера на отдела за поддръжка на Microsoft и информация за цените на поддръжката посетете следния уеб сайт на Microsoft:
http://support.microsoft.com/contactus/?ws=supportЗабележка: При специални случаи таксите, които са за свързани с поддръжката обаждания могат да бъдат отменени, ако специалист по поддръжката на Microsoft прецени, че конкретна актуализация може да разреши проблема. Обичайните такси за поддръжката ще важат за допълнителни въпроси и проблеми, които не спадат към съответната актуализация.
Необходими условия:
За да приложите тази актуална корекция, трябва да имате .NET Framework 4.5.1 инсталиран.
Изискване за рестартиране
Трябва да рестартирате компютъра, след като приложите тази актуална корекция, ако всички засегнати файлове се използват. Препоръчително е да затворите всички приложения, базирани на .NET Framework, преди да приложите тази актуална корекция.
Информация за заместване на актуалната корекция
Тази актуална корекция не замества издадените пакета.
Този пакет с актуални корекции решава проблеми
Проблем 1
Symptoms
Да предположим, че да извикате метода Application.DoEvents() от манипулатора на събитието ValueChanged на NumericUpDown контрола. Например можете да използвате следния код:private void numericUpDown1_ValueChanged(object sender, EventArgs e){
for (int i = 0; i < 10; i++)
{
Application.DoEvents();
Thread.Sleep(10);
}
}
При натискане на нагоре или надолу стрелка за няколко секунди, контролата създава таймер да генерира повторно стъпки или намалява. В Application.DoEvents таймер отметка се осъществява отново. Това води до ново ValueChanged събитие. След това да въведете таймер отбележете манипулатор на събитие. След публикуването на бутон на мишката време са разрушени в манипулатора на дъното на стека, но след това се използва повторно отново като стека е планове от други манипулатори. Това причинява изключение препратка и срив.
Заобикаляне на проблема
За да заобиколите този проблем, използвайте BeginInvoke за повикване ( Application.DoEvents) асинхронно, след като таймерът събитие се обработва. Например използвайте следния клас да промените поведението по подразбиране: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);
}
}
Забележка: По принцип не препоръчваме да въведете съобщение цикъл (Application.DoEvents) от съобщение манипулатор (ValueChanged е увеличен от Timer.OnTick съобщение на манипулатор), защото това може да доведе до препълване на стека. Например контролата NumericUpDown са големи и потребител притежава бутона със стрелка надолу дълго време. Използвайте BeginInvoke , за да избегнете препълване на стека. Тази актуална корекция не реши този проблем.
Проблем 2
Симптоми
Копиране на форматиран текст от дълги XPS документ може да отнеме няколко минути, в зависимост от текст в документа и може да предизвика приложението да застине.
Cause
Този проблем възниква, защото някои форматиране декларации изискват сканиране на документа от начало до желания избор. Тези декларации са редки (те идват от потребителски елементи, които имат TextElementEditingBehaviorAttribute атрибут, който не е маркиран IsTypographicOnly).
Логиката се променя в тази актуална корекция, за да се избегне скъпо сканиране при такива декларации са включени в избора на желаната.
Проблем 3
Симптоми
Текстов Windows представяне фондация (WPF) не може да показва един или повече знаци в края на текста. Този проблем възниква, когато са налице следните условия:
-
TextWrapping или TextTrimming е разрешена.
-
Подложка е ненулева или TextFormattingMode "Дисплей".
-
Ширината не е зададен или е зададено на "Автоматично".
-
FontFamily, FontSize и конкретни букви в текста води до неблагоприятно ширина.
Cause
Този проблем възниква поради числови неточности (кръг от грешка), които могат да възникнат при общуване ширината на текст, преобразуване разстоянието между вътрешните координати системи, подложка и подравняване на текст пиксел границите за режим на.
Защита срещу подобни неточности е добавен към изчисления, за да се уверите, че ще се покаже всички знаци, които трябва да бъдат показани.
Проблем 4
Закачване обекти може да доведе до твърде много свободна памет fragmentation, предизвиква намаляване на производителността. Тази корекция осигурява по-ефективно повторно използване на памет буфери, която намалява свободна памет фрагментиране.
Проблем 5
Понякога приложение може да възникне достъп нарушаване изключение по време на AppDomain изключване след фон операция за събиране на отпадъци.
Въпрос 6
Диагностични инструменти, които правят IL инструментите чрез профилиране API може да доведе до следните необработено изключение се хвърли от общата езикова среда (CLR):
0X80131401 "= SECURITY_E_INCOMPATIBLE_SHARE. Зареждане на това събрание ще доведе до различни помощ от други случаи.
Освен това процесът се срива. Този проблем възниква само когато използвате диагностични инструменти.
Брой 7
Когато използвате Windows комуникация фондация (WCF) 4.5 HttpMessageHandler точка на разширение (известна още като WCF HTTP канал), заглавката на WWW удостоверяване не се задава за HttpRequestMessage или HttpResponseMessage. Това е защото нова точка за разширяване на HttpMessageHandler използва различен механизъм за обработка на заглавки.
След като приложите тази актуална корекция, два механизма за добавяне на заглавки са въведени четност и един ще можете да добавите WWW удостоверяване заглавки отново.
Брой 8
NullReferenceException изключение от SqlInternalConnectionTds.BreakConnection метод. Тази актуална корекция отстранява проблем със синхронизацията, водещ до NullReferenceException изключение.
Проблем 9
Симптоми
Да предположим, че имате WCF приложение, което използва BinaryMessageEncoder клас и encoder използва UTF-8 на текстов запис на [[MC-NBFX]]. Или да приемем, че имате WCF приложение, което използва System.ServiceModel.Channels.Message.CreateBufferedCopy метод. Съобщение се обработва, която съдържа знаци в интервала от U + 10000 до U + 10FFFF (включително), които са представени в UTF-8 като поредица 4 байта. В тази ситуация кодирани двоични съобщение може да се загуби и получавате следното съобщение за грешка:
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()
Когато възникне този проблем, клиентът пъти без отговор ако приложението на WCF самостоятелно хоства. Ако приложението на WCF хоствани в мрежата (ASP.NET), клиентът ще получите грешка 500 сървър.
Причина
Този проблем възниква поради вътрешна изпълнението подробности, които понякога заделя достатъчно място, когато 4 байта UTF-8 характер поредици са декодиране.
Решение
За да разрешите този проблем, приложете актуалната корекция. След прилагането на актуалната корекция, WCF приложението ще изчакате следващата
Методът за четене за декодиране знаци, ако няма достатъчно място в изходящия буфер за декодиране многобайтови Unicode знаци.
