Jump to content

Alan_S

Member
  • Posts

    88
  • Joined

  • Last visited

Everything posted by Alan_S

  1. Thanks, I've sent the logs. Today (2017-10-10) a similar thing happened: I put the computer into hibernation - at 13:59:56 according to the Event Viewer. It also shows I woke it up at 15:18:28. The EAM UI was on the desktop and I noted that the 'barber's pole' under the 'Updates' section was spinning. It said 'LAST UPDATE 2 hours ago' and 'Software is up-to date' (update is scheduled for every 2 hours). Hovering the mouse pointer over this text gave a pop-up saying 'Next update in 3 minutes'. A few minutes later the update appeared to have been done - the 'Logs' tab showing 2017-10-27 15:23:55 2017-10-27 15:24:07 Update successful 2017-10-27 15:18:32 2017-10-27 15:18:32 Unknown update error though the 'barber's pole' was still spinning. The forensic log shows: 2017-10-27 15:24:07 Scheduler Update Downloaded and installed 22 files (5949 kb) (12 sec.). 2017-10-27 15:18:32 User xxxx Update Failed with error "Server returned error" (0 sec.). 2017-10-27 15:18:31 Scheduler Update Failed with error "Server returned error" (2 sec.). 2017-10-27 13:01:56 Scheduler Update Downloaded and installed 62 files (4669 kb) (1 min. 3 sec.). The Event Viewer, logged Event ID 1 (Source: Microsoft-Windows-Kernel-General) at 15:18:24 The system time has changed to ‎2017‎-‎10‎-‎27T13:18:24.500000000Z from ‎2017‎-‎10‎-‎27T11:59:58.923040800Z. (OK, I've found a couple of posts on the web that say a clock time change can occur on hibernation) Also, Event ID 1 (Source: Power Troubleshooter) at 15:18:28 The system has resumed from sleep. Sleep Time: ‎2017‎-‎10‎-‎27T11:59:42.168611300Z Wake Time: ‎2017‎-‎10‎-‎27T13:18:26.294003100Z About ½ hour later, the 'barber's pole' was still spinning so I did as you suggested GT500 and restarted EAM and everything is normal. Hope this helps to shed more light. Would you like me to send the debug logs too or is this enough?
  2. On October 7, Gideon Sword reported 'Problem with update EAM'. I had experienced a similar condition several times (on 2 computers) before his report and had activated Debug Logging to make my own report. But that seemed to cure the problem! Never happened again: Until today (October 26). Actually, this case is not identical to what I've experienced before. Then, it hung in “Initializing” or “Installing”, but it's still a hang-up. Also, it looks as if the update was done, but in previous cases it wasn't - at least, not listed under the Logs tab. Perhaps this one is “just” a cosmetic issue? Anyway, the good news is that debug logging was active. I had left the computer for some time (possibly it was in Sleep) when I heard a lot of disk activity. Time was about 15:00. Looked at it and the only program on the desktop / taskbar was the EAM UI: can't remember if I had launched it previously or if it launched itself (is that possible?). I noted that it had just done a scheduled update that seemed to have completed as it displayed 'LAST UPDATE 7 MIN AGO'. But the 'barber's pole' under the message was still twirling. Eventually, the disk activity ceased, but the pole was still twirling. Process Explorer showed mainly 100% “System Idle” and all was quiet on the disk front according to Resource Monitor. I clicked the Logs tab to see what it had to report. Usually, this is instantaneous but it took quite some time, with quite a lot of disk activity. Restarted the UI, but it was the same, so restarted the computer at 15:19. After that everything seemed normal. Restarted again a short time later. Environment is Windows 7 Pro 32-bit with security updates up to and including September offerings. Security software: EAM version 2017.9.0.8006 (MBAM modules excluded) Malwarebytes Anti-Malware Premium, version 2.2.1.1043 (EAM modules excluded) Malwarebytes Anti-Exploit, version 1.10.1.41 Sphinx Windows 10 Firewall Control, Plus edition, version 7.5.100.200 Attached: The UI in the reported condition The update log tab in the reported condition I'm not sure if the debug logs (total 4.2 MB zipped, the largest being 2 MB) contain any sensitive information, so I haven't attached them. How should I send them?
  3. Now they are gone - thank you Umbra! May I make a suggestion, Emsisoft? How about extending the UI to handle these logs too? Then they will be visable.
  4. Under C:\ProgramData\Emsisoft I have a directory 'Logs'. Its total size is 410MB. From the timestamps, I believe they were created while gathering data for a bug report, when I enabled 'Debug logging'. I disabled it after sending the data. I cleared all logs via UI -> Logs, but these are still present. I can't find anywhere in the UI so do I just delete them manually? By the way, UI -> Logs tabs have two buttons: Delete and Clear. I assume that 'Delete' means 'delete the selected entry' and 'Clear' means 'delete them all' (not simply 'remove them from the displayed list, but don't delete'). Right?
  5. The Beta has been running on my computer for 5 days now and the selected language has not been altered. So kudos to Emsisoft for fixing this little, but irritating, problem so quickly.
  6. Thank you - that's very good news. I'll give it a try when it turns up and report the results.
  7. To avoid potential confusion in the thread 'Problem with language selection' I'm starting one of my own. As I mentioned in that thread, I have the same problem of EAM loosing the language setting. In my case the preferred computer language is English and the location is Sweden. EAM keeps reverting from English to Swedish, sometimes totally, sometimes partially. Today I started my portable computer. It doesn't get used much and EAM reported 6 days since last update (I update manually there). The following happened: On startup, I saw that the EAM had reverted - as far as I could see, totally - to Swedish (SV) Set the language to EN Everything checked as being EN Restarted the UI Still everything is EN Restarted the UI once more. Still everything is EN Turned on Debug logging. Still everything is EN Closed the UI Restarted the computer Fired up the UI Overview tab is EN Clicked the tabs and sub-tabs in order, left to right Still EN until Settings, which is a bit of a mixture The sub-tab headings were EN Stuff under sub-tab General was Swedish (SV) and the language in the Language box also showed 'Swedish' Stuff under sub-tab Privacy was EN but 'Look up reputation' stuff was SV Stuff under sub-tab Updates was SV, though 'Update feed Stable' was just this (i.e. EN). Stuff under sub-tab Notifications was mainly SV but some EN: - Real-time detections - Removable device connections - Software updates - Don't show notifications in Game Mode - Notifications location - Email notifications Stuff under sub-tab Exclusions was EN Stuff under sub-tab Permissions was mainly EN but lead text in the Master Key box was SV Stuff under sub-tab License was SV Disabled Debug logging This has happened several times, so it seems reproducible with the computer in its current state. Note though that I've previously seen changes in other tabs and sometimes everything. I've sent the debug logs, referring to this thread.
  8. And I've sent logs too. It's just struck me though that perhaps two instances could just confuse the issue. If this is the case, please disregard my 'contribution' and let me know.
  9. Ha! I was putting together a bug report about EAM 'loosing' the language selection when I saw this. In my case, the location is Sweden but the desired language is English. All was well until the update to 2017.7.0.7838. I once watched the change to Swedish occur when an update completed, but it doesn't happen on every update by far and my impression is that this isn't the only 'trigger'. In fact I note it's just occurred while I'm writing this. I've not succeeded in finding a reproducible case. If I can contribute anything to help to nail it, just give a shout. Anyway, I don't want to hijack the thread so for the moment I'll just say 'Me too!'.
  10. Just to say that my experience is similar to that of Dan2. My computer entered sleep mode. On waking it up I launched the GUI. As far as I recall everything looked normal but after a minute or so, I noted an exclamation mark. But the licence info shows 134 days left. A minute or so later, the exclamation mark disappeared. As for the mark as such, I think the design of the GUI should present information in an intuitive manner. The user shouldn't have to search documentation for something this simple. Wouldn't it be far more obvious to have a big exclamation mark next to the licence info? Using the "Protection" header feels about as logical as having to click the Emsisoft logo to see the version of the program...
  11. Aha! The logo was just about the only thing I didn't click. Thank you both.
  12. Previous versions of EAM had an 'About' button on the 'Overview' section, under the 'Logs' box. It's disappeared in version 12 and I haven't been able to find it. Where is it - or corresponding info - hidden?
  13. Dan2: I've experienced this behaviour too and reported it in the EAM section last week ( http://support.emsisoft.com/topic/19763-strange-behaviour-on-updating).Since then, I've noticed that the 'strange' behaviour occurs on larger manual updates, e.g. after my computer has been shut down overnight. But a 'little' update, say an hour or so later, gives 'normal' behaviour, corresponding to your observation. I also looked at the files reported in the log, and their timestamps (and only theirs) are indeed those of the update. So, there doesn't appear to be anything wrong with the updating as such. As GT500 said, it seems to be a GUI thing. Even so, I hope it gets fixed sometime!
  14. Sorry, the attachment I mentioned above doesn't seem to have got attached. Anyway, here's the stuff: General Information: Update started: 2016-02-16 08:49:23 Update ended: 2016-02-16 08:49:59 Time elapsed: 0:00:36 Update successful Detailed Information: 112 modules, 3165464 bytes a2hosts.dat (447125 bytes) - updated a2trust.dat (167768 bytes) - updated Signatures\20160215.sig (19341 bytes) - updated Signatures\20160216.sig (884 bytes) - updated Signatures\BD\aitok.cvd (9440 bytes) - updated Signatures\BD\cevakrnl.ivd (467 bytes) - updated Signatures\BD\cevakrnl.rv2 (412 bytes) - updated Signatures\BD\cevakrnl.rv3 (135103 bytes) - updated Signatures\BD\cevakrnl.rv4 (13842 bytes) - updated Signatures\BD\cran.ivd (432 bytes) - updated Signatures\BD\dalvik.ivd (13778 bytes) - updated Signatures\BD\e_spyw.cvd (9097 bytes) - updated Signatures\BD\e_spyw.i00 (2424 bytes) - updated Signatures\BD\e_spyw.i09 (662 bytes) - updated Signatures\BD\e_spyw.i10 (6097 bytes) - updated Signatures\BD\e_spyw.i11 (6248 bytes) - updated Signatures\BD\e_spyw.i12 (7262 bytes) - updated Signatures\BD\e_spyw.i13 (6075 bytes) - updated Signatures\BD\e_spyw.i14 (6560 bytes) - updated Signatures\BD\e_spyw.i15 (6716 bytes) - updated Signatures\BD\emalware.000 (83451 bytes) - updated Signatures\BD\emalware.041 (3473 bytes) - updated Signatures\BD\emalware.042 (6447 bytes) - updated Signatures\BD\emalware.043 (5056 bytes) - updated Signatures\BD\emalware.044 (4701 bytes) - updated Signatures\BD\emalware.045 (4561 bytes) - updated Signatures\BD\emalware.046 (3547 bytes) - updated Signatures\BD\emalware.047 (1772 bytes) - updated Signatures\BD\emalware.048 (2733 bytes) - updated Signatures\BD\emalware.049 (5346 bytes) - updated Signatures\BD\emalware.050 (2492 bytes) - updated Signatures\BD\emalware.051 (2698 bytes) - updated Signatures\BD\emalware.052 (3049 bytes) - updated Signatures\BD\emalware.053 (3462 bytes) - updated Signatures\BD\emalware.054 (3254 bytes) - updated Signatures\BD\emalware.055 (3075 bytes) - updated Signatures\BD\emalware.056 (3492 bytes) - updated Signatures\BD\emalware.057 (4121 bytes) - updated Signatures\BD\emalware.058 (4149 bytes) - updated Signatures\BD\emalware.059 (5441 bytes) - updated Signatures\BD\emalware.060 (6078 bytes) - updated Signatures\BD\emalware.061 (4622 bytes) - updated Signatures\BD\emalware.062 (3137 bytes) - updated Signatures\BD\emalware.063 (3162 bytes) - updated Signatures\BD\emalware.064 (3111 bytes) - updated Signatures\BD\emalware.065 (2178 bytes) - updated Signatures\BD\emalware.066 (3371 bytes) - updated Signatures\BD\emalware.067 (3908 bytes) - updated Signatures\BD\emalware.068 (2515 bytes) - updated Signatures\BD\emalware.069 (2798 bytes) - updated Signatures\BD\emalware.070 (1402 bytes) - updated Signatures\BD\emalware.071 (2289 bytes) - updated Signatures\BD\emalware.072 (1910 bytes) - updated Signatures\BD\emalware.073 (2127 bytes) - updated Signatures\BD\emalware.074 (2480 bytes) - updated Signatures\BD\emalware.075 (4042 bytes) - updated Signatures\BD\emalware.076 (4961 bytes) - updated Signatures\BD\emalware.077 (2177 bytes) - updated Signatures\BD\emalware.078 (2404 bytes) - updated Signatures\BD\emalware.079 (4491 bytes) - updated Signatures\BD\emalware.080 (4870 bytes) - updated Signatures\BD\emalware.081 (4981 bytes) - updated Signatures\BD\emalware.082 (6381 bytes) - updated Signatures\BD\emalware.083 (4354 bytes) - updated Signatures\BD\emalware.084 (4735 bytes) - updated Signatures\BD\emalware.085 (6882 bytes) - updated Signatures\BD\emalware.086 (3432 bytes) - updated Signatures\BD\emalware.087 (3860 bytes) - updated Signatures\BD\emalware.088 (3077 bytes) - updated Signatures\BD\emalware.089 (2519 bytes) - updated Signatures\BD\emalware.090 (4825 bytes) - updated Signatures\BD\emalware.091 (4402 bytes) - updated Signatures\BD\emalware.092 (2509 bytes) - updated Signatures\BD\emalware.093 (2886 bytes) - updated Signatures\BD\emalware.094 (1826 bytes) - updated Signatures\BD\emalware.095 (18900 bytes) - updated Signatures\BD\emalware.096 (4920 bytes) - updated Signatures\BD\emalware.097 (10127 bytes) - updated Signatures\BD\emalware.098 (3759 bytes) - updated Signatures\BD\emalware.099 (2948 bytes) - updated Signatures\BD\emalware.100 (4275 bytes) - updated Signatures\BD\emalware.101 (2741 bytes) - updated Signatures\BD\emalware.188 (6756 bytes) - updated Signatures\BD\emalware.243 (3915 bytes) - updated Signatures\BD\emalware.380 (1564 bytes) - updated Signatures\BD\emalware.382 (22784 bytes) - updated Signatures\BD\emalware.383 (14478 bytes) - updated Signatures\BD\emalware.384 (17739 bytes) - updated Signatures\BD\emalware.385 (12731 bytes) - updated Signatures\BD\emalware.386 (11306 bytes) - updated Signatures\BD\emalware.387 (15877 bytes) - updated Signatures\BD\emalware.388 (13110 bytes) - updated Signatures\BD\emalware.i05 (1033 bytes) - updated Signatures\BD\emalware.i06 (180213 bytes) - updated Signatures\BD\emalware.i08 (12902 bytes) - updated Signatures\BD\emalware.i16 (417 bytes) - updated Signatures\BD\emalware.i20 (201746 bytes) - updated Signatures\BD\emalware.i21 (3094 bytes) - updated Signatures\BD\emalware.i24 (269572 bytes) - updated Signatures\BD\emalware.i27 (326012 bytes) - updated Signatures\BD\emalware.i30 (29357 bytes) - updated Signatures\BD\emalware.i46 (2950 bytes) - updated Signatures\BD\emalware.i47 (22816 bytes) - updated Signatures\BD\emalware.i48 (10947 bytes) - updated Signatures\BD\emalware.i49 (127026 bytes) - updated Signatures\BD\emalware.i56 (160121 bytes) - updated Signatures\BD\emalware.i65 (7116 bytes) - updated Signatures\BD\emalware.i70 (149111 bytes) - updated Signatures\BD\emalware.i71 (193787 bytes) - updated Signatures\BD\emalware.i78 (156852 bytes) - updated Signatures\BD\htmltok.cvd (1360 bytes) - updated Signatures\BD\update.txt (347 bytes) - updated
  15. Than you! I didn't know about clicking the log entries. The entry for the update I did this morning (previous was yesterday at 18:51) is attached. I don't know if it's OK but to me it looks that way. Just now (about 6 hours after this morning's run) I did a new update. I timed it from clicking 'Update now' to finished and it was 29 seconds. The time in the log says 15, so it looks like this refers to the actual update process, i.e. after the files have been downloaded. Comparing with earlier updates, it's not so startlingly quicker as I thought. Probably just feels that way due to the broken-off progress reporting. So, perhaps it's simply that the progress reporter is not reporting correctly.
  16. Siketa, I get the mixed response "Sorry, we couldn't find that!" and "You do not have permission to view this forum" when clicking your link. Sounds like it's got lost. Anyway, lets hope for better luck here!
  17. I do updates manually, as I like to be prepared for the restarts that sometimes occur due to the packaging of database updates and program updates. Recently, I've noticed a difference in the behaviour which seemed to start after the second recent hotfix. Previously - on clicking 'Update Now - I would get the progress report: - Initializing - Updating (which would show progress from 0% to 100%) - Installing - Last Update 0 mins ago But now 'Updating' stops reporting after 15% - 20%, often less. And the progress bar stops correspondingly. After a short pause, there is no 'Installing' message, but 'Update Now' flashes very briefly and then 'Last Update 0 mins ago'. Furthermore, the whole process is very much quicker than before. No apparent ill effects and the quick processing is naturally appreciated, but this and the apparent break-off make me wonder if everything is working as it should. What do the experts say? Environment: - Windows 7 Pro SP1 32-bit updated with the January offerings - EAM 11.0.0.6131 - Malwarebytes Anti-Malware 2.2.0.1024 - Malwarebytes Anti-Exploit 1.08.1.1189
  18. Perhaps I was a bit unclear in my original post. Should have waited to simmer down first. My complaint was not that OA is at an end. Obviously I knew this and I fully understand Emsisoft's position. No, it concerned the way it was implemented. The abrupt chop. Just happened out of the blue with no warning at all. I've seen nothing about this on the Emsisoft web-site. E.g. in the thread "Will Online Armor work after 31st March 2016?" I still can't see even a hint that anything like this would happen. Nor in the 'OA support roadmap'. Well, it's water under the bridge now, but Emsisoft should have handled it better. Perhaps a little cautionary pop-up and then a few days grace?
  19. My Online Armor licence expired today. Obviously, I knew this would happen but I was not prepared for what would happen. Stop updating, certainly, but to suddenly kill off the program completely? Not possible to start it, not even possible to use the Configuration Panel? I think this was a brutal ending to a long relationship with OA.
  20. Thank you - that was one SPEEDY response! Hope it continues that way as I would hate to have to choose between EAM and MBAM.
  21. In thread “Compatibility with Malwarebytes Anti-Malware” in the EIS forum, GT500 says: Technically Emsisoft Internet Security isn't considered compatible with Malwarebytes Anti-Malware due to the fact that Malwarebytes Anti-Malware uses a WFP driver to capture network traffic for their website blocking, and that driver could cause problems with the WFP driver used by Emsisoft Internet Security. Would this apply to EAM too, or does it relate to the firewall part of EIS? (I assume WFP means Windows Filtering Platform?)
  22. Steve, many thanks for your effort and feedback. When you mentioned that you installed Privoxy 'out of the box' and it worked fine it started me thinking: why did it work for you but not for me? Was it something in my customized user.action file – even though it had been OK before? So on chance I re-installed and hey – it worked fine for me too. My 8Mb connection didn't give me your 3 second response, but I was more than happy with 5. Next day, I fired up the PC and ouch! Back to 37 seconds. To cut a long story short, after a lot of experimenting, I discovered that EAM has to be operational before Privoxy starts. Privoxy certainly had a PID later than EAM but was probably in full swing before EAM had got its act together. I found a couple of programs that can delay startups but they didn't work well for me. So, I re-installed Privoxy without specifying “Launch at startup”. Then made a shortcut that daisy chains a program that waits 5 seconds and Privoxy. This I put in the Startup folder and it works fine now. A bit primitive but effective. So, it was neither a problem with EAM nor Privoxy, but with timing.
  23. Problem: Very poor browser performance when using a web-proxy and EAM Surf Protection Current configuration components are: Windows 7 SP1 (32 bit) as of October patch Tuesday EAM 8.1.0.19 Online Armor Premium 7.0.0.86 Windows Defender Internet Explorer 9 Privoxy 3.0.21 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I'm using Internet Explorer (currently, IE9) with a web-proxy (Privoxy) to filter out the most aggressive flashing and animated graphics. Have been doing so for years. and it's worked fine. But for some time now I've felt that browsing performance has deteriorated seriously. I discovered that turning off Surf Protection in EAM fixes it. For example, the BBC news site (http://www.bbc.co.uk/news) typically takes 37 secs to load with Surf Protection enabled and 6 with it disabled. Disabling Privoxy's filtering also helps: typical figures were 9 and 5 respectively (but this rather defeats the point of using Privoxy). Tried latest Firefox. Faster than IE9 but still a huge difference between Surf Protection enabled (typically 27 secs for the BBC site) and disabled (7 secs). I played around with EAM settings (added process Privoxy.exe and it's folder to the File Guard whitelist, set all three components in Surf Protection to “Don't Block”, set Application Rule “Always allow” for Privoxy.exe). Also, turned off Windows Defender. But nothing seemed to help. I had a strong feeling that this problem didn't exist a few months ago, so I took an image copy of the the system and backed to an image copy I took 2013-01-14. And yes, I wasn't imagining things: performance was good. Better with Surf Protection disabled certainly, but not a problem. EAM was of course ancient (7.0.0.12), so I updated to the latest state (I use manual updating). Immediately performance plummeted to the levels above. So, it seems something has happened with Surf Protection between EAM 7.0.0.12 and 8.1.0.19 causing extremely poor performance when using a web proxy. Constructive suggestions gratefully appreciated. Or have I found a bug? I've searched the forum but can't find anything resembling this problem. My apologies if I've missed something.
×
×
  • Create New...