Last thursday (a week ago) I stumbled upon the issue[*]: all of a sudden, MSERT (the Microsoft Safety Scanner tool) stopped working, throwing an error message:
Exception Caught: 0x8050800C
Return code: 1 (0x1)
It turns out there’s no mistery at all: Microsoft goofed up and silently “fixed” things up TODAY (March 16th, 2023).
If you’re in a hurry and don’t want to know more or read all the gore under-the-hood details, skip my long explanation below and just stick to this first &TLDR; paragraph with the quick fix:
As of today (March 16, 2023), head up to the Microsoft Safety Scanner (MSERT) webpage
and use, or bookmark, those UPDATED (fixed!) links that you should use to make sure you always get a <span style=”text-decoration: underline;”>WORKING</span> copy of MSERT:
-The 32-bit version (https://go.microsoft.com/fwlink/?LinkId=212733),
currently redirecting to
https://definitionupdates.microsoft.com/download/DefinitionUpdates/safetyscanner/x86/MSERT.exe
or
-The 64-bit version (https://go.microsoft.com/fwlink/?LinkId=212732),
currently redirecting to
https://definitionupdates.microsoft.com/download/DefinitionUpdates/safetyscanner/amd64/MSERT.exe
That’s just it – “obvious” and simple as that, period.
Now for the ugly details (in case you’re wondering)…
Yesterday night I finally got the time to take a deeper look and was able to figure out what has been going on for the past week but before I posted all about that here, Microsoft got ahead of me earlier today and I’m happy to say it seems they’ve already FIXED things up (which is GOOD to know: kudos to Redmond for that, it “only” took them a whole week to realize something was wrong and fix it! :P).
So, let me try to explain (in my non-native English, be patient) what the heck has been going on here for the past week with MSERT…
You see, Microsoft Safety Scanner (MSERT), the Microsoft Malicious Software Removal Tool (MRT) and Microsoft Defender (formerly known as Windows Defender, also in its Microsoft Security Essentials (MSSECES) “flavour” back in legacy Windows 7/8.1
systems) are all Microsoft security products that share a common antimalware platform.
However, these tools have different purposes and their release schedule varies, too:
- MSRT (Microsoft Malicious Software Removal Tool) is a standalone tool that is usually, but not always, released every month – on Patch Tuesdays, along with the “stable” Windows updates. Often featuring the most recent, stable version of the antimalware platform the tool doesn’t include ALL of the most recent antivirus and antispyware signature definitions – because it is not a replacement for a full antivirus product. Instead, the tool only includes a carefully chosen set of detections and remediation (cleaning) features for the most prevalent threats in the wild, at the moment: it’s like a swiss-army knife that acts as a clever, but essential mechanism through which Microsoft is able to provide a minimum baseline level of security to updated/patched Windows endpoints.Additionally, by default (although you can turn that off) the tool also “phones home” to Redmond providing valuable statistics that help Microsoft fine-tuning its security products in order to provide high detection rates and, overall, provide good enough protection against malware.
- MSERT (the Microsoft Safety Scanner standalone tool), on the other hand, despite being often confused with MSRT (because they both share a similar GUI) is a much more powerful tool with a specific, different purpose. MSERT is a standalone virus detection and removal tool, conveniently documented as having a short lifetime span usage of 10 days or so (after which it supposedly stops working because there’s a newer version of it that shall be used instead) primarily meant to be used as a handy helper, at any given time, to detect and clean suspect Windows systems that might already have been infected with malware.As you can imagine (and contrary to what the documentation suggests) MSERT is released quite more often than one would expect (not just every 10 days): the tool’s “version” is actually its BUILD number which (surprise, surprise) matches exactly each and every new set of antivirus and antispyware signature definitions that are released for Microsoft Defender (in the form of ‘mpam-fe.exe’, the signature updater that is also used by the legacy Microsoft Security Essentials (MSSECES) product in Windows 7/8.1; and, oddly but unsurprisingly, the same applies to ‘mpas-fe.exe’ – the legacy Windows Defender product signature updater that used to be a feature of the old, long unsupported, pre-Windows 8.x systems).
I won’t bother to get into details on why things are done that way (possibly due to technical aspects of Redmond’s CI/CD build/release methodologies): it’s suffice to say and keep in mind that, due to its nature, MSERT must be kept “up-to-date” with the latest and greatest state-of-the-art malware technology. Thus, besides featuring the latest antivirus and antispyware signature definitions, the tool must ALSO feature the latest version of the Microsoft Malware Protection Engine (MMPE), MPENGINE.DLL – a core library that acts as a crucial component of the antimalware platform.
Some of you, by now, already guessed where all of this is going…
Because MSERT has to deal with new and often unknown threats, using the latest MMPE version means that it might not be using the latest “stable” version of MMPE but rather a NEW one (often a “BETA” or experimental, unstable version) – that, eventually, will lead the way and morph into what WILL become the next MMPE “stable” release that will end up being used to upgrade and update its big brother, Microsoft Defender!
Therefore, MSERT is a perfect testlab environment for MMPE, before pushing out the next “stable” version to Defender. But there’s a catch: MSERT must “cope” with Defender so that Defender (the “main” product, which is also a core security protective Windows feature) won’t incorrectly “flag” MSERT, heuristically, as malware or a Potentially Unwanted Program (PUP) – since the MMPE (stable, beta or experimental) version used by MSERT is always theoretically equal or greater than the (“stable”) one being used by Defender.
However, in this case, Defender wasn’t blocking MSERT (there were no reports of that). Still, MSERT was refusing to work. Why? Let’s see:
- On March 8th, 2023 a 3:37:34 AM timestamp-signed MSERT v1.383.1212.0 routinely added and updated detection for several threats. Like its previous builds, it featured MMPE v1.1.20100.6 [SHA-2 signed Feb 26, 2023 – 04:27:47], which still is Defender’s latest “stable” engine (even in a March 2023 fully updated/patched Windows 10 v21H2 “guinea pig” system);
- A few hours later, a 6:55:42 AM timestamp-signed MSERT v1.383.1215.0 was out. Accordingly to its release notes, it didn’t add or update any threat detections at all, but those seem to be the culprit definitions that pinpoint the exact moment in time when problems started: the tool included a new MMPE (v1.1.20200.1 [SHA-2 signed Mar 4, 2023 – 03:49:59]), which was subsequently used by newer MSERT builds;
- On March 14th, 2023 (Patch Tuesday), MSERT v1.383.1786.0 introduced yet another new MMPE (v1.1.20200.2 [SHA-2 signed Mar 11, 2023 – 04:01:58]) – which has been used since, in subsequent MSERT builds.
So, in the end, what seemed to be the problem?
Well, Microsoft Catalog is still offering the January-2023 (Platform: 4.18.2301.6 | Engine: 1.1.20000.2) antimalware platform, despite the official documentation scheduling for this Patch Tuesday (March 14, 2023) an antimalware platform update (February-2023 – Platform: 4.18.2302.x | Engine: 1.1.20100.6)… and while Defender is still using the January-2023 Platform (4.18.2301.6) with the February-2023 Engine (1.1.20100.6), the MSERT builds for the past week were being thrown out the door with a new (beta, experimental, unstable?) v1.1.20200.2 engine that might either be buggy or having an undefined/unknown dependency of “something” in it (eventually related with Windows 11 new features support?) that makes the tool plainly unusable on Windows 10/8.x/7 systems, throwing that annoying 0x8050800C exception and displaying the weird, generic error message!
Basically, the new v1.1.20200.x engine appears to have unfixed issues and it doesn’t seem to be fully ready yet for production. That would explain why Defender is still using the February-2023 v1.1.2100.6 engine and why the v4.18.2302.x antimalware platform (albeit still featuring the same MMPE engine) didn’t make the rounds into Microsoft Catalog (even if it ever did, it would have been quickly pulled off) because Redmond is probably planning to push an updated, fixed package (featuring a new, fixed build of the v1.1.20200.x engine) in an upcoming March-2023 antimalware platform update (to be released in the upcoming days, eventually).
So, how did Microsoft fixed things up today?
Well, by taking the shortest and simplest (but effective) path: by updating the MSERT download links at the tool’s webpage…
Up until yesterday, those links referred to the VERSIONED builds of the MSERT tool (which are still available but, as you’ll see shortly, they probably shouldn’t be used at all by the average user because they’re “undocumented”) but now they have been changed to refer to a different, fixed location that presumably will always give you the latest MSERT build BUT with the latest MMPE “stable” version – meaning it will always (theoretically) deliver a WORKING copy of MSERT!
You may confirm it yourself: download the latest MSERT build
https://go.microsoft.com/fwlink/?LinkId=212732
into a temporary folder (as I was writing this down, the current binary was v1.385.169.0, an .exe file with 112,662,008 bytes). Now open a command prompt and type ‘MSERT /x’ to extract the tool’s embedded resources. Take a look at the MPENGINE.DLL file/product version, in the ‘Details’ tabsheet of the file properties:
[REGULAR.png]
Now get that very same VERSIONED build of MSERT, using the “old” link:
(you may notice that the downloaded v1.385.169.0 binary is slightly different: a bigger .exe file, with 112,846,272 bytes)
Repeat the process: open a command prompt, type ‘MSERT /x’, right-click MPENGINE.DLL, choose Properties, open the ‘Details’ tabsheet and take a look at the file/product version. See the difference?
[VERSIONED.png]
So, bottom line is: Microsoft goofed up during the past week, regarding MSERT, but they’re on it and fixed things up. Starting today (March 16th, 2023) it seems there will be not one, but TWO builds of the MSERT tool: the main one, generically available for download and offered at the tool’s webpage, that should (hopefully) always provide a working copy of the tool (preferably with the latest “stable” MMPE version) and an alternative, undocumented VERSIONED one that might be featuring a beta/experimental/unstable MMPE version but that, eventually, may be offered as a temporary replacement for the main one for e.g. in the event of a widespread 0-day infection (to help containing it, as a quick remediation).
It’s a fair compromise solution and, to the average user, it all boils down to knowing that if you ever need to use MSERT, head to the tool’s website
and just use the provided links. For a short period of time (between March 8th and March 15th) there were, in fact, some issues with the tool but it’s all been fixed now so you don’t have to worry about it anymore.
For the rest of us mortals, tech geeks out there and Woody users here, well… at least, now you have a better picture of what might have happened and a better understanding of the whole mess and some of the complexities “behind the scenes”. 😉
Just my 2 cents,
–Speccy
[*] More about it, in the news:
https://borncity.com/win/2023/03/10/defender-update-kb2267602-v1-383-1400-0-and-above-drops-install-error-0x80070643/
https://answers.microsoft.com/en-us/windows/forum/all/problem-with-microsoft-safety-scanner-msert/6750e0a5-8590-421e-8119-166293d43a35
https://answers.microsoft.com/en-us/windows/forum/all/problem-with-microsoft-safety-scanner-msert/6750e0a5-8590-421e-8119-166293d43a35
https://www.reddit.com/r/sysadmin/comments/11m7oot/msert_broken_0x8050800c/
