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.

Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Temp file with a possible path leak is filling my hard drive!

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.

 

Regards,

M. Whitaker
ni.com/support
0 Kudos
Message 11 of 16
(3,005 Views)

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.

0 Kudos
Message 12 of 16
(3,000 Views)

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...

Message 13 of 16
(2,977 Views)

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. 

0 Kudos
Message 14 of 16
(1,372 Views)

@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.

 

0 Kudos
Message 15 of 16
(1,364 Views)

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.

0 Kudos
Message 16 of 16
(1,357 Views)