Jump to content


  • Content Count

  • Joined

  • Last visited

About RoyEarle

  • Rank
    New Member
  1. FYI: My original problem has gone away. One of your updates (or one of Microsoft's) has corrected the persistent failure. With ransomware protection on, if ".exe" files were copied to another location and excuted there and then deleted, once in a while some of the ".exe" files would acquire unchangeable "..." ownership and cause access failures for read, write, execute, or delete. This condition of the files was persistent, lasting until the next chkdsk or reboot. The persistant failure was present for the MB3 version (as originally installed 2017-09-21). The persistent failure was present in neither an updated version nor the newer version. So somewhere in there something fixed the original problem. Enabling ransomware protection does still create a minor problem: it sometimes causes delayed deletion of the ".exe" files. If you test for file existence ("if exist ...") immediately after the "erase" command you will occasionally see ".exe" files still present. But a few batch file lines later the ".exe" files will be gone. (This has evidently been a problem in Windows under some conditions for many years according to my internet research.) The persistent failures were disruptive, but the transient delayed erasure problem is noticed only by the diagnostic. I do not know if the transient failure has been present all along; I had to modify the diagnostic to detect it. It may have been hidden by the persistent failures. The persistent failure could be seen in tens of iterations; the transient failures now occur only a few times in a thousand iterations (16 minutes). Both the old persistent and the (possibly) new transient failures appear only when MB3 ransomware protection has been on since boot time. Failures can be seen until you turn off ransomware protection. If you then turn it back on again without rebooting there will still be no failures until after the next computer restart. The bottom line is that I can now leave ransomware protection turned on almost all of the time. That makes me feel much safer. Roy Earle
  2. MB3 Ransomware Protection corrupts ownership of deleted executed files PROBLEM ------- With Ransomware Protection enabled in Malwarebytes 3, if (1) an ".exe" file is copied, (2) the copy is executed, (3) the copy is deleted, then the deletion attempt sometimes fails to delete the file and leaves it with its ownership undisplayable. Any further attempts to access the file (read, execute, or delete it) result in an "Access is denied." message. GRUBBY DETAILS -------------- Typical "dir /Q" output for one such file (which always shows the owner as "...") is as follows: Volume in drive R is LYNX_R_RAM Volume Serial Number is D81B-10E0 Directory of R:\TEMP 2017-05-29 08:39 <DIR> LYNX\RoyUser . 2017-05-29 08:39 <DIR> LYNX\RoyUser .. 2017-05-22 10:54 41,486 ... argout_018.exe 1 File(s) 41,486 bytes 2 Dir(s) 34,803,712 bytes free Investigating the sick NTSF files via {File Explorer, Properties, Security, Advanced} (even as the magic "Administrator" user) shows "Unable to display current owner" and complains that the user does not have the permissions needed to change the owner or look at the effective permissions. BUT the (data intact) files revert to their normal ownership and permissions after a reboot or a "chkdsk /F /V /X" on the drive. I first noticed the problem with batch files which were aborting with the "Access is denied." message. Some frequently-used ".exe" files had been copied to a RAM disk directory placed early in the Windows execution path. Occasionally a batch file would clear that directory (without checking for errors). When the clearing failure occurred all subsequent attempts to invoke the copied program would get "Access is denied." from the partially-deleted copy on the RAM disk (rather than execute the original from the hard disk directory later in the execution path). I wrote a set of batch files to automate the process of making copies of a program (e.g., argout.exe) in a specified directory (e.g., argout_001.exe, argout_002.exe, ... argout_020.exe), executing all the copies multiple times, deleting all the copies (without checking for errors), and then checking the directory to make sure it was really empty. With Ransomware Protection enabled I would get a few (sometimes none, sometimes up to 4) partially-deleted files in each set of 20 files copied. (I had to reboot after each failure, of course). It did not matter whether the copies were in the RAM disk or on one of the hard drives. Both 32-bit and 64-bit ".exe" files failed. Both Windows ".exe" files (e.g., timeout.exe) and programs I had compiled myself (such as argout.exe) failed. The same tests run without the copies actually being executed before they were deleted never failed. The tests never failed if Ransomware Protection was disabled (regardless of other MB3 options) and always failed eventually if Ransomware Protection was enabled (regardles of other MB3 options). Windows Defender was off. I repeated the tests with the internet disconnected and my anti-virus protection (ESET Internet Security) uninstalled , but that made no difference. I have done many installations of various versions of MB3 on two different computers, running mb-clean twice before each installation. The relevant installation and checking files I used were FRST64.exe mb3-setup-consumer- mb-check- mb-clean- The LYNX computer is an ASUS UL80Jt Notebook running the 10.0.14393.1198 version of Windows 10 Professional. In order to simplify the environment I used the following procedure (with appropriate reboots adjusting Windows Defender on or off after each reboot) for the last test cycle: Updated Windows Defender Disconnected internet Uninstalled ESET Internet Security Disabled Windows Defender Uninstalled MB3 Ran mb-clean Installed MB3 Enabled Windows Defender Connected internet Activate MB3 Updated MB3 Turned on MB3 options Ransomware protection Signature-less anomaly detection, Start with Windows Self-protection with early start Ran an MB3 Hyper Scan Disconnected internet Rebooted Verified the Windows Defender was off Waited for MB3 and other activity to die out Turned on MB3 Event Log Data Ran my diagnostic batch files to the RAM disk with no failure Ran my diagnostic batch files to the RAM disk with the failure shown above Turned off MB3 Event Log Data Ran mb-check Ran FRST64 Reinstalled ESET I have attached the requested files as follows: MB3_bug.txt [plain ASCII copy of this text] mb-check-results.zip FRST.TXT Addition.txt CONCLUSION ---------- As a workaround I have turned off the environment variable which tells my batch files that they may use the RAM disk to improve speed. This slows things down (despite the normal caching of the hard disk), but I really want the Ransomware Protection. Yes, this is an obscure issue, but the underlying cause may be showing up in other problems which you are trying to solve. Thanks for providing a good product! Roy Earle RoyEarle@acm.org Addition.txt FRST.txt MB3_bug.txt mb-check-results.zip
  • 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.