Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About robertleeblairjr

  • Rank
    New Member
  1. This thread is not devoted to your curiosity about MacKeeper and whether to use that software. But, it's garbage and has had a bad history with its business model. Either way, create your own thread for these inquiries.
  2. The directory com.apple.xpc.launchd contains *.plist files that will contain entries for disabled daemons for different users. The location of the directory is '/private/var/db/com.apple.xpc.launchd/'. You can determine the numeric code for your User ID by entering the command 'id' in terminal. This will list the groups you're a member of, as well. So, the file '/private/var/db/com.apple.xpc.launchd/disabled.x.plist' whereby the "x" in 'disabled.x.plist' will be the User ID numeric code and is used for disabling the launching of daemons. Check the disabled files for any entries, which are in p
  3. I would suggest for you to perform a manual search for Malwareybtes created files and remove them or use another third-party application to search for the files for removal. You could use this program, EtreCheck, that's recommended by many users on the Apple Communities support site.
  4. BTW. Is this the actual installed OS and not a virtualization of the OS? The initial errors in the sample maybe related to the touch control interface and I can't say that this doesn't cause a conflict. Change the the touch bar strip to "Expanded Control Strip" to test the app. This feature should resort to just the static function buttons; ie F1, F2, etc. I would suggest going, as far as, changing the function of the touch bar strip, uninstalling Malwarebytes with the uninstaller, removing any files created by Malwarebytes under /Library/, rebooting, and reinstalling Malwarebytes. If this doe
  5. Select the 'RTProtectionDaemon' process under the memory tab and select the "i" tab to display information related to this process which will open in another window. From this window, select "Sample" which will open another window. Alternatively, the drop down menu with the sprocket has the same command to perform a 'Sample Process' of the highlighted running process. This command will take some time to perform iterations on this before it dumps a sample text in the window which you can save to a text file for uploading to the thread. I've attached a sample text of the 'RTProtectionDaemon' pro
  6. Open the "Activity Monitor" program. Is the 'RTProtectionDaemon' process active in the memory tab? Which OS version are you currently using and is it being booted from the internal drive? Are you using any other anti-malware, anti-virus, or app monitoring programs which would restrict the process from being launched by root?
  7. I DGAF if you appreciate any complaint I've made. When you get off the tip, then I've got one lined up for you to slob on. You can't confirm nor deny the vast number of people that are "actually" affected by this bug which doesn't target a small number of users. Why? Because statistically, unless you have a large enough and randomly selected sample size to mimic the population, then it's inaccurate to deduce there's a correlation to warrant an immediate repair. However, if it had been properly tested or if there were not enough resources allocated to support initial release bugs, then the rele
  8. I am curious as to if there's a correlation to the 'RTProtectionDaemon' process virtual memory size and the leaking of real memory. The current virtual memory size of 'RTProtectionDaemon' is approximately 2.5 GB, even though, the real memory use is less than 50 MB after I disabled Real-Time Protection. However, the increase in real memory size used by the process appears to reach virtual size. However, I killed the process before allowing it to go beyond 2 GB.
  9. This can be caused by the 'RTProtectionDaemon' process being disabled and not actively persistent in memory, not present in the install, was corrupted, third-party program conflict, etc. It's possible that the problem is caused by another component of the Malwarebytes program. I can mimic this exact problem whenever disabling the load and persistence of 'RTProtectionDaemon' process by 'launchd'. I don't like the developer's choice to make the Malwarebytes GUI dependent upon 'RTProtectionDaemon' process being active since it's primary function is Real-Time Protection, which is a service compone
  10. Remove the dependency of the Malwareybytes GUI being inoperable if RTProtectionDaemon is not persistent in memory. Perhaps, allow the program to not require this persistence once the model transitions to Free from Trial or Premium. I realize that this maybe a security feature for other potential programs' malicious intent to disable the Real-Time Protection feature but this was not a necessary feature of previous versions 1.x. Now that there's a subscription model for this program, this feature wouldn't be necessary for those users who choose to use manual scan/update and use only those featur
  11. Step two has a missing reference in the command. "2. Issue the commands 'sudo launchctl disable system/Library/LaunchDaemons/com.malwarebytes.mbam.rtprotection.daemon.plist'" Caution: This will render the Real-Time Protection service component of Malwarebytes inoperable. This will be persistent after reboots/shutdowns and updates to the program. To reverse the operation then issue the commands in steps 2 & 3 by replacing 'disable' and 'unload' with 'enable' and 'load' respectively. Warning: Malwarebytes GUI will become inoperable because of the reliance upon this background servi
  12. Can't blame you. It's not very impressive that a company allows a known bug which cripples the one feature of their program and is the foundation of their subscription model to exist this length of time with no intentions of repairing it for at least another month. It's apparent that lack of proper testing was conducted on the program before the initial release because of it existing on multiple OS versions and hardware platforms. I would suggest that you can disable Real-Time Protection and kill the running RTProtectionDaemon process. You can disable the daemon from launching and residing in
  13. This must be the thread for useless posts. Great work on previous versions of Malwarebytes 1.x. However, I'm less impressed with the speed by which the developers issued an update to repair the one component of the program that the company is planning on people to purchase a subscription. Version 3.x still has an RTProtectionDaemon memory handling problem. The update to fix this bug won't be released until greater than 30 days since the initial reports of this malfunction. This problem is reported to affect multiple OS versions and platforms which leads me to speculate that there wasn't p
  14. I just read an Apple Support page that references the changes to kernel extensions. Apple is not removing or eliminating support for third-party kernel extensions but are introducing a new feature called "User Approved Kernel Extension Loading". https://support.apple.com/en-us/HT208019 The feature which is described as being a secure kernel extension loading procedure is described in more detail on the Apple Developer site. https://developer.apple.com/library/content/technotes/tn2459/_index.html#//apple_ref/doc/uid/DTS40017658
  15. RTProtectionDaemon grew to almost 2GB within 24 hours of performing a clean installation, not an upgrade, with the latest version, The developers are aware of the problem and/or know the program bug to squash with an update. However, it's yet to be seen that this is a priority for them to have a steadfast release. This is according to a staff member on this board who stated that the bug would not be resolved with an update until sometime in September.
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.