Monday, April 21, 2008

DibGraphicsBufferManager crash - Update!

Here's an update to our DibGraphicsBufferManager crash problem. You may remember that we were experiencing crashes with obscure stack traces, usually in the DibGraphicsBufferManager class. We tried disposing Graphics objects, and were toying with the crazy idea of turning off double buffering. The double buffering was a no-go, as the performance and appearance was abysmal without it. The disposal of the Graphics objects at least made the problem less common.

What we've since discovered is that there is a limit on the number of GDI objects an application can use. No surprise, really. I mean, there obviously would be a limit. What was surprising was the fact that we were hitting the limit.

GDI Objects

There is a theoretical limit of 65,536 GDI handles per session. However, the maximum number of GDI handles that can be opened per session is usually lower, since it is affected by available memory.

Windows 2000: There is a limit of 16,384 GDI handles per session.
There is also a default per-process limit of GDI handles. To change this limit, set the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota

This value can be set to a number between 256 and 65,536.

Windows 2000: This value can be set to a number between 256 and 16,384.


I experimented with a test machine here. It has five monitors, one 1280x1024 and four running at 1536x2048. I displayed a CT study at 5x8 - five images across, eight images down. It displayed fine. So I lowered the GDIProcessHandleQuota from the default 10,000 to 7,000. Rebooted. Displayed the same CT study. Boom. DibGraphicsBufferManager crash, with the same stack trace we've had before.

The hospital that has been seeing lots of these crashes played with the registry setting over the weekend and hasn't (as far as I've heard) had any more of these crashes.

We have a call in to Microsoft to find out what a safe value is for the GDIProcessHandleQuota setting. I think the hospital set it to the maximum.

And now, if you'll excuse me, I need to go dance naked around a fire in celebration.

1 comment:

  1. Ha. I was the one playing with those values at the site! I did pretty much the same you did here, bring it down to 2000 first, watch the app crash, then bump it up to a safe value.

    We set the value on every single diagnostics client to 65,536 (or 10,000 hex) on Thursday night, and as you said, no crashes ever since. Ain't that fun?

    I'm not sure if I copied you when I sent my update to Alan, but that was the coolest moment in the whole week. You guys made us look very well in front of the customer!

    Try not to get burn. It hurts a lot, you don't want to know.

    ReplyDelete