• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mtjmohr

  • Rank
  1. Here is the current, momentous situation as I expect it to be and how it normally is:
  2. Thank you for all of your help and support, dear friends, so far!
  3. Again, I agree, but they do not have to spill the beans just looking for an "emsisoft.exe" or a "kaspersky.exe" or whatever kind of symbolic file or even executed service. And again, I disagree: To my understanding it is absolutely reasonable to avoid fussing and chaos for the sake of user-friendliness which is the main stake for such a product. Friendly i the sense of all its functionality considered for the user's individual or enterprise survival. It has got nothing to do with letting it come so far that processes might be combatting. The detection in the sense of a prophylaxis needs to come on earlier, at the moment of installation or even preparation to perform an installation. So many other software programs do this along older versions, along most recent updates, along outdated drivers, etc. Thus, it is feasible. And it would be a cool understanding of what marketing and user-friendliness really are about. The more sophisticated a piece software is, the less it has to be competitive. And nobody tell me here that it does not matter which anti-malware I make a decision for. These products will prevail which have the best functionality and the best UX. UX is not everything. But as industry you must reckon that someone plays with your product or maybe uses it in a sense it had never been created for in the first place. This has got to be anticipated in UX. I do not go so far. I would be already content if someone wrote "hey, Mohr, buddy, fool, and git: here is the reason why your installation of two anti-malware systems will never ever work: ..." and then gave me some details which asked me for my tech intel level before clearing things to my understanding. Maybe this cannot even be generalized. Maybe I need a specific answer to both m problem and my status of intelligence / cognitive capabilities. Alright, so be it then. You see, I am a 30-years-experienced surgeon. If you came to me and asked my "what is to be done?" I can either give you the "statistical answer" after which you think I am an arrogant snot, or I can give you an answer which is tailored to your needs and in the end "what condition you bring with you" for me to understand before I even can answer your question. Again, I divert from the origin, but at the moment we are no longer on a technical level but a philosophical one why things possibly are not the way they should or could (I love these English conditionals 🙂) be. "Right, don' let 't 'appen again!", let's go back to the technical part. I will see how my system works now after the changes implemented and report again if there are news.
  4. Yes, absolutely, they should. We are here at a stage of advanced technology. Imagine: Emsisoft and Kaspersky are two installed software systems. The problems might possibly be caught at a level of different compatibility once they function entirely out of the cloud, and we will no longer perform individual installations. And for the rest I quite disagree: Detection and warning are both crucial and essential. Because you never know when such a system, now possibly inactive, might be activated by whom with which technical understanding. The core is to be aware that there might be reasonably often installations which are not "orthodox" in that sense but simply exist.
  5. It is not far-fetched at all. You are by law "held" to read the mandatorily encluded board manual or instruction as to how your car works - in case you cannot prove that you have read and understood the how to switch on and when to use the blinking warning system, for instance, and an accident on the evidence of this takes place, the legal consequences may vary a bit within Europe, but mainly state that you, the non-reader or non-understander but the person responsible for driving at a given point of time all of a sudden has a big problem ... I am not talking here about some lege artis applied tyres which might have been accidentally mixed by some expert in a car repair or tyre vending shop who did not pay attention. I talk about putting on these tyres myself without caring whether they are compatible to each other. I talk about myself, Mr I_m_using_two_antimalware_systems_at_the_same_time_because_I_am_a_wise_guy_who_knows_better. This is the issue. But we are drifting off into philosophical considerations, sorry for that, me to blame for.
  6. I do acknowledge that, but none of this industry's product developers and distributors do acknowledge that openly. This is the point here for me. You see, I do not care which mix of products I handle, I just want to understand what the issue is. With a technical description of the reasons for it. I cannot as proprietor of my own product go along time and never mind other products or take a look how they interact and possibly avoid that for the so-called user-friendliness or - more modern - positive "UX". This what we are talking about here is not a most recent issue. It goes on for more than one decade now. Time enough for the industry to acknowledge that there are other parties which do something similar. Other industries have already understood that for a long time. Take the car industry. Mounting two different sets of tyres diagonally or even one tyre only with another material layout than the other three is contained as "dangerous" or "not advisable" in ever car owner's manual. Why is that not possible here? Answer my question to yourself and you see why I am complaining. Not that I have not found the best help and support here in this forum. But the conundrum is a principal one: The industry *knows* and *is aware of* that there are such gits and nincompoops as I am who do install several products together, so why not try that in their own labs and say "no, no, no, no, no, don't do that!"? At the moment, with the changes performed, no disturbance as of now, at least ...
  7. I have mutually excluded all the directories now. This is something both should be able to handle without excluding every single exe file. Here is the screenshot for Emsisoft: And here is the screenshot for Kaspersky: I will keep you in the loop as to what will happen. Both configurations are installed and exported.
  8. Okay, I will test whether this changes anything. I take the entire directories so that DLLs and whatever might be included in one swish.
  9. Okay, the complexity seems to be enormous. I admit I do know about the potential of mutual affections of anti-malware products, but this is not the overwhelming rule to my experience. But: Why then does a product as Emsisoft or - vice versa - Kaspersky then at the moment of installation not tell me "Oh, Mr Mohr, you stupid git, you have Kaspersky / Emsisoft installed, we strongly encourage you not to install two such products at once."? Obviously, if this problem really results from an incompatibility of two major anti-malware products installed at the same time, this issue has been known for more than a decade. So the respective industry does not do anything for the easy detection and potential elimination of this issue? Just to give you another example: I had been using Bitdefender, always the maximum product for private users, for years and simultaneously the Antimalwarebytes product: Never for one moment was there a disturbance, my system had always been clean (to my knowledge), and system issues had been caused to 95 % because I had been hampering with some Windows system resource by trying to change a low-level change of some driver. Then, for reasons of better overall results and better individual configurability, I have changed to using Kaspersky TIS, always the latest version. And Antimalwarebytes. No issue. Now, I am using Kaspersky and Emsisoft, together, and apart from this issue with the Emsisoft Protection Service I do not see any interactions which might make me uninstall Emsisoft again. You see, I want to fine-tune a system, and one protection product has always shown not to be sufficient to keep a system clean, at least in my case. I do understand that this might not be in the special combination of Kaspersky and Emsisoft, but the principle remains abundantly clear to me that one product is not really doing everything I want it or expect it to. In this case, I do see that Kaspersky is even the stronger product, but that is my personal conviction. And, furthermore, although it is well possible to use any product developer's forum for asking nice people like you for help, I am missing the "big scheme" of direct interaction with the product developers and, additionally, that issues like this one might already have been seen multiple times and a solution proclaimed in the sense of a small FAQ like "Kaspersky and Emsisoft and vice versa do not match as a combined installation because of ... and due to ...". THAT would be really helpful in my opinion. And, finally, I do not see any such "behaviour" from Kaspersky's side, there are no CPU percentage rises or unending scans. Not a single time while Emsisoft has been installed and running.
  10. What do you *exactly* mean by "excluding"? You mean the directories where an anti-malware product stores its files (Program Files, ProgramData, %AppData%\Local, %AppData%\Roaming, etc.)?
  11. Yes, I have seen that, the same holds true for most other products I have ever been using so far (Kaspersky, Bitdefender, etc.). I have physical access to these "repositories" and can at least view what has been identified as "material to be quarantined" for both Emsisoft and Kaspersky.
  12. Well, the restarting process happened automatically after the first active termination of Emsisoft Protection Service via Windows TaskManager. I actually experienced the same behaviour as described before tonight another time, and it took me three of these terminations before the process was terminated for good (maybe I was too impatient and clicking once would have been enough) and I then, the process had been killed from the list displayed by Windows TaskManager, had to restart Emsisoft Protection Service manually which resulted in the same high CPU percentage and required to be terminated again which resulted in another process killing. After the second manual restart of Emsisoft Protection Service it "behaved" quite normal again until now.
  13. Yes, it's Windows File History. I have steered it toward saving data into the external Drive F: (which has still 135 GB space from 4 TB). It is, however, very rare that I see it at all, and I have never seen it before in this combination of appearance - nevertheless, I will take a look at it with ProcMon, too. But no longer tonight. Time to hit the sack. Good night and thank you for your efforts.
  14. Further not really interesting i<details are delivered by the Microsoft Windows Event Log Detail when looking for "Emsisoft" under "Windows Protocols" -> "System" The translation into English goes like this: "The service 'Emsisoft Protection Service' had to be terminated unexpectedly. This has happened already 1 times. The following correctional measures are being carried out within 0 milliseconds: Restart of the Service." This is the only evidence that there had been "something".
  15. Oh, sorry, I have given you improper information: The Kaspersky Total Internet Protection 2020 Quarantine is excluded from scanning (but not the other way round): I do see, though, that there is Drive F:. This is an external 4 TB drive which I excluded here as I am using it constantly for backup processes (new and incremental every day, one complete backup once a week, and one image creation job of C:\ also once a week). Could that actually play a role although I have excluded the entire drive here?