WPF Application Errors and .Net Framework Repairs

Question

Background: I have a .Net 3.5 WPF "Prism"-based application running on Windows XP and Windows PosReady 2009 PCs. The app runs on PCs that are shut down every night (via a C# call to "shutdown.exe") and booted fresh in the morning (via Wake-on-LAN). The application is touch-based (using ELO touch screens), there are no mice or keyboards attached and the users do not have access to Windows.

Issue: We sporadically see issues where one of two things happens; either the application doesn't seem to load correctly and we see a blank white form showing, or it stops responding to touch. From looking in our (log4net) logs we can see that we are still handling the touch events and logging them out in both cases. Often this seems to occur when switching views and we also see in the logs where the Prism RegionManager is removing and adding views appropriately.

Troubleshooting: The application is running on approx ~100 PCs using images applied with Clonezilla and this occurs only sporadically. Since it isn't happening on all PCs and there are no exceptions logged or anything indicative of an issue in the Event Viewer we've resorted to more PC and OS level fixes. Specifically, we tried restarting the application and the PCs with occasional short-term success - meaning that sometimes the application will function correctly after these restarts, but only for a matter of hours at most. We've also worked under the assumption that the application has somehow been corrupted and we've removed and reinstalled it, without success.

The only thing that seems to resolve the issue is a repair of the .Net framework using the provided .Net 3.5 SP1 Installer package.

Conclusion: Since this seems to resolve the issue when nothing else does, it appears that we are somehow corrupting a GAC'd framework dll - either through code or the boot/shutdown procedures on the PC.

Questions: This leads to a number of questions:

• Any ideas on how we can further identify the source of the issue?
• Any ideas on what we can do to prevent this issue?
• Any ideas on what the underlying issue might be?

Thanks for any help.

Answer 1

We were finally able to get a hold of a production machine exhibiting this behavior and through a number of troubleshooting steps, including sending dump files to Microsoft, the issue was located.

The WPF Font Caching Windows service was occasionally getting into a corrupted state, causing a simple cache request to block indefinitely. This hang caused all of the behaviors described above in the our WPF application.

Simple solution: stop and disable the service. After disabling the service and rebooting the PC the service is no longer in use and we don't see any of these issues. In theory this leads to longer application load times, but we have seen zero negative impact.

Note that there are two versions of the service: 3.0.0.0 and 4.0.0.0. If your application is targeting .Net 3.0 or 3.5 you'll need to disable the 3 service, and if targeting 4.0+ you'll need to disable the 4 service.

Thanks to all for your comments and suggestions.