In response to having this question marked as a duplicate, I added at the end a section explaining why this is not a generic malware removal question.
Today, I got a popup saying that I would be logged off in 1 minute. Sure enough, it happened.
I updated the malware definitions of MSE, Malwarebytes Free, and Spybot S&D free, then ran full scans in sequence. The latter two came up with nothing concerning, but MSE reported Nemucod, and cited c:\ProgramData\Microsoft\Search\Data\Applications\Windows\tmp.edb. I made the GUI selections to remove that, and was prompted to reboot. Upon logging in again, MSE displays a message saying that it was cleaning the malware, and that nothing need be done. Minutes later, MSE displays a warning again, and the details refer to Nemucod again. So I go through the removal routine again, but this seems to go in and "endless" loop (by which I mean iterations so far). The time stamp of tmp.edb always seems about as recent as the most recent reboot.
I used an admin account and tried manually deleting tmp.edb, but am told that the resource is busy. I booted in safe mode, but tmp.edb was nowhere to be found. Only when I booted in normal mode again did tmp.edb gets recreated.
Web browsing indicates that tmp.edb is a database file used by Windows, though I'm not sure if it is exactly the same path as above.
I am afraid that the malware isn't truly gone, and that MSE will pop up the warning again.
Why this is not a generic malware removal question
One reader marked this question as a duplicating a generic best practice and recovery thread, but if it is accepted as a duplicate, then it means that the generic original precludes any further question on malware. The specificness of this question includes the fact that it isn't necessarily asking how to remove a virus. It doesn't even presume that there is an infection. I describe how two other AVs do not flag the problem that MSE does, and the fact that the cited file is a Windows file. One that goes away when I boot in safe mode. Some new details that make this even harder to assess is the fact that the indicators of Nemucod's presence is highly varied (e.g. here and here), which makes it hard to check whether this is a false positive.
To see if new MSE definitions might now exclude this trigger, I updated definitions at 2am 2018-12-16 EST and ran a full scan. The trigger recurs. Since the definitions were still those created on 2018-12-15, however, this should not be a suprise. As the tmp.edb is a Windows Search file, I disabled Windows Search as suggested by Jatmin and confirmed the absence of tmp.edb after rebooting. As a further measure, I downloaded new MSE definitions created 2018-12-16 07:44 EST and did a full scan, which came up clean. I find Windows Search useful, however, so I re-enabled it, which caused the MSE alarms after reboot (and tmp.edb was present again). I was hopeful that new definitions created 12:47 EST would not generate the alarm, but they still did. On a positive front, I updated MalwareBytes Free definitions, and enabled rootkit detection -- the scan came up clean.
I can't believe that this problem persists with virus definitions dated 2018-12-25. Why does no one else encounter this?
I have posted this to the Microsoft forum and reported this to Microsoft.