My WPF application suddenly fails with the following exception:
System.IO.FileFormatException: No FontFamily element found in
FontFamilyCollection that matches current OS or greater: Windows7SP1
I've tried different OS but it's happening only on Windows 7 with SP1.
Microsoft released an official statement about this issue here (includes workarounds):
https://github.com/dotnet/announcements/issues/53
I've found out that the exception is connected to the latest security update KB4055532. When this update is uninstalled on Windows 7 SP1 then the problem disappear.
Since I'm not allowed to comment:
Answer by 'user2250152' is correct.
#Comment by #Lieven Keersmaekers:
'fwiw - installing KB4056894 also triggers this exception when starting Powershell ISE':
I really doubt this.
I'm dealing with this 'KB4055532' issue for 2 days now on all in all 8 machines. But after having installed 'KB4056894' there were no issues with starting Powershell ISE.
This only started to happen after installing 'KB4055532'.
And uninstalling this 'KB4055532' (but still having 'KB4056894' on the machines) resolves the issue with Powershell.
Btw:
There is a hint on the following site (and a way to 'fix' the issue):
https://ngb.to/threads/32709-Microsoft-Patchday-Januar-2018-KB4055532-NET-Font-Probleme.
The issue comes from a '*.CompositeFont' file that gets replaced by the update and which is then missing information for Windows 7. This makes programs based on WPF using functions to determine FontFamily fail/crash.
Effectively I'm quite sure it is only the file 'GlobalUserInterface.CompositeFont' that must be exchanged to temporarily fix this issue.
I ran into this error with MarkdownPad2. With the information from .NET Framework January 2018 Rollup Known Issue KB4074906 - "TypeInitializationException" or "FileFormatException" error in WPF applications (thanks #Boris!), I used the manual repair option to download and replace the corrupted font (installed by Microsoft's update) and it solved the problem.
The exception looks like this:
The invocation of the constructor on type 'MarkdownPad2.UserControls.MarkdownEditor' that matches the specified binding constraints threw an exception.
---> System.TypeInitializationException: The type initializer for 'System.Windows.Media.Fonts' threw an exception.
---> System.IO.FileFormatException: No FontFamily element found in FontFamilyCollection that matches current OS or greater: Windows7SP1
Damaging a font during an upgrade seems like an inexcusable error. Apparently Microsoft agrees, as they closed the tech note with this comment:
All updates are extensively tested before they are provided to you. We are investigating the gap in our testing and will resolve that for our next release.
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
I want to optimize my code which is written in C but this error is always displayed “The Data Cannot be displayed,there is no viewpoint available for data ”, am working on windows XP and the profiler is update 2!
There must be some error cropping up which is causing the executable to not run properly which is causing this issue. In my case, it was not able to resolve path for a .a file.
This sounds like a bug during collection stage. It is likely that result directory is missing some data due to collection error. Try to update to latest update 15 and repeat your experiment. If issue is still there you may wan to contact support team for investigation http://software.intel.com/en-us/forums/intel-vtune-amplifier-xe-and-vtune-performance-analyzer. Also make sure you XP has latest Service Pack (3?) installed
Try putting the following code inside Load event handler for WinForms or Loaded for WPF.
Dim doc As New XmlDocument
Dim nsmgr As New XmlNamespaceManager(Nothing) 'this line throws an exception
Problem is that exception is not thrown, and stack corruption happens. It may have different side effects, depending on the IDE - see below.
Affected IDEs are: 2008, 2010 and 2012 (those I could test). 2010 resets stack state, and returns from sub/handler, like nothing happened (but without proceeding with other statements there). 2012 may warn a user about a failed application and an attempt to run in compatibility mode. Next time after that it runs the same as 2010. 2008 properly throws an exception, but only on default configuration (AnyCPU). Switching platform target to x86 makes the problem reappear in 2008 as well.
Affected frameworks are WinForms and WPF. Console apps and ASP.NET
seem to work fine. .NET v2.0-4.5.
Affected scope is only Load event so far.
Putting this code into a button makes it work.
Affected build
configuration = any. Tried on default Debug and Release.
Why I consider it a bug is because it can leave objects in an unstable state - they did not finish initializing, which is not an expected behavior. What's critical about it is that nobody will know it happened, as it does not throw an exception. Depending on your design, you may end up with incorrect data in your database, which in the worst case may lead to severe consequences.
Does anyone have a good explanation to why this may be happening and if there is a workaround?
The problem is caused by the wow64 emulation layer that comes into play when you target x86 platform on a x64 OS.
It swallows exceptions in the code that is responsible to fire the Load event.
Thus the debugger doesn't see the exception and cannot step in to handle the situation.
This article seems to document well what's happening there,
This previous answer from Hans Passant (to which goes all the credits and upvotes) explains possible workarounds.
My preferite one is to move everything out of Form_Load event and put the problematic code in the form constructor. (Of course I don't know if it is applicable in your case)
So I enabled this group policy and the first time I tried to compile my solution I get this error. The funny thing is that I only use cryptographic function in one place but what I am seeing this on is all my Silverlight ResourceDictionary files and WPF userControl files. Everything else seems to compile fine.
Why am I seeing the error on only xaml files where I do nothing with encryption? I know I can disable the FIPS group policy but I do want to support it. Any idea why specific XAML files are throwing this error during compile?
I know I'm a bit late to the game but I recently came across this problem and also figured out a solution. For the reasons stated by #mdutra above, this is why it doesn't work but interestingly, Visual Studio 2010 and 2012 have two different "fixes".
A Microsoft Connect post (that no longer exists) stated:
Visual Studio 2012 now builds C# projects in a separate process that runs msbuild. The entry you added to devenv.exe.config (that worked for VS 2010) won't be seen by this process. You should add <enforceFIPSPolicy enabled="false"/> directly above the </runtime> tag in the msbuild.exe.config file; typically found at C:\Windows\Microsoft.Net\Framework\v4.0.30319\msbuild.exe.config.
I also added it to the C:\Windows\Microsoft.Net\Framework64\v4.0.30319\msbuild.exe.config file as well since I didn't know which MSBuild I was using.
After some research I found this answer which makes sense:
WPF and FIPS
Here are the contents of the link just in case it is removed:
The following is the reply I got from the WPF XAML team:
We didn’t fix it because this issue was discovered days (June 2, 2008) before the release.
I still have the BBPack I didn’t checkin. Here is the comment from the code.
// The Federal Information Processing Standard mandates that
// MD5 is obsolete and not safe for cryptographic checksums.
// We are using it to coordinating source files for debugging
// not authenticating so MD5 use is OK here.
// But, on a OS with the FIPS compliant switch ON, the managed
// MD5CryptoServiceProvider Ctor will throw. So we can't use it.
//
// Currently we use a PInvoke wrapper to the Native layer;
// which still works, even on a FIPS compliant machine. A Better
// fix would be to move to the approved SHA checksums, but that
// will require co-ordination with VS and the Debugger groups etc.
The MSI builder and a few other tools also threw on a FIPS=1 machine.
So even we if we fixed our part (in 3.5sp1), the customer’s end-to-end solution was still broken.
General FIPS info:
http://support.microsoft.com/kb/811833/en-us
I had a problem in upgrading the Microsoft XML core for my application from msxml3.dll to msxml6.dll. I chnaged the vcproj, and the header file of mine to point to the msxml6 header and library file. I also changed the class id of msxml6 to create a document praser using CoCreateVariant() function.
During execution i found my application throws unexception handling and aborts. Then i debugged with Visual studio and found that getElementByTagName() function returns a null pointer while using the msxml6.dll library which in-turn further reference cause abort and it's working fine with msxml3.dll.
Is anyone know why this "unhandled exception" was there due to msxml6.dll? And How can i fix it?
Can you double check if the element has namespace? Probably this is because of the behavioral changes between MSXML3 and MSXML6 where MSXML6 is more compliant in terms of namespace. To fix this issue, you may want to use XPath instead.