locked
Memory Leak Issue with inline DataTemplates in Xaml

    Question

  • I have been trying to track down why some of the views in my Silverlight MVVM app are not being garbage collected and after a lot of testing it seems that having a DataTemplate inline in xaml prevents a usercontrol from being garbage collected.

    If you create 2 very simple silverlight user controls like the following

    Control A

        <Grid x:Name="LayoutRoot" Background="White">
            <Grid.Resources>
                <DataTemplate x:Key="DataTemplateResource">
                    <Border Height="100" Width="100" Background="blue">
                    </Border>
                </DataTemplate>
            </Grid.Resources>
            <ContentControl ContentTemplate="{StaticResource DataTemplateResource}" />
        </Grid>
    

    Control B 

        <Grid x:Name="LayoutRoot" Background="White">
            <ContentControl>
                <ContentControl.ContentTemplate>
                    <DataTemplate>
                        <Border Height="100" Width="100" Background="blue">
                        </Border>
                    </DataTemplate>
                </ContentControl.ContentTemplate>
            </ContentControl>
        </Grid>
    

    So the only difference between these controls is that in Control A the DataTemplate is a resource and in Control B it is inline.

    Now if you run the following code you can see that Control A will be garbage collected and Control B remains in memory. 

    WeakReference a = new WeakReference(new ControlA());
    WeakReference b = new WeakReference(new ControlB());
    
    GC.Collect();
    GC.WaitForPendingFinalizers();
    
    bool isControlAAlive = a.IsAlive;  // This is false
    bool isControlBAlive = b.IsAlive;  // This is true
    

    The only thing I can think of is that this must be a Silverlight bug causing a reference to be created inside the control to stop it being garbage collected. If so hopefully they can fix it soon or if not they could provide guidance on how to structure xaml to avoid these memory leaks.

    NOTE: This occurs on Silverlight 4 RC, seems to be fine in Silverlight 3.

    Tuesday, March 30, 2010 1:41 AM

