Consider this stack trace:
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString, UriKind uriKind)
at MS.Internal.FontCache.FontSourceCollection.SetFontSources()
at MS.Internal.FontCache.FontSourceCollection.GetEnumerator()
at MS.Internal.FontCache.FamilyCollection.BuildFamilyList(List`1& familyList, SortedDictionary`2& familyNameList, SortedList`2& frequentStrings)
at MS.Internal.FontCache.FamilyCollection.MS.Internal.FontCache.IFontCacheElement.AddToCache(CheckedPointer newPointer, ElementCacher cacher)
at MS.Internal.FontCache.HashTable.Lookup(IFontCacheElement e, Boolean add)
at MS.Internal.FontCache.CacheManager.Lookup(IFontCacheElement e)
at System.Windows.Media.FontFamily.PreCreateDefaultFamilyCollection()
at System.Windows.Media.FontFamily..ctor()
This caused the following problem in a customer machine: no WPF application would start. Other .NET applications based on WinForms would start fine. Yet, a very simple WPF application sent to the customer, with just the default window created by the Visual Studio default project, would crash and present such stack trace.
Pinpointing the problem took a while: for some unknown reason, the customer had wrong entries in the registry keys that are used to build that “default font family” cache cited in the stack trace.
The customer was asked to export the entries under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts, and send the file to me. There were several font filenames strangely starting with dashes (---). These were fixed, and a registry file was sent back to the customer to import. After that, the application successfully started!
Note: There may also be the need of deleting your font cache, as per instructions in this link http://support.microsoft.com/kb/937135
Saturday, February 21, 2009
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment