Jump to content

hapless

Honorary Members
  • Posts

    24
  • Joined

  • Last visited

Reputation

0 Neutral
  1. It's a bug. If I'm wrong, I'll personally chew off my right arm. I'm sure they'll fix it soon.
  2. I'm having this same issue. We all just reinstalled MBAM, of course, because a new version was just released. And we all just encountered this problem. What are the chances that all of our installations got messed up during the original install, and that a reinstall will help? (That's rhetorical.) In any case, my own log files are attached. To other forum members: Be advised that these log files contain user names, your computer name, many directory paths (e.g. your Firefox profile path), a list of every browser extension and search plugin you have, HOSTS file entries, some details regarding your MBAM settings (including specific domain exclusions), and so on. Just an FYI, not an alarm. Also, the Farbar utility creates a "FRST" directory under the root, which is left behind afterward. FRST.txt Addition.txt CheckResults.txt
  3. Hah, I know why. I'm sure it happened to others, but it's not like everyone will notice during the short timeframe this happened in, or come here to post even if they do notice.
  4. I had the same thing just happen, but it had nothing to do with some other software scanning. Coincidence? Could be, but I think it was a bad update. I could not enable malicious website protection. Rebooted, still could not enable it. Came here, saw someone else just had the same issue. Updated databases, and suddenly, malicious website protection can start once again.
  5. Interesting. So it seems that in order to exclude a registry key under these circumstances, you have to: 1. Reboot, for no real reason (so MBAM can go into its hardcore mode, yes I know how it changes its image path and driver settings), all to delete a couple registry keys that aren't locked in the first place. 2. Restore the registry keys from MBAM. 3. Change the PUM setting to warn rather than treat as malware. 4. Scan. 5. Let MBAM detect the harmless registry keys once again. 6. Tell MBAM to exclude the registry keys.
  6. Yes, I know I can further neuter MBAM by turning off PUM detection, but I've already had to disable some other features due to bugs, and I don't want to keep turning things off.
  7. This is not a file detection; it is a FP of a "Security.Hijack" type. I just updated to EMET 5.0. MBAM keeps going into hardcore mode over a couple registry keys created by EMET: HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS\jusched.exe HKLM\SOFTWARE\WOW6432NODE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS\jusched.exe I don't see any way to exclude these keys from being detected. I have not tried excluding the file (jusched.exe), but in any case, I thought it might be a good idea to post this. fp-jusched.txt
  8. Thank you. I don't have the time or energy to search down all these separate posts and threads. I got upset when I thought my posts had been deleted, and was glad to find they had been moved instead. The events may be expected, but they are undesirable. They represent constant writing to my SSD, and they fill the event log and make it harder to find entries I actually care about. The problem is that if the MBAM team is saying "Just ignore them; they don't matter", the flip side of that coin is "If they don't matter, then don't write them to the log in the first place!" Normally, constant log bombardment would be something you would see only in betas or during explicit debug use. But hey, it's been years since I programmed so what do I know?
  9. I disabled MBAM's self protection, and no longer get these messages filling my event logs. Any hope at a fix? Or ... what do I ("we", since I'm not the only one having this issue, as we've seen) need to do to get heard?
  10. You've simply repeated yourself. You mention a policy; I asked where I may read this policy. I agree with malbilling that it generally makes more sense to keep related posts in their proper threads. But I will abide by policy of course, if there actually is one. I am dubious here because normally (i.e. in the vast majority of forums out there), a forum participant gets chastened for precisely the opposite behavior--opening separate threads for existing issues.
  11. Where is the "one user per topic" policy outlined? I don't see forum rules anywhere, and I usually remember to check for these things. I'm also fairly certain that this will indeed prove to be a single issue. And I resent having to decide between disabling self-protection and wear-and-tear on my SSD caused by constant unnecessary log writes.
  12. Funny no one chimed in when two of us reported issues with MBAM filling our event logs... I'll just disable PUP detection. Thanks.
  13. I have Flux installed. Just now, MBAM started detecting Flux as a PUP (as "PUP.Optional.Flux.A"). As far as I know, Flux does nothing untoward, is not spyware, or anything else. Why would it be listed as a PUP?
  14. I was wrong about it always saying "C0000022". Today it started with "C000000D": Mbamchameleon Failed to obtain file name information - C000000D I'm sure it will be something else soon as well. In other threads, someone advised disabling "auto protect" under "advanced options". I think that person was referring to MBAM's self-protection feature. That will probably work, since mbamchameleon is used for self-protection (it seems), but we should not have to disable an important security feature to work around this.
  15. I get these errors as well, except mine all seem to be of one type: Mbamchameleon Failed to obtain file name information - C0000022 The errors appear sometimes twice at the same time (i.e. during the same 1s interval), and sometimes 1 - 3 minute(s) apart, to the second. I am running MBAM Premium 2.0.2.1012 on Windows 8.1 Pro x64.
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.