RoyEarle

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 3.2.2.2029 version (as originally installed 2017-09-21). The persistent failure was present in neither an updated 3.2.2.2029 version nor the newer 3.3.1.2183 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

As I mentioned in the original post, it does not matter whether the destination directory is in the RAM drive or on the hard disk. The symptoms are identical. They seem to occur with the same frequency on either destination. (When I first started investigating the problem, I got hung up on the RAM drive. I even updated the Dataram RAMDisk software. I was reluctant to possibly compromise my hard disk. But then I finally tried using a hard disk destination and got the same failure. Fortunately the files are back to normal after a reboot.) What I find interesting is that with the simplified mb3ob.bat diagnostic LYNX (2011 ASUS UL80Jt Notebook) may require 50 executions of the batch file while MANX (2016 HP Envy 750-150 Desktop) always seems to fail on the first execution. (The full diagnostic with all the extra checks for file integrity, etc., took several passes to find the errors with about the same frequency on both machines.) The two machines have essentially the same running environment and software installed. I can't think of anyone besides MB3, ESET, and Windows Defender who would be mucking around with accesses to executables on a regular basis. Yet the problem occurred with ESET uninstalled and Windows Defender disabled. Is there any other class of program likely to be setting hooks? I tried killing a few of the other programs which should have been irrelevant: Bonjour, CrystalDiskInfo, DOSBox, HWiNFO64, OneDrive, Speccy, SSDlife, YTD Video Downloader. Removing them and rebooting changed nothing. Last night I saw upon the stair, A little man who wasn't there, He wasn't there again today Oh, how I wish he'd go away... Thanks, Roy Earle

Mr. Collins: Attached is the mb3ob.zip archive containing the simplified mb3ob.bat diagnostic for detecting the MB3 deleted copied executable problem. Instructions appear as comments in the batch file. Stripped of the verbiage and options it is about a dozen lines of code. In this form I sometimes have to run mb3ob.bat ten or twenty times to get a failure. If you can run mb3ob.bat in your machines without encountering failures, then there must be something peculiar to my system settings or operating environment causing the problem. In that case MB3 might be working perfectly but just making somebody else's problem visible. (And I don't feel like wiping one of my computers and reinstalling my applications one by one to find out who.) Thanks for your efforts. Roy Earle mb3ob.zip

Reply to request to submit "arwlogs.exe" data: Before running arwlogs.exe I ran my test batch files again so you would have a known approximate timestamp for the file ownership corruptions. This time the computer was in normal full operating mode with the internet connected and ESET Internet Security and MB3 both running. The MB3 options (which are mostly irrelevant and which you probably have in the logs) included Event Log Data off Usage and Threat Statistics on Ransomware Protection on Scan for rootkits on Scan within archives on Use signature-less anomaly ... on Start Malwarebytes as Windows startup on Enable self-protection module on Enable self-protection module early start on I logged in as the normal user and ran the diagnostic on the hard disk and got the failure 2017-05-31T15:00:15 57904.83351616 CopiedTest begins on LYNX ... Volume in drive C is LYNX_C Volume Serial Number is 50E6-2581 Directory of C:\WORK\CPDT\dst 2017-05-31 15:01 <DIR> LYNX\RoyUser . 2017-05-31 15:01 <DIR> LYNX\RoyUser .. 2017-05-22 10:54 41,486 ... argout_004.exe 1 File(s) 41,486 bytes 2 Dir(s) 33,344,544,768 bytes free I then ran the diagnostic with the RAM disk as the destination directory and received the results 2017-05-31T15:01:46 57904.83456355 CopiedTest begins on LYNX ... Volume in drive R is LYNX_R_RAM Volume Serial Number is D81B-10E0 Directory of R:\TEMP 2017-05-31 15:02 <DIR> LYNX\RoyUser . 2017-05-31 15:02 <DIR> LYNX\RoyUser .. 2017-05-22 10:54 41,486 ... argout_016.exe 1 File(s) 41,486 bytes 2 Dir(s) 34,803,712 bytes free I then logged out and back in as my administrative user. I copied arwlogs.exe to the administrative user's desktop and executed it in "Run as administrator" mode. It choked on two busy files but happily compressed the rest. I have attached MB3_bug2.txt ASCII copy of this text 2017-05-31-LYNX.zip arwlogs.exe output I wish you luck tracking this one down. Intermittent problems are just SO much fun to debug ... Roy Earle RoyEarle@acm.org 2017-05-31-LYNX.zip MB3_bug2.txt

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-3.1.2.1733-1.0.122-1.0.1976.exe mb-check-3.1.1.1003.exe mb-clean-3.1.0.1002.exe 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