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.
