Community forum

Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.


greg.jackson35
2016-08-08T19:21:21Z
Hello, since 7/25/16, VisualCron has failed daily at 2:08PM to 2:09PM Central Time. I have set the service to restart itself, but I am trying to resolve the issue so it does not happen going forward. At this point, we have ensured our server is up to date and uninstalled Visual Studio 2010 programs since the error we are getting seems to be related to .NET framework. When the service stops, there is nothing in the logs within VisualCron that would indicate it is under heavy load. Here is the information from the Windows log:

Faulting application name: VisualCronService.exe, version: 8.1.0.35904, time stamp: 0x5728f473
Faulting module name: clr.dll, version: 4.6.1076.0, time stamp: 0x56d79ed4
Exception code: 0xc00000fd
Fault offset: 0x0000000000157740
Faulting process id: 0x884
Faulting application start time: 0x01d1f1304a61e61d
Faulting application path: C:\Program Files (x86)\VisualCron\VisualCronService.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 8e0ca685-5d9b-11e6-a6a8-c4346bb5bdef
Sponsor
Forum information
Support
2016-08-08T21:28:19Z
Please install latest official 8.1.2 version. If it happens again please contact us again for FTP details where you can upload the dmp- file.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
greg.jackson35
2016-08-10T19:19:39Z
Updating to the newest version seems to have fixed the issue. Thanks Henrik!
greg.jackson35
2016-08-15T13:24:28Z
Unfortunately, the error is back. It only did not crash on 8/11/16, it has crashed daily at the same time again since the update. I should have waited a few days before reporting back it was fixed. Here is the newest error:

Faulting application name: VisualCronService.exe, version: 8.1.2.36471, time stamp: 0x577d58e0
Faulting module name: clr.dll, version: 4.6.1076.0, time stamp: 0x56d79ed4
Exception code: 0xc00000fd
Fault offset: 0x0000000000150a04
Faulting process id: 0x858
Faulting application start time: 0x01d1f5e73e08cb32
Faulting application path: C:\Program Files (x86)\VisualCron\VisualCronService.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 82e8625d-6252-11e6-a6b9-c4346bb5bdef
Support
2016-08-15T15:17:57Z
1. No dmp file in log directory?
2. Is it failing at same time?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
greg.jackson35
2016-08-15T15:40:30Z
1. I do see an dmp file in the log directory. Please provide FTP information and I will upload the file or files if you want more than one.
2. Yes, it is generally from 2:08 to 2:09PM CST. This is actually a point when VisualCron is under very little load, the heaviest load is around 8AM CST.
Support
2016-08-16T13:05:26Z
Thanks, the error you are experiencing was fixed in 8.1.0.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
greg.jackson35
2016-08-16T13:10:22Z
We are on version 8.1.2.36471 and still experiencing this error. I completed the FTP upload of the dmp file yesterday afternoon CST. The issue did go away for one day and then has returned for four consecutive days.
Support
2016-08-17T08:06:00Z
Sorry, we see now that this was slightly different. It seems the error is related to a Remote File Trigger using SFTP. Can you tell us some more details;

1. do you have many Remote file triggers
2. do you have many files that you are monitoring
3. what is the current memory usage of the VisualCronService.exe
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
greg.jackson35
2016-08-17T12:18:23Z
1. We have 7 remote triggers. If it helps, none of them have a last run time near the time the program is crashing.
2. We have 54 jobs that are triggered by file events, not including the 7 remote triggers.
3.169,056K, our server is currently at 9% Physical Memory usage. I have monitored system resources during the time the service tends to fail and did not notice any spike for the resources on the server.
Support
2016-08-17T16:19:50Z
Originally Posted by: greg.jackson35 

1. We have 7 remote triggers. If it helps, none of them have a last run time near the time the program is crashing.
2. We have 54 jobs that are triggered by file events, not including the 7 remote triggers.
3.169,056K, our server is currently at 9% Physical Memory usage. I have monitored system resources during the time the service tends to fail and did not notice any spike for the resources on the server.



About 1. it is not related to "running" but polling. So, it crashed, for some reasing during polling of a SFTP server. We will try to do some tests here.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
greg.jackson35
2016-08-17T16:25:17Z
I might have found the issue. There is one of those 7 that polls every 60 seconds opposed to everything else being either 6000 seconds or 3600 seconds. I have changed it to 6000 seconds. I will followup around 2:15PM CST to advise if the crash still occurs. Thanks for the idea!
greg.jackson35
2016-08-17T19:26:13Z
The issue did not happen again this afternoon. I will follow up again tomorrow to see if that resolved the issue on a more permanent basis this time. Thanks again for all of your help.
Support
2016-08-18T17:55:14Z
Are you using the Download option on the Remote file Trigger as well?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
greg.jackson35
2016-08-18T18:02:30Z
Yes, there a download task and an email task in the job triggered by remote file trigger. The file itself only downloads every now and then, not daily. I will follow up in an hour and a half to let you know if it crashes again. So far, so good though!
greg.jackson35
2016-08-18T19:15:41Z
It looks like increasing the polling time resolved the issue. Thank you very much for your help!
Support
2016-08-19T20:47:15Z
Originally Posted by: greg.jackson35 

It looks like increasing the polling time resolved the issue. Thank you very much for your help!



Thanks, we will stress test this.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Scroll to Top