• Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by JeremyNicoll

  1. @MJmusicguy  - when the OS dumps, it has to write a copy of everything in the in-use memory, to disk.  It's not safe on a system that's hurt to use usual files for that (the file system may be in a mess because of whatever has gone wrong) so the OS instead writes the info to the pagefile (which is a private file only ever used by the OS).  When the OS is rebooted the dump data inside the pagefile is then copied out and put into C:\WINDOWS\MEMORY.DMP

    It follows that the pagefile needs to be big enough to hold a LOT of data.   You maybe don't normally have a very large pagefile, but to allow this dump process to work you'll have to make a big one.

    On the webage about pagefile changes, do you see the screenshot at  "F" in section 6?    Follow the instructions to get to the same place on your system and screenshot it or make notes of what it says - how many drives, what sort of pagefiles any of them have, and tell us what the values are.  Don't change anything for now, just Cancel out of that pane.

  2. > Keep in mind that Microsoft already implemented such a feature...

    But don't users have to turn it on?  Security-minded users might well do so, but those who couldn't care less, or are non-technical, or think it won't happen to them, won't do.


    Tell me, can Win 10 users enable Controlled Folder Access and also use EAM?   Or is CFA only possible if you use Defender's a/v capabilities instead of EAM?

    (I would very much like to have CFA, not just for protection against ransomware etc, but also programming accidents (ie situations I hadn't properly thought through in my own code) and mistakes made using unfamiliar products.   As far as I can tell CFA is a pretty crude system, with folders being protected or not - whereas it's even better if you can dictate which processes can access particular folders.  CFA - as far as I know - does allow you to grant access to all allowed folders, per program, but that's a bit unsubtle.  There's no reason why - say - my favourite graphics utility should be able to update system folders; it'd be far better if it could be set up only to be able to update the folders where I kept the project I was working on.)

  3. Ok, that's better than nothing.    But the vulnerability is down to the symlink/directory junctions aspect (being used to redirect the filesystem from eg a required DLL to something else, presumed to be malicious as was the EICAR file in the example shown on the website).   Presumably replacing the AV product's DLL with something non-malicious would also be a risk - diminishing the power of the AV product.  

    If QA's test only worked because the EICAR file was detected, it's not checking the right thing. 

  4. @eliastz   Or, you could help Emsi to find out what the problem is?    The interesting thing about your most recent complaint is that it kind of implies that you've NOT had the high cpu problem recently, and it just started again ("is back to its old ... tricks"), along with the Windows updates.   You reported you had the problem in Feb and early March.  When did it go away?

    (Just to be clear: I have the other problem: a2start goes mad, a lot.  That though can be worked around because a2start doesn't have to be running all the time.)

  5. That sounds like a Windows error message.  If it is, it's presumably not an Emsisoft /mobile/ security issue.  

    Can you clarify what device this is, also what OS (and version), what version of EAM or (if it is) mobile security this is, and whether the device has any other security software on it?

  6. 1 hour ago, Frank H said:

    Running multiple scan concurrently is not support (yet) , and yes i agree we might show a dialog to inform the user.

    An interim solution might be for EAM to offer to add the context scan request to a queue and do it as soon as the main scan is over, or - maybe more useful - interrupt the main scan at the next file boundary and do the context scan, then return to the main scan.

  7. /I/ don't know the ins & outs of how the OS settings for dumps interact with (as must have happened here) an application's trapping of the problem.   Your screenshot shows that EAM itself knows that a2guard.exe has crashed (as indeed it did last time).  Maybe in this case EAM (rather than the OS) has dumped whatever the EAM programmers think is relevant, though I don't know where it would have put it.    Did you - as the pane tells you to - click "Send"?

  8. I think the overhead of having full protection turned on is so small, you'd be better to have it on.   Otherwise, you'll have to be very careful and also - probably - run full scans of all the files on the machine much much more often than you would otherwise, to be sure that nothing bad has sneaked onto the machine.

  9. Well, I'm glad it worked (if it did?).  Maybe the Inno installer checks different things, or fewer things, than the MSI ones?  Did you actually run the install with logging on?

    Your screenshot shows no protection is actually running though, even though it also suggests it's uptodate ("last update 6 mins ago"). 

    You said you wanted it to run "just as a scanner, with no real-time protection".   Why?   If you context-scan a known-bad file, does the scan actually tell you the file is bad?

  10. If MSI logging is not on (it's quite likely it's not on because logging slows down installs of Windows updates etc), then you can turn it on if you're willing to update a registry entry.  See:     Turning off logging is done by deleting the registry value, as described.

    Note that at the top of that page there's a list of every version of Windows this works for... and oddly Win 7 is not on the list, but the even older XP is.  However I've found advice elsewhere that suggests it does work for W7.   When choosing which flags to set, I usually choose "voicewarmup" ie I leave "x" and "+" not set.  Beware of setting "!" as that forces the log file to be closed after every line is added, which makes logging very very very slow (it's meant for situations when the machine crashes during an install and you want the log file, which you'll examine after a reboot,  to be as uptodate as possible).

    Most users never turn this on.   I tend to have it on because when installs fail it can be a good place to look for reasons why. 


    Alternatively, try the Inno installer.  Once you've downloaded it, make a shortcut to it.  Then edit the shortcut's properties to append  ' "/LOG"'    to the command,   that is: a space, a double quote, a slash, LOG and a trailing double quote.   Save it, then double-click the shortcut.  Have a quick look in %TEMP%; if adding the log parameter worked you'll see that a file with a name like "Setup Log yyyy-mm-dd #001.txt" has been created.  If there's no such file stop the installer, go back and look at the changes you made to the shortcut.   Hopefully you'll end up with a log from the Inno process, which again /might/ tell Arthur how, if it also fails to install EAM, how it made that check.

  11. You said Emsiclean doesn't find anything, so this is definitely something @GT500 will have to answer.    It might be worth running the diagnostic program and attaching its log, for him to look at. See:


    Also you said you'd tried the MSI installer.  Did it create a log file - usually they're found in %TEMP% with names like: MSIxxxxx.log    (the xxxxx is a 'random' string of hex digits.  If you have lots of such files find the one whose timestamp is for when you tried the install).    If there is one, attaching it might tell Arthur what specific part of its processing hit a problem.

  12. The EAM 'sales' page has a small link, just under the "free trial" button, to "alternative installation options".   Some installers are small, but have to go to servers to download the real installer *which is fine, unless that server is unavailable).   Other installers are much bigger but include the program code.    You should perhaps try one of the big installer files, either Inno or MSI.

    • Like 1

  13. Indeed; quite often the problem builds so slowly that if you shut down (or even just log out) every day you could easily not notice it, and the more cores you have the more likely you are to not notice too, as unless the machine is heavily loaded it will still cope.  For me it was only the laptop fan being on more than usual that made me look into it.  Using the laptop off mains I don't even notice diminished battery life.

  14. > We've seen high CPU usage from a2start.exe as well, however once a2start.exe is restarted the issue takes some time to manifest again (if it ever does) which is making it take extra time to debug.

    The unpredictability really surprises me.  I use my pc in, as far as I can tell, near identical ways each day - mainly at the moment browsing news websites (the same ones each day), and watching stuff on iPlayer, and a2start is fine for many hours, sometime all day, some days... and goes mad on other occasions not even when the machine is otherwise really busy.

  15. Your image doesn't show high  a2start  (the gui) cpu usage, but instead high  a2service (the bit that actually scans things etc) use.

    Do you have a scan running?

    Did you cold start the machine just because it was off and needed to be on, or were you in the midst of something else that BSODed, or applying updates, or any other issue?  Was the machine working perfectly beforehand?

  16. @GT500 said: > If you leave it enabled, then check the crash dumps folder periodically. They can waste a lot of disk space, especially if a game crashes.

    @Nikilet  did say earlier that they'd enabled only mini dumps, which are a good deal smaller than full ones.  I meant to ask: are mini dumps sufficiently useful to be worth having?


    So far as checking folders in which dumps might accumulate goes, I do that weekly.       C\Users\Public\CrashDumps    doesn't seem to exist in W8.1.   I look in:

    For each of my Windows users:
          C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Crash Reports

    and for the whole system:  C:\Windows\Minidump\

    When Firefox crashes it collects dump information but doesn't automatically submit that to Mozilla.  That's only done if the user goes to    about:crashes  and chooses which of the listed crashes they want to submit crash info for.   The folders under   C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Crash Reports   contain things waiting to be submitted as well as lists of what has been submitted.   I don't know where other browsers collect similar information, or even if they do.


  17. You might as well leave the dump-enabling thing in place, so that if something goes wrong in future a dump will be created, and you can send it to Emsisoft (or some other program's vendor).  It's /far/ better to have a dump when something goes wrong, than to wish you had one afterwards, when you don't know how to recreate the problem.

    But, if you do want to disable dumps,  run the "disable_all_crash_dumps.reg" file (which should be in the set of files you downloaded before).  If you deleted them, grab them again from the link given earlier.

    For FRST, yes, you can just delete it.  New versions of FRST are produced most days so if you need it again it would always be best to grab the newest one.  It will probably have created a "C:\FRST" folder with copies of the reports it produced and also backup copies of registry info.  You can delete those too.