JeremyNicoll

Member
  • Content Count

    1840
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by JeremyNicoll

  1. @marko @Quirky It's not what I meant. When I replied, trying to explain what timing issues might be, I'd looked back through this discussion to see when @GT500 had mentioned timing issues. But in his post [ https://support.emsisoft.com/topic/33533-wsc-integration-problems-with-latest-version/?do=findComment&comment=207877 ] he had said "Of course, that doesn't mean the CPU actually has anything to do with these issues. It's more likely an issue with timing since it doesn't happen when debug logging is enabled." and no-one has corrected that statement since he made it, so I wrote my reply under the same assumption. It's been ages since I read the whole thread (which hopefully would have made me aware of that error), as I tend just to read new posts as they are appended.
  2. Which version of EAM are you using? When you click on OK, trying to change the "at" time to 5pm, does a Forensic Log entry get created describing the attempt to change the setting? Here (with Win 8.1) I am able to change the time and a log entry is created saying what I changed. I'm wondering if you get a log entry at all, and if you do whether it describes the change happening, or (perhaps) being rejected.
  3. This suspicion is because the problem doesn't happen when debug logging is on. When such logging is on, the program(s) that is/are making the logging requests will be taking slightly longer to do the "real stuff" between each request to update the debug log (because they're doing the real stuff, and the logging as well). This suggests that something the program(s) rely on only just manages to get done in time normally (for users who don't have the problem) and fails to be done in time (for users who do see the problem). Turning on debugging gives the thing (that hasn't completed in time) enough extra time to complete. It's a problem that could also show up when code originally run on one cpu now runs on a slower or faster one, or one with more/fewer cores. Anything that affects the rate at which other processes are running can make this sort of problem appear or go away. The problem for the developers is to work out what the time-critical thing is. It could then perhaps be started earlier, or the code that needs the results can be made to wait longer before expecting them to be complete. It's a classic kind of programming problem, hard to identify, though knowing that turning on debugging does change things is itself a valuable clue.
  4. The car tyre analogy is a little bit flawed. I'm not sure that all that many people ever read their way through a car's manual, even if such things still exist? I have a feeling that the potential risks of mixed-up tyre types may be mentioned (at least in the UK) when people are learning theoretical stuff before sitting a driving test, and I think it's also the sort of thing that you'd expect any mechanic to spot, and it might also be explicitly checked when cars go through their compulsory "MOT" tests every year, after they're more than 3 years old. Maybe the EAM installer should warn people about having other products installed. I don't know if it (or more accurately they, as there's more than one type of installer in use) do so. Even if it does, a lot of users would probably just click on past such a warning. The alternative, of expecting the installer to detect if other products are installed is likely to be tricky - there's a lot of other products AND it's one thing to look for active other products, quite another to detect those that are installed but not active at that point. Or those that don't have their real-time monitors turned on at that point. None of the anti-virus / anti-malware com panies are going to reveal the inner workings of their products, which in any case change all the time to adapt to whatever the current threats are and because OS-internals also change. It is not reasonable to expect a detailed ongoing analysis of why anti-virus/anti-malware programs may obstruct or confuse each other.
  5. DLLs aren't executed in their own right, but get loaded by exe's. It's the exe which matters, so that (I suppose) EAM doesn't inject anything into that process. Whether such a process loads specific DLLs will be irrelevant, surely.
  6. It would be sensible to try the current version, which seems to be: 2020.5.0.10152.
  7. In EAM, you'd exclude from monitoring the .exe's that are part of Kaspersky's product. In Kaspersky, you'd exclude EAM's .exe's.
  8. In your August 24 screenshot, right under the Emsisoft thing using 30% cpu there's something called "Dateisversionsverlauf..." which Google translate tells me means "Fle Version History". What is that doing? Is it a backup or file/search indexer?
  9. Maybe exclusions (from monitoring) for the programs that you use to make backups and images would be worth a try. What do you have File Guard's "scan level" set to?
  10. Eventlog - yes, you said you'd terminated the previous instance. It's not a surprise that that's recorded.
  11. The assemblies thing happens (as far as I know) whenever there's a .NET update. I think each of the existing assemblies on a machine gets recreated with the uptodate versions of its parts. Anyone with a modern, fast, multicore machine is quite likely to be unaware of the rebuilds, especially if they don't have Task Manager (or in my case the much more detailed "Process Hacker") running AND look at it often. I think I read about this on one of those "my machine's slow after every Windows Update - why?" threads on some website somewhere. If you're used to using ProcMon then it might be worth logging what files a busy a2service is reading/writing. But if eg it's just (say) busy grabbing and releasing memory over and over again, then there'll be no clue why. If the problem IS interaction with Kaspersky, then I would think only EAM debug logging would help to show that. And even then, who knows what the trigger is? Drive F: exclusion is probably not a problem. But bear in mind that the whole backup & image creation processes have to read file contents (from elsewhere) too.
  12. OK, but (the new) a2service is behaving. I see its WS figures are back to 242 MB (in use now) and 420 MB (max), both of which are more or less what I'd expect. Is there nothing at all in the Forensic log, when a2service gets busy? Anything described just before it starts to get busy? If you click on log entries they show more information. Are there any indications of scans happenning at these busy times, from the files in: C:\ProgramData\Emsisoft\Reports Could any of your software have been installing updates? That might account for sudden scans occurring even if you don't know about it. And I know that after Windows Updates install, Windows will sometimes rebuild "assemblies" in the background making machines unresponsive for hours or days (for people with old slow machines) until that's done. I don't know if EAM would be busy at the same time. Do you still have Kaspersky excluded from EAM's monitoring, and EAM excluded from Kaspersky's monitoring? There are system monitoring tools that can tell an expert more about what's going on in a system ... eg: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon but tools like this generate huge amounts of information - as that page says: "millions of captured events and gigabytes of log data", and it's useless unless you know what the normal sorts of activities are.
  13. The log.db3 file is what holds the "Forensic" log, I think. I don't think that's likely to help, after all you can look at that more easily via the GUI.
  14. What's it doing? - Not that would be meaningful to you or me. If in the Details tab, you sort the display by CPU use, what else is using more than 1% ? Or, if you sort on any of the I/O columns do they show any process reading or writing lots of data? Emsisoft support might suggest that you run with debug logging on, so that next time this happens those logs might show what's so busy. But last time I had a problem with one of the Emsi processes using lots of cpu time, debug logs didn't help. (They probably showed normal EAM processes happening, without showing why they were happening so much more than usual).
  15. Here (on WIn 8.1) I used Admin Tools - Services, with admin authority, to look at some of the properties of the a2service service. Here, it says than in any one-day period, a2service will restart twice if stopped (or if it crashes). After that it might not automatically restart - I'm not sure. It suggests that terminating it deliberately might only work once or twice before you'd have to reboot.
  16. If you terminated a2service, maybe a replacement one started immediately. If you look on the Details tab, does the a2service that's running now have the pid (process-id) value 2932 that the one in the earlier Details display had (if so it's the same one) or something else (in which case it is new)?
  17. I don't think EAM scans the colossal amount of data inside MP4 files, anyway. In the screenshot above, you've got arrows pointing at what look like "Working Set" columns. The 218 MB one is unremarkable but the other - around 1.1 GB is much more than I'd expect, unless (I suppose) a2service is scanning something big. Here a2service's WS is currently 420 MB. The fact that CPU is 17% means it's clearly doing something...
  18. There were, apparently, widespread global problems with the internet yesterday, with many services which are accessed via Cloudfare being borked. I've read that that in turn was caused by a problem with another company's - CenturyLink's - infrastructure.
  19. Surely it would be better if there was an accurate message placed in the Forensic log saying what had been reset, AND saying this (especially clearing of the logs) was done at the user's request?
  20. The file you unpacked yourself is half a megabyte smaller than the "similar" one - (21.02 MB vv 21.49 MB). The not-yet-unpacked .exe is much smaller, about 8 MB.) The section in the VT report entitled "Portable Executable Info" seems to have a different selection of info for the two files - as if one maybe contains headers that the other doesn't. On the other hand I saved out the list of hashes etc of the contained resources, and compared them, and they are identical. That is both unpacked executables contain the same set of icons, executable code, etc. Maybe the version of UPX used by you, and whatever EEK uses, are different, or one or other ran with options to include (or not) some headers in the file it created? @GT500 - why do the VT reports show the two larger files as not-signed and yet also list a set of Verisign CA stuff? Does it mean that the files are signed with out-of-date, or otherwise iffy, certificates?
  21. As far as I can tell your cpu is 6 core (but that should mean it can run 12 threads at a time, unless that's been disabled somehow). You mentioned quarantined files; are any of these very large, or zipped (or otherwise compressed/archived)? Unless a re-scan was having to unpack enormous archives, I can't see why a re-scan would take long at all. @GT500 - if there ARE long-running (or even short-running) re-scans going on, would there be scan report files describing them, in C:\ProgramData\Emsisoft\Reports ? And, if there's scheduled scanning going on (even though the OP thinks not), they too would generate reports wouldn't they? Do you have any other security software installed?
  22. @mtjmohr - which version of EAM are you using? Do you (in Settings - Updates - Update feed) have "Stable" selected? You mentioned both WIn 10 Home and Professional in your first post. Which is it? What model of CPU does your machine have? If you don't know, Control Panel - System will show you. I'm wondering if your CPU figure of ~17.5% represents one core (on a six core machine) running flat out. When the EAM service is busy, if you sort the task manager display by its CPU column, is anything else very busy? @leo333D - what is your screenshot supposed to be telling us? Do you also have a performance problem?
  23. Win 8.1 64 bit The application restart process didn't work properly - or at least, not as I expected. I got the pane saying an application restart was needed, with a counting-down button and a do it at restart button, and clicked the counting-down one. It sort of froze for a few seconds (whereupon I expected the GUI to vanish from the screen) then came back (with the countdown about 5 seconds further on) and continued counting down to zero. Then the restart was done.
  24. If you still have the 10mb file, can you compress that into a smaller file first and try to send it that way?
  25. That seems a bit at odds with your earlier reply; is the difference that these latter programs take a different approach from whatever it is that Checkpoint's software does?