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.

Answer 1

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.

Answer 2

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.

Answer 3

kornfish - running the code sample you have here in post-RC builds shows both reference returning false.

Answer 4

 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

Answer 5

Cheers Tim thats great news, can't wait for the final release.

Answer 6

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.

Answer 7

We have the same trouble with our application in Silverlight 4.

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

 

Answer 8

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.

Answer 9

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.

Answer 10

Hi all, we're taking a look at this.  We've got some additional repros from others as well to add to our investigation.

Answer 11

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....

Answer 12

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> 

  

Answer 13

Hi Tim,

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

Cheers

Answer 14

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>

 

Answer 15

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.

Answer 16

 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.

Answer 17

 Hi, are there guarantees that this problem will be solved in August?

Answer 18

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.

Answer 19

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.

Answer 20

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; i = 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; }

Answer 21

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.

Answer 22

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.

 

Answer 23

 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. 

Answer 24

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

Answer 25

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.

Answer 26

We have the same issue with SL4 compilation of our application. In SL4 bits UserControls are never GC..., in SL3 everything work fine !

:(

Answer 27

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.

 

 

Answer 28

It applies to any kind of templates that are inline, so it is possible that is the case.

Answer 29

 Hi Tim,

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

Answer 30

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.

Answer 31

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

Answer 32

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

Answer 33

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

 

 

Answer 34

 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 ?

Answer 35

Yes, it applies to all templates

Answer 36

 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.

Answer 37

 More memory leak found in SL4:

http://forums.silverlight.net/forums/t/181257.aspx

http://forums.silverlight.net/forums/t/180702.aspx

http://forums.silverlight.net/forums/t/179358.aspx

 

Answer 38

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.

Answer 39

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.

Answer 40

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.

Answer 41

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.

Answer 42

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.

Answer 43

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.

 

 

Answer 44

would you still use Jesse's pattern given that navigation is a part of the core framework now?

Answer 45

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.

 

Answer 46

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.

Answer 47

Our product is affected by the data template memory leak . Bump -- hoping MS releases a fix very soon.

Answer 48

 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?

Answer 49

We are also experiencing this issue and has really got us behind.

Answer 50

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.

Answer 51

*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.

Answer 52

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. 

Answer 53

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.

Answer 54

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.

Answer 55

The hotfix is not yet available.  As indicated the service release will be made public this summer.

Answer 56

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?

Answer 57

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.

 

Answer 58

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.

Answer 59

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.

 

Answer 60

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

 

Answer 61

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.

Answer 62

Does this summer mean by the end of August?

Answer 63

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. 

Answer 64

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.

 

Answer 65

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

Answer 66

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?

Answer 67

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.

Answer 68

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.

Answer 69

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.

Answer 70

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!

Answer 71

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.

Answer 72

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

Answer 73

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?

Answer 74

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.

Answer 75

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? 

Answer 76

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.

Answer 77

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.

 

Answer 78

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.

Answer 79

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.

Answer 80

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

Answer 81

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? 

 

Answer 82

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.

Answer 83

Any updates on when we will get the fix? 

 

 

 

Answer 84

[removed]

Answer 85

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.   

Answer 86

[removed]

Answer 87

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.

Answer 88

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.

Answer 89

Quite right.

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

apologies to anyone who took offense.

Answer 90

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.

Answer 91

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.

Answer 92

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.

Answer 93

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.

Answer 94

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

 

Answer 95

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

Answer 96

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. 

Answer 97

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. 

Answer 98

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.

Answer 99

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

Answer 100

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 

Answer 101

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.

Answer 102

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!

Answer 103

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.

Answer 104

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

 

Answer 105

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.

 

Answer 106

Excellent, thanks for the update, good to know there is some progress being made.

Answer 107

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>

Answer 108

I was wondering if there was any new updates as to when the service release will be coming out. 

Answer 109

shall219: that's the only piece of information I can't provide a firm date on right now.  very soon.

Answer 110

I understand, thanks... 

Answer 111

Is there a way to get our hands on an unofficial release so we can test it with our applications? 

Answer 112

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

Answer 113

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 ?

 

Answer 114

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

Answer 115

 Yeah, seeing how Tim promised it would be released during "summer", and summer ended yesterday, it would be nice to get an update.

Answer 116

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.

Answer 117

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. 

Answer 118

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

Answer 119

Thanks Tim!

Giving it a try now!

Answer 120

Thanks, but we're still showing increasing memory.  Ah well... back to my workaround.  Thanks for the efforts all the same.

Answer 121

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.

Answer 122

That's wonderful news!!!

 

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

Best regards,

Manuel Felício.

Answer 123

Under what category in connect.microsoft.com?  Silverlight isn't listed as a product.

Answer 124

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

Answer 125

Thanks, I'm seeing improvement in our application.

Answer 126

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.

Answer 127

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 

Answer 128

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. :)

Answer 129

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.

Answer 130

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.

Answer 131

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.

Answer 132

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.

Answer 133

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.

Answer 134

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?

Answer 135

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

Answer 136

Ok, so after uninstalling and installing in that order you no longer have memory leaks with inline DataTemplates within DatGridTemplateColumns nor TreeViewDragDropTargets?

Answer 137

I would think the answer was for your VS crash...

Answer 138

Exactly I mean that,

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

Answer 139

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.

Answer 140

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).

Answer 141

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.

Answer 142

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.

Answer 143

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.

Answer 144

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.

Answer 145

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.

Answer 146

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.

 

Answer 147

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.

Answer 148

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

Answer 149

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

 

 

Answer 150

The first sample fwanicka posted and I confirmed also uses the standard Silverlight Datagrid, no third party control of any kind.

Answer 151

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)

Answer 152

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 :(

Answer 153

I can also confirm that a lot of leaks were fixed with this build. 

Answer 154

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.

Answer 155

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...

Answer 156

I am also getting datatemplate leaks in the datagrid but also the dataform.  I will put together a repro.

Answer 157

slimtim...: please also send the repro of the DataForm one to me as well.

Answer 158

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

 

Answer 159

@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>

 

Answer 160

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>

Answer 161

 @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. 

Answer 162

This solution did fix my repro case with DataGrid 

Answer 163

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?

Answer 164

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...]

Answer 165

Hehe, actually we're discussing that this last update does not solve these issues.

Answer 166

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.. 

Answer 167

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?

Answer 168

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.

Answer 169

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>

 

Answer 170

@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. 

Answer 171

@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.

 

Answer 172

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?

Answer 173

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. 

Answer 174

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.

Answer 175

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.

 

Answer 176

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

Answer 177

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 

Answer 178

<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.

Answer 179

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.

Answer 180

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.

Answer 181

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)

Answer 182

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.

Answer 183

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? =)) 

Answer 184

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.

Answer 185

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.

 

Answer 186

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.

Answer 187

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.

Answer 188

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!

Answer 189

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.

Answer 190

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! :)

Answer 191

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 ?

Answer 192

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. 

Answer 193

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

Answer 194

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,

Answer 195

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 :)

Answer 196

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!

Answer 197

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.

Answer 198

Infragistics XamGrid and XamCombo leak as well from what I can see... I applied the patch and they appear to be leaking still.

Answer 199

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

Answer 200

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

 

Answer 201

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.   

Answer 202

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.

 

Answer 203

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

Answer 204

@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?

Answer 205

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!)

Answer 206

Apoco: is this a Popup by any chance?

Answer 207

Apoco: is this a Popup by any chance?

No, it's not displayed in a popup.

Answer 208

Apoco: are you running the latest version of Silverlight (4.0.50826.0)?  I don't see your sample repro here leaking.

Answer 209

@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.

Answer 210

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).

Answer 211

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>

Answer 212

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).

Answer 213

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.

Answer 214

@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.

Answer 215

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.

Answer 216

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.

Answer 217

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

Answer 218

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.

Answer 219

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?

 

Answer 220

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.

Answer 221

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.

Answer 222

I'm sorry, tried 'remove' once. You're right, after a second click it is cleared.

Answer 223

Any chances this could be happen in Silverlight 3 too? I have serious memory leakage issues.

Answer 224

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.

Answer 225

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.

Answer 226

pauljs - we used the method described here http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-and-gcroot-to-diagnose-a-net-memory-leak.aspx to find and eliminate all our memory leaks.

Answer 227

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.

Answer 228

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?

Answer 229

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.

Answer 230

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.

Answer 231

Thanks Tim. Just wanted to make sure I wasn't missing anything. 

Answer 232

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.

Answer 233

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?

 

Answer 234

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 :-)

Answer 235

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.

Answer 236

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.  

Answer 237

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!

Answer 238

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).

Answer 239

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.

 

Answer 240

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.

Answer 241

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?

Answer 242

We've gotta get this fixed ASAP Microsoft! Our customers need reliable software that doesn't eat up 10 MB of RAM in seconds

Answer 243

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?

Answer 244

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 :-(

Answer 245

Still, thank you for the very quick reply.

Answer 246

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.

Answer 247

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.

Breaking an existing application?  Yes, that's a priority.  As noted there was NO workaround for this customer and the regression prevented this application from even starting.  The app update logic fired after loading the app, so even having them change their logic wasn't an option because it couldn't get to that point.  All their users were affected with no solution.  So yes, priority.  Releases are generally only reserved for critical issues like security or breaking issues...but there are always exceptions to the rule.  In this case it was the rule as something was broken.

Answer 248

I would think that the frustration is not that ms issued an emergency fix for a customer but that it doesn't issue one for the memory leaks that is affecting more people (i guess) ;-)

joe

Answer 249

you meant breaking an existing Microsoft application? that would definitely qualify for an exception...

Answer 250

Let's have a bit of patience and hope it will be fixed in the next couple of days :)

Answer 251

if it was an easy small fix it would have been rolled into the release-exception, so let's hope instead that when they do release a fix in the next couple of months it'll take care all memory leaks

Answer 252

I think that memory leaks in silverlight and in c# programming is a more general case.

Please refer to http://www.dcore.net/post/Avoid-ObservableCollection-memory-leak.aspx for an example.

I have for example a control that my silverlight application open, and I compile an ObservableCollection to use as ItemsSource for a ListBox, then when I close my control removing from the Grid container and calling GC.Collect() the memory stay fixed and increase if I reopen/create that control and don't decrease closing it.

I solved applying a sort of general pattern in my OpenedObject using a

virtual void OnDispose() { }

that is called from a public Dispose()

that is called from the app controller when closing my control.

In particular to solve ObservableCollection I have simply added this code :

protected override void OnDispose()
{
 base.OnDispose();

 ContactsOBC.Clear(); 
}

I don't know reactive framework (that seems to be used in silverlight 4) but maybe useful to consider evaluating this case internally the silverlight team.

Answer 253

Please refer to http://www.dcore.net/post/Avoid-ObservableCollection-memory-leak.aspx for an example.

Thanks a lot for sharing !!

Answer 254

Very interesting - I think we fall foul of this. Can anyone give any advice on how to prove one way or not whether one's app is suffering from memory leaks - does one have to get to grips with windbg etc? Is this a step by step that would show this? Thanks

Answer 255

You can download vssolution from this link http://soft.made2008.it/Developers/SLForumsRepro/DP_OO_MemoryLeak.zip

Would be useful if we can upload repro attachment in the forum for example the moderator can decide to allow attachment upload for specific thread and with a quota to avoid uploading of something that postfixes with mb. ( my repro is only 32kb ).

I'm novice in this complex topic so any suggestion area wellcome.

Trying to reproduce the behavior described above I have no successful first time because I used a simple

ObservableCollection<SampleTable> oo = new ObservableCollection<SampleTable>();

the behavior enables using :

#region oo [DEPENDENCY PROPERTY]

public static readonly DependencyProperty ooProperty =
	DependencyProperty.Register("oo", typeof(ObservableCollection<SampleTable>), typeof(SilverlightControl1),
	new PropertyMetadata(new ObservableCollection<SampleTable>()));

public ObservableCollection<SampleTable> oo
{
	get { return (ObservableCollection<SampleTable>)GetValue(ooProperty); }
	set { SetValue(ooProperty, value); }
}

#endregion  

So in the first case ( no dep. prop usage ) you don't warry about Clear() but using dep. prop you can save memory using the Dispose pattern described in previous posts. (*)

Effectively in my case I don't need to use dep. prop. but I occurred into this problem because I tought that dep. prop. maybe useful if I decided to bind to external sources.

For the windbg I expose the results below, in any case the app shows the GC.GetTotalMemory(true) continuosly. To try it :

USE REPRO

- create a database "SampleDB" in your localhost sqlserver and create into a table "SampleTable" with id PK Identity and a field str : nvarchar(50).

- start the app ( at the first get the app server-side DomainService1.cs-Get() create automatically 100 elements )

213 kb     START

660 Kb     clicked "Memory Leak (YES)"

660 Kb     clicked "FREE CONTROL"

try now with Clear() method :

760 Kb     clicked "Memory Leak (NO)"

584 Kb     click "FREE CONTROL"

the 584-213=371 Kb are the base internal framework variables that exists from first usage to the application end normally.

The control itself should occupy 760-584=176 Kb.

Also note that 760 Kb from GC.GetTotalMemory(true) for me is converted to 52.7 MB of real world using Procexp.

USING WINDBG

1) AT BEGINNING

