We've been experiencing intermittent crashes of our .NET 2.0 WinForm application in our testing environment (the UI is delivered to the test users via Citrix - as in production).
This is an app we've recently converted from .NET 1.1+EntLib 1.1 over to .NET 2.0 + EntLib3.1. We use pretty much all the App Blocks within EntLib and never experienced this problem with .NET 1.1+EntLib 1.1.
When the app crashes, the UI pops up the usual .NET message box indicating that an error had occured and that it would shut down, giving us the option to send error data back to MS. We were puzzled as to why this was happening when we had handlers for AppDomain.UnhandledException
and Application.ThreadException. We even added in the legacyUnhandledExceptionPolicy setting in the app.config to force .NET 1.1 unhandled exception behaviour. All this was to no avail - the app would keep crashing intermittently with very little diagnostic
information being logged to the event log by the .NET 2.0 runtime.
After hooking up WinDbg and a lot of investigation the exception looks to be caused by the ConfigurationChangeWatcher. See stack track below from WinDbg......
OS Thread Id: 0xc5c (0)
HelperMethodFrame: 0656f1a0 System.Threading.Thread.SleepInternal(Int32)
0656f1f4 057bd700 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.Storage.ConfigurationChangeWatcher.Poller(System.Object)
0656f210 79631fca System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
0656f218 793685af System.Threading.ExecutionContext.runTryCode(System.Object)
HelperMethodFrame_PROTECTOBJ: 0656f63c System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
0656f6a4 793684fb System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0656f6bc 793683ee System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0656f6d4 793d7ab2 System.Threading.ThreadHelper.ThreadStart(System.Object)
Looking through the EntLib code, the Poller function checks the config file's last write time and then sleeps for 15 seconds. We're assuming that some issue arises because this is occurring in a Citrix environment.
I've found one other person out there
http://www.winterdom.com/weblog/2006/09/30/StrangeCOMSCProblemWithThreads.aspx who was experiencing similar symptoms and solved it by not using EntLib anymore.
- Has anyone else experienced this problem out there? How have you solved it?
- What would be best way of turning off polling for config file changes?
Unfortunately you cannot turn off polling without modifying the source code.
I understand from your post that this problem does not occur when the application is used outside your Citrix environment. Can you please confirm this?
The analysis in the link you sent is very interesting. The conclusion there is that is not so much a problem with waiting but with the fact that several threads are launched, exhausting the resources. Did you observe the same behavior in your application?