Topic: CGWatcher is not trying to restart CGMiner (Read 1907 times)
Awesome, thanks for posting that. I'll have to find somewhere on CGWatcher's download page to post it.
AHHHH!!!
The "Ensure miner stays running..." option was not checked... That's EXCATLY what I think will do the trick! I always want the miner running, I don't care much about it spawning up without my permission.. I really just want to set and forget about it, and have it monitor and make sure it's running
I've dug into the event viewer and I've found that around the time that CGMiner crashed, it was throwing this into the Windows Application Logs. I went into the event viewer and see this at about the times my CGMiner would crash:
While I was in the Event Viewer, I saw this log about CGWatcher... I've only had CGWatcher crash a few times, and I think it might have been my fault...
Here's the log if you are interested at all:
Again, Thanks for building this app, this is an amazing project you have going.
The "Ensure miner stays running..." option was not checked... That's EXCATLY what I think will do the trick! I always want the miner running, I don't care much about it spawning up without my permission.. I really just want to set and forget about it, and have it monitor and make sure it's running
I've dug into the event viewer and I've found that around the time that CGMiner crashed, it was throwing this into the Windows Application Logs. I went into the event viewer and see this at about the times my CGMiner would crash:
Code:
The Open Procedure for service "BITS" in DLL "C:\Windows\System32\bitsperf.dll" failed. Performance data for this service will not be available. The first four bytes (DWORD) of the Data section contains the error code.
While I was in the Event Viewer, I saw this log about CGWatcher... I've only had CGWatcher crash a few times, and I think it might have been my fault...
Here's the log if you are interested at all:
Code:
Faulting application name: CGWatcher.exe, version: 1.3.2.2, time stamp: 0x5253254e
Faulting module name: KERNELBASE.dll, version: 6.3.9600.16408, time stamp: 0x523d557d
Exception code: 0xc000041d
Fault offset: 0x000000000000ab78
Faulting process id: 0xbc4
Faulting application start time: 0x01ced18d77bf0762
Faulting application path: C:\MinerApps\CGWatcher-1.3.2\CGWatcher.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: 3b917649-3d81-11e3-80b9-00237de788f9
Faulting package full name:
Faulting package-relative application ID:
Again, Thanks for building this app, this is an amazing project you have going.
I don't see any indication that CGWatcher had stopped the miner. It also appears that it never received any information from the miner saying the device was sick or dead. Is this something you saw in the miner's window? Instead, my guess would be that the miner process crashed and closed because any time CGWatcher attempts to start/stop/restart the miner it creates several log entries.
By default, CGWatcher does not restart the miner if it is closed outside of CGWatcher because it doesn't know whether the miner crashed or whether you closed it (using Q or clicking the X to close the miner window). I didn't want CGWatcher to be relaunching processes that the user wanted to remain closed, so I made this an option (disabled by default). The option can be enabled in the Monitor tab: "Ensure miner stays running unless paused or stopped in CGWatcher". Enabling this means CGWatcher will always relaunch a closed miner unless CGWatcher closes it (user clicks the Pause Mining or Stop button, or a scheduled stop).
I can't say with 100% certainty this is what is happening, but if CGWatcher had received a response indicating the device was sick or dead... or if CGWatcher had stopped or attempted to restart the miner... there would be several log entries reporting this. If you have any more information that indicates otherwise, let me know. I did add some additional logging so if this happens in future versions it will be clearer to see... including an entry created if the miner closes outside of CGWatcher. Early on there are times during testing where I would accidentally close the miner by clicking X to close its window instead of stopping it in CGWatcher... so CGWatcher has never treated this as something critical. But if you enable the "Ensure miner stays running..." option it should.
I did find a bug that would cause scheduled actions triggered by a sick or dead device to not fire, but that isn't what is happening here... the "Restart miner when sick or dead devices are detected" monitor option was unaffected. I'll be releasing a minor update later today or tomorrow that fixes this and has the additional logging, along with a few remote-related changes and improvements.
Let me know if you have any additional information or questions, or if the problem continues even after enabling the "Ensure miner stays running..." option.
Thanks,
Justin
By default, CGWatcher does not restart the miner if it is closed outside of CGWatcher because it doesn't know whether the miner crashed or whether you closed it (using Q or clicking the X to close the miner window). I didn't want CGWatcher to be relaunching processes that the user wanted to remain closed, so I made this an option (disabled by default). The option can be enabled in the Monitor tab: "Ensure miner stays running unless paused or stopped in CGWatcher". Enabling this means CGWatcher will always relaunch a closed miner unless CGWatcher closes it (user clicks the Pause Mining or Stop button, or a scheduled stop).
I can't say with 100% certainty this is what is happening, but if CGWatcher had received a response indicating the device was sick or dead... or if CGWatcher had stopped or attempted to restart the miner... there would be several log entries reporting this. If you have any more information that indicates otherwise, let me know. I did add some additional logging so if this happens in future versions it will be clearer to see... including an entry created if the miner closes outside of CGWatcher. Early on there are times during testing where I would accidentally close the miner by clicking X to close its window instead of stopping it in CGWatcher... so CGWatcher has never treated this as something critical. But if you enable the "Ensure miner stays running..." option it should.
I did find a bug that would cause scheduled actions triggered by a sick or dead device to not fire, but that isn't what is happening here... the "Restart miner when sick or dead devices are detected" monitor option was unaffected. I'll be releasing a minor update later today or tomorrow that fixes this and has the additional logging, along with a few remote-related changes and improvements.
Let me know if you have any additional information or questions, or if the problem continues even after enabling the "Ensure miner stays running..." option.
Thanks,
Justin
Hey Justin Milone,
It happened again. I've sent the email. I've also pasted the requested logs into paste bin.
Debug Report:
http://pastebin.com/uAe6q70R
CGWatcher.Log:
http://pastebin.com/bbbtKuZ7
Thanks so much for your help!
It happened again. I've sent the email. I've also pasted the requested logs into paste bin.
Debug Report:
http://pastebin.com/uAe6q70R
CGWatcher.Log:
http://pastebin.com/bbbtKuZ7
Thanks so much for your help!
When this happens, can you go to the Tests tab in CGWatcher and click "Create Debug Report"... then email me the results? (email is in readme.txt) The debug log is particularly what I'm interested in seeing to see if it explains what is happening, and the debug report includes the last 25 or so log entries. If you can attach cgwatcher.log to the email that will be even more helpful since it will have all log entries.
Thanks,
Justin
Thanks,
Justin
So, about once every day, I'll go to work or sleep, and my CGMiner will just stop working with a "DEAD" or something status.. Not sure why... So I tried CGWatcher and set the settings that if it detects that it's DEAD to restart. Now when it dies CGWatcher just says "Miner is stopped" and CGMiner is not even running...
Has anyone run into this?
Here are my specs:
BFL 60 GH/s Unit
Windows Server 2012 Datacenter
Has anyone run into this?
Here are my specs:
BFL 60 GH/s Unit
Windows Server 2012 Datacenter
Jump to: