Comments on: Silverlight’s ProgressBar And Possible Memory Leaks

By: Nike NFL Jerseys

Nike NFL Jerseys — Wed, 24 Aug 2011 06:35:00 +0000

2011 Nike NFL Jerseys are a brand sale with fast deliver,and Cheap NFL Jerseys are favorite by many fans.

By: Davy Brion

Davy Brion — Mon, 02 Mar 2009 18:11:13 +0000

@Rob

i didn’t even know you could load sos in the immediate window

By: Rob

Rob — Mon, 02 Mar 2009 18:10:14 +0000

By the way, cool thing finding the bug.

By: Rob

Rob — Mon, 02 Mar 2009 18:09:35 +0000

Why would you use windbg (beside it’s coolness factor)? You can just as well load Sos in your immediate window in VS (.load sos)

By: Samuel Jack

Samuel Jack — Fri, 27 Feb 2009 09:23:35 +0000

I had a a similar bug with the WPF progress control when it was in indeterminate mode. It was a bit weirder though, because this bug would cause memory allocations of about 4k/sec starting from a few seconds after you closed the form containing the progress bar! It wasn’t as simple as it holding onto the parent object though: IIRC the allocations were all happening inside one of the unmanaged parts of WPF.

I could never get a reliable reproduction of it though, so I haven’t been able to submit a bug to MSFT yet.

In the end, I went with making a text based control of my own, shunning WPF animation in this scenario.

By: Justin-Josef Angel

Justin-Josef Angel — Thu, 26 Feb 2009 18:34:17 +0000

Hi Davy,

Thanks, we’ve got an internal bug open on that and we’re trying to get this fixed for vNext.

Thanks for blogging about this. It’s important for the community to generate this kind of knowledge.

Sincerely,
– Justin Angel
Microsoft Silverlight Toolkit program manager