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,

I have a file that is being automatically created on my C drive.  I believe it is being created by windows in response to me real-time host.exe.  It creates the file without issue most of the time, but it occasioanlly creates a file that fills up the rest of my hardrive of 260 GB.  The file is so big I can't open it to see the error.  I posted an example of the file when it creates normally.  It mentions a possible path leak, what is the cause of this.  I am running Labview 2011 on Windows 7.  I am creating several .txt and .xls files in the code, could this be the cause.  I have been running version of this code for years, why would it start happening now?

 

Location of the file:

C:\Users\username\AppData\Local\Temp

 

Contents of the file:

####
#Date: Tue, Feb 21, 2012 3:12:25 PM
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: HEDWEC Host (Ver 1.22a)
#Version: 11.0 32-bit
#AppKind: AppLib
#AppModDate: 02/21/2012 22:00 GMT
#LabVIEW Base Address: 0x30000000

Possible path leak, unable to purge elements of base #0

 

Thanks in advnace,

Drew

0 Kudos
Message 1 of 16
(8,120 Views)

Can you post the sections of code related to creating and writing to the file?

 

Notepad or Excel can't handle a 260GB file, but you can view sections with LabVIEW with a little work.  Use Set File Position to mark where you want to start reading, then Read from Text File with the count terminal wired to get a small section.  You can at least see if the data is garbage, a repeated pattern, or something else.


--Using LV8.2, 8.6, 2009, 2012--
0 Kudos
Message 2 of 16
(8,111 Views)

Sorry for the delay on my reply, but this problem occurs very infrequently.  I have variations of this code running constantly on several different computers and I run into this problem maybe once a month.  I have posted a snippet of a file creation part of the code that is common across all of these variations.

 

I want to make it clear that the file that is filling up my hard drive is not being created by my code directly.  It is being created either by a built in labview thing or a windows thing, do you have an idea which?  Also, this file is not being created with a slow build up.  It is filling up in a very short time period, in a matter of minutes.

0 Kudos
Message 3 of 16
(7,992 Views)

Hi Drew,

 

would you be able to recreate this behavior on a consistent basis? does this giant file appear when you build an installer or does it appear when you install an installer? does it happen when a particular VI is executed? anything else that can help us recreate this issue in a more consistent manner will aid in finding the cause. Thanks!

 

 

Aldo A
Applications Engineer
National Instruments
0 Kudos
Message 4 of 16
(7,972 Views)

I have been trying to replicate the event on my test bench this week with no success.  So far it has occurred only when no one has at the computer and the real time and host proprams have been running for days.  I do not know what particular VI is causing the error.  The file that is created in the temp folder has the name of the executable.  The data file saving snippet that I sent you earlier saves every 10 seconds.  I'll let you know if I am able to cause this problem to occurr on my test bench. 

0 Kudos
Message 5 of 16
(7,967 Views)

I was able to get the computer to create the temporary file on my test bench.  It had been running in "standby mode" for 3 days with no human interaction.  It steadily filled up the computer's hard drive from 12:22am to 8:47am.  I was able to open parts of the file with labview as someone suggested earlier.  I have attached a file with some snippets of the file. Again, there are no triggers in the code that would have created a file that hadnt been created or written to hundreds of times at this point.

 

The part that draws my attention is:

"c:\builds\penguin\labview\components\LVManager\trunk\11.0\source\fontmgr.cpp(7856) : DWarn: Bogus font"

 

Hopefully this enlightens the issue.  Are there any clues as to whether it is windows or labview creating this file?

0 Kudos
Message 6 of 16
(7,936 Views)

Hi Drew,

 

It looks like providing that txt file was helpful.  It helped me to locate a few other instances where this behavior has been documented.  The bug is fixed for LabVIEW 2011 SP1, but the workaround is as follows:

 

Turn off DWarn logging by adding the following ini key to the LabVIEW log file: "dWarnLogging = FALSE"

 

In other words, add the line of text "dWarnLogging = FALSE" to the end of the LabVIEW.ini file located at C:\Program Files\National Instruments\LabVIEW 2011.

 

Hope this helps!

Ryan C.
Applications Engineer
National Instruments
0 Kudos
Message 7 of 16
(7,923 Views)

I had done the change to the configuration file as you had suggested but I just had 2 more files fill up my hard drive.  Both of the computers were running the host .exes that were developed on computers that I had altered the configuration files.  Is there a configuration file on the PCs that are running the .exe files with the run time engine?

0 Kudos
Message 8 of 16
(7,792 Views)

Hi DrewCommPower,

 

I've the same issue.... Have you solved the problem anyhow?

0 Kudos
Message 9 of 16
(7,093 Views)

I have the same exact issue with LabVIEW 2011 runtime engine.  Please if anyone knows what is causing this post it here!  

 

All the bugs in LabVIEW 2011 are killing us!

 

0 Kudos
Message 10 of 16
(6,948 Views)