JeremyNicoll

Interesting. Mostly - as I have the max display time for the slider set to 999 seconds - it's visible. It's rare for the slider to dismiss itself. Usually I click the X on it, and focus shifts. But (at the moment) focus isn't changing absolutely every time I click on the X... but often enough for me to notice that focus just changed .... again. I've not yet worked out if there's a pattern to the behaviour. I'm not well, almost always in bed, and the laptop is on a table-thing above the bed. If an update happens while I'm elsewhere - eg loo, kitchen - and dismisses itself, I probably wouldn't notice whether the focus had changed because by the time I return to bed, I'm unlikely to care about which program I was using earlier. But if I'm actually actively using a specific program and the slider pops out and I dismiss it and some other program's window pops to the front, I definitely notice that.

It went away for me though, then (I think) It came back, went again.. and had been absent for ages.

I'm seeing focus changes again (as in: https://support.emsisoft.com/topic/30648-window-focus-is-changing-after-dismissing-notification-pane ). Anyone else? It's been happening, I think, for a few days, but I've been quite sleepy, and only just realised it was happening again...

> even if you don't use the workspace functionality, my emsisoft allows you to manage ... The thing is, I already have to do all of that for every other software product I install, licence and pay for. So I already have my own way to do it. If every vendor invents their own extra system, each one is just one more thing to have to learn how to do - and (presumably) one more userid and password to have to maintain. I'm sure it's useful for corporate users, and maybe resellers, managing tens, or hundreds of users. I'm also a little curious about your statement: "allows you to view details of your current, and historic licences". If older licences were associated with email addresses I no longer use, how would their system associate them all with my current email address? Or is their system tracking users' machine ids? Somewhat contradicting myself, I seem to remember asking how they know in the first place and I think maybe I was told that users have to populate the "my emsisoft" thing with relevant data in the first place. If that's still the case and it's only telling you things you told it, it's hardly magic.

But no-one with only one or a handful of protected machines needs to be able to do that, surely?

That may be so, but I don't see much point in setting up "My Emsisoft" just for that. Does "My Emsisoft" provide any service that one actually needs? I've never used it.

Oddly, it does copy if you select it and press Ctrl-C... but not if - as you say - you right-click...

And... if you don't want the auto-subscription (many of us don't) you can get it changed back to one with an expiry date, by emailing [email protected] and asking them to make the change. I don't know yet whether we're all going to have to make that request every single year...

Malware scans look for files whose contents are known/suspected to indicate that they are malicious. On the other hand the Behaviour Blocker looks at what a program/file seems to be doing /once it is actually running/. A file can look innocent to a malware scan but once run do something that might be suspicious. In your case the BB is telling you that lots and lots of installs are being attempted. The BB alerts are all because a "hidden installation" is being attempted, that is, an "MSI" file (which is a standard Microsoft installer file) is being run. Maybe the file you downloaded was named "something.msi". If so, it is not itself executable, but is read and processed by the parts of Windows that understand MSI files. It looks as if either this particular .MSI file first unpacks itself to create many temporary files, named MSIxxxx.tmp, then uses those, or - as you say, maybe downloads a set of MSIxxxx.tmp file and uses them. Either way, the sheer quantity of them is - perhaps - dubious. If any program in Windows wants to create a temporary file - perhaps by unzipping or unpacking a container of files, (or by downloading some) - it is likely to put them in a folder whose purpose is to hold temporary files. Its name depends on the version of Windows you are running and your userid. It has a symbolic name TEMP (or %TEMP%) so that programs can refer to it without knowing what its full name is on your system. If you open a file explorer window, then put the caret in the file/folder-name area at the top (which looks a bit like a URL bar in a browser) and type %TEMP% and hit enter, the temporary files folder for your userid will be opened. On my W8.1 system, if my userid was Fred, it would be named: "C:\Users\Fred\AppData\Local\Temp" There are other temporary file folders in Windows... If an installer running under an Admin id (ie with UAC permission) creates temporary files they will probably be put in a different folder - a similar folder name but instead of the "Fred" but it'll be the Admin id's name there, eg "C:\Users\TheNameOfTheAdminId\AppData\Local\Temp". I am not sure that it's safe for you to try to exclude some folders from monitoring by the behaviour blocker; it might be a way to reduce or stop these alerts, but done incautiously it can also stop alerts coming from any malicious software that's also managed to come to roost in that folder - and it's a very likely folder for iffy things to end up in.

There's no reason to quarantine an installer that's installing stuff at your request (assuming you do trust the thing it is installing). The point about the BB is that it would spot installations (for other programs) being done that you didn't know about. What's not clear from your text is why so many separate installers are being run every few seconds. Or is it the same installer being attempted over & over again, where the thing arrived zipped up (or otherwise compressed) then unpacks & places the actual installer into a different MSIxxxx.tmp file each time? Then it runs that and the BB flags it because the rule created for the last one was for a differently named .tmp file? If the MSIxxxx.tmp files are being created in %TEMP% before being run, you could possibly exclude %TEMP% from monitoring... but that in my opinion is very unsafe because it would also mean any other installer, eg a malicious one, placed in %TEMP% would also be ignored. On the other hand, if the .tmp files are being placed in (for example) %TEMP%\ExpressVPN then you could exclude just that folder, which might help. You could experiment with excluding %TEMP% to see if an exclusion helps, but then only enable that exclusion when you're about to apply updates. Maybe the supplier could be asked to change the way their updates are packaged so that they don't all have random names.

