Jump to content

Windows system32 ntdll.dll being reported as Trojan.FakeMS.ED


Recommended Posts

  • Staff

NTDLL.Dll detection issue has been fixed with database version 2015.07.23.03

Please make sure to update to that version or higher.

It was a false positive that was in the DB for a short time.


For those using the premium with the Protection Module, once you update MBAM, you will need to shut MBAM down & restart it for new defs to kick in.

Link to post
Share on other sites

Hi Guys


For all of you with machines that are blue screening I have a quick and dirty fix.

get into advanced recovery mode where you have a command prompt and delete the latest mbam-log xml file in the directory \ProgramData\Malwarebytes\Malwarebytes Anti-Malware\Logs.

you can now reboot the machine and it should boot without blue screening but in the event that it just reboots, go into advanced recovery once more and bring up command prompt and go to the quarantine folder here:

\ProgramData\Malwarebytes\Malwarebytes Anti-Malware\Quarantine

Look for the latest quarantined files and there should be several that are all about 1.2mb in size and were created with todays date. These are renamed copies of the Ntdll.dll file. rename one of these files and then copy it back to windows\system32\ and reboot and the machine will reboot to the login screen and you can log in to the desktop 


Link to post
Share on other sites

Hello! I have the same problem!


C:/windows/system32/ntdll.dll    detected as Trojan.FakeMS.ED


Data base version 2015.07.23.04


Since I started the computer every few minutes notifications pop up with message. Please help! Thanks!

Link to post
Share on other sites

  • Staff

Sorry for my abrupt reply earlier. As you can imagine, although this false positive has affected a fairly small number of users, it was still pretty busy.

We fully understand the frustrations & are working as quickly as possible to resolve the resulting issues.


Right click MBAM icon by the clock & choose to exit MBAM.

You will be asked if you are sure (because the protection modules will be shut down)

Answer yes - you are sure.
Restart MBAM. (this will re-enable the protection modules with fresh definitions)

This *should* help clear it up & MBAM should no longer be detecting the file.

Let us know if this is not the case.


When MBAM quarantines a file, it encrypts it. This is to protect the user from possibly being able to launch malicious files. The only way to restore a file from quarantine is through MBAM itself.

If one tries to rename the quarantine file to the ntdll.dll the machine will not reboot either because the code in the file itself is encrypted.



If you already have machines that will not boot, (Windows7), in some cases we are seeing so far (including my own machine) allowing startup recovery to repair the machine has been working.

In a few cases where this has not worked, you may have to get to the Advanced Boot Options & from there, choose system restore to before this incident.


If needed, this page describes how to get into the Windows Recovery Environment:



For those having a large number of machines affected, please contact support or as "Rubber Ducky" said above, if you are having trouble reaching support to contact him.


Hope that helps some of you!

Link to post
Share on other sites

Hi Blender,


Regardless of whether renaming the file does the job or whether the presence of the encrypted file prompts windows to see it as a corrupted file and automatically replace it, the method I detailed has allowed me to get several machines to boot to a desktop today.


I'm sure that you guys may come up with a more elegant way of reviving those machines presently going around in circles rebooting into a bluescreen but for now, in the absence of any other solution, it's a starting point.

Folks could instead use command prompt from the advanced recovery console and copy the file found at x:\windows\system32\ntdll.dll into place at c:\windows\system32 instead or even type SFC /scannow at the command prompt to force windows to fix the issue.

Link to post
Share on other sites

Just wanted to throw this into the mix...


We are also getting FPs on the ntdll.dll file, but not in C:\Windows\System32. Ours, in every case so far (71 clients out of 150), has been detected in these two locations:




No BSODs so far. I have pulled down the DB update and pushed it out, so I am hoping we will be good.

Link to post
Share on other sites

Paul, wonder if just the presence of the file (in encrypted form!) caused Windows to trigger a recovery.


We do suggest decrypting the quarantined item using a clean machine and restoring it to Desktop and then copying over to affected machines and rebooting.

Hi Rubber Ducky

I suspect that the bluescreen is caused by Malwarebytes attempting to delete Ntdll.dll on reboot as this file is a protected system file and previously when things went wrong with it in Vista it was easier to remove the hard drive and mount it in a usb caddy and work on it as a slave drive. Once I had removed the mbam-log xml files from the logs folder the bluescreens stopped but it still kept repeatedly rebooting, just without the bluescreens.

When I went into the recovery console in advanced mode, doing a simple startup repair failed and the repair report told me the file was missing but the repair didn't put it back. Initially when I was trying to figure it out the report stated that the file was missing even though the file was clearly still there and it did not matter what version of Ntdll.dll I used, the repair would still not see the file was present!.

When I copied the quarantined file into place and renamed it and rebooted it did boot through to desktop so I suspect that you may be correct and that the presence of an unreadable file rather than simply an absent file may have triggered a self repair pulling a recovered file from somewhere else.

My problem was that I had a number of users with this issue at remote locations all over the UK and the only usable user interface they had to work with was the command prompt in recovery console as they could not boot into windows fully and recovery console would not find any removable USB drives to copy a clean copy onto the failed machine or copy the encrypted files off to recover on a clean machine. these users also had no ability to remove their hard drives and caddy them up on a second machine so they could only go with what they had on their local drive. I figured that renaming the original file and then copying the quarantined file into the gap left by this action or if the file was missing was probably not going to do any further damage given that startup repair wasn't seeing the file anyway.

I may be wrong but I suspect that trying to restore the ntdll.dll file from quarantine once the machine has been recovered to a desktop may just trigger another bluescreen loop as malware bytes attempts to overwrite a protected file so I didn't attempt that course of action in case it got me into further bother.

I've offered this solution here simply as a quick and dirty work-around and nothing more. I leave it to you guys to come up with a more elegant and lasting fix.


I'm just happy to help




Link to post
Share on other sites

I started manually copying a replacement DLL to many PCs this evening and in each case this fixed it. What I noticed was the DLL was present on each system, but it was damaged/corrupt. It appears that Malwarebytes tried to restore it as I requested, but the restored copy is not good.


Going to have to fix all of these the hard way. Hands on.

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.