m0unds

EIS 12 - Automatic game mode is breaking update scheduling again

Recommended Posts

I actually ran into this same issue back in May with one of the EIS11 betas, and it seems it's still a problem with version 12. I'm encountering this issue on a fresh install of EIS 12 on Win10 x64.

 

When you have a fullscreen app running and EIS suspends updates, it never resumes them again. I played a game for an hour or so, then left my PC running. Four hours later, I came back and it still hasn't fired a single update. To be clear: I did *not* enable game mode manually. I merely started a fullscreen app, then ran it for a bit, then exited out of it. I commanded an update manually after 4 hours since the last update.

 

To reproduce:

 

Start your PC.

Load a fullscreen app and run it longer than the update interval.

Exit the app.

Leave the PC running.

 

Expected behavior: EIS updates at some point in 4 hours without a fullscreen app or screensaver running.

Observed behavior: EIS doesn’t update at all.

 

If I reboot, it updates at login and continues to update so long as I don’t run any fullscreen apps. The first time a fullscreen app runs for longer than the configured update interval, EIS will no longer automatically update.

 

I can reproduce with debug logging enabled if it would be helpful, just let me know.

 

Thanks

Share this post


Link to post
Share on other sites

Unfortunately I'm not able to confirm the issue. After a few hours of ARK I opened EAM and it was downloading an update. Granted it was on Windows 7 x64, and it was EAM rather than EIS, although I don't expect either of those differences to matter. Regardless, I'll try to get this tested in a VM as well.

Your forum profile says you use Windows 10. Was it 32-bit or 64-bit?

Share this post


Link to post
Share on other sites

OK. Do you know what build of Windows 10 you have installed? If you're not familiar with how to find that information, then there's an article at this link that explains it.

Share this post


Link to post
Share on other sites

OK. Do you know what build of Windows 10 you have installed? If you're not familiar with how to find that information, then there's an article at this link that explains it.

 

Version 1607 Build 14393.321

Share this post


Link to post
Share on other sites

Hm... My 64-bit Windows 10 VM still doesn't have the Anniversary Update. I'm going to see if I can manually force it to install so that I can test this.

Share this post


Link to post
Share on other sites

Do you need any logs from me? I can provide some if it would help nail down the cause of this. I've been able to trigger it on both my workstation and laptop. I found I could trigger the issue more quickly by lowering the update check interval to 30 minutes, so I miss more scheduled updates before closing out the game I test with. 

Share this post


Link to post
Share on other sites

Sure, lets go ahead and get some debug logs:

  • Open Emsisoft Internet Security from the icon on your desktop.
  • In the 4 little gray boxes at the bottom, move your mouse into the one that says Support, and click anywhere in that gray box.
  • At the bottom, turn on the option that says Enable advanced debug logging.
  • Either click on Overview in the menu at the top, or close the Emsisoft Internet Security window.
  • Reproduce the issue you are having (wait until it's fairly obvious that updates are not being downloaded as scheduled).
  • Once you have reproduced the issue, open Emsisoft Internet Security again, and click on the gray box for Support again.
  • Click on the button that says Send an email.
  • Select the logs in the left that show today's dates.
  • Fill in the e-mail contact form with your name, your e-mail address, and a description of what the logs are for (if possible please leave a link to the topic on the forums that the logs are related to in your message).
  • If you have any screenshots or another file that you need to send with the logs, then you can click the Attach file button at the bottom (only one file can be attached at a time).
  • Click on Send now at the bottom once you are ready to send the logs.
Important: Please be sure to turn debug logging back off after sending us the logs. There are some negative effects to having debug logging turned on, such as reduced performance and wasting hard drive space, and it is not recommended to leave debug logging turned on for a long period of time unless it is necessary to collect debug logs.

Please note that if you have a lot of debugs logs, then you should not send all of them. There is a size limit, and currently there is no error if the message is rejected due to the size being too large. Normally we only need one copy of the 4 or 5 different logs that have been saved after the time you reproduced the issue (the list shows what time each log was saved). Those logs have the following names:

  • Security Center
  • Protection Service
  • Real-Time Protection
  • Firewall
  • Logs database (contains the logs you can view in Emsisoft Internet Security by clicking on Logs at the top of the window).

Share this post


Link to post
Share on other sites

Hey,

I sort of reproduced it and sent the logs. It's hard to cause the issue intentionally. That being said, EIS crashed when I tried turning off diagnostic logging, so I'm not entirely sure they actually sent before it crashed.

Thanks

Share this post


Link to post
Share on other sites

We did receive the logs.

Would it be possible to also send us a copy of your a2scheduler.ini file (in an e-mail or a private message)? It will be in the Emsisoft Anti-Malware folder in Program Files.

Share this post


Link to post
Share on other sites

Our developers let me know that the debug logs did not contain information about the problem. They believe that if you restart your computer after turning on debug logging, and then try to reproduce the issue, that the logs that are saved after the reboot will contain more information. Would it be possible to try that and get us new debug logs?

Share this post


Link to post
Share on other sites

Our developers let me know that the debug logs did not contain information about the problem. They believe that if you restart your computer after turning on debug logging, and then try to reproduce the issue, that the logs that are saved after the reboot will contain more information. Would it be possible to try that and get us new debug logs?

 

Sorry for the delayed response. Yeah, I'll enable debug logging, reboot and try to reproduce.

 

Thanks

Share this post


Link to post
Share on other sites

Were you able to send the logs? Since we haven't received any, I want to verify whether or not they have been sent yet, just in case there was an issue with us receiving them.

Share this post


Link to post
Share on other sites

Were you able to send the logs? Since we haven't received any, I want to verify whether or not they have been sent yet, just in case there was an issue with us receiving them.

 

Reproduced and sent logs just now.

 

Thanks

Share this post


Link to post
Share on other sites

I didn't see any new messages from you in our helpdesk when searching for the e-mail address associated with your forum profile. It's possible that the logs were too large.

Try holding down the Windows key on your keyboard (the one with the Windows logo on it, usually between the Ctrl and Alt keys) and tap R to open the Run dialog. Paste the following into the Run dialog, and then click OK:

%AllUsersProfile%\Emsisoft\Logs

The logs will have names with the dates and times they were saved, however you can make it easier to identify the newer ones by sorting by Date modified. Just select the ones you want to send to me, right-click on them, go to Send to, and select Compressed (zipped) folder. Windows will create a new ZIP archive with the logs in it that you can send to me in a private message. Note that you can move the ZIP archive to your Desktop or Documents folder to make it easier to find.

Share this post


Link to post
Share on other sites

Improvement request: tell the user if the debug logs are too large to send so we don't come to the forum to tell you we sent them when we didn't ;)

