Hi,

I've created a whole bunch of jobs that use the Write File task a lot to write logging messages to text files. Ever since we implemented VisualCron, these had been working perfectly, but lately they randomly fail with this message:

Exception in Task: FileStream was asked to open a device that was not a file. For support for devices like 'com1:' or 'lpt1:', call CreateFile, then use the FileStream constructors that take an OS handle as an IntPtr.

This causes the job to fail, but if I execute the job again (or even just that one task), it usually works fine. I realize that I can set this task (and all such logging tasks) to not cause the job to stop, but I'd rather figure out why it's happening in the first place. Does anyone have any ideas? I've just turned on extended debug logging, but it's not an issue that I can recreate at will, so I have to wait until the issue happens again before I can sift through the log to find any more info.

Thanks.

Not sure...StackOverflow replies indicate a possible issue with the naming or IP of the destination computer for the file to be written

Is the file you are trying to write across your network?

If yes, I would have it write two logs, the one that you currently have setup PLUS one locally. If you are writing across the network it may take time for the destination computer to be recognized and the security rights accepted. Writing locally would probably eliminate that delay.
If the local log works but the network one fails on occasion then you have your answer. The solution would be to always write locally, then follow up the "Write file" task with a "Copy file" and move on

If the answer to the above question is No, then I would check Windows logs and see what you can find. You should see an Application log for each job and task run.

Thanks for the reply. Yes, the log files are all stored on a network. I had thought about changing that to a local file and then copying that to the network folder, as you suggest, but that's a LOT of stuff I'd need to change. Some jobs create a brand new log file for each run, others write to the same log file and just keep accumulating (the files are archived once a week). It's possible I could create a new job with a VisualCron trigger "on job completion", and have it copy the previous job's log file over to the network location, which would avoid having to add the copy file task to every job I have. But the issue with writing the log files locally is that I wouldn't be able to view the log file as it's being created, unless I remote desktop into the virtual machine that we have VisualCron running on.

Also, these network log files have been working perfectly from when we first implemented VisualCron I think back in 2018 up until only a month or so ago. I agree though that since we haven't made any changes to our VC config (or version) recently, the likely cause would be network issues, so I'll have to go through the jobs and alter how they log stuff to see if that fixes it.

Just an update - I've been going through all my jobs and adjusting them so that they initially write their log file to a local file. I also added a step at the very end of each job that copies that local file to the LAN folder that I had been writing to prior to all this. This seems to have reduced the job failures, although one of the jobs failed earlier this morning with the error message below. This message makes it far more obvious that the issue is not with VisualCron, it's with our network. If a job fails for this reason, I can live with that, because it means that the rest of the job ran fine, it's just that the log file didn't get copied to the LAN.



I would like to keep the local log folder clean, i.e. I don't accumulate days worth of files there that didn't get copied due to the above type of failure. I already had a job that reboots the server every night, as well as another job that runs as soon as the server starts, so I added a task to that job that would copy anything remaining in the local log folder over to the LAN folder.