Labview program freezes computer completely but resumes after 5 minutes

[Cowbell]

I have a LabView (11.0, student) program on a laptop that communicates with a controlling computer over TCP/IP. The controlling program sends the LabView program strings which cause the program to enter various states. Everything seems to be fine for the most part. I did a lot of debugging with HyperTerminal, and it works fine.

The only weird thing is.... every once in a while (maybe once every 2 hours its on), the laptop will completely freeze for about 5 minutes, give or take. I initially thought this was unrecoverable, so I would ctrl+alt+del and I couldn't even bring up the task manager, the screen would just lock up, so I had to hard reboot. But one time, I was distracted on the phone, and the program magically resumed exactly where it had left off, and ran fine for another couple of hours without any problems. The really weird part is.... and I just noticed this, which is what made me decide to ask this question here.... is that when the laptop's LabView program resumes, I noticed that the laptop's clock had literally frozen in time as well, and is now 5 minutes behind the real time. I've had many crashed programs before... but none have ever done anything like this.

Without posting any of my code, which has a ton of sub-VIs... is there anything that could happen that would result in a frozen-in-time clock? I feel like this is a big problem and I should address it asap!

[Hooovahh]

---

@Cowbell wrote:

Without posting any of my code, which has a ton of sub-VIs... is there anything that could happen that would result in a frozen-in-time clock? I feel like this is a big problem and I should address it asap!

---

Reproduce the problem and NI will gladly help.  They don't want a buggy product anymore then you.  But I'm guessing you won't be able to isolate the problem.  Have you proven this is caused by NI?  Is there any other programs, anti-virus, firewall, or other network applications running?  Could this interaction be to blame?  Have you tried disabling parts of your code and seeing if it goes away or gets worse?

[Cowbell]

Not sure how to isolate anything, since its random when it happens (doesn't always seem to happen after the same command, for example). I don't have a virus scanner/firewall enabled (laptop's wireless card is disabled). I don't have any main processes open on my taskbar other than labview and windows explorer.

I guess in general, what are situations that could crash a computer and clock, but be recoverable (and as if nothing had happened)? Maybe then I can work backwards and see if my code is somehow doing that to the computer?

[stephencox]

An obvious first step seems to be to close Labview and let the laptop sit for a day and see if the problem reproduces.  It doesn't sound like you know Labview is the cause.  Maybe your computer is just on the way out.

If it does turn out to be Labview and you really can't see at what point in the code the problem occurs, you'll have to start removing portions of your code to see when the problem stops.  I've never seen this behavior, but I also have never looked for it--if something starts to freeze, I just kill it and undo whatever change caused the problem.  The only times I've had Labview cause a computer to stop responding, I accidentally did something that was so processor/memory-intensive that it overwhelmed the computer.  Maybe you have something like that going on.  Creating and then re-reading a massive data file, perhaps?  I can't imagine why it would return to normal after the freeze, though, unless it's something that only happens every two hours or so.

[Cowbell]

I've had this program doing the same thing for over a week now, so I think the reproducibility (from that standpoint) is confirmed. I started to keep a log file of which state the program was in when it crashed, thinking that I could see the 5 minute timestamp difference. (Usually, states are requested every 1-2 seconds at minimum, if not more like once a minute.) However, I noticed that the time wasn't changing while the program had stopped responding, so that when it would respond, the timestamp looked normal.

I am doing some data processing/copying, but I've run the program with task manager open and resource monitor open, and it looks like the max usage is ~25% of one of my CPU cores, and my HD is around 1MB/s; at most, this occurs for 60 seconds (that state occurs once every 5 min or so). Again, I have way more examples/iterations where these states DIDNT cause a crash than when they do. Which makes me think its not something in my coding directly, but in something "under the hood" that I don't understand.

[stephencox]

Did the program ever run without this problem?  If it occurs at random times in your code and you don't handle huge files or anything like that, I'm leaning toward a problem with the computer that's unrelated to Labview.  But this would be easy to test by just stopping Labview and waiting a day or two to see if the problem disappears.

[johnsold]

You mention 1 MB/s at the hard drive. How large are the files? Do you append to one file, create new ones, or something else? If you are appending to a file, the OS probably needs to fragment the file and allocate additional space from time to time.

Lynn

[Cowbell]

The 1MB/s or more was for long read times, around 60 seconds, resulting in ~60-65MB files. This didn't seem to cause any problems, as I didn't see any crashes during that step. It seems the consensus that LabView isn't causing this problem, so I'll check into other things.... Thanks!

[stephencox]

I am not ruling out Labview at all, but it seems easiest to rule out other causes first.  Another suggestion for getting timestamps of errors is to write something to another computer.  That way the correct timestamps will be preserved and you can check where the program fails.

Does the program maybe reopen the 65 MB files at some point?  Any chance it's trying to keep a bunch of these files in memory?  You could just delete the part that writes the file and run it for a while and see if the problem goes away with no data recording.

[billko]

Very strange.  You say that after an incident, the computer's time is off by that much?  Maybe it's hardware-related, like an overheating CPU or something.

I hesitate to say it's trying to write to a bad sector on the hard drive because I'm not sure if that actually stops the computer in its tracks or only bottles up the I/O.