Issues that this hotfix rollup resolves
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.
WorkaroundTo 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);
}
} 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
SymptomsA 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 4Pinning 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 5Sometimes, an application can encounter an access violation exception during AppDomain shut down after a background Garbage Collection operation.
Issue 6The 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):
0x80131401" = SECURITY_E_INCOMPATIBLE_SHARE. Loading this assembly would produce a different grant set from other instances.
Additionally, the process crashes. This issue only occurs when you use diagnostic tools.
Issue 7When 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 8A
NullReferenceException exception is thrown from the
SqlInternalConnectionTds.BreakConnection method. This hotfix resolves the timing issue that leads to the
NullReferenceException exception.
Issue 9SymptomsAssume 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.