I now also have Malwarebytes 3.1.2.1733 on my 64-bit Win 10. No drama involved in installing it. I didn't even have to restart until after the scan found unwanted files.

Many thanks, Carol, Arizona Hot, and cranioscopical, for your very encouraging postings about recent versions of Malwarebytes 3. Normally, after reading your postings, I would upgrade to the present version 3. However, I'm about to move and to be on the road with a somewhat clunky shared laptop for a while, so I think I'll wait until I'm settled again (and using my desktop computer) before I upgrade. But I'm delighted to hear the good news.

Yes, that error is seriously annoying.
Malwarebytes support forum people seem to have no idea as to what causes it either. All they do is feebly tell you stock answer No. 25 - to run some invasive software that looks all over your system and then you send them the resulting report(s).
Like that's going to happen.

I am fed up to the back teeth with it - had enough - and am currently investigating potential alternatives to MBAM.

Quote from: IainB on September 15, 2017, 03:28 PM

I am fed up to the back teeth with it - had enough - and am currently investigating potential alternatives to MBAM.

JRT, rKill and ADWcleaner, that is the trifecta I always use to get rid of malware on a infected Windows PC.

I think this is before, rather than after.  I'd rather not get the malware, than get infected and clean it.

@4wd:
Very interesting. Thanks for your comments above.
Same as you, I ran the invasive analysis software and looked over the reports, and then realised that I could censor/redact the confidential bits before sending the reports to the Malwarebytes forum, but then I decided NOT to send the reports anyway as I could see that - with or without the confidential bits - the reports clearly gave no useful information that would help in problem analysis/resolution. So Malwarebytes were just jerking the users around.

Also, same as you, I went back (last time was a while ago though) to see if there were any developments on the problem resolution. There was zilch.
Oddly enough, I did actually play around with my RAM disc in temp, wondering whether that might be the causal problem - because it had been a known (avoidable) problem in the scripts that install/start up Google Drive. However, I still couldn't get the MBAM installer to work. Tried again last week.
Hmm...odd. If it worked for you though, then it should work for me (OTBE), so I may have made a mistake somewhere. Shall re-check today.

If it worked for you though, then it should work for me (OTBE), so I may have made a mistake somewhere.

Haven't actually installed it yet so I can't say whether redirecting TEMP back to a physical drive has fixed the problem. Plus I'll have the same problem whenever they issue an update.
From their answer to me it seems like this issue has only just been highlighted and that a fix may be coming in a future update.

I'll leave it a couple of weeks before I have another look.

is there any chance (risk) it could be because of the overwhelming number of security updates (approx 60) for Microsoft Office 2010 that came a couple of days ago?

And considering I don't have Office, it's very unlikely.

.... the reports clearly gave no useful information that would help in problem analysis/resolution.

In my case it did as they picked out the RAMdisk driver.

4wd, wondering what the exact number of the file you installed was?

The current version: 3.2.2.2029



You won't have any problem if you're not running %TEMP% on a RAM drive.  I haven't installed it because I'd have to move %TEMP% back to C: for any program update that came along, I'd rather wait until they fix the problem.

In all the years I've run %TEMP% on a RAM drive, this is the only program that's had a problem with it.

Finally figured out how to sort this problem in my case:

1. I was using ImDisk Virtual Disk Driver. It's really very handy/flexible in that the \TEMP setting can be changed dynamically from (say) R:\TEMP (on the RAMdrive) to C:\TEMP, and then back again, as necessary. I used to switch it like this as a workaround for the installer script for GDU (Google Drive Update). The GDU script consistently failed if \TEMP was in a RAMdrive, and worked OK if \TEMP was in C:
   
2. But apparently this isn't enough for the MBAM (Malwarebytes) installer. To get the installer to run, the RAMdrive has to be disabled at Autostart, and then the PC rebooted, so it comes up with C:\TEMP at startup. Then the MBAM installer seems to work OK. I found this out by trial-and-error. I guess the system retains some pointers to the RAMdrive, even if the \TEMP setting has been re-pointed to C: - so it's a bit of a flaky installer if it can't adapt to there being a RAMdrive.
   _________________________________

PITA.

Note that, once the MBAM update has been successfully installed, the \TEMP in RAMdrive can be reinstated at system startup, as normal, and MBAM seems to work fine with that. So it seems to be just the MBAM installer that has a problem with \TEMP being in a RAMdrive. The updated MBAM seems to works just fine with \TEMP being in a RAMdrive.

I know this, the problem is you'll have to do it for every program update, probably even incremental, since it most likely uses the same installer the same way.
It would be better if they fixed the problem.
_____________________________________

Oh yes, absolutely. You will probably be proven right by events.
Just my opinion, mind, and not really relevant, but I feel obliged to mention that I generally feel nothing but disgust for developers who decide to leave things to remain in some sort of bad shape for the hapless users to sort out. Ultimately, such decisions tend to backfire on the authors. One does not easily forget.