Jump to content

bitsum

Members
  • Posts

    18
  • Joined

  • Last visited

Reputation

0 Neutral

Recent Profile Visitors

796 profile views
  1. It is no problem, and since there was a former incompatibility, it was prudent to ask about. Certainly the user should try w/o Process Lasso, to be safe. It just doesn't operate near any of this disk-level or file-system stuff, and the prior GUI (only) bug was fixed in absoluteness, so I'm pretty confident on it - but to be 100% would be arrogance, so don't take anything off the table.
  2. The compatibility issue with Process Lasso and MB Anti-Ransomware (the only known problem) was fixed many months ago and will not return. We also do no hooking at this file-system or device layer, so are doing nothing in that area. Analysis of the issue did show that MB Anti-Ransomware has a relatively 'heavy' footprint on some of it's low-level hooks. Now, Process Lasso (again, this is no longer the case), was calling OpenThread with an unusually high frequency, but not an absurd frequency, the CPU should have been able to handle it. Still, that was fixed. We literally do not call that API anymore, gathering the thread status from prior enumerated information we have. What I am saying is that if Process Lasso had this issue, then other software might. I mean, if an app performs great in a virgin system, a developer passes it on... but then if MBARW is installed and the performance changes, then, well, surprise! Again, Process Lasso's issue was resolved months ago, and if any evidence exist of an issue with it an MBARW, I would love to hear more (because we test with it now). I am saying this so nobody assumes this user's use of Process Lasso is the issue. As he shows, the issue goes away with Process Lasso continuing to run. p.s. Thanks for being a Process Lasso user
  3. I am happy to report that this issue has been resolved as of Process Lasso v8.9.8.48. I traced it to a high frequency of OpenThread API calls by the Process Lasso GUI. These are normally benign and quickly handled, but the extra scrutiny by MBARW resulted in this excessive CPU use. To be fair to MB, the frequency of calls was very high, and probably won't be seen in other contexts. I was able to rewrite the affected code to do 0 API calls and achieve the same function (it was some really old code from 10+ years ago, which is why it took a profiling session for me to see it). I apologize for not fixing it sooner, but we weren't initially able to reproduce the trouble, curiously. Perhaps we didn't try or look hard enough :o. Anyway, I got to it in time and now Process Lasso will have far fewer security software issues in general. Thank you all for your patience. Now you can have both security of your choice and Process Lasso. Note that this fix is being pushed out today to our new ProBalance Stand-Alone product (in alpha) and Process Lasso v9 (also in alpha), though only the latter had any real issue. I have attached a profile image just to show this in a more visual fashion...
  4. Thanks Ed! Indeed, this was an important discovery. I traced the CPU usage to a frequent OpenThread API call that (apparently) MBARW hooks at some level, and resolved it by removing the affected code and replacing it was superior code that didn't need any API calls. Really, nobody is to blame. We had a high frequency of OpenThread calls, but it never mattered on systems where no hooks are inspecting these calls. Likewise, security software is doing it's best to keep the system safe, so has to watch everything, thus the inherit overhead. Though, as I always say, although you should not run w/o security software, there is no replacing common sense when it comes to safety! This boosts the performance of Process Lasso with any security security software that is hooking the OpenThread API. We've confirmed the fix, and if the prior topic was re-opened, could state such there so everyone has a final resolution. @Mods? Attached is the final profiling image where I discovered the issue.
  5. @Decrypterfixer I agree that resource constraints (too much paging activity?) is possible, as nobody has reproduced this yet. However, I'm not convinced to dismiss it at that. As for troubles with other security software, that is due to their 'tamper-detection' methods and their infinite, repetitive logging of redundant access attempts to their processes. That does not seem to be the case here. I apologize for suggesting MBAR injects hooks all over the system, so can you tell us what it does do? This was an assumption on my part based on available data. Is there a file system filter driver? Thanks
  6. I got a notification of what, I suppose, is now a deleted post. To answer the question posed there: What they meant by 'make sure it is an administrator account' is simply that you login as a non-limited user. That is, one who is a member of the administrator GROUP. For 99% of home PCs, that should be your usual user account. Now, for applications that need to use administrative rights, you do need to allow such by using the 'Run As Administrator', or responding to it's prompt in the case of an existing manifest for that application that specifies Admin rights are required. Don't go hacking anything to unhide the built-in Win7 administrator account!
  7. @Homer712: As I've written, we've been unable to reproduce the problem at Bitsum. Of course, the issue is definitely not with our code, though apparently something doesn't interoperate well with MBAR in some cases. Do you have any other security software installed on this PC? Apologies if I ask questions you've already answered... Thanks
  8. We are also tracking this at the this Bitsum Forum Thread (I linked to this MB thread from there, and now vice-versa). I hope affected users can help me find the difference between our test bed(s) and their systems, then we can either find/develop a work-around, or pass this knowledge to MB developers. It could be another MB product is the culprit. Are there any others I should install?
  9. I set up a fresh test bed using Windows 7 x64 Ultimate /w SP1. I downloaded and installed MBAR Beta. I downloaded and installed Process Lasso. No problems seen. No excessive resource consumption. Rebooted. Still no problems. Installed MalwareBytes Anti-Malware as well. Still no problems. I will give Windows 10 a try as well, but Ed has already tested there. Thus, my next question to anyone seeing this: Have you updated to the latest versions of all products (MB and Lasso)? If so, there must be a third factor...
  10. This is under investigation. The fact that the CPU utilization appears within ProcessLasso.exe's instance does not mean it 'comes from' Process Lasso, as odd as that may sound. That is because MBARW hooks are present in that process's context. I, the author of Process Lasso, am investigating this issue to determine if there is anything I can do on this end, or if there is any guidance I can give MalwareBytes. It would be helpful for a developer on their end to engage in this as well. I'm certain that if this interoperability issue exists within Process Lasso, then it surely does in other applications as well. As for what can be done in the interim... It's possible, though not proven, that disabling the 'Process Icons' in the View menu of Process Lasso's GUI can mitigate the problem. This reduces disk accesses, which may be what MBARW is getting hung up on. If all else fails, you can set the Process Lasso GUI to start manually, since the core engine (processgovernor.exe) does all the rule enforcement. The system tray icon won't be present in this configuration, but Process Lasso's real-time optimization and automation algorithms will all be active. This thread should be merged with the other I suppose.
  11. Thanks! I'll set up a test bed, and have Ed (our QA guy) keep an eye on this as well. If I can do something (within reason), then I will. However, when an application (MBAR) injects so many hooks all over the system to intercept activity, the burden to retain proper system functionality really is with *that* application. Process Lasso, by contrast, does not inject any hooks outside it's application, so it's entirely self-contained. If MB developers would like to move this to a private conversation, please email jeremy@bitsum.com .
  12. I am the author of Process Lasso. I was notified of this interoperability issue by users a while back. Please, I do not mean to sound confrontational, but: Am I clear that your position is that you develop software that injects hooks all over the system, changing the performance characteristics of the OS and all running applications, then blame the other applications for any problems? Now, if there is anything I can do to mitigate this issue, please let me know. However, I need to understand the nature of the issue, and haven't yet had time to ferret it out. Could we cooperate, as opposed to passing the buck? Thanks!
  13. I really appreciate you taking this matter seriously and apologize we haven't hit the source of the false positive yet. The user has not responded back (maybe scared away, I dunno). We DID have a report of the SAME detection name on our CPUEater Demo (which induces a high load to show off our ProBalance algorithm) by Clean.Mx, though VirusTotal doesn't show any false positive with MalwareBytes, only 3 of 63 scanners, and those 3 of low quality. Also, our digital signature and time-stamp is in-tact on both the following. https://bitsum.com/files/CPUEaterDist32.exe https://bitsum.com/files/CPUEaterDist64.exe If you could please check these LAST TWO, then I will get out of your hair, satisfied if there was a problem, it has been resolved, unless I hear from the user with more info, or get any other data. Thanks!
  14. Hi, Thanks for checking, and sorry no false positive was found in them. I will direct the user here and request logs. Since those were clean, it's *possible* it came from our auto-update module as well, which is definitely a likely false positive candidate since it's an SFX package: URLs: bitsum.com/files/auto/pl4sfx.exe bitsum.com/files/auto/64/pl4sfx.exe http://bitsum.com/files/auto/pl4sfx_server.exe http://bitsum.com/files/auto/64/pl4sfx_server.exe Thanks!
  15. User reported false positive on Process Lasso as 'trojan.agent.gen'. (no further details yet). Probably affected report builds: 32-bit Workstation - https://bitsum.com/files/processlassosetup32.exe 64-bit Workstation - https://bitsum.com/files/processlassosetup64.exe Ancillary builds possibly affected: 32-bit Server Edition - https://bitsum.com/files/server/processlassosetup.exe 32-bit Server Edition - https://bitsum.com/files/server/processlassosetup64.exe Domains: https://bitsum.com https://processlasso.bitsum.com Thank you for your prompt attention to this matter!
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.