Jump to content

Recommended Posts

Runtime Error (at 47:120): Could not call proc

Microsoft Windows 10 Pro x64
Version 1607 (OS Build 14393.1480)

My %Temp% and %Tmp% are normally set to a RAM drive, in format 'Z:' (no quotes).

Attempting to update, offline, from MBAM free to MBAM free using mb3-setup-consumer-

I repeatedly found that immediately after selecting the language, installation failed with the message:

"Runtime Error (at 47:120): Could not call proc"

I saw the same behaviour when I tried the mb3-setup-consumer- beta installer.

Today (Thu 03 Aug 2017) I tried the 3.1 update again but first changed both %Temp% and %Tmp% back to:


(No quotes).

I then immediately, without reloading Windows, ran the MBAM 3.1 installer/updater again.

It ran right through and appears to have sucessfully updated to MBAM 3.1.

I inspected the settings, which appear to be, as far as is applicable, migrated.

During the update, MBAM appears to have been completely removed from 'Program Files (x86)' and MBAM has been installed in 'Program Files'
That seemed excellent until I noticed that 'Task Manager' > 'Processes' showed Malwarebytes is running as a 32 bit application, so shouldn't it be in 'Program Files (x86)'?

I set my %Temp% and %Tmp% both back to my normal values, directing them to the RAM drive.

I then went on line and requested whatever updates were available.
(nb Controls for that are not well presented and neither could I clearly see what updates were actually done at that stage)

I now see:

Version Information

Malwarebytes version:
Component package version: 1.0.160
Update package version: 1.0.2503

So I am able to report that temporarily switching to the default Temp and Tmp directories fixed the update failure
and it is proven that otherwise the install/update failed because it couldn't cope with those directories being on the RAM drive.

I cannot commit to any further testing or diagnostics on this but hope that my information helps.

Now I need to actually try running MBAM 3.1 and hope it will behave tolerably well.

Link to post
Share on other sites
5 hours ago, Telos said:

This is a known issue. You'll need to designate the temp folders to a fixed partition/drive.

Please read my post again, more carefully. You will see that I was actually supplying information which had already been requested from several other people who then failed to provide it.

The problem has been reported by others but none of them had replied when asked about RAM drives.

My post confirms the trigger of this bug and, in passing, provides a quick and temporary change which circumvents it.

I was already well aware that this problem had previously been reported but that no-one had confirmed its connection with RAM drives.

I'm totally bemused by your telling me of a circumvention which I had just described, in much greater detail, in my original post.

I'd simply expected a quick reply, if any, from a staff member, to acknowledge receipt of the information.

Link to post
Share on other sites
  • 6 months later...

This problem appears to have been fixed in MBAM beta.

For details see

"3.4 beta fixes update Failure when TEMP is on RAM Drive" in Malwarebytes 3.x Beta - Malwarebytes Forums at


Thanks for the fix.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

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.