JeremyNicoll

@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.

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.

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.

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.

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.

It would be sensible to try the current version, which seems to be: 2020.5.0.10152.

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.

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?

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?

Eventlog - yes, you said you'd terminated the previous instance. It's not a surprise that that's recorded.

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.

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.

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.

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).

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.