Anyway, I'll zip and upload when I have a moment and ping you after.

Thanks

Share this post


Link to post
Share on other sites

Thank you. I have added your logs to our bug report.

When zipped the logs aren't very large, so I don't think it was a file size issue that prevented us from receiving them.

Share this post


Link to post
Share on other sites

I just confirmed that we did receive the logs you sent on the 22nd. It looks like the system had automatically moved it to the Trash folder, and for some reason when I searched for your e-mail address it didn't show the message that was in the Trash folder. I apologize for not checking that sooner.

Share this post


Link to post
Share on other sites

I just confirmed that we did receive the logs you sent on the 22nd. It looks like the system had automatically moved it to the Trash folder, and for some reason when I searched for your e-mail address it didn't show the message that was in the Trash folder. I apologize for not checking that sooner.

 

no problem, thanks for confirming you got them

Share this post


Link to post
Share on other sites

One of our developers let me know that he found the following in your logs (times are from your computer, and are in 24-hour format):

  • 13:22 log shows Game Mode off
  • 13:23 log shows Game Mode is activated
  • 14:19 first attempted update with Game Mode on, which is canceled due to Game Mode, and update is scheduled to be tried again at 14:49
  • 14:49 update attempted again, also canceled due to Game Mode, and next retry is scheduled for 15:19
  • 15:19 update attempted again, also canceled due to Game Mode, and next retry is scheduled for 15:49
  • 15:49 update attempted again, also canceled due to Game Mode, and next retry is scheduled for 16:19
  • 16:19 update attempted again, also canceled due to Game Mode, and next retry is scheduled for 16:49
  • 16:49 update attempted again, also canceled due to Game Mode, maximum number of retry attempts reached and next update attempt is scheduled based on current update settings (1 hour instead of 30 minutes, so 17:49)
  • 16:50 Game Mode is deactivated
  • 17:20 Game Mode is activated again
  • 17:38 Game Mode is deactivated again
  • 17:42 logging is turned off (roughly 7 minutes before the next scheduled update attempt)

Based on that, Game Mode and the automatic update process appears to be working as expected. Unfortunately, since logging was disabled a few minutes before that last scheduled update that appeared to be about to try to run while Game Mode was off, we can't know if it would have failed or not.

If the above looks correct to you, then it is possible that you use fullscreen applications frequently enough that you may either want to decrease the amount of time between update checks in order to increase the chances that updates will be downloaded while you aren't using a fullscreen application, or simply turn off the option in Update settings that tells EAM not to run automatic updates in Game Mode.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.