0:028> !DumpHeap -stat -type SilverlightApplication1
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
049674a4        1           48 SilverlightApplication1.App
04967620        1          120 SilverlightApplication1.MainPage
Total 2 objects

2) Leaking and trying to freeing unsuccesfully then DumpHeap I got :

0:031> !DumpHeap -stat -type SilverlightApplication1
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
03949f20        1           28 System.ServiceModel.DomainServices.Client.WebDomainClient`1[[SilverlightApplication1.Web.DomainService1+IDomainService1Contract, SilverlightApplication1]]
039482a0        1           28 System.Collections.ObjectModel.ObservableCollection`1[[SilverlightApplication1.Web.SampleTable, SilverlightApplication1]]
049a24bc        1           36 SilverlightApplication1.Web.DomainService1+DomainService1EntityContainer
03948d2c        1           44 SilverlightApplication1.Web.DomainService1
0394863c        2           48 System.Collections.Generic.List`1[[SilverlightApplication1.Web.SampleTable, SilverlightApplication1]]
039474a4        1           48 SilverlightApplication1.App
049a2dd8        1           52 System.ServiceModel.DomainServices.Client.EntitySet`1[[SilverlightApplication1.Web.SampleTable, SilverlightApplication1]]
049a7134        1           88 System.ServiceModel.ChannelFactory`1[[SilverlightApplication1.Web.DomainService1+IDomainService1Contract, SilverlightApplication1]]
03947870        1          100 SilverlightApplication1.SilverlightControl1
03947620        1          120 SilverlightApplication1.MainPage
039481dc      100         8400 SilverlightApplication1.Web.SampleTable
Total 111 objects

3) If I create memory leak NO control and freeing ( in the same program session ! ) :

0:010> !DumpHeap -stat -type SilverlightApplication1
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
0394863c        1           24 System.Collections.Generic.List`1[[SilverlightApplication1.Web.SampleTable, SilverlightApplication1]]
039482a0        1           28 System.Collections.ObjectModel.ObservableCollection`1[[SilverlightApplication1.Web.SampleTable, SilverlightApplication1]]
039474a4        1           48 SilverlightApplication1.App
03947620        1          120 SilverlightApplication1.MainPage
Total 4 objects

REMAINING OBJECTS

4) Note : that 0394863c and 039482a0 still remain also using "Memory Leak (NO)" in the program session... so the memory is not really cleared at the best. I don't know how to clear that List and ObservableCollection introduced.

- the control is removed from the border

- I tried also to set the dp to null and lst.ItemsSource to null but no effect

NOTE ( THE TWENTY SECONDS QUESTION ) :

From the proceexp memory point of view the memory involes browser, os, etc... and every small GC. items goes big dresses.

The strange thing that I noticed is that in every memory allocation after 20 seconds the proceexp shows a sort of memory compacting. From the proceexp memory point of view there are no big difference between two tests for this small app.

40 MB     app started

47 MB     "Memory Leak (NO)" button

44 MB     ( AFTER 20 SECONDS )

47 MB     "Memory Leak (YES)" button

44 MB     ( AFTER 20 SECONDS )

 

 

Answer 256

I resisted but I finally had to refactor the views to use resource datatemplates. I also use Telerik RadControls and with their latest fix, I have to admit, the memory leaks are finally gone.

I'm very happy with the result, although I feel sick for refactoring the datatemplates in the whole app.

 

Answer 257

Hi,

I don't know whether this is the right thread to post this issue, but since it is related to memory leaks I'll give it a shot.

I've recently found out that if I add an SDK Expander to the VisualTree with its Visibility set to collapsed and if I never set it to Visibile, this Expander is never garbage collected after being removed from the VisualTree.


<UserControl
    x:Class="ExpanderMemoryLeak.SDKExpanderNotVisibleByDefault"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:controlsToolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit">
   
    <Grid x:Name="LayoutRoot">
       
        <controlsToolkit:Expander Visibility="Collapsed">
            <controlsToolkit:Expander.Header>
                <Grid>
                    <Button Click="Button_Click" />
                </Grid>
            </controlsToolkit:Expander.Header>

            <TextBlock Text="Content" />

        </controlsToolkit:Expander>
       
    </Grid>

</UserControl>


Steps:

1. Add this UserControl to the Visual Tree

2. Remove the UserControl from the Visual Tree

3. Call GC

4. The SDK Expander and the UserControl still remain in memory


Has anyone ever come across with this issue? Tim, do you need a sample application for this?


Regards,

Bruno

Answer 258

Have you experienced any other memory leaks with hidden controls.

Anyone else?

 

I use Telerik controls, and much was solved with their last release, but still leaking a bit and I haven't found why, I'll check out your idea.

 

Best Regards.

 

Answer 259

I've tested with telerik's RadExpander and it leaks as well.

Best regards,

Bruno

Answer 260

Hello Tim,

Any news on the fix release timeframe? That is very important for our release planning.

Thanks!

Answer 261

brunodfg: thanks for the post, no additional repro needed, I confirmed the scenario (as well as our proposed fix takes care of this one as well).

Answer 262

Hi Tim,

   I logged the issue with the Silverlight Media Framework Player

https://connect.microsoft.com/VisualStudio/feedback/details/613433/silverlight-media-framework-player-memory-leak

I downloaded the latest 2.2 version of SMF today and the issue is still there, just download and reference the dll's in a new project and try the following.

            WeakReference playerRef = new WeakReference(new Microsoft.SilverlightMediaFramework.Core.SMFPlayer());
            GC.Collect();
            GC.WaitForPendingFinalizers();
            bool isPlayerAlive = playerRef.IsAlive; //  true
            ((Microsoft.SilverlightMediaFramework.Core.SMFPlayer)playerRef.Target).Dispose();
            isPlayerAlive = playerRef.IsAlive; // still true

 

Answer 263

kornfish: the Silverlight Media Framework is an Open Source project done by a different team.  Please log issues related to their framework here http://smf.codeplex.com/workitem/list/basic. 

Answer 264

Thank sniles for your post about datagrid editing template bug in sdk:DataGridTextColumn when editing, I confirm that bug solved using your workaround.

Answer 265

Unfortunately memory leak persist if object in the itemssource of the datagrid are Entity types.

I don't know if the memory leak is in the Entity or in the DataGrid entity handling, but I have this repro http://soft.made2008.it/Developers/SLForumsRepro/ENTITY_MemoryLeak.zip

To run it you need to have a db named SampleDB with a table named SampleTable with a pk named id and a field nvarchar(max) named str.

I noticed that setting dg.ItemsSource to null and clearing the collection will limit memory leak,

but if you start an editing on a cell, then the underlying datagrid entity system will call BeginEdit, the memory leak appears.

 

Tim, do you know of this ? If yes, you know some workaround ?

thanks in advice

 

Answer 266

 

We have a simular issue with memory leaks

In our case we are using an AutoCompleteBox control. The data template is in a usercontrol.resources area and refertenced as a static resource as per instructions.

We still get the memory leak.

The Xaml:

<ResourceDictionary >

<sms:EditMenu x:Name ="EditMenu"/>

<smsi:EditStateConverter x:Key="EditStateConverter" />

<Style x:Key="TelerikMenu" TargetType ="telerikNavigation:RadMenu">

<Setter Property="Foreground" Value ="Navy"/>

</Style >

<DataTemplate x:Key ="abcTemplate">

<StackPanel Orientation ="Horizontal" >

<TextBlock Text="{Binding ItemCode}" Width ="75"/>

<ContentPresenter Content="{Binding ItemName }" />

</StackPanel >

</DataTemplate >

</ResourceDictionary >

...

ItemTemplate="{StaticResource abcTemplate }" >

We remove the control from the visual tree and add it back four times. Four instances are left in memory as per WinDBGT.  We can see that the controls are pinned by the data template.  There is a dictionary object being used as the itemsource of this contriol. 

WinDbg:

Scan Thread 8 OSTHread 1764
ecx:Root:  05c18830(System.Collections.Generic.Dictionary`2[[System.IntPtr, mscorlib],[System.Object, mscorlib]])->
  0602c440(System.Collections.Generic.Dictionary`2+Entry[[System.IntPtr, mscorlib],[System.Object, mscorlib]][])->
  05d5138c(System.Windows.Controls.ControlTemplate)->
  05d4cc3c(System.Windows.ResourceDictionary)->
  05d51440(MS.Internal.ResourceDictionaryCollection)->
  05d514a4(System.Windows.ResourceDictionary)->
  05d4c598(SMSSystems.SubProductTypeEditCntrl)
Scan Thread 22 OSTHread 15f0
Scan Thread 23 OSTHread 92c
Scan Thread 26 OSTHread 208
DOMAIN(049AA638):HANDLE(Pinned):3a712f8:Root:  06c04260(System.Object[])->
  05c18830(System.Collections.Generic.Dictionary`2[[System.IntPtr, mscorlib],[System.Object, mscorlib]])->
  0602c440(System.Collections.Generic.Dictionary`2+Entry[[System.IntPtr, mscorlib],[System.Object, mscorlib]][])->
  05d5138c(System.Windows.Controls.ControlTemplate)->
  05d4cc3c(System.Windows.ResourceDictionary)->
  05d51440(MS.Internal.ResourceDictionaryCollection)->
  05d514a4(System.Windows.ResourceDictionary)->
  05d4c598(SMSSystems.SubProductTypeEditCntrl)

When the control is removed from the visual tree we call a Dispose on it and in the dispose code we set the itemsource to nothing and the countrol's data context to nothing.  But as you can see above, the dictionaries appear to be still connected to the controls. The dictioaries are sourced from a seperate model class.

This issue is just one of many memory leaks we have in this Silverlight Application.  We are resolving some of them with weakreferences and adding and removing event handlers.  But some like this data template related one are just not going away.

This application is a large enterprise level application for the petroleum distribution market and will have a signifigant distribution within that industry since it is replacing a character based application already online. We bought into the 'Enterprise Ready" propmotion and Silverlight really is delivering in terms of capability. But this memory leak situation is becomming a show stopper.  We have been following the threads on this issue, are up to date on the SL 4.dll and the Telerik Dlls. Right now we do not appear to have any Telerik memory issues.  But we do have them with Toolkit and native controls.

@Microsoft:  Is there a real fix in the near future??

Yesa this is a doulble post...I meant to post it here, but had the wrong window open.

 



Answer 267

Tim,

This is outrageous. Why hasn't the Silverlight team been able to deliver a fix for this problem? Seems to me the team has no clue how to resolve this problem. Don't you guys get it? Choosing Silverlight for real world business apps is next to impossible if there are serious memory leaks in the technology?! You guys have not worked keeping this as top priority and instead of delivering a stable version - countless hours have been wasted on this forum trying to give excuses (for months)!

WE NEED TO KNOW WHEN THE MEMORY LEAKS WILL BE FIXED PERMANENTLY.

Whatever you guys have planned to announce at PDC this year - make sure this is part of the good news!

Answer 268

valiant_sam: I've discussed many times before ad naseum the pain of release process for things like this.  I agree, understand and can empathize that this is not ideal for our customers.  I'm doing my best to adjust the team when possible.  This particular memory leak being discussed here (in-line DataTemplates) is scheduled for the next release.  As I've mentioned before, we don't disclose release plans in the event of driving forces that require us to change them (as was the case with the last two).

Answer 269

valiant_sam, if you don't have to use the features that didn't exist in SL3, you can do what we did - compile for SL3. it seems to be working pretty well even on the machines with SL4 (thanks to the quirks mode, I suppose).

Answer 270

Silverlight 4 features are used in my projects. Going back is not an option. Thanks anyway vsi!

Answer 271

Tim: How about focusing on plugging all the known memory leaks and not just limiting to the inline data templates? That will lead to a solid future for Silverlight and all devices it will be available on - cars, TVs, phones, web, desktops (possibly more). Only if these problems are fixed can you really have a consistent and one and only one Silverlight framework for all the devices.

Will get back to you after PDC. Looking forward to the Silverlight reveal and the C# session! :)

Answer 272

As we have been fixing and/or "working around" our memory leak issues in our soon-to-be-released app, the only remaining one appears to be with the TimePicker control.  This causes multiple (many!) instances of our app objects to stay alive -- MAJOR potential leak for us (since user could open/close these views hundreds of times in a day).  I have isolated this to the control itself using the sample solution provided earlier in this thread.  The WeakReference(s) to this control NEVER gets collected during forced GC -- so something is obviously holding on tight.

Just wanted to add this to the mix...  any fix (or workaround) forthcoming for TimePicker?  Thanks...

Answer 273

ktalley - I don't see a post on this thread from you with a sample?  Are you referring to something else?  Regardless, please open a new bug with the repro so it gets into the bug database.  Instructions here: http://timheuer.com/blog/archive/2010/05/03/ways-to-give-feedback-on-silverlight.aspx

Answer 274

What did the trick for me was to ditch the XAML DataTemplate altogether, as I created a custom Column class that inherits from GridViewColumn. I then put together the Framework Elements in the code-behind for the GridView column. This seems to be captured by the GarbageCollector and taken care of.

public class MyCustomColumn : Telerik.Windows.Controls.GridViewColumn
    {
        public override FrameworkElement CreateCellElement(Telerik.Windows.Controls.GridView.GridViewCell cell, object dataItem)
        {
// Build it here in the code-behind
}
}

Answer 275

Tim:

As you requested, I have officially opened a bug with an attached repro solution:

http://connect.microsoft.com/VisualStudio/feedback/details/617573/memory-leak-with-timepicker-control

Answer 276

Hi Tim,

Could you please give us some guidance on the date for the fix release? Could we expect it withing weeks, months?

Thanks a lot!

Answer 277

No firm update just yet.  It won't be weeks unfortunately.

Answer 278

It does sound like microsoft priority is not silverlight, maybe html5? If silverlight was a priority this fix would have been provided MONTHS ago.

This is a shame

Answer 279

This bug was identified from months now (!!), and we must again wait MONTHS for a -potential- fix (or sl5) ?!!!!
That is just unbelievable, we have to re-work on all our applications (and this take a lot of time !), or back to v3... But you already have a fix internally (according to you) !! This is a major issue, when the customer's browser is eating more that 1.5Go or memory, this is a BIG problem. on the begenning i was happy to wirk under SL, but now, i'm juste searching for serious alternative... 
Microsoft priority is really crazy...
F*****g shame !

Answer 280

It does sound like microsoft priority is not silverlight, maybe html5? If silverlight was a priority this fix would have been provided MONTHS ago.

This is a shame

well i don't think that's really fair, while there has been some questions about microsoft's support of Silverlight moving forward, i don't think this one issue is cause or indication of that.

that said, yes this memory leak has been ongoing for a long time. i will personally admit that i have had to more or less ignore Silverlight 4 due to it, which is.. difficult. i hope that they work hard and provide a fix, as this impact those users using Silverlight in the most in depth way: LOB and enterprise apps, not the advertisement flashy type.

Answer 281

It does sound like microsoft priority is not silverlight, maybe html5? If silverlight was a priority this fix would have been provided MONTHS ago.

This is a shame

well i don't think that's really fair, while there has been some questions about microsoft's support of Silverlight moving forward, i don't think this one issue is cause or indication of that.

that said, yes this memory leak has been ongoing for a long time. i will personally admit that i have had to more or less ignore Silverlight 4 due to it, which is.. difficult. i hope that they work hard and provide a fix, as this impact those users using Silverlight in the most in depth way: LOB and enterprise apps, not the advertisement flashy type.

That's the problem. Lately I only hear Microsofties saying that Silverlight should be used to add multimedia to a web app which defeats the whole purpose of what we're doing with this platform (that is like you said..LOB apps).

Answer 282

That's the problem. Lately I only hear Microsofties saying that Silverlight should be used to add multimedia to a web app which defeats the whole purpose of what we're doing with this platform (that is like you said..LOB apps).

i think that has been somewhat of an over-reaction to PDC comments, and people have indeed clarified (http://team.silverlight.net/announcement/pdc-and-silverlight/) the position as best they could.

again, that said Microsoft's overall position is still somewhat fuzzy, i'm not denying that, but i think that's because they don't really know what they're doing just yet. i would recommend this article: http://arstechnica.com/microsoft/news/2010/11/silverlight-html5-and-microsofts-opaque-development-strategy.ars

it provides the most complete, indepth, and in my opinion accurate description of the current fuzzy situation. after reading it i hope you will realize that there is no clear path just yet, but at a minimum Microsoft is for now dedicated to keeping Silverlight alive and well.

Answer 283

Thank you, I've read the articles, I know what they're saying, I just don't know what they're doing.

Answer 284

You can tell us the same thing over and over again hoping that one day we just wake up and accept Microsoft's release process on Silverlight as acceptable for our internet needs. Sure, we can live with 1.5G clients, just tell our customers to get on with the times and use 8GB machines, right?

The problem with your posts is that they lack any clarity - just giving us some esoteric answer about how things take gargantuan amounts of time and effort to get cleared through the process means absolutely nothing to us, the developers, that have to wait.

Now, the damage is done, not much we can do but wait, especially for those of us heavily invested in the platform. But having said that, whether you accept it or not, the way in which Microsoft is handling this creates mistrust for the future. Why would I want to be bleeding edge again and jump to SL5 whenever it gets released when it has been a year and you cannot get some of the most fundamental and critical bugs in SL4 fixed?

In my view, if I had a product that leaks memory like this, and whose leaks affect many other products down the chain, it would be considered a hotfix priority. Instead, it seems like this is just going to be another fix in yet another service release that includes many other fixes.

It does not matter much if you have the best IDE in the world if the code it generates has very serious problems, does it?

 

Answer 285

To me, applying tim workaround ( see post 09-14-2010 1:51 AM ) about using datatemplate in resources save my lop application to be unusable ( 8gb ram can help but not solve if you not apply this workaround ).

I admit that modifications of my lop source code was no zero cost, but my app now return to the 90 mb of memory initial while without the workaround opening five documents and closing the ram 350 mb will not release and reopening the same five documents the closing the ram go to 700 mb.

If you used some event like Loaded in DataTemplate you can create a Usercontrol to insert in the resources datatemplate. For example :

<DataTemplate>

<TextBox Loaded="TextBox_Loaded" Text="{Binding something}"/>

</DataTemplate>

can change to

<Resources>

<DataTemplate><SpecificControl/></DataTemplate>

</Resources>

Where you apply the loaded using the Loaded of Specific Control.

---

After this I admit that still remains leak not solvable through the datatemplate workaround like for example having entity in the datagrid and starting editing ( post of 10-21-2010 10:24 AM ).

Fortunately 80% of my datagrid app are read-only while the edit is in a form.

Note also that we can introduce memory leak without regard of silvelight : for example using Observable Collection ( see my post 10-01-2010 1:25 AM ).

I hope too that a silverlight update will eliminate that memory leak as soon but for now I have done all I can to satisfy my customer needs.

Answer 286

KaweekaTH: I'd like to know what you want to hear.  If I give you a specific date will that help?  And what if we miss that date due to other factors?  Now how does that date help?

All: I am not hiding from the fact this isn't painful for you.  I share in your frustration and am doing my best to get a fixed release out.

Answer 287

It would help because maybe people are waiting for a fix instead of changing their whole apps. We are shiping our app this week, so I had no choice but to apply the workarounds in datatemplates everywhere. Maybe those who plan to ship within the next months won't have to change their apps if you tell us that the fix estimate release date is december.

Not having an estimate date makes us think that you guys don't even know how to fix it or that the silverlight team has less members due to HTML 5 being top priority, hence fixes are coming slower now. I'm just making assumptions, but that's what happens when we don't have estimate dates and we've been waiting since march for a bug fix.

Answer 288

Yes it will help.  Here's the difference.  If you give us an estimate, I can continue to recommend Silverlight as a development platform to my clients.  Now if you miss that date and can't provide justification, then I'll have to stop recommending it.

But without an estimate at all, I have to stop recommending Silverlight right now.  That's the difference.

I am placing on you the same expectation my clients place on me.  If I repeatedly miss estimates without justification, they will fire me.  But if I refuse to give estimates at all, they will never hire me in the first place.  They'll find a vendor who treats them with respect.

Answer 289

Hello,

Any news about this issue yet?

i have a grid with ~400 rows and the RAM goes to 400MB.

Non of the above workaround worked for me.

does any one have other tips and tricks...

thanks.

Answer 290

I've created a workable solution using Tim's second workaround. It doesn't require you to alter all code by hand. A few global search & replaces should do the trick.

First create the following class:

public class ExtendedDataTemplate : DataTemplate
{
	private static Stack<List<ExtendedDataTemplate>> createdListStack = new Stack<List<ExtendedDataTemplate>>();
	private static List<ExtendedDataTemplate> currentCreatedList;

	public ExtendedDataTemplate()
	{
		if (ExtendedDataTemplate.currentCreatedList != null) ExtendedDataTemplate.currentCreatedList.Add(this);
	}

	public static void BeginMonitorCreate()
	{
		ExtendedDataTemplate.currentCreatedList = new List<ExtendedDataTemplate>();
		ExtendedDataTemplate.createdListStack.Push(ExtendedDataTemplate.currentCreatedList);
	}

	public static List<ExtendedDataTemplate> EndMonitorCreate()
	{
		List<ExtendedDataTemplate> result = ExtendedDataTemplate.currentCreatedList;
		ExtendedDataTemplate.createdListStack.Pop();

		if (ExtendedDataTemplate.createdListStack.Count > 0)
		{
			ExtendedDataTemplate.currentCreatedList = ExtendedDataTemplate.createdListStack.Peek();
		}
		else
		{
			ExtendedDataTemplate.currentCreatedList = null;
		}

		return result;
	}

	public static void InitializeComponent(Action action)
	{
		List<ExtendedDataTemplate> extendedDataTemplateList;

		try
		{
			ExtendedDataTemplate.BeginMonitorCreate();
			action();
		}
		finally
		{
			extendedDataTemplateList = ExtendedDataTemplate.EndMonitorCreate();
		}

		Canvas c = new Canvas();
		foreach (ExtendedDataTemplate t in extendedDataTemplateList) c.DataContext = t;
		c.DataContext = null;
	}
}

This class will allow you to monitor any DataTemplates being created and automatically remove the strong reference.
All DataTemplates in XAML code should be replaced with this one.

Once this is done, all calls to InitializeComponent() should be replaced with the following code:

public partial class MyUserControl : UserControl
{
    public MyUserControl()
    {
        ExtendedDataTemplate.InitializeComponent(this.InitializeComponent);
    }
}

Tim, I do have some questions about your 2nd workaround. I see you've declared the Canvas as a field on the UserControl and not as a local variable in the constructor. Any reason for this? Is this workaround causing the Canvas to have a reference to all DataTemplates and will my solution cause the DataTemplates to be released by the GC too soon?
I'm also not quite clear about what you ment by "removal of the strong reference must still occur after the inline FrameworkTemplate has been set as a value on a managed object". Once MyUserControl.InitializeComponent() has been called all DataTemplates should already be referred to by a managed object, right?

Regards,

Robin

Answer 291

Another memory leak that need to be managed is for ContextMenuService.

To me I needed to call ContextMenuService.SetContextMenu(control,null) before closing a control that used ContextMenuService.SetContextMenu(ctl, ctxMenu).

Not only this workaround solve only memory leak until contextmenu stay closed, if you open it then the memory leak remains.

To avoid it I have to handle Right click manually avoiding usage of ContextMenuService. 

Answer 292

If you use DataForm only to organize data ( eg. not using button, using only a EditDataTemplate and CurrentItem ) and have experienced memory leak for you controls that used outside dataform have no leak, you can use this DataForm first aid replacer. The nice thing is that using this control you can see the dataform content in the visual studio designer, while using control toolkit dataform this not happen. In this CustomDataForm the CurrentItem doesn't exists, just use DataContext.

using System;
using System.Windows;
using System.Windows.Controls;

public class CustomDataForm : Grid
{

 #region EditTemplate [DEPENDENCY PROPERTY]

 public static readonly DependencyProperty EditTemplateProperty =
  DependencyProperty.Register("EditTemplate", typeof(DataTemplate), typeof(CustomDataForm),
  new PropertyMetadata(null, EditTemplateDPChanged));

 public DataTemplate EditTemplate
 {
  get { return (DataTemplate)GetValue(EditTemplateProperty); }
  set { SetValue(EditTemplateProperty, value); }
 }

 public static void EditTemplateDPChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
 {
  CustomDataForm obj = d.As<CustomDataForm>();

  obj.Setup();
 }

 #endregion

 public CustomDataForm()
 {
  LayoutUpdated += new EventHandler(CustomDataForm_LayoutUpdated);
 }

 double lblMaxWidth = 0;
 bool lblResizing = false;

 void CustomDataForm_LayoutUpdated(object sender, EventArgs e)
 {        
  if (lblResizing) return;

  var sp = formCtl.As<StackPanel>();

  double lblMaxWidthBackup = lblMaxWidth;

  foreach (var x in sp.Children)
  {
   var df = x.As<DataField>();

   var lbl = df.GetChild<Label>(0, r => r is Label);

   if (lbl == null) continue;               

   TextBlock tblk = new TextBlock()
   {
    Text = (string)lbl.Content,
    FontSize = lbl.FontSize,
    FontFamily = lbl.FontFamily
   };
   
   if (tblk.ActualWidth > lblMaxWidth)
   {
    lblMaxWidth = tblk.ActualWidth;
   }
  }
  
  if (lblMaxWidthBackup < lblMaxWidth)
  {
   lblResizing = true;
   
   foreach (var x in sp.Children)
   {
    var df = x.As<DataField>();

    var lbl = df.GetChild<Label>(0, r => r is Label);

    lbl.Width = lblMaxWidth;
   }
   
   lblResizing = false;
  }

 }

 UIElement formCtl = null;

 private void Setup()
 {
 formCtl = EditTemplate.LoadContent().As<UIElement>();

ScrollViewer sv = new ScrollViewer() { Background = new SolidColorBrush(Colors.Transparent) };

sv.Content = formCtl;

Children.Add(sv);
 }

}

public static partial class Extension
{

public static T As<T>(this object obj) where T : class
    {
        return obj as T;
    }
 
//
public static T GetChild<T>(this DependencyObject obj, int maxDepth, Func<T, bool> fnAllow) where T : class
    {
        List<T> lst = new List<T>();
        obj.GetChild<T>(maxDepth, 0, true, lst, fnAllow);

        return lst.FirstOrDefault();
    }
 
//
    private static void GetChild<T>(this DependencyObject obj,
        int maxDepth,
        int curDepth,
        bool stopAtFirst,
        List<T> lst,
        Func<T, bool> fnAllow) where T : class
    {
        var o = obj;

        int cnt = VisualTreeHelper.GetChildrenCount(o);

        curDepth++;

        for (int i = 0; i < cnt; ++i)
        {
            var child = VisualTreeHelper.GetChild(o, i);

            if (child is T && (fnAllow == null || fnAllow(child as T)))
            {
                lst.Add(child.As<T>());
                if (stopAtFirst) return;
            }

            if (curDepth == maxDepth) continue;

            child.GetChild<T>(maxDepth, curDepth, stopAtFirst, lst, fnAllow);
        }

        curDepth--;
    }
 
}

 

Answer 293

Hey MiczMicz, I had a memory leak issue which I thought was data grid related as per this post but the above mention fixes didn't solve the massive memory leaks that were occuring. In my case it seemed to be MORE related to the Navigation frame inconjuction with MVVM-Light than the datagrid inside it. Here's a couple of things that you can try that might help.

1. Firstly I dont think that MVVM-Light is the problem. Although I'm currently thinking that this form or binding might be leaky "{Binding Path=MainPage.SomeText, Source={StaticResource Locator}}"  However if I get some time i'll investigate further. 

2. Replace your datagrid with a ListBox. Keep the same itemsource and set the DisplayMemberPath to just one of this fields in your itemssource.

3. Does the memory leak still occur? If yes and you are using a navigation frame then...

4. Remove the Reference to the DataContext in you .xaml and in your codebehind (.xaml.cs) as this to the constructor

this.DataContext = ViewModelLocator.MainPageStatic;  // note: MainPageStatic is my Viewmodel I used to track this memory leak

 5.  Add the following to your code behind (.xaml.cs)

protected override void OnNavigatedFrom(NavigationEventArgs e)

{

 this.DataContext = null ;

 GC.Collect();

 GC.WaitForPendingFinalizers();

 GC.Collect();

}

Note: that the above datagrid leak is an issue as well but the above might help in the interim. 

 

Answer 294

Hello every  one,

It's really time to say if Microsoft is really switching to HTML5 ??!

I had a discussion with a friend, and they was developing products with Silverlight 3, but now they are preparing staff to Migrate all the product with HTML 5. He saied that this is the Microsoft's future stragetgy.

We are all wainting for a patch for monthes and monthes now, so if Microsoft consider that Silverlight is a part of past now, we need to know that and so consider forming our staff on other technologies.

Best regards.

Answer 295

http://team.silverlight.net/announcement/pdc-and-silverlight/

Answer 296

Hi allan1234!

i will check this today, thanks!

i will comeback with the resoults...

Answer 297

It's been 20 days since Tim peaked his head in here.  Ever get the feeling you're being avoided?

This is disappointing to me.  I've been pushing Silverlight since the first release, but I don't know if I can do that anymore.  And it had HUGE potential.  Shoot, I built a 3D CAD system for one of my clients on it!  But I have little stomach for memory leaks and less for unresponsive vendors.  So it looks like I'm going to have to direct my clients elsewhere.

Answer 298

You are not being ignored.  I see every single response here the moment it is posted.  I've been a bit under the weather the past few weeks and had some other deadlines that have been pressing.

I don't have much more to report in the timeframe, hence why I haven't popped in here with any update.  I promised I'd update when I had new information...I don't have any.  The fix has been verified by a lot of customers (and a few on this thread as well to ensure we covered a lot of bases).  I know that you'll say "that's nice, when do we get it" and that's the answer I simply don't have right now.

I'm being as responsive as I can be with the most up-to-date information I have.

Answer 299

Hi Tim,

Our company is a Microsft Partner, is there a way we can get our hands on the test version you have internally released son that we can get involved? We really need to get it right this time.

Best Regads,

JB

 

PS: The Silverlight comunity should be more involved.  

Answer 300

http://team.silverlight.net/announcement/pdc-and-silverlight/

Answer 301

First, I'll address the PS comment.  We have over 50 Silverlight MVPs that are involved in addition to 250+ early adopters/ISV partners.  These folks have direct involvement in early releases.  Our team simply isn't large enough to scale to support the world in early releases (other than public betas, etc. which transition to broader support).  I understand that we missed some things and we can take our lumps for that.  But I do feel the community is being adequately represented across the board.  Some of you may disagree, but even our top ISVs who we asked to help test fixes with even admitted they missed some of the scenarios as well.

That said, if you have an NDA relationship or have a premier support agreement you can submit a request to our team for verification of this issue.  I know some will scream just to make it public but we simply can't scale to support that outside of NDA agreements at this time.

Answer 302

Hi Tim,

I understand the pressure you guys are under (maybe justifiably so), but doesn't the fact that all those MVP / ISV structures failed to find what the community did within 24 hrs point to something amiiss in the current release strategy?

Surely these issues have sent blinking red alarms off that something needs to change to prevent this from happening again?

We, as developers (and the powers that be that pay our salaries), need assurance that not only is this specific issue being addressed, but what is being done to prevent it from recurring, and restore our faith in a technology that so many of us have invested our company's IT strategy on?

Answer 303

Was disappointed to not hear anything yesterday about a planned service pack or hotfix that might correct the memory leaks in SL 4.

We can't wait until the end of next year for SL 5 to get them corrected...

Honestly, I can't get excited about a far-off SL 5 when I can't make SL 4 work correctly...

Answer 304

I saw a lot of excitement about silverlight 4 being out only 6 months after silverlight 3 and how microsoft was committed to make silverlight the best programming technology of the upcoming years, and now silverlight 5 comes at least 1,5 years after silverlight 4? What happened to the commitment? One can only speculate..but wait 1,5 years for a bug to be fixed since it was identified..give some respect to this technology.

I'm not saying I want SL 5 out next month. I'm sure that would bring new bugs to the party. I'm just saying that SL 5 is one thing, fixing SL 4 should be another.

Answer 305

You will NOT have to wait for SL5 for this particular fix.  The vision for SL5 features was very much a preview and not intended to imply we are stopping working on SL4 fixes that are being identified.

Answer 306

With all the talk about memory leaks I was wondering if there is anyone could take a look at my recent posts (http://forums.silverlight.net/forums/t/211504.aspx).  I created a test app to reproduce a problem I was seeing in an application my company is developing using Silverlight 4.  It appears that when large number of controls are added to the visual tree, removed, and then garbage collection is forced, only a fraction of the controls are collected; decreasing as the amount memory allocated at one time increases. 

Answer 307

I appreciate and have been following the posts here for some time. I'd like to make a request for something I haven't seen here. It would preferably come from Microsoft. I'm looking for a single, definitive document or post that describes in detail best practices for memory management in Silverlight 4 using RIA services and the components within the Silverlight 4 Toolkit as well as Microsoft's prescription for mitigating all known leaks.  We've actively followed this thread and attempted several solutions suggested here to no avail: factoring out activity control, proper event handler registration/unregistration, the "data template fix", weak event references, explicit clearing and refactoring of DomainContexts, DomainDataSource optimization, Telerik control service pack, etc. This effort was extremely time consuming, destabilizing, and produced no result. I'm sure that the needle is here somewhere, but I'd like to ensure that I'm searching the right haystack. Like others here, we have a line-of-business Silverlight application using RIA services, third-party controls, and the Silverlight Toolkit originally produced from the Silverlight Business Application Template. There is a team of about twenty people whose day job is to use our application rigorously. The application's memory footprint grows and grows until IE shuts down, and it happens 3-5 times a day for each person. We are taking a final crack at this and intend to succeed.

Will you help?