I mention problems with the scripts, just in case the problem lies within the program logic, and is therefore transferred over to the EXE version. For instance shouldn't there be some form of check to see if the modem is accessible before starting these other programs?
The EXE version works quite differently.
It doesn't need any of the "other" programs to harvest the stats as it is all done via the one EXE program.
Also any temp files should be in a temporary folder.
Maybe, but I chose to have them in the Ongoing_Stats folder so that I could easily watch what happens during harvesting.
If the script terminates correctly, the temp files should be deleted.
The EXE version doesn't need to use those temp files.
The server doesn't really do much, back ups of all PCs are taken around 2pm, and cloud backup takes place from midnight to 8am. General file storage, and storage of Media Centre recorded TV. I think the problems with the modem may of triggered it, however continue reading.....
This is strange, although the modem all seems ok, my server has 508 processes running, poor things running flat out, loads of cmd,taskkill, curl etc and there's over a 100 of those data$$ files again. It seems rebooting the server this morning didn't solve the logging problem. Just rebooted it now and it's still creating multiple instances.
Did the scripts work at all following rebooting the server this morning?
Something has triggered the problem.
I see from one of your modem_stats.logs that the script had been running since 20th August, with the updated version running since 22:50, 6th September.
So, unless something has changed the script (maybe corrupted it), the root cause of the issue would appear to be elsewhere.
Little bit of investigation shows that when running the scripts I get errors: the connection is refused & the program tried to write to a non existent pipe.
Any idea's why I get this, I can login via the IP address
I have only seen the attempting to write to a non-existent pipe message when trying to run Teststats2.BAT to obtain snapshot data right in the middle of a 1 minute sampling harvest.
The 24/7 harvesting wasn't disturbed though & running Teststat2.BAT a few seconds later worked again.
Have you started to run Teststats2.BAT on a schedule that maybe clashes with the 1 minute harvest?
In Windows 7, Task Schedules can be staggered by seconds, whereas XP uses only full minutes.
I'm not sure about Vista though.
If so, a sleep command added to Teststats2.BAT can be used to stagger the actual data collection by say 30 seconds to avoid any clashes.
I remotely monitor another connection on a XP laptop, having just the log files emailed to me for graphing from the comfort of my own armchair.
I added a 30 second "sleep" to avoid just such a potential issue.
The 24/7 script takes 20 seconds or so from start to finish.
The EXE version takes less than 2 seconds to harvest & munge even more data.
PS. I've switched to my other modem last night, on the assumption the modem was faulty
Edit again: Should also mention this happens whether I run the scripts on the server or the ones on my PC
If that didn't resolve things, it may be worth stopping the 24/7 harvesting via "STOP_LOGGING_24-7.BAT", deleting the very last row in modem_stats.log to ensure the last entry is "clean" data, rebooting the server if that's where the scripts are run from/data stored, checking that the multiple instances of the programs used by the script have been cleared out & starting to log again via "START_LOGGING_24-7.BAT".
If you had manually set up the every minute schedule, stop it & restart it accordingly instead of using the STOP & START batch files.
In other words, start again almost from a new setup, but using your existing log file.
As a last resort, you could always start again with "clean" script versions & renaming modem_stats.log to force the start of a brand new log.
I hope some of that helps to get things back on track.
If not, it would suggest a possible cabling or PC problem that had suddenly started to cause problems.
The gradually increasing size of modem_stats.log, ERROR.LOG & ES.TXT shouldn't really cause too much of an issue, unless your server is running so slowly that it can't actually process the data within a 1 minute period.
My own modem_stats.log is currently 58836KB in size & previous logs had exceeded that size before archiving them, even when still using the script versions.