若要套用此 hotfix 彙總套件,請移至下列 「 知識庫 」 文件,並下載正確的 hotfix 彙總套件︰
2925383 Hotfix 彙總套件 2925383 適用於.NET Framework Windows 中的 4.5.1
簡介
本文說明的 hotfix 彙總套件 2908385 供 Microsoft.NET Framework 4.5.1。如需有關 hotfix 可以解決這個問題的詳細資訊,請參閱 < 其他資訊=""> 一節。
此 hotfix 彙總套件適用於下列作業系統︰-
Windows 8
-
Windows Server 2012
更多的資訊
Hotfix 資訊
已經可以從 Microsoft 取得支援的 hotfix。不過,其旨在修正本文所描述的問題。它只適用於發生此特定問題的系統上。
若要解決這個問題,請連絡 Microsoft 客戶支援服務 」 取得 hotfix。如需 Microsoft 客戶支援服務電話號碼以及支援費用的相關資訊的完整清單,請造訪下列 Microsoft 網站︰http://support.microsoft.com/contactus/?ws=support注意 在特殊的情況下,如果 Microsoft 支援專業人員認為某特定更新程式可以解決您的問題時,可能就不會收取一般因支援電話所產生的費用。收取支援費用會套用,如果有其他支援問題是,不能限定的特定更新程式。
先決條件
若要套用此 hotfix,您必須使用.NET Framework 安裝的 4.5.1。
重新啟動需求
您必須重新啟動電腦,如果任何受影響的檔案正在使用中,會套用此 hotfix 之後。我們建議您套用此 hotfix 之前,關閉所有的.NET Framework 應用程式。
Hotfix 取代資訊
此 hotfix 套件不會取代先前發行的 hotfix 套件。
此 hotfix 彙總套件可以解決的問題
問題 1
Symptoms
假設您叫用Application.DoEvents() 方法,從數值上下按鈕控制項的ValueChanged事件的處理常式。例如,您可以使用下列程式碼︰private void numericUpDown1_ValueChanged(object sender, EventArgs e){ for (int i = 0; i < 10; i++) { Application.DoEvents(); Thread.Sleep(10); } } 當向上或向下箭號按鈕被按下幾秒鐘,然後在控制項建立計時器以產生重複的遞增或遞減。Application.DoEvents是一次處理計時器刻度。這會導致新的ValueChanged事件。然後,重新輸入計時器的 tick 事件處理常式。當放開滑鼠按鈕後時,計時器會終結在底部的堆疊,處理常式,但然後會再次重複使用像堆疊是正在回溯由另一個處理常式。如此即 null 參考例外狀況並損毀。因應措施 若要解決這個問題,請使用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訊息處理常式引發的) 訊息處理常式,因為這可能導致堆疊溢位。例如,數值上下按鈕控制項的範圍很大,而使用者在一段長時間按住箭號按鈕。BeginInvoke可以用於避免堆疊溢位。此 hotfix 不能解決這個問題。
問題 2
狀況
長的 XPS 文件的複製格式化的文字會花費數分鐘,視文件中文字的位置而定,而且可能導致應用程式,若要凍結。
Cause 因為某些格式設定的宣告會需要掃描的文件,從開始到想要的選取範圍,就會發生這個問題。這些宣告是很少 (它們來自自訂的項目具有未標記為IsTypographicOnly的TextElementEditingBehaviorAttribute屬性)。 此 hotfix,以避免昂貴的掃描時沒有此類宣告出現在您想要的選取範圍變更的邏輯。問題 3
狀況
Windows Presentation Foundation (WPF) TextBlock 其文字的結尾,可能無法顯示一或多個字元。當下列情況成立時,就會發生這個問題︰
-
TextWrapping 或 TextTrimming 已啟用。
-
填補是非零值,或 TextFormattingMode"Display"。
-
寬度為未設定,或設為"Auto"。
-
FontFamily、 字型大小,以及文字中的特定字元會導致不適合的寬度。
Cause
之所以發生這個問題,是文字的因為數值錯誤對於 (無條件捨去的錯誤) 時計算,轉換內部的座標系統,與邊框距離,以及將文字的顯示模式的像素界限對齊帳戶處理之間的寬度寬度可能發生。 運算,請確定將顯示的所有字元,應該會都顯示已加入這類錯誤的防護。問題 4
Pin 物件可能會造成太多的堆積記憶體分散,導致效能降低。此修正程式會提供更有效率重複使用的記憶體緩衝區,以便有效減少堆積記憶體分散。
問題 5
有時候,應用程式可能會遇到存取違規例外狀況時關閉背景回收作業之後的 AppDomain。
問題 6
使用分析 API 來進行 IL 檢測的診斷工具可能會造成下列通用語言執行階段 (CLR) 擲回未處理的例外︰
0X80131401"= SECURITY_E_INCOMPATIBLE_SHARE。載入此組件會產生不同的授權集的其他執行個體。
此外,處理序當機。當您使用的診斷工具時,才會發生這個問題。
問題 7
當您使用 Windows 通訊基礎 (WCF) 4.5 HttpMessageHandler擴充性點 (也就是 WCF HTTP 管線) 時,則 WWW 驗證標頭無法設定在HttpRequestMessage或HttpResponseMessage。這是因為新的HttpMessageHandler擴充性點會用不同的機制來處理標頭。
您套用此 hotfix 之後,這兩個機制,以加入標頭就會被帶入同位檢查,而且其中一個應該能夠一次加入 WWW 驗證標頭。問題 8
從SqlInternalConnectionTds.BreakConnection方法,會擲回NullReferenceException例外狀況。此 hotfix 解決通往NullReferenceException例外狀況的計時問題。
問題 9
狀況[MC NBFX]。或者,假設您有一個使用System.ServiceModel.Channels.Message.CreateBufferedCopy方法的 WCF 應用程式。訊息處理包含 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 應用程式是 web 裝載 (ASP.NET),用戶端會收到 「 500 伺服器錯誤。
假設您有使用BinaryMessageEncoder類別中,WCF 應用程式,並且編碼器會使用 utf-8 基礎文字筆資料佔一原因
之所以發生這個問題,是因為 4 位元 utf-8 字元順序會解碼時,有時會配置空間不足的內部實作詳細資料。
解決方案
若要解決這個問題,請套用 hotfix。您套用此 hotfix 之後,WCF 應用程式會等候下一步
要解碼的字元,如果解碼多位元組的 Unicode 字元輸出緩衝區中沒有空間不足,無法讀取方法。