From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-11-2013 09:49 PM
Hello,
Were you able to turn off DWarn logging? Do you have access to a newer version of LabVIEW, if so do you still see the same behavior?
Are you able to regular reproduce the memory leak or is it sporadic similar to the other cases in this discussion forum?
You might also get more discussion from a new discussion thread related to the misbehavior you are experiencing as this thread is over a year old.
07-12-2013 03:47 PM
We were able to fix the problem. Unfortunetly I can't remember exactly how we were able to fix it. It might have been fixed when we updated our version of LabView. Maybe 2011SP1. Sorry I can't be more help.
07-17-2013 01:13 AM
The problem is fixed!
NI support told me that this behavior is a bug in LV2011, it is fixed with LV2011 SP1.
But it is possible to deactivate the useless logging with the parameter "dWarnLogging=FALSE" in the *.ini file.
Before NI told me the above points, I did another workaround, I just set the file to "write protect" (--> take care, the file is separately created for each user).
This worked, too of cause...
03-29-2017 07:50 AM
Making the change to the LabVIEW.ini file only affects when you are running source code. When running an executable.exe, you need to copy and deploy any relevant ini file settings to the executable.ini file, not just the LabVIEW.ini. For example, I often customize the default blink colors and speed, in addition to changing them in the LabVIEW.ini for development, I have to make those same ini entries in the corresponding exename.ini file that gets deployed (or created) during the build. As a saftey, I often write those entries programatically as part of the init. If I forgot to write them, they will at least be there on the next run.
03-30-2017 12:55 AM
@LabVIEWFL
While building an executable file, you can select to use a specific *.ini file for the output which is copied in the root folder while installing the EXE file. I usually create such file with all necessary entries.
03-30-2017 08:08 AM
Certainly. The person in the post above had made the change in the LabVIEW.ini and still had exe problems, was just clarifying the difference for them / future readers. Unless they specifically deployed a predefined ini, their LabVIEW ini settings are not transferred to the generated exe by default.
Also to all : be aware that when hunting this exe crash log entry :
"Possible path leak, unable to purge elements of base #0"
There are many possible different causes, not all related to DWarn ini param.
It has a more generic and elusive definition and, I think, is caused by a variety of situations, one of which is missing absolute DLL paths. I wish there were more clear and larger list of potential reasons.