Hotfix rollup 2908385 is available for the .NET Framework 4.5.1 on Windows 8 and Windows Server 2012

Prerequisites

To apply this hotfix, you must have the .NET Framework 4.5.1 installed.

Restart requirement

You have to restart the computer after you apply this hotfix if any affected files are being used. We recommend that you close all .NET Framework-based applications before you apply this hotfix.

Hotfix replacement information

This hotfix package does not replace a previously released hotfix package.

Issue 1

Symptoms

Assume that you invoke the Application.DoEvents() method from the handler of the ValueChanged event of a NumericUpDown control. For example, you use the following code:private void numericUpDown1_ValueChanged(object sender, EventArgs e)
{
for (int i = 0; i < 10; i++)
{
Application.DoEvents();
Thread.Sleep(10);
}
} When the up or down arrow button is pressed for several seconds, the control creates a timer to generate repeated increments or decrements. In Application.DoEvents the timer tick is handled again. This causes a new ValueChanged event. Then, you reenter the timer tick event handler. When the mouse button is released, the timer is destroyed in the handler at the bottom of the stack, but then is reused again as the stack is being unwound by the other handlers. This causes a null reference exception and a crash.

Workaround

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.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);
}
} Note 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.

Issue 2

Symptoms

Copying 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.

Cause

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.

Issue 3

Symptoms

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.

Cause

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.

Issue 4

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.

Issue 5

Sometimes, an application can encounter an access violation exception during AppDomain shut down after a background Garbage Collection operation.

Issue 6

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.

Issue 7

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.

Issue 8

A NullReferenceException exception is thrown from the SqlInternalConnectionTds.BreakConnection method. This hotfix resolves the timing issue that leads to the NullReferenceException exception.

Issue 9

Symptoms

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()
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()
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.

Cause

This issue occurs because of an internal implementation detail that sometimes allocates insufficient space when 4-byte UTF-8 character sequences are decoded.

Resolution

To 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.