This hotfix rollup is available for the following operating systems:
- Windows Server 2008 R2 Service Pack 1 (SP1)
- Windows Server 2008 Service Pack 2 (SP2)
- Windows 7 Service Pack 1 (SP1)
- Windows Vista SP2
Hotfix InformationA supported hotfix is now available from Microsoft. However, it is intended to correct only the problem that this article describes. Apply it only to systems that are experiencing this specific problem.
To resolve this problem, contact Microsoft Customer Support Services to obtain the hotfix. For a complete list of Microsoft Customer Support Services telephone numbers and information about support costs, visit the following Microsoft website:Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
PrerequisitesTo apply this hotfix, you must have the .NET Framework 4.5.2, the Microsoft .NET Framework 4.5.1, or the Microsoft .NET Framework 4.5 installed.
Restart requirementYou must restart the computer after you apply this hotfix if any affected files are being used. We recommend that you exit all the .NET Framework-based applications before you apply this hotfix.
Hotfix replacement informationThis hotfix package replaces the following previously released hotfix packages.
To work around this issue, use BeginInvoke to call Application.DoEvents() asynchronously after the timer event is processed. For example, use the following class to override the default behavior:
public class MyNumericUpDown : System.Windows.Forms.NumericUpDownNote Generally, we do not recommend that you reenter a message loop (Application.DoEvents) from a message handler (ValueChanged is raised from the Timer.OnTick message handler), because this could lead to stack overflow. For example, the range of the NumericUpDown control is large, and the user holds down the arrow button for a long time. Use BeginInvoke to avoid the stack overflow. This hotfix does not address this issue.
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.
BeginInvoke(new Action(() => base.OnValueChanged(e)));
Issue 12Copying formatted text from a long XPS document can take several minutes, depending on the position of the text within the document, and can cause the application to freeze.
This issue occurs because some formatting declarations require scanning the document from the beginning up to the desired selection. These declarations are rare (they come from custom elements that have a TextElementEditingBehaviorAttribute attribute that is not marked IsTypographicOnly).
The logic is changed in this hotfix to avoid the expensive scan when no such declarations appear in the desired selection.
A Windows Presentation Foundation (WPF) TextBlock may not display one or more characters at the end of its text. This issue occurs when the following conditions are true:
- TextWrapping or TextTrimming is enabled.
- Padding is nonzero, or TextFormattingMode is "Display."
- Width is not set, or is set to "Auto."
- The FontFamily, FontSize, and specific characters in the text lead to an unfavorable width.
This issue occurs because of numeric inaccuracies (a round-off error) that can occur while computing the width of the text, converting the width between internal coordinate systems, accounting for padding, and aligning the text to pixel boundaries for Display mode.
Protection against these kinds of inaccuracies has been added to the computations, to make sure that all the characters that should be displayed will be displayed.
Pinning objects can cause too much heap memory fragmentation, causing a decrease in performance. This fix provides more efficient reuse of memory buffers, which minimizes heap memory fragmentation.
Sometimes, an application can encounter an access violation exception during AppDomain shut down after a background Garbage Collection operation.
The diagnostic tools that do IL instrumentation by using profiling API can cause the following unhandled exception to be thrown by the common language runtime (CLR):
Additionally, the process crashes. This issue only occurs when you use diagnostic tools.
When you use the Windows Communication Foundation (WCF) 4.5 HttpMessageHandler extensibility point (also known as the WCF HTTP Pipeline), the WWW-Authenticate header cannot be set on HttpRequestMessage or HttpResponseMessage. This is because the new HttpMessageHandler extensibility point uses a different mechanism for handling headers.
After you apply this hotfix, the two mechanisms to add headers are brought to parity, and one should be able to add WWW-Authenticate headers again.
A NullReferenceException exception is thrown from the SqlInternalConnectionTds.BreakConnection method. This hotfix resolves the timing issue that leads to the NullReferenceException exception.
Assume that you have a WCF application that uses the BinaryMessageEncoder class, and the encoder uses a UTF-8 based text record per [MC-NBFX]. Or, assume that you have a WCF application that uses the System.ServiceModel.Channels.Message.CreateBufferedCopy method. A message is processed that contains characters in the range of U+10000 to U+10FFFF (inclusive) that are represented in UTF-8 as a 4-byte sequence. In this situation, the encoded binary message may be lost, and you receive the following error message:
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(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)
When this issue occurs, the client times out without a response if the WCF application is self-hosted. If the WCF application is web-hosted (ASP.NET), the client will receive a 500 server error.
CauseThis issue occurs because of an internal implementation detail that sometimes allocates insufficient space when 4-byte UTF-8 character sequences are decoded.
ResolutionTo resolve this issue, apply the hotfix. After you apply the hotfix, the WCF application will wait for the next
Read method to decode the characters if there is insufficient space in the output buffer to decode multibyte Unicode characters.
Issue 20.NET Framework applications that use serialization code may experience intermittent crashes.
Issue 21In Windows Communication Foundation (WCF) 4.5 or later versions, the mechanics of using the StreamBodyWriter.OnWriteBodyContents(XmlDictionaryWriter) API functionality was modified.
Previously, you had to make sure that the XmlDictionaryWriter passed in had already written the <Binary> tag prior to calling the OnWriteBodyContents method when you used this API.
In WCF 4.5.1 or later versions, the behavior was changed so that the <Binary> tag does not need to be written prior to calling StreamBodyWriter.OnWriteBodyContents(XmlDictionaryWriter). This is achieved by checking the state of the passed-in XmlDictionaryWriter. This means that anyone performing an upgrade from WCF 4.0 to WCF 4.5 or later versions and that has implemented a derived StreamBodyWriter based on the WCF 4.0 behavior may find that the body contents are no longer written at all.
After you install the hotfix, StreamBodyWriter behaves as follows:
- If the project's Target Framework is the .NET Framework 4.0, then the old behavior (manual write of <Binary> tag) will be used.
- If the project's Target Framework is the .NET Framework 4.5 or later versions, then the new behavior (automatic write of <Binary> tag) will be used.
SymptomsAn Entity Framework 5 model uses a QueryView to map one of the entity sets, and there is a 1 to 0..1 relationship between the entity set mapped by using the QueryView and a related entity set. When a query uses .Include() on the entity set to obtain the related entities through the QueryView, Entity Framework will generate a stack overflow exception.
The issue does not occur in Entity Framework 4.
Hotfix informationAfter you install this hotfix, the stack overflow exception is not thrown when you encounter the previously mentioned situation, and the query should work the same way it did in Entity Framework 4.
Issue 23Assume that you have a Microsoft Windows Presentation Foundation (WPF) application, and that one or more of the following is true:
- Another process (such as a handwriting recognizer or an assistive tool) is using Microsoft Text Services Framework (TSF) to query the screen position of text in your application.
- Such a query arrives at a time when there is pending layout work in your application.
- The text that is queried is changed by executing the pending layout work.
This issue depends on the relative timing of your application and the TSF client process. Therefore, it seems to be an intermittent or random failure.
This update prevents the exception from occurring, but instead returns an error to the TSF query when this situation occurs.
Article ID: 2974336 - Last Review: 16 Sep 2014 - Revision: 1