redactor

Tester
  • Content count

    101
  • Joined

  • Last visited

Community Reputation

1 Neutral

About redactor

  • Rank
    Forum Regular
  • Birthday

Profile Information

  • Gender
    Male
  • Location
    USA

System Information

  • Operating System
    Windows 10
  • Firewall or HIPS Software
    EIS
  1. As was the case with Win10 Pro x64, problem disappears after reboot under x86 as well. So I can no longer reproduce the problem.
  2. FWIW, manual malware scan immediately after auto update to 6956 took 39 seconds (Win10 Pro x64 installed on a SSD) -- minus Documents folder contents, which I've hard-linked to a separate HDD. Also, the problem of non-functioning Stop and Pause buttons during scan, which I reported in another thread a few days ago, has gone away in this build.
  3. Update -- After computer reboot into x64 OS, the Pause and Stop buttons worked as intended. However, immediately after EIS update on the Win10 X86 side of my dual-boot machine, the identical problem appeared: Pause and Stop buttons have no effect during a scan. I haven't yet rebooted the x86 side to see if the buttons work ok -- will get to that tomorrow. Maybe something about the update process itself requires a full reboot, not just a program restart??
  4. The title says it all. After auto update of EIS to 6936 on Win10 Pro x64, manually ran a malware scan. Halfway through tried to stop it, then pause it. Hitting those buttons multiple times had no effect -- though pressing "Pause" did toggle the display to "Resume" and back again, but had no effect on the actual scan. Shut down and restarted EIS several times and reran scan. Same behavior. Can others duplicate this (mis)behavior?
  5. To my mild surprise, this morning EIS automatically updated from v. 11. x x x to v. 12.0.0.6799 under Win10 x64 -- surprise because I thought the upgrade from v. 11 to v. 12 required the user's affirmative decision and manual download of the installer, even with beta updates enabled. But that's not my main point. While exploring the new GUI, it froze at the screen shown in the title above. As the attached screenshot shows, the edit window was incompletely drawn and showed no controls on the right side of the title bar. An attempt to clear the screen by "Shut down protection" failed. The only way to clear the frozen screen, short of rebooting, was to (alt-ctrl-delete) log off and log back on again to cause explorer.exe and the desktop to reload. After the one-time freeze, I couldn't duplicate the problem. No logs, since this was an unexpected upgrade.
  6. Thanks for the clarification. It was on the regular beta update feed. Not really an inconvenience. I was considering installing v12 on one of the OS installations. This way the decision was made for me. Any help on the second issue: Any attempt to view attachments to posts in the beta forum produce an error message: "Sorry, you don't have permission for that!"
  7. Greetings -- Any explanation how/why on my dual boot Win10 PC (x86 + x64), yesterday afternoon my x86 EIS automatically updated from v. 11.10.0.6563 to v. 12.0.0.6723? Then subsequently on the x64 side EIS continued to update definitions only (after the firewall component update earlier in the day). Both are set to allow beta updates. Also, completely unrelated, every attempt to view attachments to posts (in the beta forum only) produce an error message: "Sorry, you don't have permission for that!" What's the problem here?
  8. Not only that, but for me, if not for all Windows 10 users, until the last Windows 10 cumulative update before the anniversary update, Windows Update would always fail unless Windows Firewall was enabled and running. I discovered this fix only through trial and error after many hours of anger and frustration at being unable to install any Windows updates for a couple of months. Once the Windows Firewall was enabled, Windows Updates would successfully download and install. That problem went away somewhere around June.
  9. Yeah, I know. I forgot where I was on the board and I lost track of whether this was a public beta or a private beta. Then when I got to the Testing Corner section, I didn't feel like making another entry there.
  10. I've run into the same problem with this latest EIS build (running under Win10 x86). I use this OS only 2 or 3 times a week. So each time I boot, its signatures are two or three days old. When I attempt to update manually, the Overview screen shows an update grinding away but never completing (today it kept that up for a couple of hours). Finally, I tried to cancel the update and EIS gave the "cancelling" message, and it kept that up indefinitely (still grinding away as I type this -- take a look at the attachment.) Never had this problem until the current build (11.6.0.6267).
  11. Arthur -- Thanks for your prompt reply. Just as the problem appeared yesterday afternoon mysteriously out of nowhere (I had run services.msc just a couple of days ago with no problem, but that was before both an unexplained Windows update and an unexplained EIS program update), last evening, the problem disappeared just as mysteriously, when another attempt to run the Windows utility succeeded. So for now, at least, everything is back to normal.
  12. I'm running Win 10 x64 and EIS v. 11.5.1.6247, and I'm trying to examine the state of an installed service (OpenVPNService). When I try to run Windows' services.msc utility, it won't start and either EIS gives an error message or Windows gives an error message about EIS (screen shot attached). I find this confusing since I don't understand what EIS and a2hooks64.dll have to do with running a Windows utility -- services.msc. I suppose it's a cryptic explanation for why services.msc fails to run. I've rebooted a couple of times to no effect. Can anyone shed some light on the matter and tell me what I need to do to remedy the situation. Do I need to reinstall EIS?
  13. First let me state clearly that this is not, strictly, an Emsisoft problem, but there is a problem nonetheless. I've been using EIS for almost a year now. One on the things I learned early on was that EIS (and Online Armor before it) turned the Windows Firewall (hereafter WFW) off upon installation. Nevertheless, when I've gone poking around I've discovered on more than one occasion that, contrary to the stated procedure, WFW was running on my Windows 10 Pro x64 (currently v.1511). Each time I've found WFW running, I've turned it off, most recently, just yesterday. Today Microsoft published two updates for Windows 10: Cumulative Update for Windows 10 Version 1511 for x64-based Systems (KB3140743) Update for Windows 10 Version 1511 for x64-based Systems (KB3139907) Three times Windows notified me of the updates; each time they failed with error code 0x800706d9. After the third failure, an online search yielded, amid all manner of irritated discussion and gnashing of teeth, a description of the error and ways to fix it. It turns out that this error is related to Windows Firewall and the fix is simple -- turn Windows Firewall ON. As soon as WFW was running, the updates proceeded without further ado. There is, at the very least, a very annoying issue here. Third party security software, like Emsisoft, presumably with Microsoft's approval, is supposed to turn off WFW (and also Windows Defender). But now when it is disabled, Windows updates fail. What the *(^%#@!! This is all very frustrating and time wasting. Microsoft and security software vendors, I submit, need to get together and decide how this is supposed to go and then just make it work!
  14. Just updated to 5935. This time "Enable protection . . ." remains checked upon restart, and the icon appeared in the system tray as well. So, whatever the problem was, appears to be fixed now.
  15. It happens (to me) only at an EIS program update when a system restart is required. However, I think it did not occur after yesterday's firewall update. Waiting for the next build to see if the problem recurs.