Jump to content

m0unds

Member
  • Posts

    138
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by m0unds

  1. 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
  2. your screenshots are cropped - do you have tabs at the top of the window like this?
  3. if you bring up taskmgr and it's a small window that has no tabs, click "more details" at the bottom left of the window. once it expands, click the "details" tab and you should see it there.
  4. There's a bug in Win10 that can cause the search box not to work (regardless of whether you or not you have EAM/EIS installed) - the easiest way I've found to "fix" it, aside from just rebooting is to restart explorer via taskmgr.
  5. Yeah, I exported the settings while EIS was set for beta updates. Are there any plans to make EIS/EAM more immediately trigger an update after a prolonged period of time in game mode? It seems like it only triggers after the configured update interval passes after leaving game mode (i.e. if you're in game mode for 3 hours and your interval is set to 1 hour, you'll go 3 hours without updates) Mine seems fine now. not entirely sure why it kept failing to update, but I have a feeling it had something to do with my imported settings.
  6. I ended up uninstalling (2x reboot) and reinstalling and updating to the latest beta build without importing my settings and it's working correctly now. I uninstalled and reinstalled again, and imported my settings and it didn't work correctly after. I'm not sure if there's something about importing settings from the stable build into this beta that might cause issues, but that seems to be the case.
  7. I can confirm I'm still seeing the same thing w/6457. Ran a fullscreen app, no updates occurred while it was running. Waited for the update interval to pass after closing the app and no automatic update occurred. EIS logs show it hasn't even invoked an automatic update in almost 2 hours at this point. *EDIT* I verified that I could reproduce it by doing the following: 1. Set EIS to 30 minute update interval, to avoid having to wait an hour. IMO, I think it should probably just execute update/missed tasks immediately after leaving "game mode". 2. Ran a fullscreen application (different one than yesterday just to rule that out) for 60 minutes. 3. Quit the fullscreen app. 4. Left my PC on the desktop (no screensaver or anything) After approximately 2h30m it still hasn't updated. It looks like it tried to kickoff an update, but hung up. The log doesn't indicate it started an update, but the product UI shows this: I let it go for 10 mins or so, but it never finished. When I clicked to cancel, the UI showed "cancelling" until I rebooted several minutes later. *EDIT again* On build 6465 now, still see the same issue. Same repro steps.
  8. Lots of modern consumer routers provide some level of protection for devices connected via IPv6 - I know ASUS, Netgear and D-Link all provide a stateful firewall option for IPv6 clients (using ip6tables to drop connections w/invalid state, etc) Here's example output of ip6tables -L from one such device: ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all anywhere anywhere rt type:0 segsleft:0 ACCEPT all anywhere anywhere state RELATED,ESTABLISHED ACCEPT all anywhere anywhere state NEW ACCEPT all anywhere anywhere state NEW ACCEPT ipv6-nonxt anywhere anywhere length 40 ACCEPT all anywhere anywhere ACCEPT all anywhere anywhere ACCEPT udp anywhere anywhere udp spt:547 dpt:546 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp destination-unreachable ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp packet-too-big ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp time-exceeded ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp parameter-problem ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-request ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-reply ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 130 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 131 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 132 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-solicitation ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-advertisement ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 141 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 142 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 143 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 148 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 149 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 151 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 152 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmptype 153 DROP all anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination DROP all anywhere anywhere state INVALID ACCEPT all anywhere anywhere state RELATED,ESTABLISHED DROP all anywhere anywhere rt type:0 segsleft:0 ACCEPT all anywhere anywhere DROP all anywhere anywhere state INVALID ACCEPT all anywhere anywhere ACCEPT ipv6-nonxt anywhere anywhere length 40 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp destination-unreachable ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp packet-too-big ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp time-exceeded ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp parameter-problem ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-request ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-reply DROP all anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination DROP all anywhere anywhere rt type:0 segsleft:0 Chain PControls (0 references) target prot opt source destination ACCEPT all anywhere anywhere Chain logaccept (0 references) target prot opt source destination LOG all anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "ACCEPT " ACCEPT all anywhere anywhere Chain logdrop (0 references) target prot opt source destination LOG all anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix "DROP " DROP all anywhere anywhere
  9. try setting it on your primary adapter, not the tunnel adapter - the tunnel one is dynamically configured when the VPN comes up. leave the tunnel on automatic.
  10. if you run nslookup dl.emsisoft.com from cmd, what dns server does it say it's using? i'm wondering if the vpn client isn't properly pushing a DNS server. when i looked at @bernx's dns batch test result, it seems like it's trying to reach the DNS server on their LAN (192.168.0.254) - if you specified a local dns cache (say, the IP address of your router, if it's running as a local forward resolver) i wonder if it would fail as well. in my case, it's failing because windows prefers IPv6 in all cases, and VyprVPN breaks IPv6 connectivity when you connect to prevent IP leakage. @bernx if you go into windows adapter settings on either computer and specify IPv4 DNS servers of 208.67.222.222/208.67.220.220 and reconnect to the vpn, does it work then?
  11. oh, sorry - it's the checkbox below "VyprDNS" in your screenshot in this post: http://support.emsisoft.com/topic/19342-update-eis-failed-with-vyprvpn/#entry143062
  12. did you clear your DNS cache before testing it? when i'm trying w/vyprdns enabled, it fails to resolve dl.emsisoft.com or update.emsisoft.com using nslookup before timing out. @bernx maybe try disabling dns leak protection, reconnecting and seeing if it works after that (you can try it w/either VyprDNS or another DNS provider specified)
  13. which VPN location are you using, @bernx? do you always use the same location, or does this happen regardless?
  14. you could try it as a troubleshooting step, but it would provide an opportunity to leak the IP address assigned by your ISP (assuming you're using the VPN for privacy purposes)
  15. @bernx are you using the VyprDNS option in the VPN application? VyprVPN's DNS resolution can be horribly slow (I've noticed it with other sites before, sometimes exceeding 5 seconds for a NS response)
  16. it would prevent your system from actually resolving the sites referenced in the file. e.g. if you set badwebsite.com to localhost or 127.0.0.1, when you try to visit badwebsite.com it would resolve to localhost and fail to load (unless you happen to have apache or iis or something running locally with a badwebsite.com vhost configured)
  17. The only host that would need to be blocked to defeat this battery of Metasploit-derived exploit payloads (which again, aren't actually malicious - they load calc.exe) is "malware.wicar.org", which isn't itself a malicious site. Additionally, if your system isn't actually vulnerable to the exploits used in the test files, I don't think it would even give the behavior blocker a chance to detect anything, as the exploits would just fail to execute. Personally, I worry more about a product's efficacy vs actual malware and bad hosts (which, coincidentally, Emsisoft's products perform very well against in third party testing), and not exploits derived from Metasploit Framework.
  18. Whoops, my bad - meant resource monitor but linked docs to and mentioned performance monitor. derp.
  19. If you're on a modern version of Windows (Win7+), the built-in performance monitor's "network" tab will show you active TCP connectivity, remote server address/IP and remote port as well. https://technet.microsoft.com/en-us/library/cc749249.aspx
  20. Hey, I have a handful of files that have been showing "unknown" in the reputation column of the behavior blocker ui since I reinstalled EIS under Windows 10. Two of them are high prevalence, and one isn't. http://www.isthisfilesafe.com/?md5=5E6073F1F62609722853E23984C66797 http://www.isthisfilesafe.com/?md5=DAE6C3099D291EED8922A65C29ABCF52 http://www.isthisfilesafe.com/?md5=7253113771F811DB54BE48C9DD7217A0 Is this because the files aren't digitally signed, or is it something else? I'm just trying to get an idea of how that functionality works. Thanks!
  21. On my desktop PC (wired), I have the firewall set to private as I trust every device on that segment of my network. I segregate trusted wlan traffic onto its own vlan, and then guest wifi is on a different vlan from that. If I had a laptop connected to a public wifi hotspot, I'd use a vpn and my vpn interface would be classified as public because it's an untrusted network.
  22. I haven't had any issues on either of my two SSD-only machines (one laptop, one desktop). I'm not using EIS at the moment due to Windows 10, but I had no issues with EIS on Win8/8.1 *EDIT* Didn't realize the beta that fixed Win10 compatibility had been moved to stable. Reinstalling now.
×
×
  • Create New...