Jump to content

Pluto

Honorary Members
  • Posts

    66
  • Joined

  • Last visited

Posts posted by Pluto

  1. As part of my license, I have MB 3.11.1 for Android, running under Android 12 on my OnePlus Nord.

    Now I appreciate that you may not be the true "owner" of this problem, but since changing the phone from Android 11 to 12 the phone moans, periodically, that MB is using power in the background and wants me to "optimize" the battery settings for that app. Now we all know that the scanning etc. does consume some juice and I am not, for one moment, suggesting that MB is being too profligate with power, but I cannot find a way of stopping the periodic moaning originating from the Android system.

    Any thoughts about where to go / what to do with this one?

  2. 4 minutes ago, Porthos said:

    I believe they're encrypted as they are entered. It is to keep other process from adding exclusions

    That makes sense, but it can't be that difficult to provide a tool to convert the settings to something portable for export, with red flashing lights and alarm bells to warn the user to delete this information after it has served its purpose.

  3. 3 minutes ago, Porthos said:

    If you would like to help us figure out why this happened to you...

    Much as I would like to take up the offer, I'm too busy at the moment. So as long as this remains a one-off incident, I'm happy to file it under “just one of those things”. I certainly don't disagree with your philosophy of using Windows Defender as well as…

    I did take a few minutes to look at the system event logs from around this time and I am reminded that it was about then that a system update (KB4023057) went in. So it's just as likely that the fault lies there as anything to do with MB. As I said, as long as it doesn't become a habit, I'm content to move on.

  4. Just now, Porthos said:

    …the built in uninstaller is supposed to remove it and all the settings.

    Fair enough, although a more sensible (and more typical) convention would be for a simple uninstall to retain settings unless the user specifically opts otherwise viz.

    1. Delete user settings except license number
    2. Delete user settings including license number
    3. Retain all user data (i.e. perform a remedial install)

    It certainly would be useful to have the ability to save settings in a single, simple file so that complicated exclusion lists and the like could be easily transferred from one machine to another.

  5. 3 hours ago, Firefox said:

     a simple reboot may have helped your issue.... (of course I am assuming you did not reboot).

    I did In fact, but it made no difference. This required the old tried and tested uninstall, reinstall approach which, I have to note, did not preserve all my existing settings. Please don't ask which ones it kept and which it did not [although I recall it did not retain the display theme] because I didn't have the time to stop and make notes; I merely had to get the job done as quickly as possible. It did retain important stuff like my license number but the reinstall process was not 100% painless which it would have been had all the settings been preserved.

  6. OK -- uninstall, reboot, reinstall, reboot appears to have restored Windows 10's ability to accept MB as a valid security system.

    BUT, and I'm really unsure of the relevance of this, despite having the "beta" switch enabled, at this moment MB only updates as far as 4.5.8.191 / 1.0.54492 / 1.0.1666.

    So we'll see how things progress and I'll report back.

  7. Possibly since updating to current beta edition (4.5.9.198 / 1.0.54490 / 1.0.1672), I cannot persuade Windows 10 21H2 to accept MB as the de facto security software. MB itself seems happy enough and is showing all the right indicators but Windows Security Centre / Security Providers appears not to acknowledge the existence of MB as an alternative.

    Your thoughts and advice please.

  8. 14 hours ago, Firefox said:

    Personally I would prefer per session, once you exit out of GUI

    I tend to agree, provided the logic of “what constitutes a session” is correct i.e. a GUI session, commencing at the point when the full MB GUI becomes visible and ending when the GUI is closed or, perhaps, minimized.

    I think an element of timer is necessary just in case the GUI is left open on the screen. If the interface is devoid of activity, the password ought to time out after a few minutes.

    Anyway, I dare say the MB back office folks now have a handle on what's required and will come up with something!

  9. 4 hours ago, ChuckOp said:

    What about a timed approached?

    Well, I thought that was what I was suggesting when I said...

    On 8/8/2021 at 7:50 PM, Pluto said:

    make a successful password entry last for, say, 1/2/3 minutes...

    Perhaps make this time user-configurable. Sorry to answer questions with questions but when you say...

    4 hours ago, ChuckOp said:

    maybe it's per-session; entering the password unlocked the settings for the duration of the mbam.exe (main UI) session

    It depends exactly what you mean by a “session“. If this means ‘until the next reboot’ then no, as (in my case) this can sometimes mean several days. Does a “session” terminate at a logout? Or when the machine enters a sleep state? Unless you can nail this down precisely, then I would say this is not the way to go.

    Personally, I'm inclined to favour the "while the main interface remains visible” approach. Assume the MB service is happily running and no interface is visible apart from the M symbol in the notification area i.e. a standard, normal startup. The password is demanded the moment one of the ticked options is called. At that stage, the password remains valid until the interface is put away i.e. the top right × is pressed. I'm not sure if that covers it totally, but think that approach would be a good start.

    Also, a timer element along the lines of the password validity never lasting more than n minutes between an event that demands the password and a subsequent such event – i.e. the password is demanded, it is given, I do whatever I wanted then leave my desk. At that point, the password remains valid for n minutes. If I return to the desk and then switch to another passworded operation within less than n minutes, I am not bothered for a further password entry.

    Just to explain that another way: a successful password entry sets a timer running n minutes to extinction. Switching the interface to another password-protected operation before n minutes have elapsed resets the timer back to n minutes. But If the timer is not reset before n minutes elapses (i.e. I have gone away, got distracted etc.), the password is again demanded when a protected operation is called. But at any stage, pressing × causes the timer to go immediately extinct so the next password-protected event will demand the password.

    Hope that all makes reasonable sense.

  10. Requiring a password to alter settings; good in principle. However, how many times do you need to ask for the password? I understand how the tree and check-box structure within "manage access" permits the user to choose which areas should be password protected but, for example, do you really need to keep asking for the password when flipping from tab to tab within "settings"?

    I think you ought to decide upon a scope of validity for a successful password entry and settle for that. For example, make a successful password entry last for, say, 1/2/3 minutes or while the interface remains visible (i.e. not minimized). Right now, the repeated demands for a password will cause users to disable the need for passwords, and that will be counter-productive.

    ALSO

    The need for a password when disabling individual protections is understandable. But do you really need a password when re-enabling those protections?

    • Like 1
  11. Preliminary tests confirm that access to network printers functions as expected following installation of 4.3.0.98 / 1.0.1130.

    It is worth noting that while this update did not demand a Windows restart (on my Win 10 machine), such was necessary for the visibility of network printers problem to be fixed.

    Well done and thanks to all who participated in locating and fixing this rather obscure set of problems; let's hope that we can now move on from this tedious issue!

    • Like 3
  12. The fact that you have said

    13 hours ago, AdvancedSetup said:

    We do hope to have another build soon to address this issue

    is an excellent sign; as I might have stated earlier, with a slightly knotty bug/issue the biggest problem from a user's standpoint is, very often, getting a developer to accept the bona fides of the problem!

    Malwarebytes has a quality reputation and it's reassuring to experience that attitude first hand.

    • Like 1
  13. An update that might throw more light on this issue. It appears that SNMP cannot be disabled on either of my printers, so I tried another avenue: select Printer Properties / Ports / Configure Port. There is a check box called SNMP Status Enabled. UNchecking this resolves the problem with MB Web Protection but it prevents Windows (and thereby, any applications running thereon) from detecting whether the printer is on or not. I don't quite understand this because most Windows systems (mine included) do not have the SNMP protocol enabled by default.

    So this is, at best, a not-entirely-satisfactory workaround. Bear in mind that there is a considerable timeout between setting up whatever you are testing, and the printer disappearing (or not). As such, it is likely that this problem is rather more widespread among your users than they themselves might realise.

  14. OK – I'm afraid this one is still running, and it seems to be along entirely the same lines as the earlier NAS issue. I have done a clean reinstall as asked earlier and can add the following, which is critical to you being able to reproduce the problem. I have two network printers, an old HP LaserJet and a Xerox Phaser 7500, each having a stable IP address on the LAN.

    With Web Protection disabled, all is well. When Web Protection is re-enabled, after about 8 minutes the printers appear to go offline – they "grey out" in the "devices and printers" window. Before the point at which they go offline, they remain useable but printing something does not seem to reset any counters – the printers become unavailable when the original 8 minutes (approx.) expires.

    But let's get back to the crux of the matter – disable Web Protection and all the printers become available within a few seconds.

  15. OK – your message gave me a hint of something to try; sundry protocols were disabled on the printer (SSDP, IPSec, which have been disabled for six or seven years although SNMP has been enabled all along) and re-enabling them has, so far, cleared the issue. Does this make sense? Is the print communication now defaulting to a more secure state with which MB web protection is happier?

    I have been using this configuration on the printer unchanged for quite a time (see above) and clearly, something has changed fairy recently but because I seldom print to paper these days, I cannot really say with any accuracy when this issue first arose.

    Let's see how it goes for a while; I'm sure others will report their experience in this respect.

    Thanks.

  16. Following on the from the resolved local NAS issue, I have another that sounds very similar. It has not come to light sooner because I do very little printing right now. I use a network attached printer on the same network as my NAS. It seems that following a system restart, Windows will not send data to the printer (which remains visible in the print job queue) until I disable, you guessed it, our old pal Web Protection.

    This is so very similar to the inaccessible NAS mystery that it simply has to be related. Could someone please go through the appropriate code and see what's going on. Despite the discussion we had earlier on the subject, I am concerned that traffic which begins and ends on my own local network is being blocked. FWIW my printers are configured to use port 9100, presumably using the AppSocket protocol.

  17. Many thanks to MB staff for persevering with this one. At one point it seemed as though the (then) offered solution worked for most, but not me! But it does appear that the true culprit has now been dealt with.

    Bravissimo!

    • Like 1
    • Thanks 2
  18. Here are the gathered logs from my Windows 7 machine, showing identical symptoms, which should be a whole lot simpler to interpret than my Windows 10 unit. I can confirm that following this re-install process, merely disabling Web Protection causes the NAS device to snap back to visibility (and accessibility) within a few seconds.

    What follows possibly confuses and frustrates your attempts to pin this down:

    Having disabled web protection to access the NAS, on subsequent re-enabling of web protection the NAS remains accessible for a considerable time (?5, 10 minutes). What does seem highly consistent, after rebooting with full MB protection enabled, is that the NAS is not visible until web protection is disabled.

    As before, please delete this upload after you have retrieved it. Thanks.

     

  19. Thanks for the confirmation Max; it's slightly reassuring that I'm not the only one.

    But you having mentioned it, I might as well admit that I experienced the same pattern of events. It appeared to have fixed the problem for me following the update but subsequently, status quo ante.

    I didn't mention that on account of the fact that it felt like an oddity, but you having experienced exactly the same oddity might be useful information for the back office who are, no doubt, currently tearing their hair out on this one!

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.