• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JeremyNicoll

  1. I just tried a malware scan here, and that also minimised ok.
  2. Weird! It's working fine here (Win 8.1) with build 10275.
  3. Someone who knows more than me will need to comment. It's odd that EEK, using (according to its log) uptodate definitions, thinks - it seems - that one of these files is iffy. On the other hand, all those a/v products, including EAM, think the files are ok. That makes me wonder if there was ever another file involved - can EEK quarantine things? I don't know. Or if a directory itself can somehow be infected? I note also that the EEK scan did look in Alternate Data Streams. If any of these font files have an ADS, I don't know if that would have been uploaded to VirusTotal along with the principal content of the files. You could use: to see if any of the file do have an ADS, or (if you prefer a GUI):
  4. @bluescreen You might be able to tell from EAM's logs (assuming they survived uptodate across the termination), or failing that date & time stamps on its updated program files, precisley when the new version got installed. If the 'System' Eventlog records that mention services terminating are at the same time, maybe it is just one of those things - an update that didn't go as planned. But if the times are different then the contents of the System Termination log records might be useful. If you click on each one there'll be a "Copy" button in the pane that opens, that will let you copy its contents here.
  5. You could try uploading each of the three font files to VirusTotal - see: - and make sure you use the "File" tab there. Their system will let lots of different antivirus products examine the files, and tell you what it thinks about each one. If it's clear that most of all of the other products think the files are fine, it'd be useful to Emsisoft if you'd post the URLs of the three VirusTotal reports into your next reply.
  6. Does EEK have a log? If so does it show more info if you double-click the line saying there's a detection? One might hope for the name of the supposedly-infected file. Also, in your File Explorer settings, do you have the option to display hidden files turned on? (That should, if W10 is like W8.1, be in the View tab of File Explorer's Options dialog.)
  7. @bluescreen - can you find any eventlog records describing a2start terminating (if it did)? No cpu use in the other tasks too is worrying.
  8. For info, really... I finally got around to changing the registry keys concerned so that application dumps will be 'full' ones (ie as detailed as possible). I know you've got .reg files that make that change for those who wish it, and nominate %PUBLIC%\CrashDumps rather than the Windows default of: %LOCALAPPDATA%\CrashDumps as the place to which dumps will be written. There's clearly a small risk (with the %PUBLIC% location) that - on a system with multiple users - someone unauthorised could read a dump created on behalf of another user. Maybe you should highlight that? I took ages to set this up because I also read in detail around the subject of "Windows Error Reporting" (which is the bit of Windows in which support for different types of user dump is implemented), and wrote notes for myself about all of this. For these dump options, see: My eye was caught by the text that says that the nominated location only applies to dumps from applications being run /by users/, ie not dumps from services. It says that service dumps will be elsewhere and does not give a full list of those locations ... except that they'll be somewhere inside %WINDIR%. In a command prompt opened with Admin authority, the command: dir /b /s %WINDIR%\*.dmp* will search through all the possible places that might contain such dumps and list where they are. I found 24 dumps I didn't know existed... mostly pretty old. Some of them were from a2service.exe ... and those (here anyway) were in: C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps\ None of the folders containing service dumps are (on Win 8.1 anyway) able to be opened in File Explorer unless you have Admin authority. The other places (not explicitly listed as possibilities in that MS document) in which I found service dumps were: C:\Windows\LiveKernelReports\WATCHDOG\ C:\Windows\LiveKernelReports\WinsockAFD\ C:\Windows\SysWOW64\config\systemprofile\AppData\Local\CrashDumps\
  9. There's really no point in having a "beta" that is only available for a few minutes before it becomes "stable". Compare this with @GT500 's comment (about a possible "Malwarebytes" release) at:
  10. @andrewek - excuse me, but I am confused. Is "Well, bravo, Emsisoft!" a happy statement or an unhappy/cynical one? I can't tell from your picture whether it shows what you want it to look like ro not. Also "Obviously, a small one has been fixed - but the problem with maintaining the window size of the program (interface)." - is only half a sentence. Is there meant to be more? "But" what?
  11. Which current beta? The one we've been running for days, or the one released 15 minutes ago? (it's a bit soon to say for the latter. For the former, yes it was still not perfect, as I reported on the Beta forum.)
  12. Your second line down ... C:\Program Files\Emsisoft Anti-Malware ... is enough (for EAM) because that's where the various a2- & epp- .exe programs (and DLLs etc) live. You shouldn't need to exclude any C:\Program Data\... folders, at least not the Emsisoft one, as the whole point of a ProgramDATA folder is that it is not meant to contain any executable programs, just data files that programs use. I don't know what's in the C:\ProgramData\Dell Inc, or C:\ProgramData\SupportAssist folders though. If they actually do contain executable programs rather than just data they may need to be in the exceptions list.
  13. Did you mean a window that looked like the following - white, black text, red icon? (Ignore the fact that this example is for some other program.) @GT500 - if this was an EAM failure, should there have been an Eventlog record?
  14. @Nikilet - you should be able to find some info in an Event Log, using the Event Viewer. In Win 10 you can find that by typing in "Event Viewer" in the search box. Be aware that the event viewer shows contents of normal reports of all sorts of things going on in the OS. For example it's common for bits of Windows to try something, fail (perhaps because something else is going on at the same time), and the bit that failed will be retried later and work. Failures do not mean there's something wrong. [Most of the technical support scams (ie when someone phones you and claims they are from Microsoft or your ISP, and your computer has a problem) use this perfectly normal list of apparent errors to convince people that there's a problem with their system.] These logs are really normally only of interest to programmers. Anyway, if you can find Event Viewer as suggested above, and start it, you'll probably be asked for the system's Admin password. That's because some of the logged info is in files normally only accessible by the Admin user. It's fine to give the password. Then - if the viewer is like the one in Win 8.1, it will open with a small list on the lefthand side saying Event Viewer (Local) - Custom Views - Windows Logs - Applications and Services Logs Subscriptions Click on "Windows Logs" and it should expand to show Application Security (maybe) Setup System Forwarded Events Click on "Application". The display's central panel should then show a long list of log entries, and the date and time they were created at. Scroll the list to find any that are as close as possible to the time you think EAM had the problem. They /might/ have "Emsisoft" named in the "Source" column, but then again they may not. If you can't find any in the "Application" set, look also in the "System" set. Look at anything whose date & time is around the right time. If you double-click an entry in the long list of entries it will open and show more information. Don't expect it to mean anything to you. Ideally you're looking for any of these "event logs" that mentions EAM or Emsisoft, and possibly also words like "exception". If you find any, there should be a button labelled "Copy" - in the Win 8.1 version it's at the bottom lefthand corner of the box with all the extra cryptic information. Click on "Copy" then paste the results into a reply here. If there's lots of records that all seem EAM-related have a look to see if they all say similar things. Examples of each type of thing will be useful.
  15. I've waited a few days to see how 10259 seems to be behaving and it's certainly looking a lot better - cpu has stayed low. However I just got to teh end of a custom scan - which was long running - just over 4 hours; two drives (both SSDs, though one is fairly empty), 1.4 million files. The scan looked inside archives which is why it took so long (a scan of the same disks but skipping archives usually takes around 70-75 minutes). Also debug logging is on. But, see this summary from Process Hacker. A2start, during the scan had a WS of 1.1 GB, and still does now that the scan is finished. It peaked at 1.11 GB and peak virtual memory use was 1.41 GB. It's a hell of a lot for a process that's supposedly only doing the user-facing stuff. When I was watching the scan running, near the end, a2service - the bit that as far as I know is actually doing the work - was using around 770 MB. I don't understand how a2start can be using more memory then the scanner itself.
  16. Whether a system restarts after a BSOD depends on a setting in (at least in W8.1 - the options might have different names in W10): Control Panel - System - Advanced System Settings - Startup and Recovery - Settings - System failure ... where you can choose whether "Automatically restart" is selected. Some people like a failed system to restart, others hate it. In particular some kinds of problems can cause a continual loop of crash, restart, crash, restart, crash, restart ... Also, some people (eg me) will always do some extra things (look for dumps, look for eventlog records, run chkdsk full scans...) after any BSOD and really would not want the machine to just restart. Depending on what you normally have a machine set up to do when restarted it might be easy not to notice that BSODs had occurred. Why would a WIFI problem have anything to do with your ISP? They may have provided the WiFi router that you connect to, but that would be a hardware problem in your home with that router, not a problem in the ISP's own network.
  17. It's not what I meant. Doesn't MS release new versions of Win 10 every 6-8 months? I wondered if both machines had the same version. After that, I'd also wonder if both of them are uptodate with Windwows Updates.
  18. Do those both have the exact same version of Win 10 on them?
  19. I only have the small dump that I already sent.
  20. @pkolasa - I certainly did not try to undermine you. It's not the way I think, nor (in case you think I was trying to) was I either trying to "solve" your problem or imply it was minor. I merely responded with thoughts that might have been relevant. I did notice that you're classed as a "Tester", but your post count is low and I'm not used to seeing posts from you... so I thought it likely that you don't spend a lot of time here on the forum. I know you didn't say specifically that a2start/a2service were using lots of CPU. I was merely pointing out that there's currently a known problem of high cpu use affecting both processes for some users some of the time. As no-one seems to know why it happens, maybe it affects systems in other ways too. I didn't (and still don't) fully understand the point you're making about 4 MB/s being significant. You said there's a problem "whenever I download something with high-speed (over 4 MB/s) through the network". Is that a high rate? Compared with what? It was your implication that you're choosing to download at a high rate, AND the 8-fold difference between 4 MB/s and 34 MB/s that I didn't follow. I wondered if in fact that "4" was a typo for "40". There's no point in suggesting to me that I might read about how FDM works. What would matter is how you'd configured it. If (as you imply) it was only ever trying to download large files using ten connections (as opposed to hundreds or thousands) I wonder why there'd appear to be quite so much DNS activity going on. > 2) I know it worked, just as you have said. I just did not use it after switching to MyEmsisoft. The folder is created, but only empty folder, no files in it. I have explicitly stated it. I know you explicitly stated what happened for you. I wasn't doubting it. And, yes, I know (as you do) that it used to work the way I described. What I didn't know (and probably you didn't either) is whether the current version of EAM still successfully saves settings in the old way. It's been months since I last tried it. You gave no indication of whether you'd tried it (without MyEmsisoft being involved) today or recently. Even if you had done, it's quite common here whenever someone says they have a problem with some feature of EAM for other users to see if they also have the problem. You seem to think I was challenging what you said. I was not. > I will also open a ticket to Support, as using just forums may not be the best idea. @GT500 lives, I think, In the US. The hours he works do not fit all that well with the hours that people in Europe are awake. He's often not here at all over weekends. It is my practice - if I am awake and alert enough (I've a long-term illness) - to try to reply to many people's posts to get a discussion going, even though it may be a while before he gets involved. Sometimes what people post is very vague and I try to ask them the sorts of things he might ask later on. It speeds the whole process up, and also means that people whose posts would otherwise go unreplied to for many hours (or even several days) are less likely to think that no-one cares.
  21. Export Settings - I /don't/ use MyEmsisoft and when I just tried exporting Settings, the files did get created. So that does somewhat imply MyEmsisoft (rather than the process of creating the files) is the problem. Here, the default location for the exported files was in a folder named "Exported settings" in my Desktop folder, which already existed. Did the folder already exist on your machine? If it did: then maybe none of the process of exporting stuff actually happened for you. If it didn't... it's odd that creation of the target folder would be done and then EAM not create any files in it; you might think if MyEmsisoft was somehow blocking this that the folder would not be created at all.
  22. Are you aware that there's an ongoing problem with different people reporting high cpu use by either a2start or a2service? See: I'm a little puzzled by you saying "high-speed (over 4 MB/s)" when the download manager thing shows 34 MB/s. I know that download managers can appear to work miracles ... but what is the speed of your connection? I think I remember (having asked Emsisoft a while ago why one of the EAM .exe's was doing so much I/O... that the I/O figure includes network traffic, not just disk I/O, though of course bytes arriving over the network have to be written to disk somewhere... but not, I would have thought, by a2service). On the other hand, I'm not sure why EAM would need to look at every incoming byte of traffic. I can't see what it can tell from doing that. Surely it has to look at complete files? Or.. I know download managers will split big downloads into multiple ones from the same (or also mirror) servers. Could that be tens or hundreds of thousands of very small 'files' (files in the sense that each chunk is fetched separately and written somewhere .. and thus would appear to EAM to be a separate file needing scanned as its fetch completed? I just don't know. Surf Protection works by intercepting/monitoring DNS lookups, so presumably EAM's monitoring of that is done at the OS DNS level not at the browser one. If the download manager really is fetching your file as thousands of small pieces rather than just a handful of pieces, maybe it does a DNS lookup at the start of each fetch. Does the download manager have any statistics or logging that tell you how many servers its fetching from, and just how small each fragment is?
  23. This happened again this morning, albeit with a slightly newer version of a2start. I've PMed Arthur with the location of the dump, debug logs, eventlog records etc.
  24. Again. FFS. Win 8.1, 64-bit. Last reported (albeit with a beta) three weeks ago. This is a newer version of a2start and the exception offset is different from last time, so maybe a different cause. Who knows? Not me. As last time, restarting a2start and doing the exact same things (indeed the same things I always do to start a custom scan), it worked. I suppose I should be 'grateful' for that. I have PMed @GT500 with the location of the dump, debug logs, eventlog records etc.