WPF ProgressBar.IsIndeterminate = true causes unmanaged memory leak - by antbj

Status : 

 


3
0
Sign in
to vote
ID 529736 Comments
Status Active Workarounds
Type Bug Repros 2
Opened 2/1/2010 8:31:58 AM
Access Restriction Public

Description

We have an application which needs to be able to run for days. On startup, while some stuff is being initialized on a background worker, it displays a splash screen containing an indeterminate progress bar. That splash screen is a WPF Window, displayed using ShowDialog(). Once initialization is finished, the splash screen is closed, and the main application Window is displayed.

After having been running for a couple of days, the application crashes with OutOfMemoryException.
SOS showed no managed memory leak, but the memory usage of the (32-bit) application was more than 1.4GB which was abnormal. So it had to be unmanaged memory. A few WinDbg sessions later, it turns out that millions of 72 bytes allocations had been made, and they start from right after the splash screen closes. It's not always 72 bytes, the attached sample project, for example, leaks by 80-byte allocations on my computer.
Not setting IsIndeterminate to true on the progress bar fixed the memory leak.
Sign in to post a comment.
Posted by ambrauer on 3/11/2010 at 6:24 AM
I've encountered the same exact issue. Since upgrading to .NET 4.0 is not an option for us at this time, I found a workaround here:
http://stackoverflow.com/questions/1705849/wpf-memory-leak-on-xp-cmilchannel-hwnd

Adding this line:
new HwndSource(new HwndSourceParameters());
to the Application constructor seems to fix this memory leak, as well as another one we have noticed with TextBoxes.
Posted by antbj on 2/11/2010 at 2:29 AM
It's actually the version of the .NET Framework that's important.
I've tested the same project with VS 2010 RC1, and I can reproduce the issue.
However, if I change the target framework to .NET 4.0, the problem is indeed fixed.
Whether this bug is relevant or not depends on what Microsoft's plans are for supporting .NET 3.5.

For reference, here is the evolution of the heap when the memory leak occurs:
(output from WinDbg)

- Seconds after starting process
    size     #blocks     total     ( %) (percent of total busy bytes)
    100000 1 - 100000 (46.84)
    e738 3 - 2b5a8 (7.93)
    a000 1 - a000 (1.83)
    3000 3 - 9000 (1.65)
    dd0 a - 8a20 (1.58)
    30 2c6 - 8520 (1.52)
    8058 1 - 8058 (1.47)
    4010 2 - 8020 (1.47)
    5f8 11 - 6578 (1.16)
    1870 4 - 61c0 (1.12)
    6018 1 - 6018 (1.10)
    5c80 1 - 5c80 (1.06)
    210 28 - 5280 (0.94)
    103c 5 - 512c (0.93)
    1b00 3 - 5100 (0.93)
    19b0 3 - 4d10 (0.88)
    20 265 - 4ca0 (0.88)
    18e8 3 - 4ab8 (0.85)
    28 1c1 - 4628 (0.80)
    50 d4 - 4240 (0.76)

- A few more seconds later
    size     #blocks     total     ( %) (percent of total busy bytes)
    100000 1 - 100000 (43.31)
    50 92c - 2ddc0 (7.76)
    e738 3 - 2b5a8 (7.34)
    a000 1 - a000 (1.69)
    3000 3 - 9000 (1.52)
    dd0 a - 8a20 (1.46)
    30 2c6 - 8520 (1.41)
    8058 1 - 8058 (1.36)
    4010 2 - 8020 (1.35)
    5f8 11 - 6578 (1.07)
    1870 4 - 61c0 (1.03)
    6018 1 - 6018 (1.02)
    5c80 1 - 5c80 (0.98)
    210 28 - 5280 (0.87)
    103c 5 - 512c (0.86)
    1b00 3 - 5100 (0.86)
    19b0 3 - 4d10 (0.81)
    20 264 - 4c80 (0.81)
    18e8 3 - 4ab8 (0.79)
    28 1c3 - 4678 (0.75)

- A few minutes later
    size     #blocks     total     ( %) (percent of total busy bytes)
    50 6e84 - 228940 (49.04)
    100000 1 - 100000 (22.72)
    e738 3 - 2b5a8 (3.85)
    51 5ce - 1d62e (2.61)
    a000 1 - a000 (0.89)
    3000 3 - 9000 (0.80)
    dd0 a - 8a20 (0.77)
    30 2c7 - 8550 (0.74)
    8058 1 - 8058 (0.71)
    4010 2 - 8020 (0.71)
    5f8 11 - 6578 (0.56)
    1870 4 - 61c0 (0.54)
    103c 6 - 6168 (0.54)
    6018 1 - 6018 (0.53)
    5c80 1 - 5c80 (0.51)
    210 28 - 5280 (0.46)
    1b00 3 - 5100 (0.45)
    19b0 3 - 4d10 (0.43)
    20 265 - 4ca0 (0.42)
    18e8 3 - 4ab8 (0.41)

Within a day, it's hundreds of megabytes leaked
Posted by Vincent [MSFT] on 2/10/2010 at 10:11 AM
This issue is not repro'ing on Dev10 RC1.
Posted by antbj on 2/3/2010 at 7:10 AM
It seems that the memory leak also occurs in other situations, not just when IsIndeterminate = true.
It disappears in all situations if a custom ControlTemplate is used for the ProgressBar.
Posted by Microsoft on 2/1/2010 at 9:53 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you