> As I said before the only CPU user was Emsisoft at 96%, that is a bit extreme. I'm not disagreeing. Do you have any scheduled scans defined? EAM taking lots of cpu is not in itself unusual - Emsisoft designed the scanner part so it uses as much spare cpu as is available. If for example your machine has SSD(s) in it rather than spinning rust drives, I/O is very fast and thus - when doing a scan - the disks don't slow things down they way they used to do. The question though is whether a long-running scan could have been taking place. Does EAM's log show whether a scan (or anything else) was going on at the time? Also, even if EAM is doing a long-running scan, one might expect the OS to give other processes, eg your browser, an equal amount of cpu time. I don't now why that wouldn't happen. Something else that might affect that is how many cpu cores your machine has.

Glad things have improved. > I have the latest version, whatever that is, You can find out by clicking on "About", near the bottom right corner of the "Security Overview" screen. Bear in mind that our latest version might not be the same as other people here are on, because (a) some of us are using "Betas" ie things that have not yet been released to everyone else, and also (b) the updates don't get released to everyone spread across the world all at the same time. Maybe EAM was genuinely very busy. Despite the date being only the 4th of the month I noticed that Windows Update is offering updates today. One of those is a "Preview" of changes to .NET support. If you've just installed that, it's normal for Windows to do some cpu-intensive work soon afterwards - I think it recreates indexes or cross-reference info or something, whatever "rebuilding assemblies" means... And if that was happening there might have been lots of files being opened and EAM might have been suddenly busy. If it was that... there's something else to say though. Here (for W8.1), that .NET update is a "Preview" one, described in Windows Update as "optional". You might think that it's a good idea to install optional updates as well as "important" ones... but that's not so. In particular, the "Preview" versions of fixes are not meant to be installed by ordinary users. Microsoft aim them at software developers so they have a chance - a month or more before everyone else gets the update - to see if these updates introduce problems. If your version of W10 allows you to choose, you should opt out of automatic installs of Previews.

Who knows? Which version of EAM have you got? Which browser (and what version)? Which OS? Are you using the browser extension?

> Things aren't necessarily added to the system when they're reported. Especially with bug reports, since QA may have to check into them before a bug report is created. I can see how that might be... but maybe you could lobby QA so that they do add them ... with "unconfirmed" status? Then everyone who needs to would know that there was a hint of a problem in a particular area, and you and they would have one place to keep track of it? > Actually, Emsisoft is far better than others.... OMG! Maybe I was luckier than I realised with my past employer... Anyone technical could create problem records with as much or as little description as they liked. They could direct it to the attention of the team they thought would be most interested (or leave it 'floating' if they had no idea who should start looking at it, in which case people who ran the 'problem management' team would make that assessment.) In time, people from multiple teams would get involved and they'd all add information about what they'd found, what needed done, and the timescales. Everyone could read every team's contributions. Normally, no-one could go back and rewrite any entries to make a team or person seem to be blameless even if that's not what was first written... though I do recall once an outbreak of obscenity was removed. One could cross-reference between related issues. The same overall database system contained our change management stuff too, so planned changes were cross-referenced back to the related problems, and of course not a few problems were raised because of unintended effects of previous changes. OK, it was a bank. They could afford to spend money on doing this properly. And with many hundreds of technical staff there had to be somewhere to record all the details. Also, they'd been an early adopter of computer services - with their first system in the 1960s. They'd had plenty of time to learn that problem and change management systems needed to be good.

> I have access, however I don't generally know the issue numbers of bug reports and feature requests, which can make them difficult to find. Really? For reports that you have passed to QA, surely something in them should say that that info came from you. If it didn't then the date that you passed it, or the date that you know that someone else passed the info must narrow it down. In THIS case Batman said logs were sent on 19 Sept... But in general, not just this case, I get the strong impression that you pass info on to QA and there's not enough information coming back to you. QA (or whoever) should change their process so for every bit of info you pass to them, they reply to you with the ticket id (or whatever) of wherever they logged that information. I'm not saying that subsequently I expect them to tell you when fixes etc happen, but you should be able to search based on that ticket id (or whatever) to find out what's been done already or is going to be done, about that issue. I'm staggered that a professional software house are not already totally on top of this. Where I used to work, one of the teams I was in adopted new practices at one stage. We'd thought we were doing ok before that, but we started formally discussing all the planned changes we'd (all) worked on in the previous weeks, and how implementation actually went. Moreover we discussed what could have been done better. Over time, we experimented with new ways of running our own team workload... and guess what? Things improved. It was easier to train junior staff because we had standardised procedures. It mattered less which senior member of staff did the work for something, because we knew that everything that was a vital part of the process would definitely have been done rather than just, hopefully. Despite all of us in theory being experts, we implemented a "one person prepares a change, someone else checks it, and - ideally - the change is implemented by one of those two people (rather than whoever was scheduled to work that weekend)" work flow. And so the person at the sharp end at 3am Sun morning was already familiar with the details of the changes... It didn't always work - people would be sick and someone else step in at the last moment... but the net effect was better change control. And just as well - our team did OS support for a UK bank's mainframes. I'm telling you that because - although your situation is different - one of the important things we learned to do better was ... communicate better. Planned changes were numbered. Documentation was in a standard format (a tick-list, if you like) for certain types of change that were often done. Cross-checks between things that might affect each other were done in a standard way. The personn who checked that a change had been prepared properly checked that the documentation trail - change numbers, backout numbers, etc were all in sync. In your situation, long ago, I would have complained. If you "don't generally know the issue numbers of bug reports and feature requests," then it's time whoever runs QA gets that sorted out.