Anlo
Anlo

Reputation: 3266

.NET graphics problem with GroupBoxes and NumericUpDowns

We're having some kind of graphics problem which seem to be related to the .NET runtime. Once in a while, the borders of all GroupBoxes and the arrows of all NumericUpDowns in our application dissappears. It seems like they stop repainting for some reason, because the NumericUpDowns sometimes have graphics garbage where the arrows should be.

We suspect that the error occurs after restarting the application several times. Once the problem is present, restarting the application doesn't help. But closing all .NET processes and restarting the application makes the problem disappear, this points toward a problem in the .NET runtime.

Our application is a WinForms app developed using VS 2008 SP1 and targets .NET 3.5. It runs on Windows XP SP3 in classic mode (client company policy).

I've searched for others having similar problems, but most hits involve custom paint events for GroupBoxes. Our controls are plain standard - no paint events are used at all.

EDIT: How can I deliberately exhaust the desktop heap to reproduce the problem? I've been playing with Task Manager and GdiUsage while creating pens, brushes and fonts like crazy. Not calling dispose of course, but also storing them in a list to avoid garbage collection. Still, after creating 100 000 pens with random colors I just have a few objects according to the monitor tools.

List<Pen> pens = new List<Pen>();
Random rnd = new Random();
for(int i = 0; i < 100000; i++)
  pens.Add(new Pen(Color.FromArgb(rnd.Next())));

Upvotes: 0

Views: 229

Answers (1)

Hans Passant
Hans Passant

Reputation: 941635

This is the telltale sign of a program that is leaking handles. Windows maintains a heap for GDI and User objects for all programs running on the machine. There's a quota of 10,000 handles for each individual process but a couple of leaking or heavy programs can get the heap filled to capacity. Once that happens, requests for a pen to draw a border (for example) will fail and stuff stops getting painted. This isn't always checked, particularly in native code.

You can diagnose it with Taskmgr.exe, Processes tab. Use View + Select Columns and tick Handles, USER Objects and GDI Objects. Watch for a program that has a lot of these (hundreds) and has steadily increasing numbers while you use the program.

You can leak handles in a .NET program when you don't use Dispose() or the using statement on disposable objects like pens, brushes, fonts, bitmaps. And when that program doesn't otherwise use enough memory to trigger a garbage collection so that the finalizer can release the handle.

Upvotes: 2

Related Questions