• Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by JeremyNicoll

  1. No, the screenshots are fine.    You asked " ... to remove from the settings of the EAM Behavior Blocker what has been proposed and how" ...

    I think that if that is possible, it should be something that Emsi tell you how to do, but they should not change BB so that other people don't see the BB messages.   Other people, and certainly me, will want to know if powershell has been disabled IF IT WASN'T DONE BY THEM.


  2. @Amigo-A   " Therefore, the verdict should be unambiguous - delete all pre-installed programs without a doubt. "     I disagree.   /Some/ of the vendor-installed programs are necessary.  Eg on several of my Samsung laptops, those programs include the logic to make the Fn+F2 (etc) buttons perform their ancilliary functions.  Another of the programs is one that offers and installs updates to that program and others.    

    If I get rid of the latter program, how do I get updates/fixes for the first program I mentioned?  

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

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

  5. 6 hours ago, Ken1943 said:

    In My.Emsisoft your license shows. The three horizontal lines to the right of each license has an option to cancel auto renew. Just checked my license and it was set to auto renew and got confirmation when I changed it. Checking dates I found the date of when the license was renewed.

    The information is there, you just have to look. It does not say "license ends on xx/xx/xxxx.

    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.

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

    • Thanks 1

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




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

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

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

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


  12. I see that Christian's announcement of the restart thing does not say what you said above.  He has

    "Many of our customers have requested an option to schedule required restarts to times when the computer is not being actively used. Based on this feedback, we’ve added a new setting that allows you to define time frames for restarts (e.g. allow restarts between 2:00 a.m. and 4:00 a.m.). The computer will not restart if it is being used."

    That last sentence is NOT the behaviour you described above.   So, did it get changed after my comments or is his statement wrong?

    Also, in that paragraph he mentions 2am - 4am, but the screenshot that accompanies it shows (a surprising) 2/pm/ to 4am definition.   That might confuse someone.   Also, has anyone checked that the code does support a cross-midnight interval definition like the (presumably unintended) screenshot example?


    Also... in the main screenshot in Christian's article, there's a field title that says   "Operation system".   Surely that should be "Operating system"?

  13. > I haven't heard anything new about it, however I normally wouldn't unless  ...

    You say this quite often.  It strikes me as most peculiar.    /Surely/ any problem reported to Emsisoft gets logged somewhere, not written on the back of an envelope and stuffed under a sofa cushion?   Why on earth wouldn't you then have access to that system?   And why wouldn't the developers also record notes on fixing & testing the solution on the same system - even if it's just a list of the relevant commits?   How else do the developers track what they change, and keep on top of changes that might be in conflict with each other?   I'd expect every bug and request-for-enhancement to have its own number in such a system, and product source to include that in comments when things are changed.   I'd describe that as standard practice.  Even sole-developers do it.        

  14. > This option mainly will be used by enterprise users

    Possibly, but it's there in Settings where anyone might turn it on even if they don't fully understand what it will do and when.


    > We did not add the silent mode parameter  ... to avoid that remote devices would not reboot when a screensaver or similar thing that triggers silent mode, is blocking the set restart.

    Parameter?     The point I'm trying to make is that no matter what your intention is, in some situations the interaction between silent mode and auto restart may take people by surprise. You can mitigate that by explaining the relationship properly.

    It might be better handled by allowing adminstrators, concerned with update of remote machines, to prevent them from going into silent mode in the first place.

    Silent mode after all affects anyone who is in it because they're playing a game or watching a video or whatever, not just people who intentionally turn it on.


    Something else:  anywhere in the GUI where one can see tooltips for the icons that are arranged down the lefthand edge:  in almost all cases the tooltip tells people what they will achieve by clicking the icon.  But for silent mode, the exact opposite is the case.  When I'm in "Normal mode" the tooltip says "Silent mode OFF".  But that's its current status not what clicking it will do (and the reverse applies too).  The text should say something like "Silent mode is OFF; click here to turn it ON" which is unambiguous.


  15. Thank-you.

    In Settings - Updates, if this option is not ticked (which I hope will remain the default, so as not to surprise anyone), the tooltip over the "i" works, but the text in it adds no information,
    saying just "Enables automatic device restart".  It should say something like "Allows you to choose if/when EAM will automatically restart after an update which requires a restart."

    If (with this still not ticked) you click on Edit, the "i" tooltips inside the sub-pane do not display anything unless you actually enable the option at the top of the sub-pane first.

    It says (of "Restart only if device is idle") that "idle"  means "no mouse or keyboard activity".   If that's true, then I think you need to add another condition - that EAM is not running in Auto-Silent mode.   Someone watching a film or playing a game would not want the machine to do an unannounced restart.