Closed oomek closed 5 years ago
Thank you for logs. I've published a new release (v1.0.63) with some changes.
It seems your crash happened after 15 days. If the crash isn't reproduced after 30 days with the new release, this bug can probably be closed.
Check the log. I've rebooted my PC on 13th of June
Right! Well, 30 days is still a long shot, by Windows standard. Feel free to close earlier if you're comfortable with this new release. And you can stop logging by deleting or renaming settings.txt (although you'd need to restart the program for it to take effect).
This is the event from the system logs that precedes the crash. It's just after I resumed the pc from sleep.
The system time has changed to 2019-07-08T14:58:14.500000000Z from 2019-07-08T14:46:44.104440500Z.
Change Reason: System time synchronized with the hardware clock.
Process: '' (PID 4).
and the one after that
The system has returned from a low power state.
Sleep Time: 2019-07-08T14:46:41.363786200Z
Wake Time: 2019-07-08T14:58:17.247894500Z
Wake Source: Unknown
Thanks for the logs. As far as I can tell, the sleep/wake event you mentioned is not related to this issue.
I have fixed a small bug in the way system awaking is handled, but it probably won't help. So, in addition to more logs, I have added another timer, running more slowly and using a slightly different mechanism.
From what I can tell, the program just stop being called by the system after approximately 70h of continuous execution (after sleep time is accounted for). I hope these changes will fix this issue, and if they don't I'll probably just give up. And curse Microsoft name again, as I have countless times.
The new release will be available shortly.
No news, I'm assuming the fix worked.
Crashed after 15 days. Sorry for not reporting it earlier. I was away. log.zip
Thanks for these logs, but didn't shed light on what the issue really is.
There are various ugly ways to resolve this, but I don't want to engage in any of them, I rather understand the problem. For now I'll just reopen the issue so that people are aware of it. Sorry!
What if you launched another process that monitors the base one and if it crashes it could relaunch it. This could of course work both ways.
I bet it's one of the ugly ways you've mentioned. I really start believing that Windows is killing your app if it detects what it's doing considering the fact how Microsoft has become paranoid recently when it comes to updates.
Yes, I'd call that an ugly fix.
Can you add to the debug log the values of the timers and any temporary variables used for conditionals? That would help detecting any potential overflows.
I don't have any of these things. Everything relevant is already in the log, as far as I can tell.
Your app is needed more than ever recently. Microsoft just forced the buggy update that breaks the searchui on my another machine after killupdate crashed once again after 7 days :(
The latest release 1.0.90 is a new attempt at fixing this problem. Hopefully the last, but let me know if there are side effects.
ZombifyMe. Cool idea for a name. Will it show a message to notify me if the restart happened, or will it record it in the log only?
There will a log entry.
TaskbarIconHost - 09/08/2019 21:53:45129: This process has been restarted
By default there is a notification when a process is restarted, but I've turned it off. Kill-Update seems to be widely used, I don't want to scare people. :)
Edit: It's a good thing you asked, because I found a big bug in v1.0.90. I have removed it and added a v1.0.91. Sorry about that...
v1.0.91 has a high-CPU consumption bug. It's fixed in v1.0.92.
Log in the attachement, but nothing that could explain the crash is there. It just silently stopped 1,5 h ago. Timer/variable overflow? log.txt