Crash computeur => erase my configs files

[Francois Aujard]

Hello everyone,

I work on windows 10 (64bits) - labview 2021 (32 bits). Yesterday during a bench test, the power supply crash and my computer too.  When I restart my program, I realise that all the *.ini files (20 files!!!) I read with the Vi attached are empty..... I just used the read function of the Vi, at the beginning of my program. That's it. 

How is it possible that my 20 *.ini files are deleted? As if Windows had kept them in memory, I have big doubts about the Vi reading config files. 

Does anyone have an explanation? My code is unstable? what happened? Has this ever happened to you? 

Thanks for your help...

Translated with www.DeepL.com/Translator (free version)

ERR - Section en erreur V1.vi RW Parametres d'une voie.vi ConfigAnaIN.ini

[Antoine Chalons]

I've seen this, I can't open your code because I'm in LV 2020.

I'm guessing when the power cut happened, the file ref had been opened and not closed yet.

I don't know which VIs you use for to read/write your INI, but my I suggest to make sure that any time you access the files, you do use open file, read or write and close file as soon as you're done.

[LogMAN]

This can happen when the computer turns off while it writes data to disk.

I've had the same issue recently, which was caused by broken power supplies. Fortunately, we do automatic backups of all configurations, so it was an easy fix.

Other than that, I don't think there is much you can do about it. A UPS might be a good idea.

[Francois Aujard]

Thank you for your replies

@Antoine Chalons  attached to this mail the Vis in labview 2017 version. I use the basic NI Vis (Open config data, read key, close config data, etc...). You can look in my Vi, I open, read and close... I don't understand what's happened...😰

@LogMAN I use the write condition only when I do a calibration of my sensors, and I was not in this case. And I never write 20 files in the same times... It's very strange...

 

I have doubts about the config files Vis... 

 

ERR - Section en erreur V1.vi RW Parametres d'une voie.vi

[LogMAN]

Does the issue also occur during normal operation or only during a power failure?

If the files get cleared during normal operation, then there is probably a bug in your software. Otherwise, fix the power failure.

1 hour ago, Francois Aujard said:

I use the write condition only when I do a calibration of my sensors, and I was not in this case. And I never write 20 files in the same times... It's very strange...

Even if you do not intend to write data to disk, the configuration file VIs use an internal "dirty" flag to determine when data should be written to disk. This "dirty" flag is set to true during write operations. You can prevent it from writing any data using the optional input, but that input is not wired in your VI. This flag may get corrupted during power failure, causing it to write garbage data to disk.

Then there is also file caching from the operating system which could play a role in this: https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching

Quote

By default, Windows caches file data that is read from disks and written to disks. This implies that read operations read file data from an area in system memory known as the system file cache, rather than from the physical disk. Correspondingly, write operations write file data to the system file cache rather than to the disk, and this type of cache is referred to as a write-back cache.

[Antoine Chalons]

To get ride of this issue, I used a modified version of the MGI read / write anything (https://www.vipm.io/package/mgi_lib_read_write_anything/)

 

The modification was adding a "close file" primitive both when reading and writing the file, and when writing also a "flush" before the close.

[Antoine Chalons]

if I remember well moving from OpenG to MGI made the code run much faster.

[Francois Aujard]

Hello everyone and sorry for my late reply, I have a lot of work and machinery to deliver at the moment.

@LogMAN, I have test to add false in the input option "write file if changed" of the Vi "close config data", but I have the same problem again... after a power crash 😤😭

I will read the link you past in your last message https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching and try to understand the text. I am not very good at english... I think it's a good way to solve my problem. For the moment the problem appears only when I have crash power.... 

One interesting thing, I have another parameter file that uses the config data Vi. This one I run by dynamic call and close it at the end and the call reference and I have no problem with this file. The vi that crashes and that I sent is inserted in my code, at the beginning, but it is not called dynamically. Is it a coincidence that this one crashes and not the other one called dynamically?

@Antoine Chalons I will look at the vi in VIPM. I have often hesitated to redo the Vi of config data which I find very slow but practical. Since my crash files I have big doubts about these Vi NI. I will test the ones you suggest, thank you 

 

 

[LogMAN]

2 hours ago, Francois Aujard said:

I will read the link you past in your last message https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching and try to understand the text. I am not very good at english...

Mise en cache des fichiers - Win32 apps | Microsoft Learn

Edited November 9, 2022 by LogMAN

[LogMAN]

3 hours ago, Francois Aujard said:

One interesting thing, I have another parameter file that uses the config data Vi. This one I run by dynamic call and close it at the end and the call reference and I have no problem with this file. The vi that crashes and that I sent is inserted in my code, at the beginning, but it is not called dynamically. Is it a coincidence that this one crashes and not the other one called dynamically?

Are both files accessed at the same rate?

I'd assume that the one you call more often is more likely to fail.

---

Edit: It appears that the configuration file VIs clear the file size before they write new content. If your computer crashes at this moment, it will result in an empty file:

Here is what could happen:

To prevent this issue, try this:

1 - Use 'replace or create' instead of 'open'

2 - Disable buffering (this will directly write to disk without caching)

3 - Remove 'Set File Size' function

Warning: This VI is installed with LabVIEW, so changing it will affect any project on your computer!

Alternatively, it is also possible to just write the string to disk without opening the file explicitly. However, in this case caching will be used.

Edited November 9, 2022 by LogMAN

[Francois Aujard]

14 hours ago, LogMAN said:

Are both files accessed at the same rate?

Files that crash are queried less often. Only once at startup. The other one is read at startup and maybe written from time to time.

 

Thank you very much for your help, I am beginning to understand better what can happen... The Vi labviews are actually not very good  😉

 

Last night before shutting down the machine I looked at the resource monitor and surprise, all my files are in memory (see picture)

 

I changed my call from Vi to dynamic and no problem . The files appear in memory and then disappear. I was happy  , I put back as it was before to validate that I had maybe the problem and no more problem either  ... 

In fact Windows sometimes keeps the Vi in memory without writing them and sometimes not... And if I have a power cut while it decided to keep them in memory, it's screwed. My files will be lost on the next reboot. 

I will try your solution to force the writing of the files. I have seen that there is a memory management vi, do you think it will help me?

[LogMAN]

43 minutes ago, Francois Aujard said:

Last night before shutting down the machine I looked at the resource monitor and surprise, all my files are in memory (see picture)

Did you try disabling buffering as mentioned in my last post (2)?

15 hours ago, LogMAN said:

30 minutes ago, Francois Aujard said:

I changed my call from Vi to dynamic

What do you mean by that?

31 minutes ago, Francois Aujard said:

I have seen that there is a memory management vi, do you think it will help me?

I don't think it makes a difference.

If you dynamically call VIs using 'Call and collect' or 'Call and forget', then the 'Request Deallocation' function could free up memory earlier.

That said, it is mostly useful when you work with large amounts of data.

[Francois Aujard]

58 minutes ago, LogMAN said:

Did you try disabling buffering as mentioned in my last post (2)?

No, I saw your message after... 

 

58 minutes ago, LogMAN said:

What do you mean by that?

I will try your suggestion...  

 

[Rolf Kalbermatter]

22 hours ago, Francois Aujard said:

No, I saw your message after... 

 

I will try your suggestion...  

 

It sounds weird to me. Somehow you seem to open a file refnum in that configuration VI without closing it. How that could happen with the NI Config VIs is vague to me.

When you call a VI through the Call Asynchronous node, it is in fact started as its own top level VI. This means that LabVIEW resource cleanup rules apply to it separately. Once a top level VI goes idle (stops executing) LabVIEW will garbage collect any refnums that were opened during its execution in an subVI of it. So those refnums you see being open will go away as soon as that asynchronous call stops executing.

But how the standard INI files could cause this is pretty unclear to me. The NI Config Open VI opens the file, parses its contents and stores it in the object wire and then closes the file. The NI Config Close does only open it for writing when it determines that the configuration file contents is modified AND the boolean to save changes is set to true and then closes it again. If you set that boolean to false it never will open the file at all.

This makes me believe one of 2 things:

1) you do something else with the file in your configuration VI and don't properly close the refnum

2) you or someone else has modified the NI Config Open vi on your LabVIEW installation and that does not anymore properly close the config file after reading its contents

The only other possibility I can think of is a highly corrupted LabVIEW installation or some weird Windows configuration that keeps files open in the background despite the application having requested to close it. But the fact that making the VI asynchronous will "fix" it, would contradict the weird Windows configuration. It's simply LabVIEW again requesting to close that file handle as soon as the LabVIEW file refnum is garbage collected. This is the same happening when your code explicitly closes the file refnum.

Edited November 11, 2022 by Rolf Kalbermatter

[Francois Aujard]

Hello and thank you for your reply @Rolf Kalbermatter

I found out why the files are open in memory and it was my code that caused it. When I start the machine I open and read all the configuration files. Then I update a sensor offset and rewrite all the files. I see 2 improvements to make in this part of my code:

- Don't rewrite all the files when there is only one modified. We agree it's a bit silly.
- Redo the offset only once at PC startup (not at each program startup). And come to think of it, there's really no need to update it in the *.ini files

