I am experiencing a problem at application startup from time to time on production machines. It doesn’t happen every time the application starts, and apparently it only happens on reboot. The application is started from login, added to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
Apparently, the problem is more frequent when resetting the machine, than during a reboot. Starting the application manually after it crashes is successful.
The following exception is thrown during startup:
Initialization of ‘System.Windows.Controls.TextBlock’ threw an exception.
System.Windows.Markup.XamlParseException: Initialization of ‘System.Windows.Controls.TextBlock’ threw an exception. —> System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it.
at System.Windows.Threading.Dispatcher.VerifyAccess()
at System.Windows.Style.Seal()
at System.Windows.StyleHelper.UpdateStyleCache(FrameworkElement fe,FrameworkContentElement fce, Style oldStyle, Style newStyle, Style& styleCache)
at System.Windows.FrameworkElement.OnStyleChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.FrameworkElement.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.Controls.TextBlock.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
at System.Windows.DependencyObject.InvalidateProperty(DependencyProperty dp)
at System.Windows.FrameworkElement.UpdateStyleProperty()
at System.Windows.FrameworkElement.OnInitialized(EventArgs e)
at System.Windows.FrameworkElement.TryFireInitialized()
at System.Windows.FrameworkElement.EndInit()
at MS.Internal.Xaml.Runtime.ClrObjectRuntime.InitializationGuard(XamlType xamlType, Object obj, Boolean begin)
— End of inner exception stack trace —
at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri)
at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri)
at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
at Exception.Occurs.At.Different.Origins.Between.Startup()
As seen from the StackTrace, there is something going on while updating style cache. I haven’t been able to reproduce this on my own computer. There are no threads involved here while starting the application, but there are a few AppDomains. The origin of the exception is not always the same, but it is exactly the same from Application.LoadComponent(Object component, Uri resourceLocator)
Because our application needs to find the configuration file from a different location than the executable (..\ProgramData….) depending on the OS, we use a separate AppDomain where we instruct it where to look for the configuration file, as we could not find any better solution of telling ConfigurationManager where to look for the file. It could of course, be related to this, though not necessarily. EDIT: ConfigurationManager.OpenMappedExeConfiguration Doesn’t seem to work, as it won’t refresh any user or application settings accessed through Properties.Settings.Default, etc.
Does anyone have any suggestions or recommendations on how to deal with this? Sorry I am not able to provide you with a sample to reproduce with.
Getting rid of the extra AppDomain used to specify configuration file, and replacing it with the method specified in this link took care of the problem.