כדי להחיל את אוסף תיקונים חמים זה, לעבור למאמר knowledge base הבאים ולהוריד את אוסף תיקונים חמים הנכונה:
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 יקבע שעדכון ספציפי יפתור את הבעיה. דמי התמיכה המקובלים יחולו על נוספים שאלות וסוגיות תמיכה אשר אינן מצריכות העדכון הספציפי האמור.
דרישות מוקדמות
כדי להחיל תיקון חם זה, יש לך 4.5.1 מותקן .NET Framework.
דרישת הפעלה מחדש
עליך להפעיל מחדש את המחשב לאחר החלת תיקון חם זה, אם נעשה שימוש בכל הקבצים המושפעים. מומלץ לסגור את כל היישומים מבוססי .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 Foundation (WPF) עשוי להציג תו אחד או יותר לא בסוף הטקסט שלו. בעיה זו מתרחשת כאשר מתקיימים התנאים הבאים:
-
TextWrapping או TextTrimming זמינה.
-
ריפוד שאינו אפס, או TextFormattingMode "תצוגה".
-
רוחב אינו מוגדר, או מוגדר כ- "אוטומטי".
-
FontFamily, גודל הגופן ולאחר תווים ספציפיים בטקסט להוביל לרוחב unfavorable.
Cause
בעיה זו מתרחשת עקב מספרי אי דיוקים (עיגול שגיאת) עלולה להתרחש בעת מחשוב הרוחב של הטקסט, המרת הרוחב בין מערכות קואורדינטות פנימית, חשבונות עבור מרווח ויישור הטקסט לגבולות הפיקסל עבור מצב התצוגה.
הגנה מפני סוגים אלה של אי דיוקים נוספה חישובים, כדי לוודא כי כל התווים שיש להציג יוצג.
בעיה 4
הצמדת אובייקטים עלול לגרום יותר מדי פיצול זיכרון ערימה, גורם לירידה בביצועים. תיקון זה מספק חוזר יעיל יותר של מאגרי זיכרון, ממזער פיצול זיכרון ערימה.
בעיה 5
לעתים, יישום עשוי להיתקל חריג הפרת גישה במהלך AppDomain כבה לאחר רקע פעולת איסוף פסולת.
בעיה 6
כלי האבחון בהם לעשות מכשור IL באמצעות API ליצירת פרופילים עלולים לגרום את חריג שאינו מטופל הבאים להיות התריע על הריצה שפה (CLR) נפוצים:
0X80131401 "= SECURITY_E_INCOMPATIBLE_SHARE. טעינת הרכבה זו תפיק ערכת ממופעים אחרים מענק שונה.
בנוסף, התהליך קורס. בעיה זו מתרחשת רק בעת שימוש כלי אבחון.
בעיה 7
כאשר תשתמש את נקודת הרחבה HttpMessageHandler תקשורת Windows Foundation (WCF) 4.5 (המכונה גם צבר HTTP WCF), אין אפשרות להגדיר הכותרת לאמת WWW HttpRequestMessage או HttpResponseMessage. הסיבה לכך היא נקודת הרחבה HttpMessageHandler החדשה משתמשת מנגנון אחר לטיפול כותרות.
לאחר החלת תיקון חם זה, שני המנגנונים כדי להוסיף כותרות תובא זוגיות ולאחר אחד תהיה אפשרות להוסיף כותרות אימות WWW שוב.
בעיה 8
התרעה על חריגה NullReferenceException מפעולת השירות SqlInternalConnectionTds.BreakConnection . תיקון חם זה פותר את בעיית תזמון המובילה על החריגה NullReferenceException .
בעיה 9
מאפייני הבעיה
נניח כי יש לך יישום של WCF המשתמשת המחלקה BinaryMessageEncoder , ומשתמש המקודד רשומה 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.
