gleichman Posted March 15, 2017 Report Posted March 15, 2017 I have a program that is creating about 200 new GDI Objects an hour. After about 24hrs of execution the GDI Objects exceeds 5000 and LabVIEW crashes (Sorry for the inconvenience). I disabled all of my UI updates and it continues to leak. Are there non-UI actions that create new GDI objects? Quote
MikaelH Posted March 15, 2017 Report Posted March 15, 2017 I always start by changing the GDI Object limit to 65535, but that just solves your issue for few more days.https://msdn.microsoft.com/en-us/library/windows/desktop/ms724291(v=vs.85).aspx Does this happen in exe file version as well? Quote
gleichman Posted March 16, 2017 Author Report Posted March 16, 2017 I run the system as an executable and it has the same problem. I was hoping to find out what kind of LabVIEW functions create new GDI objects. This is probably something bad that my code is doing, but my system is large and it has been difficult to isolate the culprit. Quote
MikaelH Posted March 16, 2017 Report Posted March 16, 2017 Do you open references to Reentrant VIs and not closing the reference? Quote
gleichman Posted March 17, 2017 Author Report Posted March 17, 2017 I ran DETT and found a reference leak. I fixed it and verified the fix with DETT, but I still have the same GDI object leak afterwards. Quote
Rolf Kalbermatter Posted March 20, 2017 Report Posted March 20, 2017 LabVIEW creates a fixed set of GDI objects on start and then as needed when it draws something on the screen, and also offscreen when you work with Picture control or print something. In my work with LabVIEW I haven't really seen LabVIEW itself leaking GDI objects for quite a few years. However if you interface to external components such as ActiveX, .Net or DLL functions, that of course does not mean anything. They can create and not properly deallocate GDI objects as much as they like. DETT only can look into LabVIEW resources itself, not into resources allocated by those external components. The way to go after this is to get an idea of the rate of GDI object increase and trying to relate that to certain operations in your application. Then starting to selectively disable code parts until the object count doesn't increase steadily anymore. From there concur and divide by disabling smaller and smaller parts of code until you get a pretty good idea about the location. Quote
smithd Posted March 23, 2017 Report Posted March 23, 2017 I've never used this but it might help: http://www.nirsoft.net/utils/gdi_handles.html seems to give you a vague idea of what the objects are actually being used to display Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.