WPF Application Errors and .Net Framework Repairs

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

.net wpf prism .net-framework-version

Edit

Report

2 Answers

2

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.

answered 2012-07-26T12:50:41.253

0

We have had problems reminding of yours with our WPF application when connecting touch screens. This was due to a bug in the automation framework in .Net. It caused our application to either become very slow or entirely hang the GUI thread.

You can read more about the problem at: http://social.msdn.microsoft.com/Forums/en-IE/windowsaccessibilityandautomation/thread/6c4465e2-207c-4277-a67f-e0f55eff0110

The workaround suggested in the thread above where one removes any listeners of automation event periodically worked for us.

This is not a real answer but since I do not have enough rep? (I guess) I can't use the comment function :)

answered 2012-02-18T07:12:43.200

Your Answer