OK, so that's good. So I didn't just read the *.ini files at startup, I also wrote them. Now, I think @LogMAN 's explanation is right. Windows keeps the files in its cache and only writes them when there is enough to write, right? Why would these files stay open in the resource monitor all the time, sometimes? It's not often, but I've seen it happen. I like the idea of disabling file buffering in the Vi NI Config Close.  What do you think about it?

If Windows didn't save the files, it would be fine, but it empties them completely in case of a crash.... In this case, a power failure...

I'm going to keep investigating my code to see if somewhere I have a loop that would write the files permanently (I don't really believe it). The Vi that is used to write the files is the one I pasted in this post and unless I'm mistaken I close the references... Or maybe there's still something I didn't understand about references... 

 

Thank you for your help 🙏

[LogMAN]

5 hours ago, Francois Aujard said:

Windows keeps the files in its cache and only writes them when there is enough to write, right?

Something like that. The actual implementation takes several factors into account, for example, how frequently a file is accessed. Also, your disk has its own cache on top of that.

5 hours ago, Francois Aujard said:

Why would these files stay open in the resource monitor all the time, sometimes?

If you have a virus scanner running, it might lock the file for processing.

5 hours ago, Francois Aujard said:

If Windows didn't save the files, it would be fine, but it empties them completely in case of a crash.... In this case, a power failure...

I believe the Set File Size function is to blame for that. By changing the file size to zero, the file is effectively cleared. The write function after that is cached and never gets flushed to disk because of power failure, which leaves the file empty after reboot.

I'm not sure why it was implemented this way. The following will produce the same result without this issue:

[Rolf Kalbermatter]

3 hours ago, LogMAN said:

I'm not sure why it was implemented this way. The following will produce the same result without this issue:

This functionality is a post LabVIEW 8.0 feature. The original config file VIs originate from way before that. They were redesigned to use queues instead of LVGOOP objects, but things that were supposedly working were not all changed. Also using the "create or replace" open mode on the Open File node has the same effect.

Still something else is going on here too. The Config file VIs do properly close the file which is equivalent to flushing the file to disk (safe of some temporary Windows caching). Unless you save this configuration over and over again it would be VERY strange if the small window that such caching could offer for corruption, would always happen at exactly the moment the system power is failing. Something in this applications code is happening that has not yet been reported by the OP.

[LogMAN]

1 hour ago, Rolf Kalbermatter said:

This functionality is a post LabVIEW 8.0 feature. The original config file VIs originate from way before that.

That makes sense. Thanks for clearing that up!

1 hour ago, Rolf Kalbermatter said:

Still something else is going on here too. The Config file VIs do properly close the file which is equivalent to flushing the file to disk (safe of some temporary Windows caching). Unless you save this configuration over and over again it would be VERY strange if the small window that such caching could offer for corruption, would always happen at exactly the moment the system power is failing. Something in this applications code is happening that has not yet been reported by the OP.

A very similar issue happened to me a couple of month ago on multiple stations with broken power supplies. On those stations, the PC would sporadically turn off, sometimes (approx. 1-2 times a month) causing several of our configuration files to contain empty or garbage data (random bytes) after reboot. Those files are only written to at the start of a cycle that takes several minutes to complete. The likelihood of a power failure in that exact moment is very slim at best. On top of that, we currently update configurations sequentially, which means that only one file is open at any given time. However, often multiple files were affected. We never got to the bottom of it, as replacing the power supplies fixed the issue entirely.

I'd be happy to know what is causing this issue...

Edited November 12, 2022 by LogMAN

[Francois Aujard]

On 11/12/2022 at 9:08 PM, Rolf Kalbermatter said:

would always happen at exactly the moment the system power is failing

Not always happen, sometimes... perhaps once in 20 or 30...

[Rolf Kalbermatter]

1 hour ago, Francois Aujard said:

Not always happen, sometimes... perhaps once in 20 or 30...

Still, VERY high frequency if it is true that you don't continuously try to write to that file. 

[Francois Aujard]

Yes, that's why I'd like to change the Vi config so that it writes files directly to disk without going through the Windows cache. 

I don't often write to the config files. I can't modify the config file VIs or even copy the NI VIs they are private ... I'll end up redoing them entirely if this continues 😤.... 

I'm tired ☹️

[ShaunR]

1 hour ago, Francois Aujard said:

Not always happen, sometimes... perhaps once in 20 or 30...

I've only seen those sort of frequencies of corruption if the files are on a network drive.

[Francois Aujard]

when I say once every 20 to 30 to 30 power outages, it's an order of magnitude... I didn't have fun doing it really... Lately we've had a lot of outages due to machine start-ups and especially to a bad calibration of our main line

[Francois Aujard]

How is it possible to modifiy the NI Vi as you suggest me @LogMAN? I can't on my computer... The Vi are private...

[LogMAN]

They are unprotected in 2019. Was this changed in later versions?