All replies

  • This bug applies to inline Control Templates as well as Data Templates as you can see with this similar example

    Control A

        <Grid x:Name="LayoutRoot" Background="White">
            <Grid.Resources>
                <ControlTemplate x:Key="DataTemplateResource" TargetType="Button">
                    <Rectangle Width="100" Height="100" Fill="Green" />
                </ControlTemplate>
            </Grid.Resources>
            <Button Template="{StaticResource DataTemplateResource}" />
        </Grid>
    

    Control B

        <Grid x:Name="LayoutRoot" Background="White">
            <Button>
                <Button.Template>
                    <ControlTemplate TargetType="Button">
                        <Rectangle Width="100" Height="100" Fill="Green" />
                    </ControlTemplate>
                </Button.Template>
            </Button>
        </Grid>
    

    As with the first example the only difference is that with Control B the Control Template is inline instead of a resource and again Control B is not garbage collected while Control A is.

    This is an issue introduced in Silverlight 4. If you set the projects Target Silverlight Version to Silverlight 3 everything is garbage collected fine.

    Tuesday, March 30, 2010 6:28 AM
  • If anyone from the Microsoft Silverlight team are reading this it would be great to know if this will be fixed for the Silverlight 4 release. These memory leaks will make it impossible for us to release our app and since DataTemplates and ControlTemplates would be used in most applications this should be a high priority fix.

    Tuesday, March 30, 2010 8:55 PM
  • kornfish - running the code sample you have here in post-RC builds shows both reference returning false.
    Thursday, April 01, 2010 3:27 AM
  •  I have the same issues with my application,

    since I have upgraded to RC from beta, my silverlight app, showing a big leak problem

    since I know in fact, that my app doesn't leaked in silverlight 3.0 and  also in silverlight 4.0 beta

    I am suspecting that there is a problem in the GC, also I don't know if it is inline DataTemplate issue but it looks like a good explanation

    since I don't have any strong references to event handlers (I am implementing WeakEvent pattern all over my code)

    I have my self tried to pin down the problem, but with no success (until this post),

    the most annoying symptom of the leak, that it is continues after the page is refreshed (even call to GC.Collect() doesn't help),

    so the app is destroyed and reloaded, but the memory doesn't released, instead doubled each time (as it showed in the Task Manager, at the browser  process)

    after 3 refreshes, It is impossible to  work with the app, because it becoming very slow and not responsive (test on:  IE 7.0/IE8.0/Firefox 3.6)

    my suggestion,

    kornfish - please report this issue as you described to the Microsoft report bug at http://connect.microsoft.com

    Thursday, April 01, 2010 5:10 AM
  • Cheers Tim thats great news, can't wait for the final release.

    Tuesday, April 06, 2010 11:36 AM
  • Hi Tim,

       I just ran this code with the new Silverlight 4 release and the problem is still there. I created a brand new Silverlight Application in Visual Studio 2010 Premium targeting Silverlight 4 and the controls with an inline data template or control template are not being garbage collected. If I switch the target silverlight version over to Silverlight 3 the garbage collection works fine.

    This is causing major memory build ups in our app and these are such common scenarios that it must be affecting a lot of people.

    Friday, April 16, 2010 12:13 AM
  • We have the same trouble with our application in Silverlight 4.

    Replacing all of the tens inline datatemplates is unacceptably...

     

    Friday, April 16, 2010 3:20 AM
  • Also confirmed to still be leaking in SL4 RTW.  Moving an inline ControlTemplate to the Resources section fixed the leak.

    Now I have to start the task of changing and retesting a lot of other functionality that may have inline templates.  Combine this with the AmbiguousMatchException breaking my production SL3 app for end users, reliability so far of SL4 isn't looking good.

    Saturday, April 17, 2010 9:33 AM
  • Hey all, the behavior seems to have regressed from a previous build I was using.  I'm investigating with the team now, using this repro.

    Sunday, April 18, 2010 5:31 PM
  • Hi all, we're taking a look at this.  We've got some additional repros from others as well to add to our investigation.
    Monday, April 19, 2010 5:32 PM
  • I am also suffering due to this issue. I'm glad this thread exists explaining the exact cause, as I was unsure what was causing it in my app. It's pretty terrible, as memory starts to skyrocket quickly....
    Tuesday, April 20, 2010 12:14 PM
  • I have also this problem. I'm using Silverlight 4 (version 4.0.50401.0).

    In my case the DataTemplete is inside of DataGrid control:

     

                <data:DataGrid Grid.Row="0"
                           x:Name="grdDatos"
                           ItemsSource="{Binding ..., Mode=OneWay}"
                           AutoGenerateColumns="False">
                    <data:DataGrid.Columns>
    
                        <data:DataGridTemplateColumn Header="..."
                                                 SortMemberPath="..."
                                                 Width="255">
                            <data:DataGridTemplateColumn.CellTemplate>
                                <DataTemplate>
                                    <StackPanel Orientation="Vertical">
                                        <ToolTipService.ToolTip>
                                            <StackPanel Orientation="Vertical">
                                                <TextBlock Text="{Binding ..., Mode=OneWay}"/>
                                                <TextBlock Text="{Binding ..., Mode=OneWay}"/>
                                            </StackPanel>
                                        </ToolTipService.ToolTip>
                                        <TextBlock Text="{Binding ..., Mode=OneWay}"
                                               VerticalAlignment="Center"
                                               HorizontalAlignment="Left"
                                               TextAlignment="Left"/>
                                        <TextBlock Text="{Binding ..., Mode=OneWay}"
                                               VerticalAlignment="Center"
                                               HorizontalAlignment="Left"
                                               TextAlignment="Left"/>
                                    </StackPanel>
                                </DataTemplate>
                            </data:DataGridTemplateColumn.CellTemplate>
                        </data:DataGridTemplateColumn> 
      
    Thursday, April 22, 2010 9:23 AM
  • Hi Tim,

       Are there any updates on how this issue is progressing or when it might be fixed?

    Cheers

    Tuesday, April 27, 2010 3:42 AM
  • Also, the workaround doesn't work in all cases.  If your ControlTemplate contains a control whose Template property is set to some other static resource, it will still leak.  In this case, making your template inline actually seems to make the leak go away.

    For example, this will leak:

     

    1    <Grid.Resources>
    2 <ControlTemplate x:Key="MyContentTemplate"
    3 TargetType="ContentControl">
    4 <Grid>
    5 <TextBlock Text="Hello" />
    6 </Grid>
    7 </ControlTemplate>
    8
    9 <ControlTemplate x:Key="MyButtonTemplate"
    10 TargetType="Button">
    11 <Grid>
    12 <ContentControl Template="{StaticResource MyContentTemplate}" />
    13 </Grid>
    14 </ControlTemplate>
    15
    16 </Grid.Resources>

      But this will not:

      

    1    <Grid.Resources>
    2 <ControlTemplate x:Key="MyButtonTemplate"
    3 TargetType="Button">
    4 <Grid>
    5 <ContentControl>
    6 <ContentControl.Template>
    7 <ControlTemplate TargetType="ContentControl">
    8 <Grid>
    9 <TextBlock Text="Hello" />
    10 </Grid>
    11 </ControlTemplate>
    12 </ContentControl.Template>
    13 </ContentControl>
    14 </Grid>
    15 </ControlTemplate>
    16 </Grid.Resources>
     
    Wednesday, April 28, 2010 8:43 AM
  • I've also found that sometimes you can move the local template into app.xaml and then it will stop leaking.

    This leak is a huge problem for any SL app that is larger than a simple hello world app, and considering one of the themes of SL4 is LOB apps, I'm surprised a patch hasn't been released to fix this already.  My app easily now gets to 500MB-1GB RAM usage, where-as under SL3 it was no more than 50MB all the time.

    If a fix is only going to be released in August, then I'm afraid that the silverlight brand is going to be tarnished, up until now it has been a better and more performant alternative to flash, but to me SL4 is unusable in its current form.  Short of receiving official word within a few days that it's going to fixed real soon, we're abandoning our investment into silverlight and will go with the alternatives.

    Wednesday, April 28, 2010 8:47 PM
  •  There is another option actually, which we are considering.

     If you target your application toward Silverlight 3.0, then the leak does not occur at all, even if it's loaded by the SL4 runtime.  Obviously if you do this, you can't use any of the new stuff in SL4.

    Wednesday, April 28, 2010 8:57 PM
  •  Hi, are there guarantees that this problem will be solved in August?

    Thursday, April 29, 2010 4:18 AM
  • Additionally, I am seeing the items in memory that are leaking still responding to LayoutUpdated event. Is this correct?

    To illustrate this issue, please download the sample app I have created here: http://tinyurl.com/25qbyjx.

    Once you download it, run it in debug mode, and press the top button first a few times which will create some leaky user controls. Next, click the second button to remove them from the visual tree, and last press the 3rd button (garbage collect) just for good measure. The number displayed at the bottom is the number of leaky controls (just to indicate they are indeed stuck in memory). Now, put a breakpoint in the LayoutUpdated event handler, and re-size the browser. Your break point will still be hit.

    Thursday, April 29, 2010 11:44 AM
  • Hi tsheflin!

    I write a small post talking how to identify this bug on Silverlight code with WinDBG, I used your code sample if you don't mind :)

    http://www.luisguerrero.net/en/post/Detecting-memory-issues-with-Silverlight.aspx

    All the best.

    Luis Guerrero.

    Friday, April 30, 2010 2:06 PM
  • The memory leak information is printed on "Output" window. [ This advantage is in "Debug" mode only. ] Example int _tmain() { int* ptr = NULL; ptr = (int*)malloc(sizeof(int)*20); for( int i=0; iIdea = i; #ifndef NDEBUG int flag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG); // Get current flag flag |= _CRTDBG_LEAK_CHECK_DF; // Turn on leak-checking bit _CrtSetDbgFlag(flag); // Set flag to the new value #endif //free(ptr); printf("\n\nPress Enter..."); getch(); return 0; }
    Tuesday, May 04, 2010 5:46 AM
  • Hi all, thanks for being patient with us while we take a look at this.  We are evaluating a workaround in the interim which I've outlined below.  Our developers and testers have looked at this with a few but wanted to put our proposed workaround out there.  So far the workaround looks promising.

    It involves using a dependency property and attaching to your data template.  Here's an example (assuming this is on MainPage.xaml):

     

    1    public readonly static DependencyProperty TemplateWorkaroundProperty =
    2    	   DependencyProperty.RegisterAttached("TemplateWorkaround", typeof(Int32), typeof(MainPage), null);
    3    
    4    public static Int32 GetTemplateWorkaround(DependencyObject o)
    5    {
    6    	return (Int32)o.GetValue(TemplateWorkaroundProperty);
    7    }
    8    
    9    public static void SetTemplateWorkaround(DependencyObject o, Int32 value)
    10   {
    11   	o.SetValue(TemplateWorkaroundProperty, value);
    12   }
    

     and then in your XAML:

     

    1    <Grid x:Name="LayoutRoot" Background="White">
    2    		<ContentControl>
    3    			<ContentControl.ContentTemplate>
    4    			<DataTemplate local:MainPage.TemplateWorkaround="1">
    5    					<Border Height="100" Width="100" Background="blue">
    6    					</Border>
    7    				</DataTemplate>
    8    			</ContentControl.ContentTemplate>
    9    		</ContentControl>
    10   </Grid>
    
      As I mentioned, this is our current workaround we are evaluating.
    Wednesday, May 05, 2010 1:09 PM
  • Thanks Tim.  For me the workaround you suggest works for the simple case of moving the inline template to a resource, but found it didn't work for the case of nested templates (which is the hard one).  With a large app with many themed controls, it is a nightmare to figure out which nested templates are causing the leak, so that it can be moved around to and stop the leak.

     

    Thursday, May 06, 2010 11:31 AM
  •  Hi every body,

     

    We are working on a project, and we are facing this problem. leaked Memory is affecting the performance of our product, and this is very annoying to make our Clients to press F5 each time the memory is crowded.

    the project is a big one, I tried to track Memory with WinDBG, but i am getting the same result as mentioned in this post :

    http://www.luisguerrero.net/en/post/Detecting-memory-issues-with-Silverlight.aspx

    We are looking for correcting this issue from the Microsoft Team because other workarounds didn't worked for Us. 

    Friday, May 07, 2010 10:23 AM
  • hi  heuertk,

    the workaround that you proposed is working well for me, especially if  I'm forcing GC.Collect()

    but, I'm still facing a leak problem when the browser is refreshed (F5) or browsed from the page,

    when the browser is refreshed while the app is running, all the memory that was used by the app is remaining occupied,

    I have tried to call GC.Collect() on the App_OnExit event, but with no great results.

    so after the client is browsed through the site pages, with silverlight apps running on them, after a while,

    the browser is becoming non-responsive

    Saturday, May 08, 2010 2:28 AM
  • Hi Tim,  Thanks for looking in to the problem! I’m also having this exact issue, which in our system is easily identifiable in WinDbg. I will try your workaround and see how that goes. Look forward to a permanent solution. Thanks again.
    Sunday, May 16, 2010 2:04 AM
  • We have the same issue with SL4 compilation of our application. In SL4 bits UserControls are never GC..., in SL3 everything work fine !

    :(

    Tuesday, May 18, 2010 11:12 AM
  • Does the workaround apply to a datagridtemplatecolumn as well?  I'm finding memory usage goes up by 50% when the user scrolls from the first row of the datagrid to the last row (maybe a thousand rows and there is a datagrid in the datagrid) also I can't get the memory to release.

     

     

    Thursday, May 20, 2010 3:49 PM
  • It applies to any kind of templates that are inline, so it is possible that is the case.

    Thursday, May 20, 2010 8:15 PM
  •  Hi Tim,


    Thanks for posting the work-around. Is there any update on when we can see expect a release that resolves this bug?

    Wednesday, May 26, 2010 3:41 AM
  • Yes, an update would be helpful. This bug makes certain third-party controls (Telerik's) unusable because of the massive memory leaks they cause.By converting the DataTemplates in my datagrids to Resources and getting rid of binding to the Commands in my ViewModels (which is another bug that causes a View/ViewModel not to get garbage-collected), the page will get garbage collected. But if I add one Telerik ComboBox to the page, it's back to hanging in memory, due to the default control template in the Telerik controls. So, I'm back to using the standard Silverlight ComboBox for now.

    I'm wondering how many of these LOB apps shown in blog articles are being used in the real world, because this bug would kill most of them in 30 minutes unless you had 8 gigs of RAM.

    Thursday, May 27, 2010 9:47 AM
  • Any idea on when a more permanent solution might be made available?  This is causing MAJOR issues in our LOB application and we are in need of a resolution.  Please keep us posted as to any resolve that your team might find.

    Thanks,

    SMIMS

    Thursday, May 27, 2010 12:05 PM
  • Hopefully very soon..

    In addition, I have found another memory leak that is slightly harder to come by involving DependencyObjects using DependencyProperties with a default value. The thread can be found here: http://forums.silverlight.net/forums/t/184342.aspx. I hope this can also be fixed for the next Silverlight release.. which, again, is hopefully soon

    Thursday, May 27, 2010 12:11 PM
  • Apparently this issue was found sometime way back as detailed in the following link .. http://forums.silverlight.net/forums/p/77862/239489.aspx.  We tried the sample app posted here in both SL3 and SL4.  It worked in SL3 (so they fixed something between SL2 and SL3 if you read the post) but showed the memory leak in SL4.  This looks like the same problem we're all seeing here.  Funny, someone on the dev team did respond to this way back.  Maybe this can help Microsoft to resolve what's going on .. who knows.

    Regards,

    SMIMS

     

     

    Thursday, May 27, 2010 12:25 PM
  •  Is any body knows, if this bug also applies to ItemsPanelTemplate ?

    ItemsPanelTemplate doesn't inherits from DataTemplate, but instead from  FrameworkTemplate.

    so my question is, if the leak originating from the FrameworkTemplate which is the parent for all templates in silvelright

    or only from the DataTemplate ?

    Friday, May 28, 2010 11:03 AM
  • Yes, it applies to all templates

    Friday, May 28, 2010 10:09 PM
  •  Another memory leak found in SL4 (not related to templates): http://forums.silverlight.net/forums/t/179177.aspx

    This pretty much affects everyone, since even having a scollbar causes the leak.

    Monday, May 31, 2010 12:54 PM
  • I think we all need some guidance

    1 - use silverlight 3 and put up with the wcf service exceptions and script errors and lack of new features

    or

    2 - use silverlight 4 and watch the memory leaks crater the computer

    or

    3 - invest vast amounts of time, on top of the vast amounts of time already invested, taking the telerik controls out the grids, trying to find work arounds for all the other memory leaks posted.

    or

    4 - give up and move on WFP or Ruby or ...

    or

    5 - have Microsoft provide a fix for this crippling problem - if there is not going to be a fix then we need to know.  If there is going to be a fix we need an idea of when it will be available - if it's August it's August.  It's been 6 weeks.  Top kill, junk shot, whatever - the leaks all need to stop. 

    I don't know what to tell my customer apart from apologizing for  choosing this technology and pointing out that priority support in forums means nothing.  I can't be silent they know where I live.  I guess I'll have to move.

    Tuesday, June 01, 2010 4:10 PM
  • I definitely agree there needs to be better communication from Microsoft on where things are at with this issue so that we can make some decisions.

    We have invested pretty heavily in Silverlight as the technology for the next generation of our apps. Silverlight 4 seems to finally have all the pieces in place to meet our requirements but these memory leak issues are a deal breaker if they can't be resolved.

    The problems need to be fixed properly too, even if we were able to structure our xaml in a certain way to avoid some of the problems it makes our applications much too fragile. We have a team of 20 or so developers in multiple offices and our app will end up with hundreds of xaml files so its not practical to be manually checking all the xaml changes for possible memory leaks.

    Like estern says "if it's August it's August" but we need to know so we can make decisions for our projects.

    Tuesday, June 01, 2010 11:17 PM
  • estern - we aren't deaf on this issue.  As acknowledged by the team in this post we are aware of the issue, have provided some workarounds (that work for some users but not for all) and are investigating.

    All -- we believe we have a fix in place and our developers have looked at this and it is now in the test cycle along with other priority fixes for the runtime.  This will not be a one-off fix that we'll distribute.  It will be bundled with other fixes to maximize resources on all sides.  Right now I don't have an ETA I can provide on the fix being available as it has just been entered into testing.

    Tuesday, June 01, 2010 11:29 PM
  • Hello Tim,

    Yesterday there was Silverlight Update, as we can see in http://support.microsoft.com/kb/982926/pt . I didn't read anything about memory leaks there. Do you confirm that the bug has not been fixed?

    Best regards,

    MF.

    Friday, June 04, 2010 5:21 AM
  • Manuel - not he memory issue identified here is not addressed in the service release yesterday (3-Jun).  This DataTemplate issue was discovered after the servicing period for yesterday's release had already passed.  This issue will be addressed in the next servicing release cycle which is underway.
    Friday, June 04, 2010 9:35 AM
  • can Jessie Liberty's page switcher be added to the QA test plans (VB and C#) for this change?

    Also thanks for the info - I'm hearing August here so after I finish changing the application to reuse all the pages from a static cache, as there appears to be no way to remove a page from memory, then I'll rework the grids to not use Telerik controls to stop the gusher and then maybe I won't lose a customer I've had for 10 years and I can keep my house.  Good luck with your move.

     

     

    Monday, June 07, 2010 2:00 PM
  • would you still use Jesse's pattern given that navigation is a part of the core framework now?
    Monday, June 07, 2010 2:09 PM
  • I've been working on the same project since SL2 (which explains my desperation).  I considered upgrading to the navigation control but my understanding, from this thread http://forums.silverlight.net/forums/t/174870.aspx, is that it has the same problem.

     

    Monday, June 07, 2010 3:45 PM
  • I took your navigation sample project, upgraded to SL4, ran it, looked at memory with windbg - page memory is released but ...

    I have read that value converters cause leaks so I added a simple converter and datagrid - page memory is released but ...

    I added a wcf service reference - addhandler and removehandler - to the home page.  Run it, flip around the pages, run windbg - home page is in memory 7 times.

    I added

                GC.Collect()
                GC.WaitForPendingFinalizers()

    To the navigate event handler - no change

    Code sample is here (sorry you have to wait 20 seconds before you can download)

    http://www.4shared.com/get/313621284/c83fcbb1/NavigationSample.html;jsessionid=D8D5F789AA71FE091C8ED7D1B4B927E8.dc214

    I did not add an inline DataTemplate.  Having this sample project, with an inline datatemplate, in the QA test plans would be fantastic.

    The navigation control looks great and I'd like to use it.

    Saturday, June 12, 2010 10:45 AM
  • Our product is affected by the data template memory leak . Bump -- hoping MS releases a fix very soon.
    Thursday, June 17, 2010 9:46 PM
  •  This is a huge problem, and it is very disconcerting that it has not yet been fixed. Where is John Galt when you need him?

    Friday, June 18, 2010 12:48 AM
  • We are also experiencing this issue and has really got us behind.
    Thursday, June 24, 2010 11:04 AM
  • When Exactly the BugFix will be Released, because we have to deliver soon a product that experiment problems with this Issue,
    Thanks All,
    and looking for an urgent Reply.

    Thursday, June 24, 2010 12:24 PM
  • *exactly* depends on testing and security sign-offs. Servicing releases are expensive in time/resources to both microsoft, but more importantly our customers. So we bundle a bunch of fixes in one. We are in testing with this next servicing release now. The best response I can give right now is "summer" but I'm hopeful it is sooner than that. However I'd rather underpromise/overdeliver than give you something that will slip.
    Thursday, June 24, 2010 3:56 PM
  • is there any chance of getting a hotfix (even without a go-live license / but preferably with one).  It sounds like there are a lot of people who would like to help Microsoft test this fix. 

    Friday, July 02, 2010 9:37 AM
  • We actually have made it available to our early adopter program participants which represents a wide spectrum of customers.  By "testing" I meant our own internal testing as well as external partners already having existing agreements with pre-release versions of software.

    Friday, July 02, 2010 10:21 AM
  • How can I get a copy of this hot fix? We develop commercial controls and have customers reporting leaks. It would be great if we could test the fix and let customers know the issue has been (or will be) addressed by Microsoft.

    Thanks in advance.

    Wednesday, July 07, 2010 6:40 PM
  • The hotfix is not yet available.  As indicated the service release will be made public this summer.
    Wednesday, July 07, 2010 10:50 PM
  • I've reported a similar issue: https://connect.microsoft.com/VisualStudio/feedback/details/571681/elementname-leaks

    Can I expect the hotfix to solve this too?

    Thursday, July 08, 2010 10:50 AM
  • Hi All,

    We in RSA are also in a verdy deep dark hole as on the system for my customer they handle calls for vehicle recoveries and the system is built to save lives.

    Now with the memory issues and data templates since we went to SL 4 the application is not stable at all, luckaly so far, no one has been killed yet.

     

    Microsoft please get a fix released soon, this is a very Dangerous problem for us and a PR nightmare.

     

    Monday, July 12, 2010 4:10 AM
  • I seriously hope that was an ironic reply willeyburger.


    However, even though nobody is likely to get killed because our product crashes, it is still a big issue. If there isn't a solution soon we might seriously lose a lot of money and really regret choosing to use Silverlight for out bussiness application.

    Monday, July 12, 2010 5:53 AM
  • Unfortunatly this was not an ironic reply. In our application time is critical, should the application crash during a recovery time is lost to start it up again and log back in, this lost time can be fatal for a victim.

     

    Monday, July 12, 2010 6:04 AM
  • Hi Tim,

    Thanks for braving the waters here and responding to all of us. This is obviously a nasty little issue. One question for you..

    Does a list of all current memory leak problems with Silverlight 4 exist somewhere? If so, where might I find it?

    Thanks in advance,

    - Aaron

     


    Monday, July 12, 2010 1:59 PM
  • Unfortunately we don't have any public exposed bug list of sorts.

    The two primary mem leaks in some situations we are aware of are the ones spoken about here as well as some mouse capture situations.  Both of these we believe to be addressed in the forthcoming update.

    As to a status update on the service release: we hit a snag with some testing of other fixes and my hopes of 'sooner' aren't going to happen.  My original estimate here of this summer though is still on target.

    Monday, July 12, 2010 2:06 PM
  • Does this summer mean by the end of August?

    Friday, July 23, 2010 3:53 AM
  • I've found another related leak: https://connect.microsoft.com/VisualStudio/feedback/details/577710/unused-controltemplate-leak

    This time, the template isn't even used. 

    Friday, July 23, 2010 9:44 AM
  • I seriously hope this gets addressed soon.

    We  have an enterprise level silverlight application being released to clients in just about every country by the end of the year, and we cannot upgrade to SL4 (and all it's helpful LOB stuff) until this is sorted.

    Profiling our own memory / perf issues without SL4 hooks is also impossible, so the sooner the better.

     

    Tuesday, July 27, 2010 7:23 AM
  • Tim,

    Its been 4 months now since the many memory leak issues were seen,  experienced and reported. Silverlight 4 was released in such short time after Silverlight 3 (it was rushed and pushed out too quickly without thorough testing) and so, now its taking more than 4 months to fix memory leaks! Unbelievable!

    You owe your customers and loyal Silverlight users an exact date of when the "fix" (hopefully it will resolve all issues reported here and other posts in the forums) will be released. "Summer" is simply not good enough. Microsoft earns billions and surely has resources to fix these issues quicker than this... Silverlight is an important product and Microsoft cannot afford to lag and be late in everything it does.

    - A very concerned customer

    Wednesday, July 28, 2010 10:01 PM
  • There is a horrible memory leak issue with the Silverlight ChildWindow control. Memory is never released/garbage collected after the first use of this control. Is this also going to be fixed with the next service release of the Silverlight 4 runtime?

    Thursday, July 29, 2010 8:18 PM
  • valiant_sam: thanks for the post.  I can say I certainly wish that the money Microsoft makes is funnelled 100% into our team, but it is not :-).  Our team has resources we need to manage as well and try to do that with a balance of a release and service cadence that is optimal for everyone.  Inevitibly it isn't for customers with pain points that need things ASAP.  

    As I've explained above in the comments, we package many updates into one servicing release to maximize these resources.  While the memory leak noted here (DataTemplate) has been fixed, it is in the release cycle with other fixes we are working on and verifying in other parts of the framework as well.

    For ChildWindow, if you have a sample repro project indicating this, please feel free to send it my way and I can provide you with the results based on current builds or verify the issue you are identifying is accurate.

    Thursday, July 29, 2010 8:23 PM
  • Tim,

    Thanks for the reply but it still didn't answer your user's questions: When will the fix be released? It's been too long! How do you expect people to use Silverlight without basic functionality working properly?

    As for the ChildWindow memory leak issues - I will describe it as concisely as possible:

    1. Create a new Silverlight application using either the Navigation Template or the Business Template with RIA services. This provides you with an ErrorWindow child control/window.

    2. Create a few pages and add them to the navigation. Set the NavigationCacheMode to Enabled and set the cache size to 5 (it can be any number you want).

    3. Add some controls on the pages. Add a Button on one of the page and fire an event to invoke and show the ErrorWindow using:

    a) the Show() method and

    b) using the Create method provided in the RIA template

    Test with both templates and both ways of calling the error window.

    4. Run the app and browser through the pages (make sure you browse to enough pages so that 5 pages are cached) and observe the task manager process for your app.

    Until you hit the button that calls the ErrorWindow, everything is fine and garbage collection seems to work. Memory is reclaimed. As soon as the first error window is shown, the application's  memory issues start and memory will never be re-claimed again. The app will keep eating up more and more memory as the error window is shown again and again.

    Observed the above with good mid-sized applications (3 of them) with memory usage crossing the 100MB mark for over 30 mins in the task manager. I did not use any diagnostic tool as yet to get into more details... (time constraints!)

    Also - you can try making your own child control and observe the same.

    Friday, July 30, 2010 12:10 PM
  • Sorry for the many posts - but also wanted to clarify that I was showing those ErrorWindows to display error messages from web services on the server side. Observed the same memory issues using either - RIA or regular WCF based web services. However, I suspect it has nothing to do with RIA or WCF. It's the ChildWindow control that seems like the culprit. There are lot of articles/forum discussions online that talk about similar issue(s) with this control.

    Friday, July 30, 2010 12:29 PM
  • valiant_sam, I beg to differ -- facing the same issue whenever I use RIA's RefreshInterval.  Its not only the Child Window, but also controls refreshing that are leaking like a sieve all over the place.  DomainContext/DomainServices a possibility?  I eagerly await the next build and see if the problem has been solved!

    Friday, July 30, 2010 12:42 PM
  • Rocube: I did not check or play with RIA's RefreshInterval. Let's hope everything will be fixed with this next build. This is a very concerning issue and has damaged a thus far relatively flawless reputation of Silverlight.

    Friday, July 30, 2010 1:36 PM
  • valiant_sam: the fix will be released when it is ready.  I'm sorry I can't give you any specifics.  If I give you a date and we miss it then you'd not be happy.  If I give you a date that is too far in your mind, then you'd not be happy.  Right now we have a plan and are driving toward that plan which I've mentioned here as before end of Summer.  I had hoped it would have been MUCH earlier (we actually had a more aggressive plan, but found things that regressed and needed to address them).

    As to the ChildWindow, I'll take a look, but recommend you log a bug using the BUG steps mentioned here: http://timheuer.com/blog/archive/2010/05/03/ways-to-give-feedback-on-silverlight.aspx

    Saturday, July 31, 2010 1:19 AM
  • Tim: If the fix is not released by summer end (hopefully earlier) - then we can help you to get in touch with some Bill Gates. He would be glad to help you guys with coding and with a few millions in change. ;)

    Just like you, I practice and promote good technology. You do it on a large scale for Microsoft, I do it on a smaller scale for people and organizations that I work with. It is clearly disturbing to find this kind of issue (and for this long) all of sudden after 3 successful implementations and versions of a game changing product. It is also very difficult to explain such bugs and issues to clients. You must have read other people's plights in this forum as well. We all eagerly await this fix so we can all get back to business.

    Very excited about Silverlight on the phone as well. Let's hope these kind of issues don't crop up there.

    Thanks for all the work you do for us! Btw, your videos are very informative, helpful and to the point. When can we see more Windows Phone videos from you?

    Saturday, July 31, 2010 5:54 PM
  • valiant_sam: we're doing our best.  Trust me in that a lot of folks want to get this out ASAP as well.  We're being as aggressive as we can with the other issues.

    Monday, August 02, 2010 10:52 AM
  • Tim, let me add my voice to the list of people itching to get this fix released. We use third party controls heavily in commercial software for hospitals and military, the next release of which is scheduled for the end of August. Is that still roughly the time frame you have in mind? 

    Friday, August 06, 2010 4:58 PM
  • I am also affected by the memory leak issues. BTW, the memory leak is not the only issue that occurred when switching from SL3 to SL4. I just noticed that one of my older applications written originally for SL3 has issues when run under SL4. I did not investigate yet the cause of those issues and to be honest I suspect a bug in my code. Even if that is my bug, it is a bug that did not caused issues in SL3 and reared its ugly head only when switching to SL4. Imagine such occurrences with critical LOB applications. I really hope you guys will consider side by side.  I realize this is not a feature easy to add but it would greatly alleviate problems like this.

    Sunday, August 08, 2010 2:48 AM
  • This article:

    http://www.zdnet.com/blog/security/microsoft-drops-record-14-bulletins-in-largest-ever-patch-tuesday/7097?tag=nl.e539


    Seems to infer that there will be a patch released for silverlight on Tuesday. Can we expect that the aforementioned fixes will be in this patch ?


    Can I also mention that I am another developer that is hugely affected by this issue. We rolled out a corporate wide app shortly after the production release of Silverlight 4 and RIA Services. This is just a simple data entry application, however it will quickly consume over 1 gig of memory and crash the users system. Simply instantiating a (telerik Rad) combobox by editing a grid detail line, going out of edit mode, and then editing the same or another line will consume 60MB of memory that is not Garbage Collected. Edit 20 lines and your application Grinds to a halt.

    Sorely disapointed that this issue was identified and even fixed month(s) ago, but has not been deployed for a production ready supported 1.0 (well 4.0) release from the biggest software development tool company on the planet.



     





    Thursday, August 12, 2010 12:35 AM
  • Wow this post has over half a million views! I think that should communicate just how critical this issue is.

    I have a few products ready to launch or go into beta but I can't launch them till this issue is resolved. Which bottom line translates into dollars for me and I am sure everyone else is in the same boat.

    It appears that the updates didn't fix it for me. So still waiting.

    Thursday, August 12, 2010 11:29 AM
  • Really need this Memory Leak fix, what is the status? I have an application that should be going into production soon and without this fix, I might hold off.

    Tuesday, August 17, 2010 10:56 AM
  • Hi,

     

    I've found that SL4 is leaking every where, a SL4 LOB app can easily eat all the RAM of a computer. More than 1.5 Gbs!! And no I've triple checked, we do not have unsubscribed events.

    This didn't happen on SL3  

     

    I've seen other people having theese same issues.

     

    Any News?

     

    Best Regards,

     

    Jaime

    Tuesday, August 17, 2010 7:44 PM
  • Tim, the problem with your replies is that they really don't say anything at all other than "we are working on it, we are working on it, it will be coming soon" while blaming all the problem to "other issues" that you don't even care to enumerate.

     

    We are experiencing the very same issues as the many posters in this thread. We are an LOB that lives on the cloud, so this makes matters worse, as we have absolutely no idea of the hardware configuration of our customer's machines, which in some cases is some old XP laptop running on 1GB of memory. With these memory leaks the application is simply not usable under such conditions, and I suppose you expect us to tell our customers to go to the nearest Costco an upgrade themselves to a nice 8GB Windows 7 machine. Heck, 16GB, this way only need to reboot every couple days?

    So, in 3 months since you started telling this audience that the fixes are in testing we still have absolutely no clue about when this is going to be delivered and you expect us to be understanding because Microsoft is trying to "bundle" many "service fixes at once". Have you notice anybody here giving a hoop about anything other than their 1G+ SL4 applications? 

     

    Tuesday, August 17, 2010 10:26 PM
  • I think like you. Microsoft is making very poor management of this problem.


    I think Microsoft has been quick to publish SL4. I do not understand as they have been able to publish this version with these serious problems.

    We have chosen to develop into another different technology.

    Wednesday, August 18, 2010 2:19 AM
  • Any updates on when we will get the fix? 

     

     

     

    Wednesday, August 18, 2010 2:36 AM
  • [removed]

    Wednesday, August 18, 2010 3:42 AM
  • Well dude,

    We tested, found this leaking everywhere because is not only the DataTemplates. 

    we can't fix them because they are framework issues.

    Best Regrds.   

    Wednesday, August 18, 2010 11:04 AM
  • [removed]



    Wednesday, August 18, 2010 11:17 AM
  • Do you really have nothing better to do with your time than to come in here and tell us we shouldn't be complaining about this? You really need to get a hobby.

    Wednesday, August 18, 2010 11:22 AM
  • Im fairly sure that this thread doesn't exist to find out who's to blame. The fact is that this is a major issue and Microsoft still hasn't fixed it after a long time. Sure, you're right that anyone that's released buggy software is to blame as well for not testing properly but pointing that out doesn't achieve anything. Either way let's keep things civil and focus on bringing this to the attention of Microsoft and the Silverlight team. I'm sure we're all professionals here.

    Wednesday, August 18, 2010 11:25 AM
  • Quite right.

    It was not my intension to offend (as I clearly have) - removing offending posts...

    apologies to anyone who took offense.


    Wednesday, August 18, 2010 11:37 AM
  • Hi Tim. I am also suffering from serious memory leaks. I originally chalked it up to poor coding, being new to Silverlight and RIA services. I look forward to the update when it comes. I am fortunate to have a reasonable customer who will be patient for the time being.

    Keep on  keepoing on.

    Wednesday, August 18, 2010 1:53 PM
  • KaweekaTH - I'm sorry you don't feel I'm enumerating enough.

    -Is there a problem with DataTemplates and a memory leak: Yes
    -Do we know about it: Yes
    -Are we fixing it: Yes
    -Did we verify the fix with several customers: Yes
    -When will the fix be released: this is the only area I've been vague about...best answer I can give is "soon" -- I know this is useless information, but I'm trying to set expectations.  If I tell you "next week" and it isn't, then we'll all be just as unhappy and various other consipiracy theories will fly.

    Status: We've verified the fix for this issue with several customers.  They have helped us acknolwedge the fix in external testing.  The service release had much more than just this fix and we are in testing of those other items as well.  We're not going to release a servicing update for only one issue.  As I've mentioned before we're trying to maximize the release resources.  We're in final test passes now which take time for our various partners that may be impacted (we have to get sign-off from a lot of teams).

    Other than the specific release date, what can I enumerate more for you?  I'm trying to be as transparent as possible.

    Wednesday, August 18, 2010 2:07 PM
  • I think the big issue is that there is no sense of urgency, which seems to indicate you don't understand what a huge problem this is in the real world. I know you have said you are taking it seriously, but actions speak luder than words and the fact that this has dragged on for months shows you aren't grasping the severity of the problem.

    This whole idea that you can't release a critical fix because it addresses just one issue is foreign to most developers IMO. Are you telling me that after the launch of Windows 7, if there was bug that caused a computer to crash after a couple of hours of use, that MS would have told everyone there will be a fix in a few months, because we won't release a fix for just one issue?

    If I had a bug in my software, and I told my customer that, I'd be out of business in no time.

    Wednesday, August 18, 2010 2:29 PM
  • fwanicka - I don't think that's fair to say from your point of view.  There is a total sense of urgency of how this is impacting folks.  There are also *other* issues impacting folks.  We have resources we need to manage against and are trying to prevent multiple servicing releases. 

    If there was an issue that was caushing a crash/security issue, of course we wouldn't wait.  Frankly, this is neither of those categories and in most cases can be mitigated, which is why it wasn't prioritized as a zero-day fix.  Comparing this to a Win7 zero-day exploit or something like that isn't an apples-to-apples.

    Regardless, I've been 100% transparent with this forum.  I'm sorry that's not good enough for some.

    Bottom line: the fix is complete and we're in the release cycle.  It is a required cycle for us for normal releases with multiple teams needing to sign off.

    Wednesday, August 18, 2010 2:57 PM
  • Its is rather amusing to see posters get on the offensive about this when the request being made here is one to benefit the whole community. I don't recall seeing a single reference to anybody here being in production for that to even being an issue to be brought up by anybody.

    The impact that some of US are seeing is severe, whether Microsoft likes to see this as a zero issue or not is inconsequential to me anyway. As I stated, my target customer is one that has a laptop with 1G of memory and the purpose of investing so much time and effort on migrating to SL4 is because we want to take advantage of the relatively low footprint that SL4 promised over competing alternatives. That benefit is all but gone due to the severe memory leaks displayed by the RTC of SL4 so far. In response, Microsoft has taken the soft approach of bunding this issue is part of a multiple release patch, which I guess is fine with them, but hardly fine with me or some other people in this forum.

    Sure, you cannot apease everybody, but you certainly can at least try to be more transparent. When I was asking about enumeration, I think it was quite clear to see that I was asking for more informatio about the "other issues" that were part of this service release so that at least I could try to understand and sympathize with the scope of the release being tested. The ambiguity of the posts is what got me ticked off because I just read this thrad and didn't see much of any additional information after people waiting for this issue to be fixed over a period of 4+ months.

    So, not we are told it is in the "release cycle" ... what is that supposed to mean to me in terms of "when can I download this, and more importantly, when can my customers (beta, pilot, test, whatever you want to call them) be able to get an updated SL client so that they don't get to "enjoy" multiple gigabyte SL4 applications?

    That's all

     

    Wednesday, August 18, 2010 3:28 PM
  • I guess we'll have to agree to disagree. You marketed SL4 as a LOB application. It is completely unusable for that purpose at this point.

    It is impossible to mitigate the multiple memory leak bugs in any LOB application in my opinion. It is impossible to work around with any of the third party controls we have licensed, and the vendors will tell you that.

    You have been transparent and up-front and there is something to be said for that. We just disagree on how serious this bug is. To me, if there is a bug that makes a product unusable for its intended purpose, that's as bad as it gets.

    Just my 2 cents

    Wednesday, August 18, 2010 3:33 PM
  • How about enumerating the *Other* issues? Besides from memory leaks, what are the other flaws that our applications have that we do not know about?

     

    Best regards,

    Manuel Felício. 

    Wednesday, August 18, 2010 3:36 PM
  • I agree with fwanicka. I have deployed an LOB application into user acceptance testing cor a customer using older computers. They have felt a lot of pain as they have gotten out of memory error's consistently. To the customer, it is my code that doesn't work and they hold me accountable. I respect the fact that Microsoft has a process for bundling patches to maximize effort and resorces. Not to mention a rigorous testing and sign off process, but it doesn't make the situation any less frustrating. I'm not blaming, just venting. 

    Wednesday, August 18, 2010 4:02 PM
  • All -- feel free to vent away.  I don't want anyone to think that this communication is not valuable in any way to us...especially me.

    As to Kaweeka TH comments about being more transparent -- I've been as transparent as I can be with the exception of the release date which is something I simply cannot provide.  I apologize for that.  Honestly I would have hoped this released earlier in summer but we found other critical issues that prevented us from doing so.  Kameeka TH assertion that I was being vague about these issues...I apologize...yes I did not understand specifically what you were asking...sorry for being dense.

    As to the other issues, sure I'm happy to enumerate some of them in summary for you.  Along with the DataTemplate issue pointed out here there was also a similar memory issue releated to Mouse capture in some instances which has been fixed.  Other critical areas had to do with how some of the Media stack was providing and interpreting failure information.  DRM also had some important issues that have needed to be addressed.  Firefox also shipped 3 dot releases in this timeframe, the first of which broke Silverlight in 2 areas that we needed to add logic to change our behavior now to work around.  Chrome has had an additional browser release in the timeframe that added some test pressure since we now support it.  Mac platform had some issues related to mouse scrolling that we had plans to implement in this release as well.

    Most of our service release is in that bucket of categories (it wouldn't make sense to enumerate the literal bug list as a lot are interelated).

    Release cycle means we've completed our coding and are now awaiting test passes, numerous team sign-offs, code signing, security checks and the like.  That is a process for us here that I wish was fast, but simply isn't.

    Wednesday, August 18, 2010 6:03 PM
  • Tim,

    I hope the team has looked in WCF and RIA Services along with the ChildWindow control for memory leaks as well. I had a chance recently to try another application and it just never releases memory back. However, I am curious after reading about the "Mouse capture" issue that you mention in your reply. After going through all this, it will be a shame if memory leak issues persist. Did you get a chance to try out the app I was referring to in my previous posts?

    Please ask the people responsible for releasing Silverlight 4.0 so quickly to take a step back and improve their process for testing thoroughly before releasing new versions of Silverlight. All this bad and negative feedback due to a rushed release...

    Sam

    Wednesday, August 18, 2010 8:31 PM
  • Sam,

    Maybe Tim was talking about this bug of mine: https://connect.microsoft.com/VisualStudio/feedback/details/575799/leak-when-the-click-handler-removes-the-button

    Regards,
    Bruno 

    Wednesday, August 18, 2010 9:49 PM
  • Easy fix for me:  Put EVERYTHING in a DataGrid.  Memory leaks becomes a memory so to speak.  A kludge and ugly a bit, but able to deploy with minimal complaints from customers until this fix comes in.

    I know there may be circumstances where you cannot just put EVERYTHING in a DataGrid, but here's hoping that'll alleviate SOMETHING.

    Wednesday, August 18, 2010 10:12 PM
  • I will add a quick comment to why I think some people are as frustrated (or at least one of the reasons we are). I believe it has something to do that there was such a short release cycle between SL 3 & 4. For us we were almost complete with a few projects (50-70%) that we were targeting for SL 3 but when we saw that SL 4 would be out so quickly and a number of features added enough business value, we decided to wait for SL 4. So we took a little time to do some extra features in many of our applications and projects, well now our customers are getting excited for these new features. 

    I understand that Tim and the teams around Silverlight are working hard, and I am glad they are putting the extra effort to get most of this resolved and get all teams to sign off on it. 


    We are all eager to see the results of these fixes.


    Thanks to you and your team for all their hard work!

    Wednesday, August 18, 2010 10:19 PM

  • Yes I concur with jmtechware Silverlight is too cool. We see the potential. We all want to see this fixed so we can move forward.

    Thanks Tim! Keep up the good work and keep that team motivated.

    Wednesday, August 18, 2010 10:46 PM
  • Silverlight is awesome technology. Our Silverlight application really impresses our users, and I hope the memory leak issue won't spoil their experience.

    I am glad to know that at least it has been fixed and looking forward to it.

    Thanks for your hardwork!

    --Karlkim

     

    Wednesday, August 18, 2010 11:17 PM
  • Just wanted to say thanks for being as transparent as possible, even though is gives some people an avenue to vent their frustrations... I'm sure there are many more (including myself) which find it very valuable to be kept in the loop. 

    Thanks, T.J.

     

    Thursday, August 19, 2010 1:30 PM
  • Excellent, thanks for the update, good to know there is some progress being made.


    Friday, August 20, 2010 3:46 PM
  • Same problem with Styles Defined in resources

    Example A which defines ControlTemplate inline of style (InResources!) will cause memory leak

     when Example B which references ControlTemplate from resources works fine

    Example A:

     <UserControl.Resources>
    <Style x:Key="ButtonStyle1" TargetType="Button"> 
          
     <Setter Property="BorderBrush">
                    <Setter.Value>
                        <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                            <GradientStop Color="#FFA3AEB9" Offset="0"/>
                            <GradientStop Color="#FF8399A9" Offset="0.375"/>
                            <GradientStop Color="#FF718597" Offset="0.375"/>
                            <GradientStop Color="#FF617584" Offset="1"/>
                        </LinearGradientBrush>
                    </Setter.Value>
                </Setter>
         

                <Setter Property="Template">
                    <Setter.Value>
                        <ControlTemplate TargetType="Button">
                            <Grid Width="80" Height="80">

    ..... blah blah i will memory leak

    </Grid>
                        </ControlTemplate>
                    </Setter.Value>
                </Setter>
            </Style>
    </UserControl.Resources>

        <Grid >
            <Button Height="80" Width="80" Style="{StaticResource ButtonStyle1}" Margin="-40,-40,0,0"/>
        </Grid>
    
    
    Example B:
       <UserControl.Resources>
            <Style x:Key="ButtonStyle1" TargetType="Button">
                <Setter Property="BorderBrush">
                    <Setter.Value>
                        <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                            <GradientStop Color="#FFA3AEB9" Offset="0"/>
                            <GradientStop Color="#FF8399A9" Offset="0.375"/>
                            <GradientStop Color="#FF718597" Offset="0.375"/>
                            <GradientStop Color="#FF617584" Offset="1"/>
                        </LinearGradientBrush>
                    </Setter.Value>
                </Setter>
                <!--<Setter Property="Template">
                    <Setter.Value>
                        
                    </Setter.Value>
                </Setter>-->
            </Style>
            <ControlTemplate x:Key="MyTemplate" >
                <Grid Width="80" Height="80">
    ..blah blah i will NOT memory leak
                </Grid>
            </ControlTemplate>
        </UserControl.Resources>

    <Grid >
            <Button Height="80" Width="80" Style="{StaticResource ButtonStyle1}" Margin="-40,-40,0,0" Template="{StaticResource MyTemplate}" />
                
        </Grid>
    Wednesday, August 25, 2010 3:31 PM
  • I was wondering if there was any new updates as to when the service release will be coming out. 

    Thursday, August 26, 2010 3:45 PM
  • shall219: that's the only piece of information I can't provide a firm date on right now.  very soon.

    Thursday, August 26, 2010 4:12 PM
  • I understand, thanks... 

    Thursday, August 26, 2010 4:26 PM
  • Is there a way to get our hands on an unofficial release so we can test it with our applications? 

    Thursday, August 26, 2010 5:19 PM
  • Tim,

    "very soon" is great.  We've got a product in controlled release that is experiencing this leak.

    Is there a MS Connect link that goes along with this issue.

    Thanks,

    Mike

    Friday, August 27, 2010 9:51 AM
  • I noted this problem only this week,

    fortunately this blog is started before :)

     

    I would to thank all for paying attention to this subtle problem.

    I hope this experience open a new guidance and patterns into managed code about handling of

    memory leaks caused by event handling, etc...

    ( this post explain the simplest example http://marshaledthoughts.com/post/Event-Handler-Memory-Leaks.aspx )

    to take attention to this problem and improve Silverlight 4 toward

    the best one classical well structured/documented RIA programming system in the near future.

    I would also to thank Tim and the silverlight team to make this old dream ( writing web app like desktop app ) become reality.

     

    [ curiosity ]  A question for Tim : the problem of datatemplate was related to the use of the new NET Rx Framework in silverlight 4 ?

     

    Saturday, August 28, 2010 6:26 AM
  • Hi Tim,

    Thanks for keeping everyone up to date so far. It's Sep already and I've been following this thread for a while. Our application is fairly big LOB application and we have a huge issue with memory leaks. We have tracked it to SL 4 upgrade and are waiting for the fix. On the size of our application, it's difficult to find the exactly places to apply workarounds, especially with the 3 party tools that are also in place. 

    I feel it would be fair to expect at least a good range of dates for the service release. We have been trying to set customer expectation for a while now and it's becoming harder and harder as days go by. Is it possible to get our hands on the code you guys are testing with or get an updated and more accurate range of dates. 

    Thanks

    Wednesday, September 01, 2010 11:36 AM
  •  Yeah, seeing how Tim promised it would be released during "summer", and summer ended yesterday, it would be nice to get an update.

    Wednesday, September 01, 2010 11:55 AM
  • A) Tim never promised anything

    B) Summer ends on Sept 21st


    If you don't like the memory leak, you can always make your app in SL3 and it will work fine.


    I think there's been enough complaining on this thread already - seriously, give it a rest guys - I think everyone has got the message.

    Wednesday, September 01, 2010 12:42 PM
  • From Tim earlier in this thread:

    We are in testing with this next servicing release now. The best response I can give right now is "summer" but I'm hopeful it is sooner than that. However I'd rather underpromise/overdeliver than give you something that will slip. 

    My bad regarding the last day of summer. As for the rest of your post, thanks for the constructive criticism. lol.

    Now go get Tim a cup of coffee and shine his shoes. 

    Wednesday, September 01, 2010 12:59 PM
  • Thanks for your patience everyone.  See my update (bits now available): http://timheuer.com/blog/archive/2010/09/01/silverlight-service-release-september-2010-gdr1.aspx

    Wednesday, September 01, 2010 1:54 PM
  • Thanks Tim!

    Giving it a try now!

    Wednesday, September 01, 2010 3:24 PM
  • Thanks, but we're still showing increasing memory.  Ah well... back to my workaround.  Thanks for the efforts all the same.

    Wednesday, September 01, 2010 3:53 PM
  • robcube: can you verify the increase of memory footprint is a result of a leak?  If you have a repro, please submit it as a bug to Connect.

    Wednesday, September 01, 2010 4:07 PM
  • That's wonderful news!!!

     

    I'll give you feedback of our app within the next week. 

    Best regards,

    Manuel Felício.

    Wednesday, September 01, 2010 4:13 PM
  • Under what category in connect.microsoft.com?  Silverlight isn't listed as a product.

    Wednesday, September 01, 2010 4:17 PM
  • robcube: yes, that's lame (it's weird how our systems work in that regard).  it's under the VS2010 product line, then choose SL4 as the "version"


    see http://timheuer.com/blog/archive/2010/05/03/ways-to-give-feedback-on-silverlight.aspx

    Wednesday, September 01, 2010 4:23 PM
  • Thanks, I'm seeing improvement in our application.

    Wednesday, September 01, 2010 4:33 PM
  • As to the other issues, sure I'm happy to enumerate some of them in summary for you.[...] Firefox also shipped 3 dot releases in this timeframe, the first of which broke Silverlight in 2 areas that we needed to add logic to change our behavior now to work around.

    Hi Tim. After testing the service release I'm afraid these issues have not been fixed, at least not those filed to Mozilla and Microsoft at the end of June, details see here, for example. It's still very easy to crash the plug-in in Firefox, or have it produce bogus data, with that method.


    Thursday, September 02, 2010 3:04 AM
  • Thats great news Tim.

    If our applications are using 3rd party controls or Silverlight Toolkit controls will we need to wait for a new version of those compiled with the new SDK or should they work now?

    Cheers 

    Thursday, September 02, 2010 3:11 AM
  • Hello Tim,


    I was very happy to see the today's Silverlight Release.

    I have installed the Windows developer runtime as well as the 4.0.50826.0 Silverlight SDK. I have also set the minRuntimeVersion parameter to 4.0.50826.0 and install the latest version of Silverlight on my client's machine.

    I have then rebuilt the solution and started testing. Unfortunately, the memory leaks do not seem to be fixed.

    Next, I added the two lines needed to force the GargageCollector (when going on a new page) and then attached the WindowsDebugger to the solution to find out more details. It seems that one of my pages (that contain a DataTemplate) is not freed because of the DataTemplate. Here is my result of !gcroot windbg command:

    Scan Thread 8 OSTHread e80
    Scan Thread 9 OSTHread eb4
    Scan Thread 10 OSTHread fbc
    Scan Thread 16 OSTHread 960
    Scan Thread 19 OSTHread 5b8
    Scan Thread 23 OSTHread fc4
    DOMAIN(01B24BC0):HANDLE(Pinned):44512f8:Root:  03194260(System.Object[])->
      021a9d4c(System.Collections.Generic.Dictionary`2[[System.IntPtr, mscorlib],[System.Object, mscorlib]])->
      036f54e0(System.Collections.Generic.Dictionary`2+Entry[[System.IntPtr, mscorlib],[System.Object, mscorlib]][])->
      023ad678(System.Windows.DataTemplate)->
      0238e140(MySolution.Views.MyView.MyPage)->
      023b66cc(
    MySolution.Views.MyView.MyPageViewModel)

    Finally, if I remove the DataGridTemplateColumns containing the DataTemplate everything is freed nicely.

    I have also noticed that the release does not include a fix for the TreeViewDragDropTarget memory leak.

    For example I have added a simple control like this in a new Silverlight BusinessApplication Home page and forced the Garbage Collector.

    <controlsToolkit:TreeViewDragDropTarget x:Name="Test"/>

    Using the windbg I see several instances of TreeViewDragDropTarget (one for each visit of my Home page). If I remove this Test control I never have more instances of my Home page.

    Hope this helps you. :)

    Thursday, September 02, 2010 4:13 AM
  • MisterG: There were some FF issues that were crashing bugs that were fixed (MessageBox and DragDrop areas) as a result of changes from FF we had to work around.  The issue you pointed to related to some networking things is something I'm not aware of.  I've pinged our test lead to see if this has been triaged as a Silverlight issue or perhaps specific only to RIA Services/WCF.

    Thursday, September 02, 2010 8:00 AM
  • kornfish: you don't necessarily need to compile your apps using the new bits (it never hurts of course), but any user experiencing these issues would need the new runtime to have the fixed behavior.  This was not a developer-related fix, but more of a runtime fix.


    Thursday, September 02, 2010 8:01 AM
  • fmedrea: can you please create a repro we can have and submit it as a bug (or direct to me) so that we can investigate if this is the same issue (which I'm not sure is the same use as what this fix targeted) or something new we need to examine.  Having an explicit repro of your usage scenario will help identify this.


    Thursday, September 02, 2010 8:03 AM
  • It's too bad you didn't make a test build available as numerous people in this thread have been asking for for months, so that all the bugs could have been identified. We are still experiencing memory leaks as well. I'm worried that it's going to be another 5 months until these bugs are really fixed.

    The Telerik suite of controls have huge memory leaks that they have been claiming were caused by the DataTemplate bug in the Silverlight runtime. They've been saying since April that the leaks would go away as soon as this new build was released. Well, they're still there with the new build. Now, they're claiming they have to build against the new SDK for the leaks to be fixed. I have my doubts. I wonder if they they offered a chance to try out the fixed build in advance. They're one of the largest third-party vendors of Silverlight controls. One would think they would have gotten a chance to test it months ago when you said this particular issue was identified and fixed.

    Thursday, September 02, 2010 8:25 AM
  • fwanicka: We work closely with our control vendors on every release.  They are a part of our early adopter programs and have access to these verification builds.  A lot of customers (no, not the general public, but those who were already in early adopter programs, had NDAs, etc.) had access to these builds and verified fixes for us.

    If you feel you still have an issues, PLEASE log a repro bug so that we can identify indeed if it is a leak and if so, log it as a bug to investigate.

    Thursday, September 02, 2010 8:31 AM
  • It may be a red herring but ever since I installed the SL updates last night my Visual Studio has decided to crash on me quite regularly. Looking at my EventViewer I see two related exceptions:

    .NET Runtime - the process was terminated due to an unhandled exception; and

    Microsoft Visual Studio - EventType clr20r3, P1 devenv.exe P2 ... system.accessviolationexception, P10 NIL

    Anyone else have this?

    Thursday, September 02, 2010 9:00 AM
  • I have had no problem with new sdk and runtime; I suggest you to remove all silverlight relatived from control panel ( tools, toolkit, sdk, runtime 3 and 4 ) then reinstall in this order :

    - runtime

    - sdk

    - tools (this includes also the ria)

    - toolkit

    - runtime for developer

    Thursday, September 02, 2010 11:40 AM
  • Ok, so after uninstalling and installing in that order you no longer have memory leaks with inline DataTemplates within DatGridTemplateColumns nor TreeViewDragDropTargets?

    Thursday, September 02, 2010 12:34 PM
  • I would think the answer was for your VS crash...

    Thursday, September 02, 2010 1:11 PM
  • Exactly I mean that,

    in any case I tried reinstalling and nothing change about memory usage.

    Thursday, September 02, 2010 1:47 PM
  • Sorry. My mistake. I see which post you are responding to now. I am just anxious to see if this new build fixed the memory leaks for anyone. So far, I'm not seeing it.

    Thursday, September 02, 2010 2:19 PM
  • fwanicka: please provide a repro of your issue/app.  We've verified the data template memory leak identified in this thread as fixed via numerous customers.  If you are seeing a memory leak and have verified it, please let us know the code path (sample repro is easiest to do this).

    Thursday, September 02, 2010 2:30 PM
  • Ok, I just submitted it to Connect. For everyone else's benefit, here's what I did:

    Create a new project using the Silverlight Navigation template. In the Home.xaml, add:

    xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"

    to the namespaces and

     <sdk:DataGrid>
                        <sdk:DataGrid.Columns>
                            <sdk:DataGridTemplateColumn Header="Description"
                                                        IsReadOnly="True"
                                                        SortMemberPath="FullDescription">
                                <sdk:DataGridTemplateColumn.CellTemplate>
                                    <DataTemplate>
                                        <TextBlock>
                                        </TextBlock>
                                    </DataTemplate>
                                </sdk:DataGridTemplateColumn.CellTemplate>
                            </sdk:DataGridTemplateColumn>
                        </sdk:DataGrid.Columns>
                    </sdk:DataGrid>

    to the XAML.

    I also added the following to the ContentFrame_Navigated event handler in the MainPage code-behind, but the Home class never gets garbage-collected.

    GC.Collect();
    GC.WaitForPendingFinalizers();

     

    Run the app. Click back and forth between Home and About screens several times. Run WinDBg. You will see that Home is in memory as many times as it loaded, and doesn't get garbage-collected. Here are the details from WinDbg.

    DOMAIN(06EF4440):HANDLE(Pinned):5d212f8:Root:  083a4260(System.Object[])->
      073b72fc(System.Collections.Generic.Dictionary`2[[System.IntPtr, mscorlib],[System.Object, mscorlib]])->
      07405e80(System.Collections.Generic.Dictionary`2+Entry[[System.IntPtr, mscorlib],[System.Object, mscorlib]][])->
      073fed60(System.Windows.DataTemplate)->
      073fdbd8(SilverlightMemoryLeakDemo.Home)

    Please tell me if I am misinterpreting these results. I hope I am.

    Thursday, September 02, 2010 3:38 PM
  • but the Home class never gets garbage-collected.

    I can confirm these findings.

    One of my applications which also suffered from the leaks before seems to behave slightly better now than with the previous runtime version (some memory is released). But when I checked it still looked as if it was leaking heavily (as in measured in MiB per page view). Switching back and forth between different views with DataGrids on them, one can easily bring memory usage to 100+ MiB within a minute or less.

    So I took fwanicka's sample code and first tried to use Performance Explorer and its object lifetime analysis on it, but with inconclusive results. Then I used Windbg and got the same results: I also see memory is being hogged, and Windbg says Home lives in memory as many times as it's been loaded, despite the forced garbage collection. !GCRoot shows similar results like in fwanicka's post, with Home being pinned by DataTemplate.

    Thursday, September 02, 2010 7:32 PM
  • Don't have WinDbg set up here but your example leaks for me too.  However my guess is it's a problem with the DataGrid and not DataTemplates in general.  I borrowed your markup, put a large image inside and set the ItemsSource with a 1 item list.  With the DataGrid, memory usage keeps going up and no destructor is ever called.  However, with just an ItemsControl or ListBox using an identical data template, memory usage stays put and destructors are called.

    Friday, September 03, 2010 2:46 AM
  • After testing some more this morning, the same issue exists with both the Telerik RadGridView and the DevExpress agGrid, using the following code respectively:

      <telerik:RadGridView>
                        <telerik:RadGridView.Columns>
                            <telerik:GridViewDataColumn>
                                <telerik:GridViewDataColumn.CellTemplate>
                                    <DataTemplate>
                                        <TextBlock>
                                        </TextBlock>
                                    </DataTemplate>
                                </telerik:GridViewDataColumn.CellTemplate>
                            </telerik:GridViewDataColumn>                     
                        </telerik:RadGridView.Columns>
                    </telerik:RadGridView>
     
    <dxg:AgDataGrid>
                        <dxg:AgDataGrid.Columns>
                            <dxg:AgDataGridColumn>
                                <dxg:AgDataGridColumn.DisplayTemplate>
                                    <ControlTemplate>
                                        <TextBlock />
                                    </ControlTemplate>
                                </dxg:AgDataGridColumn.DisplayTemplate>                            
                            </dxg:AgDataGridColumn>
                        </dxg:AgDataGrid.Columns>
                    </dxg:AgDataGrid>
     

    It gets pinned to the DataTemplate in the Telerik grid, and the ControlTemplate in the DevExpress grid. So, either nobody knows how to code a datagrid that doesn't leak, or there is still an issue with the runtime. Which one of those is truly the case is for someone else to figure out.

    What I do know is that virtually no LOB app is going to be without a datagrid of some sort, and the fact that this wasn't tested and discovered months ago is ridiculous. The testing going on internally and by the third parties MS had testing the "fixed" version for the past few months is obviously inadequate. Within a day of the "fixed" build being released, several leaks were identified in this thread. This is exactly why myself and others in this thread have been "complaining" continuously, and this is exactly what I was worried would happen. We waited 5 months and there are still memory leak issues. If a "test build" had been made available months ago, these issues could have been identified and probably fixed by now.

    It is not my intention to come in here and bash Tim nor the Silverlight team. I really like Silverlight, and I have invested a lot of time and money (purchasing third-party controls, many of which are currently unusable) in it. I want it, and need it, to work as a LOB platform.

    Friday, September 03, 2010 9:25 AM
  • I guess we all drank the "line of business ready" Kool Aid without realizing Jim Jones had been reincarnated and now works in Microsoft’s marketing department. 

    Obviously the cell phone is the priority.  However, for those of use with huge investments in this technology, some honesty on releases and futures is needed.  If Silverleak line of business apps are not a priority for Microsoft then we should not be here trying to develop them.

    Friday, September 03, 2010 9:48 AM
  • Hi Tim,

       The update has definitely helped with the leaks but as others have mentioned there still seem to be issues. Another example is the Silverlight Media Framework Player control (http://smf.codeplex.com/), If you create a new control and place the player on it then it won't get garbage collected, even if no media source is ever set and Dispose is called.

    I was hoping the update was going to fix the fundamental problem causing this but it hasn't, maybe it uses a DataGrid internally or maybe its an issue with the control itself, not sure. I have posted the issue on their codeplex issue tracker as well.

     

    Friday, September 03, 2010 10:13 AM
  • We are talking with Telerik now.  This may be a different code path that isn't a part of the original issue.  I'm not sure why they are just finding it in their testing as well.

    Friday, September 03, 2010 11:34 AM
  • kornfish: can you please provide the repro steps or better yet, log a bug with the steps and a sample project?  I haven't dug deep into the code of SMF, but want to make sure we are officially tracking these issues.  This forum is great for discussion and I don't want to discourage it, but if you believe you have found a bug, the best way is to log it officially with a repro of the case.  Details of how that can be done on Connect are here: http://timheuer.com/blog/archive/2010/05/03/ways-to-give-feedback-on-silverlight.aspx

    Friday, September 03, 2010 11:38 AM
  • In addition to the Telerik and DevExpress examples posted by "fwanicka", we've also done some testing an noticed the issue is still showing up with the basic Silverlight DataGrid ...

    <sdk:DataGrid Margin="0,20,0,0" AutoGenerateColumns="False" ColumnWidth="*" IsReadOnly="True" ItemsSource="{Binding Source={StaticResource Employees}}">
                <sdk:DataGrid.Columns>
                    <sdk:DataGridTemplateColumn>
                        <sdk:DataGridTemplateColumn.CellTemplate>
                            <DataTemplate>
                                <TextBlock Text="{Binding DisplayName}" />
                            </DataTemplate>
                        </sdk:DataGridTemplateColumn.CellTemplate>
                    </sdk:DataGridTemplateColumn>
                </sdk:DataGrid.Columns>
            </sdk:DataGrid>

     

    We're working on posting our test example.

    Thanks,
    SMIMS

     

     

    Friday, September 03, 2010 11:48 AM
  • The first sample fwanicka posted and I confirmed also uses the standard Silverlight Datagrid, no third party control of any kind.

    Friday, September 03, 2010 11:56 AM
  • So, is it "only" the datagrid that is leaking? Can anyone confirm that they at least have fixed some of the leaks? (some reports seem positive)

    Friday, September 03, 2010 3:22 PM
  • I can confirm that a lot of the template-related leaks have been fixed, as well as the mouse capture leak, which was affecting us.

    I can also confirm that the data grid template column leak is present in the latest build :(

    Friday, September 03, 2010 3:29 PM
  • I can also confirm that a lot of leaks were fixed with this build. 

    Friday, September 03, 2010 3:32 PM
  • fljohwat: we're looking at the DataGrid this morning and it does appear so far that all the repros share that in common.  The initial thread starter here (DataTemplates in user controls, etc.) more generically has been verified.

    I'll post more back to this thread when I have more information.

    Friday, September 03, 2010 3:35 PM
  • Thanks Tim,

    We are using the Telerik controls, and again, this fix does seem to have resolved the majority of template related leaks, a measurable difference for our LOB applications. Our ship date is in 12 days, so this was in the nick of time! Phew...

    Friday, September 03, 2010 3:49 PM
  • I am also getting datatemplate leaks in the datagrid but also the dataform.  I will put together a repro.

    Friday, September 03, 2010 3:52 PM
  • slimtim...: please also send the repro of the DataForm one to me as well.

    Friday, September 03, 2010 4:36 PM
  • Tim

    Please read this post from Silverligt 3 beta. It looks as though it is the same memory leak with the datagrid that was previously fixed in Silverlight 3 RTM.

     

    http://forums.silverlight.net/forums/p/77862/239489.aspx

     

    Friday, September 03, 2010 5:19 PM
  • @heuertk - I have filed a Microsoft Connect issue here:

    https://connect.microsoft.com/VisualStudio/feedback/details/594630/dataform-datagrid-memory-leak-in-silverlight

    I uploaded a solution (but it will take a while to appear on the MS server) that uses a WeakReference list and a garbage collector to demonstrate the memory leak.  When the code is run click the add buttons to add a DataForm, Textblock or DataGrid and then click the subtract button the same number of times as you clicked the add button.  Then click GC Collect and it will display what didn't get released.

    I will email you a direct link to the solution as well in case you want to get on this now.

    The dataform is simple and this will cause a leak

            <df:DataForm x:Name="dataForm"
                AutoGenerateFields="False">
                <df:DataForm.EditTemplate>
                    <DataTemplate>
                        <Grid x:Name="rootPanel" df:DataField.IsFieldGroup="True">
                            <df:DataField x:Name="dfTest">
                                <TextBlock x:Name="tbTest" Text="TextBlock"></TextBlock>
                            </df:DataField>
                        </Grid>
                    </DataTemplate>
                </df:DataForm.EditTemplate>
            </df:DataForm>


     

    Friday, September 03, 2010 7:03 PM
  • Hi all, I'm wondering if a few can test a workaround for me with regard to this DataGrid discovery.  Instead of using in-line templates, can you try using resources?  i.e.,

    <UserControl.Resources>
            <DataTemplate x:Key="TestTemplate">
                <TextBlock Text="Hello" />
            </DataTemplate>
        </UserControl.Resources>
            <sdk:DataGrid AutoGenerateColumns="False" >
    		<sdk:DataGrid.Columns>
    			<sdk:DataGridTemplateColumn Header="Approver"  x:Name="cApproverCol" CellTemplate="{StaticResource TestTemplate}">
    <!-- instead of this -->
    
    	<!--<sdk:DataGridTemplateColumn.CellTemplate>
    					<DataTemplate>
    						<TextBlock Text="Hello" />
    					</DataTemplate>
    				</sdk:DataGridTemplateColumn.CellTemplate>-->
    			</sdk:DataGridTemplateColumn>
    		</sdk:DataGrid.Columns>
    	</sdk:DataGrid>


    Friday, September 03, 2010 8:24 PM
  •  @heurtk - yes that works in my test harness that I mention above.  Also it works for my dataform issue as well.  I changed the dataform to this:

        <UserControl.Resources>
            <DataTemplate x:Key="TestTemplate">
                <Grid x:Name="rootPanel" df:DataField.IsFieldGroup="True">
                    <df:DataField x:Name="dfTest">
                        <TextBlock x:Name="tbTest" Text="TextBlock"></TextBlock>
                    </df:DataField>
                </Grid>
            </DataTemplate>
        </UserControl.Resources>
    
        <Grid x:Name="LayoutRoot" Background="White">
            <df:DataForm x:Name="dataForm"
                AutoGenerateFields="False"
                EditTemplate="{StaticResource TestTemplate}">
            </df:DataForm>
        </Grid>


    Now I will have to see how hard it will be to change the code in my giant LOB. 

    Friday, September 03, 2010 8:55 PM
  • This solution did fix my repro case with DataGrid 

    Friday, September 03, 2010 9:26 PM
  • I'm wondering if a few can test a workaround for me with regard to this DataGrid discovery.  Instead of using in-line templates, can you try using resources?  i.e.,

    Hallo Tim. Yes, this fixes the DataGrid issue. No more leaking.

    Can you elaborate a bit, once you found the cause for this problem, so we can deliberately avoid these situations?

    Saturday, September 04, 2010 3:08 AM
  • Hi there,

    look like the last update (http://support.microsoft.com/kb/2164913) is solving this issue isn't it ?

    [Edit: Sorry, was half-sleepy...]

    Monday, September 06, 2010 1:20 AM
  • Hehe, actually we're discussing that this last update does not solve these issues.

    Monday, September 06, 2010 3:41 AM
  • It is not solving our memory leak issues.. We don't use dataforms but we use Telerik's datagrid and a lot of images. If we open a 2MB image the memory goes up 50MB and never goes down..

    I'll try refactoring the inline datatemplates to use them as static resources.. 

    Monday, September 06, 2010 6:21 AM
  • Just a thought..what happens if I define an inline DataTemplate inside a DataTemplate that is declared as a StaticResource ? Does this leak?

     

    Edit: I refactored some views in my app and still leaks. There is only one place where I use inline datatemplates declared inside static resource datatemplates that I didn't refactor. May that be the cause? Anyway, wasn't this fix supposed to FIX this?

    Monday, September 06, 2010 7:16 AM
  • I have also been experiencing DataGrid memory leaks. Making the DataTemplates a resource instead of inline fixed the obvious leaks. However, I found a specific case that still leaks for me: editing a cell.

    I can add/remove rows in the grid with no problems. I can also edit the rows in the code behind with no problems. By no problems, I mean I can do these things, leave the page, run garbage collection, and that page is no longer in memory.

    However, when I click on a cell to edit via the UI (in this case, it is a DataGridTextColumn), the memory leak returns. I thought perhaps the issue was with my XAML-declared CellEditEnded event. However, I removed this event, so there are no events assosiated with this DataGrid now. The memory leak remains.

    So, just the act of clicking in a cell to make it editable causes a problem.  At this point, if I leave the page and run garbage collection, the there is a page instance in memory as many times as it was visited (and the cell edit activated).

    Running WinDbg seems to show that it is the same DataTemplate issue:

    ...

    0782cd90(System.Windows.Controls.DataGridCell)->
    076bd5a8(System.Windows.Controls.DataGridTemplateColumn)->
    076bceb8(System.Windows.DataTemplate)->
    076a9004(Project1.Views.Lessons)

    The only DataGridTemplateColumn I have in this DataGrid is the one that uses the resource-based DataTemplate. I.e. the act of editing the cell seems to kill the workaround, even though the cell being edited and the DataTemplate cell are different columns.

    I'm thinking this may be a big reason why some people see their leaks as fixed, while others don't. I'm curious to know if anyone else has this problem, especially those who have fixed the memory leak via resource-based DataTemplates.

    Monday, September 06, 2010 5:07 PM
  • It seems I have found a workaround for the cell editing issue that I posted. The memory leak occured when I had two columns, one which was a DataGridTextColumn and one which was a DataGridTemplateColumn using a non-inline DataTemplate. When I change the DataGridTextColumn to another DataGridTemplateColumn and use a non-inline DataTemplate to create my TextBox, I don't get a memory leak when I edit the cell.

    I assume the leak is gone because the grid no longer uses the same editing mechanisms in the background. This technique breaks some things things like the CellEditEnded event, but it's possible to work around those issues.

    To summarize, this code leaks when editing a cell in the DataGridTextColumn:

                   <sdk:DataGrid.Resources>
    <DataTemplate x:Key="DataTemplateResource">
    <Button Click="button_Click">
    <Image Source="/Project_1;component/Assets/Images/red_x_2.jpg" />
    </Button>
    </DataTemplate>
    </sdk:DataGrid.Resources>

    <sdk:DataGrid.Columns>
    <sdk:DataGridTextColumn Binding="{Binding Path=Name}" />
    <sdk:DataGridTemplateColumn CellTemplate="{StaticResourc DataTemplateResource}"/>
    </sdk:DataGrid.Columns>

    This code does not leak when editing the TextBox:

                 <sdk:DataGrid.Resources>
                        <DataTemplate x:Key="DataTemplateResource">
                            <Button Click="button_Click">
                                <Image Source="/Project_1;component/Assets/Images/red_x_2.jpg" />
                            </Button>
                        </DataTemplate>
                        <DataTemplate x:Key="DataTemplateResourceTextBox">
                            <TextBox Text="{Binding Path=Name}" />
                        </DataTemplate>
                    </sdk:DataGrid.Resources>
    
                    <sdk:DataGrid.Columns>
                        <sdk:DataGridTemplateColumn CellTemplate="{StaticResource DataTemplateResourceTextBox}"/>
                        <sdk:DataGridTemplateColumn CellTemplate="{StaticResource DataTemplateResource}"/> 
    </sdk:DataGrid.Columns>



    Monday, September 06, 2010 6:50 PM
  • @sniles : Thanks a lot for sharing.

    for others, is there any one that after getting the fix, he is now seeing his application 100% fixed and without leaks. I am asking this question because I am in a team working with Sl4, and i am responsible for any delay in deadlines if We pretend that SL4 is now ready and  after that our clients see that it wasn't true... 

    @Tim : Please if any of the problems identifed after the fix (and reported in Connect.Ms.com) was verified and are truly leaks, please give us feedback, so we can planify our next release ...

    Thanks in advance. 

    Tuesday, September 07, 2010 1:32 AM
  • @amine.boussema - Yes.  I am 100% fixed without leaks now that I have converted all my datatemplates in my DataGrids and DataForms to static resources.   Interestingly, after changing out all my datatemplates I had to dive deep into Windbg and find a couple memory leaks that were my fault and unrelated to this thread but now they are all cleaned up and all works great.

    @sniles - I use inline (without static resource) DataGridTextColumn without memory leaks in my DataGrids however my grids are read only so that is probably why all is well for me.

     

    Tuesday, September 07, 2010 2:50 AM
  • I'm using telerik controls heavily, especially the RadGridView and this "fix" unfortunately didn't fix the leaks for me. So the question would be, what could I do next?

    Tuesday, September 07, 2010 4:56 AM
  • Wait a moment. Why are we refactoring inline datatemplates to resource datatemplates if the Fix that was released on September 1st fixed this problem? Some people say it fixed, others say it didn't.

    I'm confused. 

    Tuesday, September 07, 2010 6:48 AM
  • I vote for the issue NOT being fixed.  I am still seeing memory leaks and confirmed using windbg that DataTemplate is the issue.  Refactoring to resource DataTemplates does fix the issue though.  But I hate to refactor my entire application right now.

    Tuesday, September 07, 2010 7:57 AM
  • It hasn't affected the issues with the Telerik suite of controls, that's for sure. You can drop a RadComboBox on a page, and not set a single property:

    <telerik:RadComboBox />

    and it leaks. Every Telerik control we use still leaks. They are claiming it's an unfixed bug in the Silverlight runtime. The standard Silverlight ComboBox does not leak in this manner, nor does the DevExpress one I just tried. I really wish Telerik and MS would have been better coordinated on thsi over the past few months. We like the Telerik controls feature set.

     

    Tuesday, September 07, 2010 8:50 AM
  • Hi fwanicka,

    Can you please open a support ticket and attach your sample leaking application using your Client.NET account on telerik.com? Alternatively you could send this directly on my email: stefan.dobrev[at]telerik.com.

    Thanks,

    Stefan


    Tuesday, September 07, 2010 9:39 AM
  • I did on 9-3 (ticket # 345158), and got this reponse a few hours ago:

    We investigated the problem and found out that this issue is caused by a problem in Silverlight. We will try to find a work-around for this problem while Microsoft fix the Silverlight runtime and write you back as soon as we have one.Regards,
    Miroslav Nedyalkov
    the Telerik team 

    Tuesday, September 07, 2010 10:32 AM
  • <telerik:RadComboBox />

    Can someone at Telerik please explain why such a (simple) case causes leaks? To me this seems totally unrelated to the bug we're discussing in this thread (datatemplate). Is there a fundamental flaw/bug in SL or Telerik that we aren't aware of? My project is also affected by Telerik's treeView and grid - switching from inline templates to resource based ones haven't helped.

    Tuesday, September 07, 2010 11:10 AM
  • Hello,

    The problem described in the previous post is slightly different from the one discussed in this thread. The problem I was talking about is related with the Popup control. If you have a custom control with ControlTemplate and you place a Popup control in the ControlTemplate and a ContentPresenter in it, it leaks if the ContentPresenter Content property is template bound to a custom property of the Control. For more information you could refer to the following project that tests two scenarios with and without a ContenetPresenter in the ControlTemplate - http://cid-82d9c9314acafcd3.office.live.com/self.aspx/For%20Share/SilverlightMemoryLeakWithPopup.zip.

    Regards,

    Miroslav Nedyalkov.

    Tuesday, September 07, 2010 11:42 AM
  • I'm curious if anybody else is seeing this behavior. I've put week references on the usercontrols that get instantiated and I call GC.Collect everytime I reload the usercontrols. The Weakreferences are showing Reference.IsAlive = false for the old usercontrols after reload but the memory usage doesn't go down by much compared to how much it went up. I'm not sure if it's an issue with some style/graphic, which we extensively use but I can't figure out why the memory usage is so high. I have seen as much as 10 mb taken by a simple user control and it'll go down by a few hundered KB if I unload the usercontrol. I've tried to use WinDbg but my iexplorer freezes any time attach WinDbg to it.

    Tuesday, September 07, 2010 1:04 PM
  • pp, I see the same behavior as you. When I call GC.Collect only a few KB are collected compared to MB's.

    It is normal that your browser freezes when you attach WinDbg. That's like setting up a breakpoint on Visual Studio (your app is paused)

    Tuesday, September 07, 2010 2:09 PM
  • Hey all, we've discussed this today and recommend the workaround of moving DataTemplates to resources.  We're looking at seeing if there are other workarounds that are better, but in the meantime this is the workaround until a fix is established.

    On behalf of the team, I apologize for this issue.  We had our service release distributed to roughly 350 customers and partners, all of which confirmed that the memory leaks were fixed in their scenarios.  Unfortunately, immediately after the release, some customers identified scenarios where it was not fixed, which some of you are facing.

    Tuesday, September 07, 2010 8:58 PM
  • i guess, i should ask the question everybody want to know an answer.

    When can we expect, next service release, that will fix other memory leaks? =)) 

    Tuesday, September 07, 2010 9:05 PM
  • Vadim: I don't have a timeframe unfortunately.  I know this isn't the answer anyone wants to hear.  I'm prepared to take a beating on this forum I'm sure.  I sat with our triage team today and expressed the concern about this issue and the urgency.  We're seeing what we can do about this. 

    When I know more information I'll report back here.  Until then I don't (and will not) have an answer on when.

    Tuesday, September 07, 2010 9:23 PM
  • Tim,

    Of course all the scenarios were not tested! Next time, please just listen to your "real" users. We can help you guys fix things quicker if you just release these fixes to us instead of or ALONG WITH the 350 partners and privileged customers.

    Please give the Silverlight team a clear message: Get your act together and fix ALL the leaks up before thinking about Silverlight 5. Please ask them to take a look at the Popup controls, WCF proxies in Silverlight client, INLINE DataTemplates, styles and other issues reported. Offering user to change their way of programming or giving less flexibility (not doing inline datatemplate) is not a solution by any means.

    So again, we find ourselves back to square one: When will the fix be released? Sometime before Winter ends is not acceptable. This literally means Silverlight 4 was never released because it is un-usable since it is unreliable.

     

    Tuesday, September 07, 2010 10:04 PM
  • Tim,


    I think we all understand that, you guys, worked hard to get recent release out of the door, and to include as many reported issues as possible, and i want to thank you for that.

    Also i would like to ask forum members, to concentrate their attention on identifying, narrowing down to a little samples, and reporting their sources of memory leaks to the SilverLight team, and, if used, vendors of third-party controls, instead of pointless beating.

    The more different examples will be reported, the greater chance of covering all edge conditions during testing/fixing, that may be missed otherwise.

    Tuesday, September 07, 2010 10:40 PM
  • valiant: If it were up to me alone, I'd give everyone access :-).  But it isn't and honestly there is good reason why we didn't (we did this in SL2 days and it was a nightmare for customers).  I'll be encouraging us to find a way to get these out a bit more open this next time around if I can...I won't promise anything, but will do my best.

    The 350 customers/partners *were* 'real' users.  Why none of this was caught in those test cases is beyond me.  I've received a few apologies from some of our key partners even saying they missed this in their testing as well.  Regardless, it is an issue that we need to fix.  We thought we had it fixed, but it was a portion of the problem.  Luckily we have a workaround that works (whereas before we didn't have a workaround that worked for everyone).

    vadim: thanks for the encouragement.  Having repros is great and the repro that started this thread here, in fact, was a base that was used.  We can do better though...I'm not going to pretend we can't :-).  The more we can test with everyone the better, and is something I'll press more for in the next release.

    Tuesday, September 07, 2010 11:16 PM
  • Tim,

    We appreciate your efforts to get these issues resolved. We (Silverlight developers, designers, test engineers, community) will help out as much as we can either through concise steps or repros. The Silverlight team needs to treat every report seriously and double check all possible scenarios for leaks (and not just inline datatemplates - for other reported problems as well).

    Thanks!

    Tuesday, September 07, 2010 11:38 PM
  • valiant: we do actually test for these things.  However in this case this is a 'different' type of leak.  I know that isn't much consolation to you at this point.  I'm trying to author a post to explain the differences in types of memory leaks and how this one is different at a technical level.  We have now, however, added some test cases in place in our toolset to look for these 'soft leak' situations.  There is some native->managed stuff happening here and this is one of those areas.

    Tuesday, September 07, 2010 11:44 PM
  • Tim,

    It would be very useful and helpful for everyone if you could also post:

    1. "Best practices" to avoid memory leaks with Silverlight (or Silverlight 4) with special focus on event handlers (especially with user controls and popup controls), datatemplates, styles, etc.

    2. Best tools to help identify possible causes of memory leaks with Silverlight applications

    3. General guidelines or steps to simplify XAML/Code for performance optimization and reduced XAP size (generic and not MVVM specific)

    The 3rd one is bonus to us since we have been patient with the fixes! :)

    Wednesday, September 08, 2010 12:08 AM
  • I vote with valiant.

    I add another important point (perhaps related to telerik library) : how to use Telerik controls now, before the next release, to avoid Mem. Leaks ?

    Wednesday, September 08, 2010 1:25 AM
  • I agree ... several Telerik controls are leaking (their SL equivalents are not leaking with the latest fix and the resource workaround). We need workarounds/fixes for those too. Especially the datagrid, treeview and combobox. 

    Wednesday, September 08, 2010 1:55 AM
  • Hi all,

    Please find the answer to your Telerik releated question on Telerik forums here. If you have any Telerik releated problem please share it on our forums, because this way it will be handled by the same team members authering the respective control. Alternatively you can send me an email (on the address mentioned above) and I will connect you with the appropriate team.

    Thanks,

    Stefan

    Wednesday, September 08, 2010 5:26 AM
  • Hi,

    I think no one answered a question I asked. Does declaring inline datatemplates inside static resource datatemplates still leak? 

    Best regards,

    Manuel Felício,

    Wednesday, September 08, 2010 6:47 AM
  • Actually it still leaks almost everywhere.

    After moving all of my inline templates to static resources - first I've found that memory leaks were gone, then I've realized that editing datagrid - causing memory leaks too.

    So I simply refactored all of my Navigation based pages to UserControl, I preload them on first time, and reuse them. And my app became much more faster :)

    Wednesday, September 08, 2010 7:31 AM
  • Actually it still leaks almost everywhere.

    After moving all of my inline templates to static resources - first I've found that memory leaks were gone, then I've realized that editing datagrid - causing memory leaks too.

    So I simply refactored all of my Navigation based pages to UserControl, I preload them on first time, and reuse them. And my app became much more faster :)

     

    That's actually a great idea. For people who use MVVM, we simply need to switch the datacontext and we can reuse a lot of views since they're never gone. Voted!

    Wednesday, September 08, 2010 7:49 AM
  • I just want to second the request that any fix you come up with be released to more than just the 350 testers you had "test" the last one. You can say what you want about them being "real", but the fact is none of them found these issues over the course of several months, and it took a few people in this thread less than 24 hours. If you have a policy that's not working, just change it. It benefits you and us.

    Any guidance you can give regarding a timeline would be greatly appreciated. Unfortunately, I'm very close to the point of having to switch to a different technology. My customers don't want to hear excuses. They'll just go find another company who can deliver a product that works in the real world. As much as I like what Silverlight promises, I may be forced to do the same. I'm sure I'm not the only one.

    Wednesday, September 08, 2010 9:12 AM
  • Infragistics XamGrid and XamCombo leak as well from what I can see... I applied the patch and they appear to be leaking still.


    Wednesday, September 08, 2010 10:19 AM
  • With all due respect, the lack of any approximate time frame is appalling.   I understand and appreciate the many directions that the Silverlight team, like any dev team, is pulled on a daily basis.  However, this is a HUGE issue.  After attending the last SL deep dive, we made the jump to start porting our line of business applications to Silverlight.  However, with the current memory leaks our application becomes unstable after about 15 minutes of use.  We've been incredibly worried about this for months but thought, hey everybody understands the critical nature of memory leaks, Microsoft will get us home and fix it.  We've been waiting months for an update that addresses the issue, the whole time in the dark as to when we might finally receive it; and when we finally do it falls so short that I'm now faced with having to come up with something to tell my customers.  Either 1) why our new application sucks so much that they really can't even use it or 2) why it is delayed and oh yeah, sorry but I don't have a timeline for delivery. 

    Microsoft is touting Silverlight as a line of business platform.  The people on this thread are not building a cute little video player out on the web.  This is enterprise, what companies rely on each and every day to run their businesses.  When a customer reports a critical bug to us, we're fixing it immediately.  We're on hourly or daily calls with updates until it's resolved.  If I told them "sorry, I just don't have a time frame unfortunately" I'd lose all of my customers in very short order. 

    I can't stress enough how important this issue is, not just to us but to every company out there building or considering building line of business applications on Silverlight.  If this isn't addressed shortly, there's no way anybody out there is going to risk their neck and say, hey, lets build this new app on Silverlight - they'd be a fool...

    I urge you to work with the dev team to resolve this/these leaks as quickly as possible WHILE providing communication back to the community on progress and time lines.  None of us can build in the dark.  We need all of the help we can get if this is going to be a viable  platform for these types of applications.

    Best Regards

    Geoff

    Wednesday, September 08, 2010 10:56 AM
  • Here is a tool that can be used to demonstrate the memory leak of inline datatemplates.  It can also be used to test other third party controls (Telerik, Infragistic, DevExpres,etc...) to see if the UIElement derived control can be properly garbage collected.

    http://www.devtoolshed.com/silverlight-memory-leak-datagrid-dataform-datatemplate-etc

     

    Wednesday, September 08, 2010 12:59 PM
  • Hi Tim.

     

    Please! Please! Publish a public beta next time. I swear I knew (like many other people in here) that this was going to happen.

     

    Best Regards.   

    Wednesday, September 08, 2010 3:41 PM
  • Tim,

    Sorry for the endless posts - but customers and organizations that I deal with are getting very upset about this whole thing. It is extremely embarrassing and difficult to explain to people about these crazy issues in Silverlight 4. I back the urgency to fix this problem with renewed interest. Microsoft has to learn to LISTEN, adjust and make provisions for urgent bug fixes and releases. The Silverlight team at this time cannot afford to go by the book and the long useless process that has set in at Microsoft to produce service releases and updates. Don't people at Microsoft learn anything from Google, Mozilla or other competitors out there? Fixes are relatively quick and work when released.

    Please do not tell us that you guys are going to address several other issues and delay these urgent memory leak fixes and go into endless regression testing. It is unacceptable no matter what the costs because in this case it is Microsoft's fault we are in this position today.

    I am also very disappointed by Scott Guthrie. He seems to be there in all big Microsoft/Silverlight announcements. It seems he is usually never around to help the team get their act together or get more resources to get a fix in place that has been known since March of this year?! I posted a query a few weeks back in one of his posts regarding this same issue - he never bothered to reply. Further, if you cannot give us approximate dates for the fixes due to whatever reasons, may be Scott has the authority to give us an estimate for this fix in near future.

    I don't want to sound like I am giving you guys a beating, it's just all very disappointing - especially when these things used to work just fine in Silverlight 2 and 3.

     

    Thursday, September 09, 2010 12:54 AM
  • I have ran a test and some the following Infragistic Controls appear to be leaking:


    ***    Possible memory leaks in the objects below or their children.   ***
    *** Clear memory again and see if any of the objects free from memory. ***
    Infragistics.Controls.Grids.XamGrid
    Infragistics.Controls.Editors.XamComboEditor
    Infragistics.Controls.Menus.XamOutlookBar
    Infragistics.Controls.Menus.XamMenuItem
    ----
    GC.GetTotalMemory(true): 832388 Bytes, 0 MB

    Thursday, September 09, 2010 10:18 AM
  • @gmcalab - Good discovery.  You used the tool from DevToolShed mentioned above.  I used it yesterday and discovered that the RichEdit control from DevExpress also leaks.  I then used WinDbg to the control was still hanging onto two event handlers.

    Were you able to attach Windbg and figure out if the Infragistics controls are leaking due to the DataTemplate leak?

    Thursday, September 09, 2010 10:35 AM
  • Here is a tool that can be used to demonstrate the memory leak of inline datatemplates. 

    Very nice tool.  I can now see exactly which controls are leaking.  

    I'm concerned because even one very simple control that we use is leaking.  It has nothing to do with data grids, but rather, it contains a simple ContentControl that has its template defined inline within its style.  I would think that would be the most basic test for verifying the inline template memory leak fix.  Here's the UserControl's definition:


    <UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
                 xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
                 xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:local="clr-namespace:Company.Product.UI.Views" 
                 x:Class="Company.Product.UI.Views.SettingsPanel"
                 mc:Ignorable="d" xmlns:u="clr-namespace:Company.Product.UI.Utils">
      <ContentControl Style="{StaticResource SettingsPanelContentStyle}" 
                      VerticalContentAlignment="Stretch" x:Name="PanelContent"
                      HorizontalContentAlignment="Stretch">
        <ContentPresenter/>
      </ContentControl>
    </UserControl>
    


    And here's the style resource it uses:


      <Style x:Key="SettingsPanelContentStyle" TargetType="ContentControl">
        <Setter Property="Foreground" Value="#FF000000"/>
        <Setter Property="HorizontalContentAlignment" Value="Left"/>
        <Setter Property="VerticalContentAlignment" Value="Top"/>
        <Setter Property="Template">
          <Setter.Value>
            <ControlTemplate TargetType="ContentControl">
    <!-- Truncated long designer-generated content -->
    </ControlTemplate> </Setter.Value> </Setter> <Setter Property="Height" Value="155"/> <Setter Property="Padding" Value="10"/> <Setter Property="HorizontalAlignment" Value="Stretch"/> </Style>


    If something as simple as a ContentControl hasn't been fixed, what exactly was fixed?

    (Adding my torch and pitchfork to the crowd.  Please focus on fixing this memory leak before anything else!)

    Thursday, September 09, 2010 11:51 AM
  • Apoco: is this a Popup by any chance?

    Thursday, September 09, 2010 2:23 PM
  • Apoco: is this a Popup by any chance?

    No, it's not displayed in a popup.

    Thursday, September 09, 2010 2:30 PM
  • Apoco: are you running the latest version of Silverlight (4.0.50826.0)?  I don't see your sample repro here leaking.

    Thursday, September 09, 2010 2:31 PM
  • @heuertk - Apoco is using the tool found here to find memory leaks:

    http://www.devtoolshed.com/silverlight-memory-leak-datagrid-dataform-datatemplate-etc

    It is a VS2010 solution.  Please take the time to download it and include something similar to this in your Silverlight testing.

    The program dynamically creates UIElement derived objects and adds them programmatically to a StackPanel and a WeakReference list.  They are then removed and a garbage collection done.  If the objects still exist and are alive in the WeakReference list, I call that a memory leak.

    Thursday, September 09, 2010 2:54 PM
  • slimtim: yes I know...but using his apoco's markup above I don't see it leaking (perhaps the truncated designer stuff not present here is the issue).

    Thursday, September 09, 2010 2:56 PM
  • are you running the latest version of Silverlight (4.0.50826.0)?


    Yes, the Microsoft Silverlight Configuration dialog shows version 4.0.50826.0.

    I don't see your sample repro here leaking.

    Strangely, when running the leak tester application with the debugger, the tool reports the leaking objects, but when it's run without the debugger, it reports no leaks.  In either case, the memory usage is shown to be increasing.

    Here's the full style without the template truncated in case that matters.  I'd truncated it before because it contains a lot of imported-from-Illustrator XAML.

      <Style x:Key="SettingsPanelContentStyle" TargetType="ContentControl">
        <Setter Property="Foreground" Value="#FF000000"/>
        <Setter Property="HorizontalContentAlignment" Value="Left"/>
        <Setter Property="VerticalContentAlignment" Value="Top"/>
        <Setter Property="Template">
          <Setter.Value>
            <ControlTemplate TargetType="ContentControl">
              <Grid>
                <Grid x:Name="menu_background" Height="2" VerticalAlignment="Top">
                  <Path Data="M0,155L1000,155L1000,0L0,0z" Stretch="Fill" Margin="0,0,0,-153" UseLayoutRounding="False">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                        <GradientStop Color="#FF191919" Offset="0"/>
                        <GradientStop Color="#FF191919" Offset="0.095245398581027985"/>
                        <GradientStop Color="#FF222222" Offset="0.91111797094345093"/>
                        <GradientStop Color="#FF222222" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                  </Path>
                  <Path Data="F1M0,1L1000,1L1000,0L0,0z" Fill="#FF0D0D0D" Height="1" Stretch="Fill" Margin="0" UseLayoutRounding="False" VerticalAlignment="Top"/>
                  <Path Data="M0,2L1000,2L1000,1L0,1z" Height="1" Stretch="Fill" Margin="0" UseLayoutRounding="False" VerticalAlignment="Bottom">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">
                        <GradientStop Color="#FF191919" Offset="0"/>
                        <GradientStop Color="#FF313131" Offset="0.15237399935722351"/>
                        <GradientStop Color="#FF595959" Offset="0.3238070011138916"/>
                        <GradientStop Color="#FF272727" Offset="0.51745599508285522"/>
                        <GradientStop Color="#FF595959" Offset="0.6888890266418457"/>
                        <GradientStop Color="#FF6D6D6D" Offset="0.7873079776763916"/>
                        <GradientStop Color="#FF3B3B3B" Offset="0.91429102420806885"/>
                        <GradientStop Color="#FF1B1B1B" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                  </Path>
                </Grid>
                <Canvas x:Name="menu_main_left" Width="485" HorizontalAlignment="Left" Margin="10,10,0,10">
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-10,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="13,11">
                          <BezierSegment Point3="10,14" Point2="10,12.344" Point1="11.344,11"/>
                          <LineSegment Point="10,14"/>
                          <LineSegment Point="10,141"/>
                          <BezierSegment Point3="13,144" Point2="11.344,144" Point1="10,142.656"/>
                          <LineSegment Point="13,144"/>
                          <LineSegment Point="495,144"/>
                          <LineSegment Point="495,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M13,11C11.344,11,10,12.344,10,14L10,14L10,141C10,142.656,11.344,144,13,144L13,144L495,144L495,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="sc#1, 0.001517635, 0.001517635, 0.001517635" Offset="0.30707874894142151"/>
                          <GradientStop Color="#FF0A0A0A" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="sc#0.196078435, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.14705883, 0, 0, 0" Offset="0.30707874894142151"/>
                          <GradientStop Color="sc#0.09803922, 0, 0, 0" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-10,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="13,11">
                          <BezierSegment Point3="10,14" Point2="10,12.344" Point1="11.344,11"/>
                          <LineSegment Point="10,14"/>
                          <LineSegment Point="10,141"/>
                          <BezierSegment Point3="13,144" Point2="11.344,144" Point1="10,142.656"/>
                          <LineSegment Point="13,144"/>
                          <LineSegment Point="495,144"/>
                          <LineSegment Point="495,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M13,11C11.344,11,10,12.344,10,14L10,14L10,141C10,142.656,11.344,144,13,144L13,144L495,144L495,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="Black" Offset="0.8571469783782959"/>
                          <GradientStop Color="Black" Offset="0.97460901737213135"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.52323947169497842"/>
                          <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.65990843625158391"/>
                          <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.75142497933420316"/>
                          <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.82263761344812281"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.8571469783782959"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.8571469783782959"/>
                          <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.94964087143647669"/>
                          <GradientStop Color="Black" Offset="0.97460901737213135"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-10,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="13,11">
                          <BezierSegment Point3="10,14" Point2="10,12.344" Point1="11.344,11"/>
                          <LineSegment Point="10,14"/>
                          <LineSegment Point="10,141"/>
                          <BezierSegment Point3="13,144" Point2="11.344,144" Point1="10,142.656"/>
                          <LineSegment Point="13,144"/>
                          <LineSegment Point="495,144"/>
                          <LineSegment Point="495,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M13,11C11.344,11,10,12.344,10,14L10,14L10,141C10,142.656,11.344,144,13,144L13,144L495,144L495,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="Black" Offset="0.87301599979400635"/>
                          <GradientStop Color="Black" Offset="0.97778302431106567"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                          <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.53292660656370572"/>
                          <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.67212582880087268"/>
                          <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.76533668804945165"/>
                          <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.83786773644275314"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.87301599979400635"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.87301599979400635"/>
                          <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.95551336449903246"/>
                          <GradientStop Color="Black" Offset="0.97778302431106567"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-10,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="13,11">
                          <BezierSegment Point3="10,14" Point2="10,12.344" Point1="11.344,11"/>
                          <LineSegment Point="10,14"/>
                          <LineSegment Point="10,141"/>
                          <BezierSegment Point3="13,144" Point2="11.344,144" Point1="10,142.656"/>
                          <LineSegment Point="13,144"/>
                          <LineSegment Point="495,144"/>
                          <LineSegment Point="495,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M13,11C11.344,11,10,12.344,10,14L10,14L10,141C10,142.656,11.344,144,13,144L13,144L495,144L495,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0,0.5" StartPoint="1,0.5">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="Black" Offset="0.9700009822845459"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0,0.5" StartPoint="1,0.5">
                          <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.592130421406182"/>
                          <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.74679354594817937"/>
                          <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.8503593741254889"/>
                          <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.93094803252834879"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.9700009822845459"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.9700009822845459"/>
                          <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.99362330891031025"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Path Data="F1M12.218,144L13,145L495,145L495,144z" Height="1" Canvas.Left="2.218" Stretch="Fill" Canvas.Top="134" Width="482.782">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">
                        <GradientStop Color="#FF2D2D2D" Offset="0"/>
                        <GradientStop Color="sc#1, 0.0278652329, 0.0278652329, 0.0278652329" Offset="0.23254890746284218"/>
                        <GradientStop Color="sc#1, 0.03139607, 0.03139607, 0.03139607" Offset="0.29329015522987589"/>
                        <GradientStop Color="sc#1, 0.03608007, 0.03608007, 0.03608007" Offset="0.33396383001916163"/>
                        <GradientStop Color="sc#1, 0.041681882, 0.041681882, 0.041681882" Offset="0.36561362166637323"/>
                        <GradientStop Color="sc#1, 0.045186203, 0.045186203, 0.045186203" Offset="0.38095098733901978"/>
                        <GradientStop Color="#FF3C3C3C" Offset="0.38095098733901978"/>
                        <GradientStop Color="sc#1, 0.0357137136, 0.0357137136, 0.0357137136" Offset="0.82977171954971551"/>
                        <GradientStop Color="#FF2D2D2D" Offset="0.9509279727935791"/>
                        <GradientStop Color="#FF2D2D2D" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                  </Path>
                  <Path Data="F1M13,10L12,11L495,11L495,10z" Height="1" Canvas.Left="2" Stretch="Fill" Canvas.Top="0" Width="483">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">
                        <GradientStop Color="#FF2D2D2D" Offset="0"/>
                        <GradientStop Color="sc#1, 0.0278652329, 0.0278652329, 0.0278652329" Offset="0.23254890746284218"/>
                        <GradientStop Color="sc#1, 0.03139607, 0.03139607, 0.03139607" Offset="0.29329015522987589"/>
                        <GradientStop Color="sc#1, 0.03608007, 0.03608007, 0.03608007" Offset="0.33396383001916163"/>
                        <GradientStop Color="sc#1, 0.041681882, 0.041681882, 0.041681882" Offset="0.36561362166637323"/>
                        <GradientStop Color="sc#1, 0.045186203, 0.045186203, 0.045186203" Offset="0.38095098733901978"/>
                        <GradientStop Color="#FF3C3C3C" Offset="0.38095098733901978"/>
                        <GradientStop Color="sc#1, 0.0357137136, 0.0357137136, 0.0357137136" Offset="0.82977171954971551"/>
                        <GradientStop Color="#FF2D2D2D" Offset="0.9509279727935791"/>
                        <GradientStop Color="#FF2D2D2D" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                  </Path>
                </Canvas>
                <Canvas x:Name="menu_main_right" Width="485" HorizontalAlignment="Right" Margin="0,10,10,10">
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-505,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="505,11">
                          <LineSegment Point="505,144"/>
                          <LineSegment Point="987,144"/>
                          <BezierSegment Point3="990,141" Point2="990,142.656" Point1="988.656,144"/>
                          <LineSegment Point="990,141"/>
                          <LineSegment Point="990,14"/>
                          <BezierSegment Point3="987,11" Point2="988.656,11" Point1="990,12.344"/>
                          <LineSegment Point="987,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M505,11L505,144L987,144C988.656,144,990,142.656,990,141L990,141L990,14C990,12.344,988.656,11,987,11L987,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="sc#1, 0.001517635, 0.001517635, 0.001517635" Offset="0.30707874894142151"/>
                          <GradientStop Color="#FF0A0A0A" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="sc#0.196078435, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.14705883, 0, 0, 0" Offset="0.30707874894142151"/>
                          <GradientStop Color="sc#0.09803922, 0, 0, 0" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-505,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="505,11">
                          <LineSegment Point="505,144"/>
                          <LineSegment Point="987,144"/>
                          <BezierSegment Point3="990,141" Point2="990,142.656" Point1="988.656,144"/>
                          <LineSegment Point="990,141"/>
                          <LineSegment Point="990,14"/>
                          <BezierSegment Point3="987,11" Point2="988.656,11" Point1="990,12.344"/>
                          <LineSegment Point="987,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M505,11L505,144L987,144C988.656,144,990,142.656,990,141L990,141L990,14C990,12.344,988.656,11,987,11L987,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="Black" Offset="0.8571469783782959"/>
                          <GradientStop Color="Black" Offset="0.97460901737213135"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                          <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.52323947169497842"/>
                          <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.65990843625158391"/>
                          <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.75142497933420316"/>
                          <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.82263761344812281"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.8571469783782959"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.8571469783782959"/>
                          <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.94964087143647669"/>
                          <GradientStop Color="Black" Offset="0.97460901737213135"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-505,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="505,11">
                          <LineSegment Point="505,144"/>
                          <LineSegment Point="987,144"/>
                          <BezierSegment Point3="990,141" Point2="990,142.656" Point1="988.656,144"/>
                          <LineSegment Point="990,141"/>
                          <LineSegment Point="990,14"/>
                          <BezierSegment Point3="987,11" Point2="988.656,11" Point1="990,12.344"/>
                          <LineSegment Point="987,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M505,11L505,144L987,144C988.656,144,990,142.656,990,141L990,141L990,14C990,12.344,988.656,11,987,11L987,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="Black" Offset="0.87301599979400635"/>
                          <GradientStop Color="Black" Offset="0.97778302431106567"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                          <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.53292660656370572"/>
                          <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.67212582880087268"/>
                          <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.76533668804945165"/>
                          <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.83786773644275314"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.87301599979400635"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.87301599979400635"/>
                          <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.95551336449903246"/>
                          <GradientStop Color="Black" Offset="0.97778302431106567"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Canvas Height="133" Canvas.Left="0" Canvas.Top="1" Width="485">
                    <Canvas.Clip>
                      <PathGeometry FillRule="Nonzero">
                        <PathGeometry.Transform>
                          <MatrixTransform Matrix="1,0,0,1,-505,-11"/>
                        </PathGeometry.Transform>
                        <PathFigure IsClosed="True" StartPoint="505,11">
                          <LineSegment Point="505,144"/>
                          <LineSegment Point="987,144"/>
                          <BezierSegment Point3="990,141" Point2="990,142.656" Point1="988.656,144"/>
                          <LineSegment Point="990,141"/>
                          <LineSegment Point="990,14"/>
                          <BezierSegment Point3="987,11" Point2="988.656,11" Point1="990,12.344"/>
                          <LineSegment Point="987,11"/>
                        </PathFigure>
                      </PathGeometry>
                    </Canvas.Clip>
                    <Path Data="F1M505,11L505,144L987,144C988.656,144,990,142.656,990,141L990,141L990,14C990,12.344,988.656,11,987,11L987,11z" Height="133" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="485">
                      <Path.Fill>
                        <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">
                          <GradientStop Color="Black" Offset="0"/>
                          <GradientStop Color="Black" Offset="0.9700009822845459"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.Fill>
                      <Path.OpacityMask>
                        <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">
                          <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                          <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.592130421406182"/>
                          <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.74679354594817937"/>
                          <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.8503593741254889"/>
                          <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.93094803252834879"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.9700009822845459"/>
                          <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.9700009822845459"/>
                          <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.99362330891031025"/>
                          <GradientStop Color="Black" Offset="1"/>
                        </LinearGradientBrush>
                      </Path.OpacityMask>
                    </Path>
                  </Canvas>
                  <Path Data="F1M505,144L505,145L987,145L987.781,144z" Height="1" Canvas.Left="0" Stretch="Fill" Canvas.Top="134" Width="482.781">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="0,0.5" StartPoint="1,0.5">
                        <GradientStop Color="#FF2D2D2D" Offset="0"/>
                        <GradientStop Color="sc#1, 0.0308684018, 0.0308684018, 0.0308684018" Offset="0.23254890746284218"/>
                        <GradientStop Color="sc#1, 0.040928565, 0.040928565, 0.040928565" Offset="0.29329015522987589"/>
                        <GradientStop Color="sc#1, 0.0542743653, 0.0542743653, 0.0542743653" Offset="0.33396383001916163"/>
                        <GradientStop Color="sc#1, 0.07023521, 0.07023521, 0.07023521" Offset="0.36561362166637323"/>
                        <GradientStop Color="sc#1, 0.08021982, 0.08021982, 0.08021982" Offset="0.38095098733901978"/>
                        <GradientStop Color="#FF505050" Offset="0.38095098733901978"/>
                        <GradientStop Color="sc#1, 0.05323052, 0.05323052, 0.05323052" Offset="0.82977171954971551"/>
                        <GradientStop Color="#FF2D2D2D" Offset="0.9509279727935791"/>
                        <GradientStop Color="#FF2D2D2D" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                  </Path>
                  <Path Data="F1M505,10L505,11L988,11L987,10z" Height="1" Canvas.Left="0" Stretch="Fill" Canvas.Top="0" Width="483">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="0,0.5" StartPoint="1,0.5">
                        <GradientStop Color="#FF2D2D2D" Offset="0"/>
                        <GradientStop Color="sc#1, 0.0308684018, 0.0308684018, 0.0308684018" Offset="0.23254890746284218"/>
                        <GradientStop Color="sc#1, 0.040928565, 0.040928565, 0.040928565" Offset="0.29329015522987589"/>
                        <GradientStop Color="sc#1, 0.0542743653, 0.0542743653, 0.0542743653" Offset="0.33396383001916163"/>
                        <GradientStop Color="sc#1, 0.07023521, 0.07023521, 0.07023521" Offset="0.36561362166637323"/>
                        <GradientStop Color="sc#1, 0.08021982, 0.08021982, 0.08021982" Offset="0.38095098733901978"/>
                        <GradientStop Color="#FF505050" Offset="0.38095098733901978"/>
                        <GradientStop Color="sc#1, 0.05323052, 0.05323052, 0.05323052" Offset="0.82977171954971551"/>
                        <GradientStop Color="#FF2D2D2D" Offset="0.9509279727935791"/>
                        <GradientStop Color="#FF2D2D2D" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                  </Path>
                </Canvas>
                <Grid x:Name="menu_main_center" Margin="495,10">
                  <Path Data="M505,144L495,144L495,11L505,11z" Stretch="Fill" Margin="0,1" UseLayoutRounding="False">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                        <GradientStop Color="Black" Offset="0"/>
                        <GradientStop Color="sc#1, 0.001517635, 0.001517635, 0.001517635" Offset="0.30707874894142151"/>
                        <GradientStop Color="#FF0A0A0A" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                    <Path.OpacityMask>
                      <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                        <GradientStop Color="sc#0.196078435, 0, 0, 0" Offset="0"/>
                        <GradientStop Color="sc#0.14705883, 0, 0, 0" Offset="0.30707874894142151"/>
                        <GradientStop Color="sc#0.09803922, 0, 0, 0" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.OpacityMask>
                  </Path>
                  <Path Data="M505,144L495,144L495,11L505,11z" Stretch="Fill" Margin="0,1" UseLayoutRounding="False">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                        <GradientStop Color="Black" Offset="0"/>
                        <GradientStop Color="Black" Offset="0.8571469783782959"/>
                        <GradientStop Color="Black" Offset="0.97460901737213135"/>
                        <GradientStop Color="Black" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                    <Path.OpacityMask>
                      <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                        <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                        <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.52323947169497842"/>
                        <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.65990843625158391"/>
                        <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.75142497933420316"/>
                        <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.82263761344812281"/>
                        <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.8571469783782959"/>
                        <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.8571469783782959"/>
                        <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.94964087143647669"/>
                        <GradientStop Color="Black" Offset="0.97460901737213135"/>
                        <GradientStop Color="Black" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.OpacityMask>
                  </Path>
                  <Path Data="M505,144L495,144L495,11L505,11z" Stretch="Fill" Margin="0,1" UseLayoutRounding="False">
                    <Path.Fill>
                      <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                        <GradientStop Color="Black" Offset="0"/>
                        <GradientStop Color="Black" Offset="0.87301599979400635"/>
                        <GradientStop Color="Black" Offset="0.97778302431106567"/>
                        <GradientStop Color="Black" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.Fill>
                    <Path.OpacityMask>
                      <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
                        <GradientStop Color="sc#0, 0, 0, 0" Offset="0"/>
                        <GradientStop Color="sc#0.00571483327, 0, 0, 0" Offset="0.53292660656370572"/>
                        <GradientStop Color="sc#0.0181397088, 0, 0, 0" Offset="0.67212582880087268"/>
                        <GradientStop Color="sc#0.03462254, 0, 0, 0" Offset="0.76533668804945165"/>
                        <GradientStop Color="sc#0.054335095, 0, 0, 0" Offset="0.83786773644275314"/>
                        <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.87301599979400635"/>
                        <GradientStop Color="sc#0.06666667, 0, 0, 0" Offset="0.87301599979400635"/>
                        <GradientStop Color="sc#0.533333361, 0, 0, 0" Offset="0.95551336449903246"/>
                        <GradientStop Color="Black" Offset="0.97778302431106567"/>
                        <GradientStop Color="Black" Offset="1"/>
                      </LinearGradientBrush>
                    </Path.OpacityMask>
                  </Path>
                  <Path Data="F1M495,145.0001L505,144.9601L505,144.0331L495,144.0001z" Fill="#FF2D2D2D" Height="1" Stretch="Fill" UseLayoutRounding="False" VerticalAlignment="Bottom"/>
                  <Path Data="F1M495,11L505,11L505,10L495,10z" Fill="#FF2D2D2D" Height="1" Stretch="Fill" UseLayoutRounding="False" VerticalAlignment="Top"/>
                </Grid>
                <v:TiledImage Margin="0" Source="/Assets/Graphics/PresetEditor/Texture.png" Opacity="0.12" TileSize="100,100"/>
                <Path Data="M0,155L1000,155L1000,0L0,0z" Stretch="Fill" Margin="0" UseLayoutRounding="False">
                  <Path.Fill>
                    <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                      <GradientStop Color="Black" Offset="0"/>
                      <GradientStop Color="sc#1, 0.001517635, 0.001517635, 0.001517635" Offset="0.05264312408852577"/>
                      <GradientStop Color="#FF0A0A0A" Offset="0.1714320033788681"/>
                      <GradientStop Color="#FF0A0A0A" Offset="1"/>
                    </LinearGradientBrush>
                  </Path.Fill>
                  <Path.OpacityMask>
                    <LinearGradientBrush EndPoint="0.5,0" StartPoint="0.5,1">
                      <GradientStop Color="Black" Offset="0"/>
                      <GradientStop Color="sc#0.5, 0, 0, 0" Offset="0.05264312408852577"/>
                      <GradientStop Color="sc#0, 0, 0, 0" Offset="0.1714320033788681"/>
                      <GradientStop Color="sc#0, 0, 0, 0" Offset="1"/>
                    </LinearGradientBrush>
                  </Path.OpacityMask>
                </Path>
                <ContentPresenter Cursor="{TemplateBinding Cursor}" ContentTemplate="{TemplateBinding ContentTemplate}" Content="{TemplateBinding Content}" HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}" Margin="{TemplateBinding Padding}" VerticalAlignment="{TemplateBinding VerticalContentAlignment}"/>
              </Grid>
            </ControlTemplate>
          </Setter.Value>
        </Setter>
        <Setter Property="Height" Value="155"/>
        <Setter Property="Padding" Value="10"/>
        <Setter Property="HorizontalAlignment" Value="Stretch"/>
      </Style>
    



    Thursday, September 09, 2010 3:28 PM
  • Apoco - the tool is reporting the leaking objects, but when I put your template in a control and add it to this tester that everyone is using, it isn't showing the leak (only the inline template one is).

    Yes, the code for that tool only reports leaks in debug mode (per the code).

    Thursday, September 09, 2010 3:38 PM
  • The TiledImage control which I missed in my last post may have been the culprit for the leaked object being reported.  When it's removed, the leak tool stops showing my control as leaking.  However, the memory usage still shows the increased memory usage each time through even without it.  

    It seems that internal objects inside of the Silverlight framework are leaking.


    Thursday, September 09, 2010 3:40 PM
  • @Apoco -  That is interesting that the tool is saying that there are no memory leaks when the debugger is not attached.  I looked at the ObjectTracker class.  Change the line in ShouldTrack() from:

    _ShouldTrack = Debugger.IsAttached;

    to

    _ShouldTrack = true;

    This will allow the objects to be added to the weakreferencnce list regardless if the debugger is attached.

    Thursday, September 09, 2010 3:46 PM
  • How embarrassing... I didn't realize that I still had the test tool's sample controls still present when running this.  The memory is only increasing by a few hundred bytes each time around now, and that may be due to something in the tool itself rather than in Silverlight.

    So sorry everyone.  False alarm with the memory leak in this case.  Now I'm excited that we can maybe eliminate a lot of our memory issues through fixing our own leaks.  Thanks to the author of the tool for creating an easy-to-use app for also finding our own memory leaks, and thanks to Microsoft for investigating our issues.

    Thursday, September 09, 2010 4:00 PM
  • is this a Popup by any chance?

    Is there a known problem with Popups?  

    All of my ChildWindow-based controls are reported as leaking, and I wanted to make sure there's not already some known problems with them before diving in too deep.

    Thursday, September 09, 2010 4:52 PM
  • Here's details on another repro for the leak.  This is a really simple FrameworkElement with a DataTemplate property.  Even when not creating anything from the template, the control is not garbage collected.

    http://forums.silverlight.net/forums/p/200278/467789.aspx#467789


    Saturday, September 11, 2010 11:22 PM
  • Hi all, we wanted to get some documented workarounds to you about this issue and get feedback.  Yes I realize the best workaround is to "fix it" and that is a majority of the feedback -- trust me I have heard this loud and clear.  In the interim, here are some workarounds.

    Problem

    Using in-line DataTemplates in cases such as DataGridTemplateColumn.CellTemplate can cause soft memory leaks of the template of varying size.  Note we're using DataGrid here as an example, but it isn't limited to this area.

    Workaround 1 – Move template markup to Resources

    Given the following example:

    <sdk:DataGrid AutoGenerateColumns="False">
                <sdk:DataGrid.Columns>
                    <sdk:DataGridTemplateColumn>
                        <sdk:DataGridTemplateColumn.CellTemplate>
                            <DataTemplate x:Name="testTemplate">
                                <TextBlock Text="TextBlock"/>
                            </DataTemplate>
                        </sdk:DataGridTemplateColumn.CellTemplate>
                    </sdk:DataGridTemplateColumn>
                </sdk:DataGrid.Columns>
            </sdk:DataGrid>

    Moving to this example:

    <UserControl.Resources>
            <DataTemplate x:Name="testTemplate">
                <TextBlock Text="TextBlock"/>
            </DataTemplate>
        </UserControl.Resources>
    
        <Grid x:Name="LayoutRoot" Background="White">
            <sdk:DataGrid AutoGenerateColumns="False">
                <sdk:DataGrid.Columns>
                    <sdk:DataGridTemplateColumn CellTemplate="{StaticResource testTemplate}" />
                </sdk:DataGrid.Columns>
            </sdk:DataGrid>
            
        </Grid>


    will resolve the soft leak.  This would require developers to alter markup in any place where in-line DataTemplates occur.

    Workaround 2 – Code-based

    Given the following example:

    <Grid x:Name="LayoutRoot" Background="White">
            <controls:DataGrid AutoGenerateColumns="False" x:Name="foo2">
                <controls:DataGrid.Columns>
                    <controls:DataGridTemplateColumn>
                        <controls:DataGridTemplateColumn.CellTemplate>
                            <DataTemplate>
                                <TextBlock Text="{Binding Path=FirstName}"/>
                            </DataTemplate>
                        </controls:DataGridTemplateColumn.CellTemplate>
                    </controls:DataGridTemplateColumn>
                    
                    <controls:DataGridTemplateColumn>
                        <controls:DataGridTemplateColumn.CellTemplate>
                            <DataTemplate>
                                <TextBlock Text="{Binding Path=LastName}" FontSize="24" />
                            </DataTemplate>
                        </controls:DataGridTemplateColumn.CellTemplate>
                        <controls:DataGridTemplateColumn.CellEditingTemplate>
                            <DataTemplate>
                                <TextBox Text="{Binding Path=LastName}" FontSize="24" Foreground="Red" />
                            </DataTemplate>
                        </controls:DataGridTemplateColumn.CellEditingTemplate>
                    </controls:DataGridTemplateColumn>
                    
                    <controls:DataGridTextColumn Binding="{Binding Path=Age}" />
                    
                    <controls:DataGridTemplateColumn>
                        <controls:DataGridTemplateColumn.CellTemplate>
                            <DataTemplate>
                                <Slider Width="400" Value="{Binding Path=Ratio}" Minimum="0" Maximum="1" />
                            </DataTemplate>
                        </controls:DataGridTemplateColumn.CellTemplate>    
                    </controls:DataGridTemplateColumn>
                    
                </controls:DataGrid.Columns>
            </controls:DataGrid>
        </Grid>


    a developer can add code to the control constructor (or if no control, the container for the control…i.e., page UserControl) to set a property on a FrameworkElement to cause the runtime to unpeg the managed memory peer and release the memory.

    An example of this is below which would iterate through all the templates in a DataGrid and perform this operation.  Note that “DataGridInlineTemplate” is the name of the UserControl instance being used here.

    Canvas c = new Canvas();
    
            public DataGridInlineTemplate()
            {
                InitializeComponent();
    
                foreach (var item in foo2.Columns)
                {
                    try
                    {
    
                        if (item.GetType() == typeof(DataGridTemplateColumn))
                        {
                            DataGridTemplateColumn dtc = (DataGridTemplateColumn)item;
                            c.DataContext = dtc.CellTemplate;
                            c.DataContext = dtc.CellEditingTemplate;
                            c.DataContext = null;
                        }
                    }
                    catch
                    {
                        // these aren't the droids you are looking for
                    }
                }
    
                Loaded += new RoutedEventHandler(DataGridInlineTemplate_Loaded);
            }


    The immediate cause of this leak is due to a strong reference that Silverlight keeps to ensure that a managed object is not collected between the time that the object is created, and the time that it is referenced by a member on some other managed object.  The work-around provided here causes that strong reference to be removed.

    It should be noted that the removal of the strong reference (by the application of this work-around) must still occur after the inline FrameworkTemplate has been set as a value on a managed object.   Failure to ensure that the Template is referenced in some way could result in undefined behavior.

    Both workarounds require a change to code, either markup or managed code in an application.  A sample of these working solutions using the memory leak tester tool that the community is using is available here.

    Monday, September 13, 2010 7:51 PM
  • Apoco: is this a Popup by any chance?

    I've reproduced another memory leak that using data templates in resources does not resolve, and it only happens when using a Popup:

    <UserControl x:Class="SilverlightUIElementLeakTester.UserControls.ItemTemplateLeak"
                 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                 xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
                 xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
                 mc:Ignorable="d" d:DesignHeight="300" d:DesignWidth="400">
      <UserControl.Resources>
        <DataTemplate x:Key="TestItemTemplate">
          <StackPanel/>
        </DataTemplate>
      </UserControl.Resources>
      <Popup>
        <ItemsControl ItemTemplate="{StaticResource TestItemTemplate}"/>
      </Popup>
    </UserControl>
    


    If the ItemsControl is not inside of a Popup, then this control does not leak.  However, once the ItemsControl is inside of a Popup, it does.  Is there a workaround for this?

     

    Monday, September 13, 2010 10:26 PM
  • Hi heuertk, I've tried the workaround with the change to the managed code you've uploaded and when I tried to edit a cell in the grid and click Remove All the memory still leaks.

    Tuesday, September 14, 2010 2:32 AM
  • S. Dimitrov: are you sure?  we've checked this on a few environments.  Make sure you click 'remove' again.  The GC isn't always instant, but it recovers and collects.

    Tuesday, September 14, 2010 2:53 AM
  • I'm sorry, tried 'remove' once. You're right, after a second click it is cleared.


    Tuesday, September 14, 2010 2:57 AM
  • Any chances this could be happen in Silverlight 3 too? I have serious memory leakage issues.

    Tuesday, September 14, 2010 9:31 PM
  • We've found tons of memory leaks in our app when we were using Silverlight 3, but they were all our fault, and once we fixed them, our app didn't leak any more.

    I haven't run across any memory leak bugs in Silverlight 3 itself.

    Tuesday, September 14, 2010 9:39 PM
  • Rob263 -- Maybe you can tell any guidance on how I can prevent the memory leakage. My app is a MVVM Silverlight app, having several modules with DataGrid's in each of them. Even with each change of page the memory goes up in order of 5 or 10MB! After using the app for about 15 or 20 min. changing pages frequently, the consumption memory of the internet explorer goes up up to 500 or 600MB! sometimes more! so eventually the app crashes. Please I need any guidance on this. I'm using Silverlight 3.0

    Thanks.


    Wednesday, September 15, 2010 1:49 AM
  • Wednesday, September 15, 2010 8:19 AM
  • Hi Tim,

    Any updates on how things are progressing? Is there a way to get on a mailing list for when your team delivers releases?

    I'm certainly not pushing for a time-frame. Just wanted to know if I was missing the release.

    Tuesday, September 21, 2010 9:10 AM
  • If the ItemsControl is not inside of a Popup, then this control does not leak.  However, once the ItemsControl is inside of a Popup, it does.  Is there a workaround for this?
     

    I found out that if I created a new UserControl with the content of the Popup it would solve the leak. This behaved well with Apoco's ItemsControl and also in my case where I had bindings set inside the Popup that would also cause a leak.

    Another workaround I tested (needs more typing and didn't solve my "actions with triggers inside popup also leak case"), involved clearing all the bindings in the UserControl Unloaded event, like this:

    void SilverlightControl2_Unloaded(object sender, RoutedEventArgs e)
    {
        var tb = MyPopup.FindName("MyTextBlock"as TextBlock;
        tb.ClearValue(TextBlock.TextProperty);
    }
    In this case the bindings should also be set in the Loaded event, in case the UserControl should load again, instead of beeing set in xaml.  

    For the ItemsControl case used something like this:

    void SilverlightControl1_Loaded(object sender, RoutedEventArgs e)
    {
        var ic = MyPopup.FindName("MyItemsControl"as ItemsControl;
        ic.SetValue(ItemsControl.ItemTemplateProperty, Resources["TestItemTemplate"]);
    }
    void SilverlightControl1_Unloaded(object sender, RoutedEventArgs e)
    {
        var ic = MyPopup.FindName("MyItemsControl"as ItemsControl;
        ic.ClearValue(ItemsControl.ItemTemplateProperty);
    }

     

    PS: Can anyone please tell me how to format a nice code block when posting?

    Tuesday, September 21, 2010 1:25 PM
  • cademoor: no release timeframe updates right now.  We haven't received negative feedback on the workarounds (other than it takes time to go back and change an app, which does suck).  We are fixing the issue, but no update on when that update will come out just yet.

    Tuesday, September 21, 2010 1:35 PM
  • Please be aware that your workarounds don't work when you have licensed third party controls and the controls don't have the workaround in them (Telerik, some DevExpress controls, etc.). It sounds like the sense of urgency you originally had has waned since you have provided some workarounds. I assumed you guys were working around the clock to fix these bugs since the "leak-free" version came out. Just because we're not in here 24/7 providing "negative feedback" doesn't mean there shouldn't be a rush to get them fixed.

    On a different topic, are you aware of a bug with binding to a RIA Services Entity? I have a memory leak if I do so that does not exist when I bind to a POCO. Before I work on a repro, I wanted to see if this is a known issue.

    Tuesday, September 21, 2010 1:53 PM
  • Thanks Tim. Just wanted to make sure I wasn't missing anything. 

    Tuesday, September 21, 2010 1:58 PM
  • fwanicka: actually the workaround can be applied to Telerik and others as well.  Here's the example using the workaround for Telerik RadGridView:

    foreach (var item in radGridView1.Columns)
                {
                    try
                    {
                        GridViewBoundColumnBase dtc = (GridViewBoundColumnBase)item;
                        if (item != null)
                        {
                            c.DataContext = dtc.CellTemplate;
                            c.DataContext = dtc.CellEditTemplate;
                            c.DataContext = null;
                        }
                    }
                    catch
                    {
                        // move along
                    }
                }

    As to the sense of urgency -- it is still urgent to me.  I've been working with our lead dev on this area to ensure our fix is solid.  We also created new test harness in an attempt to identify these different types of leaks in our test passes.  The timing of releasing this fix is now the only thing to be decided.  I'm pushing for as soon as possible as always, but I'm not the only decision maker or forces at play.

    Tuesday, September 21, 2010 3:54 PM
  • Well here is some negative feedback!

    I don't want to have to re-code a bunch of stuff in my LOB app being developed with Silverlight 4 to work around this bug - very inconvenient.

    We hoped to go live in a month and now that is looking really bad (as are we, and Microsoft for that matter).

    Is there somewhere else that I can see that you receive negative feedback on it?

     

    Wednesday, September 22, 2010 2:10 PM
  • mannaggia: As I stated above...clearly there is a NEGATIVE of having to do anything...we hear that.  However there is a workaround that, while painful, does work.

    There is no other place where feedback has been coming in other than here and my personal inbox :-)

    Wednesday, September 22, 2010 5:00 PM
  • Yes, it's a pain to re-think or re-code stuff. Been there, done that. Our project was hit by these leaks, but the way I see it our application has come out more robust and agile because of this. When we started out I assumed (the mother of all f*ckups) all low level stuff like GC was taken care of. Because of the bugs it wasn't and now - 2-3 weeks later - our application dynamically allocates usercontrols and windows, reusing them if GC haven't cleaned them out (everything is stored as weak references and reused if they're still alive). Now we're just waiting for Telerik to iron out a few issues (SP2 next week) and everything's golden.

    Wednesday, September 22, 2010 5:40 PM
  • Well, the workaround works in some cases for Telerik controls, but not all. For example, the instant you add a ComboBox, before ever setting a property, it leaks.  

    Wednesday, September 22, 2010 7:58 PM
  • You know what Tim? This is not working out. I don't want to be forced to change my style of coding and live with work-arounds. Why the hell should we have to do low-level dirty digging for memory leaks for everything we do - just to be sure that its not something we or Microsoft did to cause a leak? We are Silverlight and .NET developers - not C/C++ programmers. Enough already. Just tell us when will the team fix the problem and release a stable Silverlight once and for all.

    I don't understand why you don't involve Scott Gu with this issue and ask for more urgent action.

    Listen to your customers and real users!

    Wednesday, September 22, 2010 10:16 PM
  • Well, the workaround works in some cases for Telerik controls, but not all. For example, the instant you add a ComboBox, before ever setting a property, it leaks.  

    I think that one is fixed in the latest internal build. Anyway, that's why I mentioned SP2 which will come out next week - Telerik is working actively on this and fixing leaks as they are reported (I reported a leak in the RadToolBar on monday and it's already fixed).

    Thursday, September 23, 2010 2:08 AM
  • Yea have to say i am quite happy with Telerik support. Just closed a ticket there with same memory problems with 3 controls: datepicker, combobox and scheduler. They have fixed them with workarounds (tested the Lastest Interals Build binaries) and service pack 2 will release next week indeed.

    Anyway thank you for you effort Tim Heuer, I know you do the best you can. I hope Microsoft will pay more attentions on QA for the next Silverlight releases. Silverlight becomes a very popular platform now, as developers we should able to trust the platform we are using, workarounds costs money, resources and our faith in Silverlight.

     

    Thursday, September 23, 2010 5:05 AM
  • valiant_sam: I totally understand the frustration.  Workarounds are not meant to be permanent but we at least wanted to provide you with options until a permanent runtime fix is available.  Hopefully you understand that.

    A fix has been investigated and being reviewed.  In addition to that we're seeing how much additional testing infrastructure we can add to find these soft leaks in the future.

    So here's the status: We have a fix.  We don't have a scheduled release date I can share at this point.  I can tell you that daily we're discussing this against a reasonable release schedule with our systems.  As soon as I have something to share on a date I will advise.

    And yes, thanks to Telerik who has been very understanding of this issue working with us and even going as far as releasing their own service pack including workarounds we've engaged with them on.

    Thursday, September 23, 2010 11:25 AM
  • last time it took 3 months to get from the "we have a fix" stage (message dated 06-01-2010 11:29 PM) to the actual release, I'm just curious are we talking about the same timeframe here or there is a possibility that the fix might come out sooner?


    Thursday, September 23, 2010 4:16 PM
  • We've gotta get this fixed ASAP Microsoft! Our customers need reliable software that doesn't eat up 10 MB of RAM in seconds

    Tuesday, September 28, 2010 2:13 PM
  • Yesterday evening, a new Silverlight version (4.0.50917.0) was rolled out through Microsoft Update. The kb article says:

    "This update fixes an incompatibility issue between Microsoft Silverlight 4 GDR 1 (4.0.50826.0) and earlier versions of the Bing Toolbar. The current release of Bing Toolbar (version 6) is not affected."

    Since the article does not list the fixed issues in particular (like previous articles did), I wonder if anything else (especially regarding this disussion) is included in the update?

    Wednesday, September 29, 2010 12:21 AM
  • 50917 included no other updates other than fixing a regression that prevented an app from functioning/updating.

    And no, no further timeline updates on this update :-(

    Wednesday, September 29, 2010 1:07 AM
  • Still, thank you for the very quick reply.

    Wednesday, September 29, 2010 1:20 AM
  • 50917 included no other updates other than fixing a regression that prevented an app from functioning/updating.

    And no, no further timeline updates on this update :-(

    So this is the big priority? Really? And you release an update that fixes just this one issue? I thought that was against your policy.

    No reply is needed. I'm just venting.

    Wednesday, September 29, 2010 8:33 AM
  • Question