The GDI Object limit problem

[Odd_Modem]

I have been asked to look at someone's program which opens up and runs in the editor but causes a crash during the app build. The crash is caused by the application builder reaching the Windows 7 limit of 10000 GDI Objects during the build. When the project is opened it will allocate about 5000 GDI objects and then the build process causes the count to increase from there. If the source code is opened it allocates about 5000 GDI Objects. This is LabVIEW 2012 32 bit running on Win7 64 bit. I have 22GB of RAM and 12 GB of video memory.

The program is nicely written and makes extensive use of classes. The vi loader seems to think there are 16K+ vis in the program. There are about 20 or 30 base class and the inheritance can run up to five levels. I compared the GDI object allocation of one of my programs that does not use objects and for a size of 2000+ vis mine had allocated 400 objects. I started to delete FP controls and sections of code in the hopes that one single change would reduce the amount of GDI Objects allocated and I actually removed all of the FP controls and all of the vis that call class methods, except for one. When I deleted the last vi that called class methods the GDI object allocation fell from 4000 to under 500.

Is there something about LabVIEW classes that causes GDI Object resources to be allocated?

The GDI Object quota key in the registry did not change the problem on Win7. Will increasing the quota throught the registery key work on XP so we can get a build done?

Thanks for any help!

[tst]

---

@Odd_Modem wrote:

Is there something about LabVIEW classes that causes GDI Object resources to be allocated?

---

I don't know the internal details of LVOOP, so I can't answer that, but there is one thing which comes to mind - classes load all their VIs into memory when they are loaded. If they call other classes, then they are also loaded, etc. If loading VIs uses GDI handles (although I don't see why it should), then this would explain that.

I know that silver controls use more GDI handles than modern or classic controls. Do the VIs in the classes use them? I wouldn't expect that to make a difference if the front panels of those VIs weren't actually open, but maybe they do.

You could try using this tool to see where the handles are - http://www.nirsoft.net/utils/gdi_handles.html

I never used it myself, but that guy's stuff is usually good.

[Odd_Modem]

A class member vi is then just a vi that has class terminals on it or does the vi have to appear in the class definition project like the read and write accessor vis? I have seen some vis in the code that have class terminals and the graph front panel control rather than a reference to the graph that is in the program GUI, as if the graph formatting result will be passed by value rather than by reference. I wonder if these graph formatting vis with their front panel objects are causing the large amount of GDI Objects.

[tst]

Member VIs are only those that are listed under the class in the project, but if you have VIs which use the class, they also load the class into memory. If you say you removed all the class VIs, then you would have to have removed that as well. It's easy enough to see in the dependencies section of the project. If you really removed all the classes, then they won't appear there (and I'm assuming they're not added explicitly to the project tree. If they are, then LV will load them).

I can say that your hierarchy seems fairly large. Usually, at these sizes people employ some kind of dynamic loading, if only to save on the time necessary to read all the files and load them into memory. I have no experience with a hierarchy of that size myself, but you could see about doing that. There are some documents online (the large apps group in the communities section is a good place for this, and you could also try asking this there). I don't know how practical that would be at this point in the project.

[Thomas_robertson]

Dear NI:

We wasted 4 days on this same issue.  LabVIEW was either crashing with the dreaded drawmgr.cpp message, or it was silently and mysteriously closing without even a crash report.  After snooping around on the forums for a bit I discovered the trick of increasing the registry entries for "GDIProcessHandleQuota" in the Windows 10 regsitry.  That is very obscure however and you need to help us poor programmers figure out what is going on.

When LabVIEW gets to the limit of GDI instantiations it would be nice if you could throw a meaningful error message such as "Exceeded GDI Handle Quota!" even if it still crashes that would have given us something to google.  It's a wonder that I stumbled across the GDI quota trick and I could have very well been tearing apart my code for a month if I hadn't.

[wiebe@CARYA]

Any chance these problems have anything to do with picture controls?

I'd expect to have exceeded the 10000 limit a long time ago if all controls\indicators allocated a gdi resource on load.

I know for a fact that the picture control uses GDI to draw. I'm not entirely sure, but I think most drawing should be done with mesa\opengl. I have seen this crash, and the picture control would fit.

[DahlmanR]

Hello!

This KnowledgeBase article seems to summarize a few steps that you can use when running into these limits, including the changing the registry quota. 

DAbort in image.cpp or drawmgr.cpp: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7OGSA0

[Odd_Modem]

I'm glad the posting helped find the source or solution to some problems. LabVIEW 7.1 was a great lunar lander; I didn't have much more flight after that version. Windows 32 bit and 64 bit have different registries, so maybe in my ignorance I change a setting in the wrong registry. Doing my own thing now, thanks a bundle for the learning experience NI.

[cordm]

Did this problem get fixed by NI? I moved to a new PC and forgot to increase the GDI limit - but the built did not crash this time! In fact the number of GDI stays quite low now (a few hundred). This is with LabVIEW 2020 SP1. I could not find any mention of it in the release notes.