Home > Posts > How to crash Visual Studio 2010 via (Silverlight) XAML recursion bug

How to crash Visual Studio 2010 via (Silverlight) XAML recursion bug

Following up on a note about Visual Studio 2010 crashing at my previous post, this is the XAML that crashes VS2010 when opened up in a Silverlight project:

<UserControl x:Class="SilverlightApplication1.MainPage"
  d:DesignHeight="300" d:DesignWidth="400">

       <Style x:Key="MyStyle" TargetType="StackPanel">
         <Setter Property="Margin" Value="0,5,0,5" />

  <Grid x:Name="LayoutRoot" Background="White">

      <Style TargetType="StackPanel">
         <Setter Property="Style" Value="{StaticResource MyStyle}" /> <!– THIS LINE CRASHES VISUAL STUDIO (EVEN WHEN YOU TRY TO TYPE IT IN) –>




This crashes VS2010 upon loading, because it tries to show the XAML page in the designer. I created that XAML in Notepad++ since when I was trying to type the problematic line (marked in the XAML above) it crashed VS2010 immediately before I managed to save.

BTW, you should use the XAML syntax I suggested at my previous post that uses Style inheritance instead (although it would be nice if you could do for any node <X CloneSource=…/> for any XAML node to copy its attributes and values from a same-typed node instance in some resource etc. instead of relying on the node supporting some mechanism like Style does with BasedOn [that is Style Inheritance]).

   <Style TargetType="StackPanel" BasedOn="{StaticResource MyStyle}" />


Speaking of crashes, VS2010 should be more clever and if it sees a certain file caused a crash (assuming it has info on file being loaded upon or just before crash), the next time of opening the solution it should warn the user against opening that file (to avoid a new crash that stops one from loading the solution).


Note that I tried to open up the XAML file standalone in Visual Studio and it says:

Style object is not allowed to affect the Style property of the object to which it applies.
   at System.Windows.Setter.Seal()
   at System.Windows.SetterBaseCollection.Seal()
   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.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.TreeWalkHelper.InvalidateOnTreeChange(FrameworkElement fe, FrameworkContentElement fce, DependencyObject parent, Boolean isAddOperation)
   at System.Windows.FrameworkElement.ChangeLogicalParent(DependencyObject newParent)
   at System.Windows.FrameworkElement.AddLogicalChild(Object child)
   at System.Windows.Controls.UIElementCollection.AddInternal(UIElement element)
   at System.Windows.Controls.UIElementCollection.Add(UIElement element)
   at System.Windows.Controls.UIElementCollection.System.Collections.IList.Add(Object value)
   at Microsoft.Expression.DesignModel.InstanceBuilders.ClrObjectInstanceBuilder.InstantiateChildren(IInstanceBuilderContext context, ViewNode viewNode, DocumentCompositeNode compositeNode, Boolean isNewInstance)

Probably it loads it into an implicit WPF project. So is this some issue with Silverlight 5 XAML loading only? And if so isn’t this a potential exploit against Silverlight apps/plugin (if they allow XAML to be passed to them that is)?

It would be interesting to fix the test solution manually to not try to load the XAML file at startup, then build it and run it to see if it crashes the Silverlight plugin, the web browser, or whatever other side-effects it causes that might be exploitable.

This issue has been submitted to Microsoft at https://connect.microsoft.com/VisualStudio/feedback/details/753211/xaml-editor-window-fails-with-catastrophic-failure-when-a-style-tries-to-set-style-property. I have attached a test Silverlight project there (should be available for download soon [takes a while] from issue details)

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: