JeremyNicoll

Member
  • Content Count

    1840
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by JeremyNicoll

  1. Is the version of EAM one you downloaded from Emsisoft's website? What does "So I tried to uninstall it and reinstall without any luck." mean? Did you in fact do an uninstall? If so did you follow recommended practice and reboot the machine twice after doing that? And then a reinstall - was that attempted, were there any problems? "No uninstaller": are you saying that within Add/Remove Programs (if that's what it's called in W7), there's no listed entry for EAM? Have you tried uninstalling Avast, then (if you can) uninstalling EAM and then reinstalling EAM?
  2. W8.1, 64bit machine, EIS 2017.4.1.7484 I just woke my machine up; as usual when I do that it did an immediate update - that occurred at 06:55 (as you can see from the update log). I did a few other things then started Firefox, and to my amazement was presented with a BB alert box for Firefox (or at least its updater component, I think). Why would I get such an alert? I clicked the down-arrow on the alert box and there was no information. Why not? Later I checked the update really had occurred a decent amount of time before FF was started - yes, 13 minutes. And I looked at the BB log too - which also shows to me what looks like a problem - it seems to say the automatic rule for the FF updater daemon (assuming that's what this is) was deleted and added many times in the last couple of days - surely that's not right either? See: screenshot of alert box with empty details area: https://www.dropbox.com/s/f7lrflx6ma9r702/20170521 0708 01 (screenshot).jpg?dl=0 recent part of update log: https://www.dropbox.com/s/tkpgxtpzurc1m6v/20170521 0708 02 Update log - Update_170521-071950.txt?dl=0 recent part of BB log: https://www.dropbox.com/s/gr9qeghdxdhxlmy/20170521 0708 03 BB log - BB_170521-071403.txt?dl=0
  3. Also, does your machine have other anti-virus or anti-malware software installed? And, what do the error messages say?
  4. Basherz: if you had "exactly the same problem" back in 2014, why tell us now? If you have just had it, then it's unlikely to be exactly the same thing, bearing in mind that all the software concerned is three years older by now. According to your avatar above, that's your first post. Did you seek help here when you had these problems?
  5. Arthur > This is a known issue. It started on Windows 10 after the Creators Update was released. Yes, I know. I nearly posted a link to the thread in the Beta forum about something similar (though that's not reported as a crash), then I thought: there's no evidence that hairygeek has W10 let alone the newly updated one, so didn't. And - until a quick Google just now made me better informed - I assumed that the "Creators update" was for developers, based on its name.
  6. I was thinking, I'm sure I remember reading about this a while ago... and it turns out you reported something like this in Nov 2016: Is it the same URL again?
  7. It's worth uploading the file that Avast thinks is suspicious - a2emergencykit.exe - to the virustotal website where it will be examined by lots of different anti-virus/malware programs to see whether they all think it's a problem or just a few programs do. If you do that, you could then include the virustotal website URL for the report about that file, here. Does the free version of Avast update its signatures often?
  8. > He posted it in a reply to another topic, and I split it off into a new topic In that case, I apologise to JoeP.
  9. JoeP> Emsisoft Anti-Malware This is the forum for Emsisoft Internet Security. It won't matter, as GT500 has seen the question, but usually it's more sensible to ask things in the right place.
  10. > The Task Manager wouldn't open using the Ctrl+Shift+Esc shortcut? Dunno. Didn't try it - not familiar with the shortcut - usually start TM from right-click on taskbar, if I need it. But that's rare because I have Process Hacker running... but obviously didn't look at that because there was no desktop. Just a dark blue screen, with thank-goodness, my text editor window still alive. I don't know why that /was/ accessible, unless it's just that it was the only non-minimised application running at the time.
  11. I don't think so. It doesn't (as far as I know) scan ANY files on download. Scans are done when you open the files. Edited later by JN: I was wrong. See settings for File Guard.
  12. > ..tell them to use Alt+F4 then it will be able to be closed !! Stapp, I'm sure you said that with a big grin - maybe you just munched an extra juicy piece of grass ;-) But unless that info is displayed on the GUI the average user will not know to apply it. It's far better to stop the undismissable pane from being displayed in a stupid place.
  13. > A batch file that uses BatchGotAdmin will usually trigger a BB alert ... OK. I'll try to find time to see if I can provoke a recurrence. Although it wasn't the cause then, what happens if one is offline when an AMN lookup might be attempted? Does the BB recognise that and just not bother - and if so, does the suspiciou sactivity just get blocked? On the other hand, if - say - I provoke an AMN lookup then switch off the laptop's wifi, would you expect the AMN lookup process to handle that cleanly? > Updates being installed while there was an AMN lookup could have certainly caused a freeze ... Yes but they weren't being. Your log shows the update process was complete 17 seconds before the editor macro attempted to run the VBS script. > Usually that freeze only lasts for a few seconds, however if there's a lot of files to update then that freeze can certainly seem like it takes longer. It wasn't just a few seconds. It was about 15 minutes before I finished investigating and (looked up notes on eg the shutdown command) and decided to try it to shut down the machine. I was VERY lucky that the text editor, with its command-issuing potential, was still running because when explorer took away the desktop there was no way for me to find my way to other tools.
  14. > I understand, however unless you can reproduce the issue then we won't be able to find out what is causing it. We'd probably need a > complete memory dump from the system that shows the frozen processes so that we can get an idea of why it happened. Is there an easy way to provoke the BB into doing an AMN lookup? I looked earlier today to see if there was any logging of the BB alert (no), or if the script had somehow got itself added to the application or BB rulesets (no,no). The sccript has run 33 times since the reboot after the hang, and I've not seen another BB alert. > We update the Behavior Blocker periodically, and can do so without a program update, so an update with changes to the > Behavior Blocker detection rules is more than likely why the Behavior Blocker suddenly started trying to verify its safety. I did mention that there had been an uodate at 4pm. Specifically: General Information: Update started: 10/05/2017 16:00:20 Update ended: 10/05/2017 16:00:31 Time elapsed: 0:00:11 Update successful Detailed Information: 28 modules, 11000910 bytes a2hosts.dat (1298 bytes) - updated a2trust.dat (397 bytes) - updated Signatures\BD\dalvik.ivd (4656 bytes) - updated Signatures\BD\e_spyw.i00 (1178 bytes) - updated Signatures\BD\e_spyw.i19 (95252 bytes) - updated Signatures\BD\e_spyw.i20 (214095 bytes) - updated Signatures\BD\e_spyw.i21 (310537 bytes) - updated Signatures\BD\e_spyw.i25 (330976 bytes) - updated Signatures\BD\e_spyw.i26 (370845 bytes) - updated Signatures\BD\emalware.000 (413411 bytes) - updated Signatures\BD\emalware.187 (72027 bytes) - updated Signatures\BD\emalware.212 (147059 bytes) - updated Signatures\BD\emalware.213 (174299 bytes) - updated Signatures\BD\emalware.216 (210113 bytes) - updated Signatures\BD\emalware.217 (223145 bytes) - updated Signatures\BD\emalware.i06 (689135 bytes) - updated Signatures\BD\emalware.i50 (554961 bytes) - updated Signatures\BD\emalware.i52 (559602 bytes) - updated Signatures\BD\emalware.i57 (629369 bytes) - updated Signatures\BD\emalware.i59 (580942 bytes) - updated Signatures\BD\emalware.i66 (613796 bytes) - updated Signatures\BD\emalware.i68 (566923 bytes) - updated Signatures\BD\emalware.i76 (672384 bytes) - updated Signatures\BD\emalware.i78 (584927 bytes) - updated Signatures\BD\java.cvd (2253750 bytes) - updated Signatures\BD\mdx_97.cvd (725188 bytes) - updated Signatures\BD\mdx_97.ivd (297 bytes) - updated Signatures\BD\update.txt (348 bytes) - updated and my editor macro's log shows that I'd run the script just once before the hanging instance, but that scrpt started execution a few seconds after the EIS update was show to be complete: 20170509 15:56:24.550000 . 20170509 16:00:48.350000 under interprt=>KEXX< args=>fav icons< 20170509 16:00:48.350000 src=>Windows COMMAND fav< ver=>KEXX 5.62 14 Nov 2012< 20170509 16:00:48.400000 Now process 1 user arguments: 20170509 16:00:48.400000 1] arg: ICONS 20170509 16:00:48.400000 simple srch --> ix=0 20170509 16:00:48.400000 subset srch #matches: 1 20170509 16:00:48.400000 so ix=143 n=ICONS-FOR-SHORTCUTS t=DIRY p=C:\Dropbox\JN_Icons_for_shortcuts 20170509 16:00:48.400000 => queued vbsopenf cmd 20170509 16:00:48.400000 Now execute 1 queued commands: 20170509 16:00:48.400000 1] issuing: winexec nowait normal wscript.exe "C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs" "full" "C:\Dropbox\JN_Icons_for_shortcuts" 20170509 16:00:48.410000 rc: 0 20170509 16:00:48.410000 KEXX processing times: start->nicknames defined: 0.030000 20170509 16:00:48.410000 KEXX processing times: start->after file checks: 0.050000 20170509 16:00:48.410000 ending; began: 20170509 16:00:48.350000, logstart: 20170509 16:00:48.350000. 20170509 16:00:48.410000 . 20170509 16:35:13.570000 under interprt=>KEXX< args=>fav progr< As that shows, the script log (although it's written as the script is ending, the lines in it are timestamped according to what the script is doing as it does it) started execution at: 20170509 16:00:48.350000, which is 17 seconds after your update process says it was complete... unless that latter 'complete' is only for the fetch?
  15. > We are considering adding a feature to move the window back into the visible area of the screen when the EAM/EIS window opens > and notes that it is outside of the visible screen space. Excellent! > It should be relatively easy to close the window by right-clicking on its icon in the taskbar, and then reopening it. Do you mean when i had the original problem, or do you mean in the future when the new feature is added? If the latter, I can't see why one would need it. If the former: the taskbar icon seems only to refer to the main GUI window, not the superimposed About pane. At least I assume that because of two things: firstly, the thumbnail image of the window never shows the About pane, and secondly, as soon as I try to right-click the thumbnail (which would normally give one access to the move/minimise etc actions) the thumbnail disappear. You don't get a menu. If you meant 'close the main window' when you suggested right-clicking its taskbar icon, that doesn't work even when the main window is entirely visible. It's as if main-window mouse-clicks/actions are suspended/stacked until the About pane is dealt with.
  16. See: https://www.dropbox.com/s/rd27krg5roiqnli/20170510 2128 99 EIS thread screenshot.jpg?dl=0
  17. YES, I can see it. I was a bit surprised, but ISTR there's more than one way of putting an image into a discussion.
  18. > Can you see his screenshot? Well, it's in the post, but hard to see what's in the circled bit. But if you save the image and then magnify it a lot, you can just make out the star.
  19. Arthur, you've missed the point. I was unable to wrest control from EIS when it got stuck trying to contact the Anti-malware network. Possibly that happened at the start of running the VBS program, or maybe when that program asked windows to open the ProgramData folder, because when it hung, it crashed explorer. Maybe that was caused by me telling Windows to end the unresponsive EIS task? But why should EIS not have stopped holding me up? Why wouldn't it take a click on its 'Cancel' button? Whenever I moved the mouse over the 'suspicious behavior' pane, the pointer changed to a small blue (revolving?) circle. And, if you're right that the BB thought the script was suspicious, why alert me then and not tens of times previously, every day, when the same script is run? My logs show that happened 14 times yesterday. The hanging instance was roughly in the middle of the 14 uses.
  20. > I must have misunderstood ... update process I dragged it off-screen while the scan was running. What update process?. > We generally have the About popup appear in the middle of the window The middle of the window is no use if the window is mainly off-screen. if the user cannot even see that the About pane has been opened they will not understand why the main window cannot be dragged etc etc. Also, I had thought that this only happens if you click on 'Emsisoft' but in fact you can click in the white area to the lefthand side of the word Emsisoft and have the same thing happen, in an area that's approximately the same width as the "EM" letters. So a user who happens to place the mouse pointer there as they try to start a drag will cause the About pane to open and very likely have no idea that they even requested that.
  21. EIS 2017.4.0.7424 W8.1 64bit Within my text editor, Kedit, I issued a command (of a sort I run many times per day) which runs a script that runs within the editor environment. The command was: fav progr It (fav.kex - written in KEXX which is more or less REXX but built-in to Kedit) presents a list of a bunch of folders and files whose nicknames (set by me) match the parameter I gave and lets me open whichever one I wanted. On this occasion I chose C:\Program Data, and then nothing happened. The editor fav.kex script (which logged what it did) issued: winexec nowait normal wscript.exe "C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs" "full" "C:\ProgramData" and that process (executing 'winexec') ran ok; the logs show that it received a zero return-code. But I got an EIS pop-up telling me that the behaviour of that vbs program was doubted - which in itself is odd because that program is run many times per day & has not changed since May 2016. The pop-up said: Suspicious behaviour has been found in the following program: C:\Dropbox\JN_VB_and_VBS\JN-Shell-Explore-Folder.vbs ? Verifying status with Anti-Malware Network... Cancel Clicking 'Cancel' had no effect. After maybe a minute or two, I got an OS message box: title: Emsisoft Real-Time Protection Emsisoft Real-Time Protection is not responding. If you close the program you might lose information. -> Close the program -> Wait for the program to respond After clicking on the latter option a few times, which each time just returned me to the 'Suspicious behaviour' dialog, and after a while told me again that Emsi wasn't responding, I chose the 'Close the program' option. The EIS systray icon then disappeared. I wasn't then absolutely sure if just the GUI had gone or more than that. The 'Suspicious behaviour' thing had, it seemed, stopped explorer from opening a folder viewer, and when I next clicked on part of an explorer window, the whole desktop background vanished leaving a dark blue screen with a bronze stripe across the bottom of the screen (where the taskbar would be), with a grey box where the system clock display should be. After a while, I got another message box: "Windows Explorer is not responding"... Fortunately I had my text editor window open, so could create these notes, and also issue system commands. I tried: "dosq explorer.exe" but that didn't seem to do anything. However "dosq cmd.exe" did give me a command window, and I was able to use (SysInernals') pslist, and in due course pskill to kill explorer. However although I was able to start a new instance of explorer, that didn't bring back the desktop. After saving my notes, I did manage to shutdown the system, by opening another cmd.exe window and issuing: shutdown /s /t 0 After the reboot, looking in EIS' logs, I see that there was a successful update at 16:00, which is about half an hour before the freeze. My own logs show the 'fav progr' command that provoked this was executed around 16:35 & had been preceded by several similar commands issued after 4pm. I'm naturally curious why EIS picked on that instance of running the VBS program, but I'm much more concerned that clicking 'Cancel' on the 'Suspicious activity' message box did not give me control of the machine. After all, I don't care what the Anti-Malware network might think of my program - I know it's doing what it is meant to do.
  22. I don't recall anything like that way back when I first installed the EIS trial. It suggests the values entered aren't being saved, but you'll need to get an Emsisoft employee to comment on whether or not that's normal. Did anything ... unusual... happen when you did the install? And error messages? Where did you get the trial version from? Once it's running, what version number is it? (You find out by opening the main GUI window and clicking on the 'Emsisoft' logo at the top lefthand corner.)
  23. No. At least, not as far as I know. I have no three-step process. But maybe what you're seeing isn't meant to happen, even in the trial version. What are the steps?