Fatal Internal Error: "drawmgr.cpp" line 3793

[DogOnWood]

Well if anyone is still interested it appears that the issue was NOT fixed in SP1

program died at 64 hrs with the same old drawmgr.cpp error

been beating on this for a year and as you can guess upper management is getting a bit restless

hope someone decides to fix this soon.

[andylikescandy]

I have had this exact error too in a compiled executable.  The executable was compiled in 32 bit LabVIEW 2010 and was running on 64 bit Windows 7 enterprise edition.  We have not seen this error in LabVIEW 2011, but unfortunately there were other errors with version 2011.  Specifically, Memory Access Violations using LabVIEW 2011 (Access violation (0xC0000005)).  These issues are killing us.

If anyone from National Instruments is listening, PLEASE work on solving all these critical bugs in LabVIEW.  Instead of coming out with a new version every year, it would be better if you worked on creating one stable version of LabVIEW that we could count on.

[DogOnWood]

I no longer have this issue, it has to be related to one of three things.

I was using tabs - removed them from the interface -  I have a feeling this was the cause

I was using MS Access as my db, switched to MySQL

and I can't remember what the third item I changed was and I can't find my notes 😞  it was interface realated

last test sequence was run for over 1700 hrs with no problem.

[andylikescandy]

Thank you for updating me on how you resolved it.  We use tabs extensively so eliminating them isnt really an option.  Are you using serial communications? If so, what type of serial port hardware are you using?

[DogOnWood]

I comminicate with a chiller over RS-232, using the PC's built in serial port, can't say I've had any issues there.

I'm getting it's temperature reading once every 20 seconds or so...

[ThiCop]

Hello Andy,

To make sure i understand you correctly:

Are you getting the drawmgr.cpp Fatal Internal Error as well as the Memory Access Violation?

[andylikescandy]

Looks like this is probably the issue I have been having that was causing the Memory Access Violation.  Thanks to NI support for figuring it out!

 

1. Bug Fixes

The following items are bugs fixed for LabVIEW 2012 SP1

ID	Fixed Issue
356459	Crash in DrawPlot when trying to display 42984 points on XY Graph

Im not sure if this relates to the drawmgr.cpp error or not...

[Mike_Le]

I am experiencing the same kind of problem, but while I try to build an executable.

The project file is about two years old and we've been doing builds on it a couple times every month with updates to the original application.

Recently, we were getting an error 1003 on build attempt, claiming one of the VIs was broken. Everything ran fine in Developer mode and the "broken" VI ran fine as well, no broken arrow. We did a mass compile, which didn't resolve the problem.

Finally, I took the "broken" VI and renamed it. Then I saved a copy of the renamed VI back to the original file location. The 1003 error during builds went away.

Instead, the build would progress maybe 1/6th of the way through the progress bar, then completely crash the LabVIEW developer environment.

Here's the error message we get from LabVIEW Crash Reporter:

DAbort 0x9b027400 in drawmgr.cpp.

Version: 12.0.1f4 (32-bit)

Any ideas? Attached is the error data.

[m1ndst0rm]

I found out, that this error occured because there are so much UNSAVED info in your VI.

Temporary this error can be removed by decreasing autosave time as less as needed. It was set to 5 minutes - crashes almost every 15 mins, after decreasing to 2 minutes - no crashes for 3 days.

I think that crash type caused by too small memory available to storing unsaved changes of VI (ypur VI is too big and so many unsaved changes).

IMHO, but thinking so I was able to remove this error.

PS Operating and programming on Fastwell CPC304 (AMD Geode 500MHz, 256 RAM, VI size almost 500 KB w/o subVIs, WinXP + LV2009 running well!)

[Gajic4x4]

I was running into the same error message "DAbort 0x9B027400 in drawmgr.cpp" on my machine with LabVIEW 13.0.1f2 on Windows 7 Professional 64-bit

The compile would run about 1/3 of the way through and then labview would stop and show the crash reporter. In my case it turned out to be the "GDI Object" problem described in the 3 posts linked below.

http://digital.ni.com/public.nsf/allkb/ED23C965B6F2BDA586257AB5007880F7

http://forums.ni.com/t5/LabVIEW/Application-Builder-Crash-drawmgr-cpp-line-3570-when-building/td-p/6...

https://forums.ni.com/t5/LabVIEW/Silent-crash-when-building/td-p/1233575

I confirmed this by using windows task manager during the compile to observe the numnber of GDI objects.

Instructions on displaying GDI objects in windows task manager are here

http://technet.microsoft.com/en-us/library/cc958260.aspx

Within about one second of reaching 10000 GDI objects, the LabVIEW crash would occur.

I tried changing the registry as described in the 2nd linked post to 20000, restarted the computer and still the compile would crash at 10000 GDI objects.

Instructions can also be found here

http://msdn.microsoft.com/en-us/library/ms724291.aspx

I checked the registry again and found the that value in the key had reverted to 10000. I changed it to a smaller number (15000 this time) and restarted the computer. The compile needed about 10100 GDI objects in my case and LabVIEW would run without crashing.