Malicious Software Removal Tool in Win10 Home won't run

I've done both types including the download many times, mostly to test the past questions relating to preliminary infection results, so nothing you and I've discussed seems abnormal to me.

Only the aborting operation for the OP seems out of place and I'd had little true opinion until I did this testing myself today.  All my previous comments had been based on discussions in the thread itself, so only in the last few hours did I learn what I posted recently.

I'm using the right-click - Run command instead of Cortana, but there's really no difference for our purposes here.

Rob

I'm not sure exactly what you mean when you say that the manual download has a different name so therefore it is different and would not interact with MRT.exe located in system 32.

From auto update: KB890830.

From the manual download page: Windows-KB890830-x64-V5.49.exe

This is a manual download of KB890830 that was already (installed if you will) by auto update. Initiating Windows-KB890830-x64-V5.49.exe just installs the update again. Being that it is always KB890830 the version number must be paid attention to. This is why after the OP installed the old one after the new one had been installed by auto update auto update then reinstalled the new one again.

I have to run now guys, Good luck!

-Richard

Ah, I'd never bothered to look that closely since I'd only clicked the selection to Run the KB890830 download and never actually saved or examined its contents.

So now the only question remaining is whether the two methods of execution actually operate differently for RikDatta, since one attempts to execute the existing copy directly while the other runs it automatically after exploding the download package.

Both are most often aborting according to RikDatta, but we don't know for certain if one is being blocked from running entirely, since we can't see that in the logs as nothing will be added in that case.

At this point though, I'd be more interested to learn if there's anything in the Event Viewer, most likely the Application log indicating errors such as an appcrash.  Once we know that we can try to find an actual cause and worry about the differing starting methods later.

Rob

Hi Rob,

After I got back home I put this together to help illustrate the time line involved with the log posting from the OP that I think may tell a story, based on what we know now after collaborating on our experiments. Without elaborating any further on my end at this point do you see a possible pattern here that may explain the unexpected behavior?

Granted, the info supplied so far from the OP is most likely not complete in entirety however from what I have seen so far .... Anyway, this is a .jpg that is narrow enough to fit here but is tall, I've noticed in the past that when such is placed in a reply on this site the entire image is reduced in size. If so you can either right-click >open in new tab or window then zoom or copy and paste to your favorite image app and zoom in to be able to read it. I'd be interested to hear your thoughts on this theory, (I think that you will get my drift?).

-Richard

Richard,

In this view of the log I see the timing of the downloads I'd missed earlier when concentrating on the length of time each scan took while looking for failure or success.

Since the second of the two failures with v5.48 in each case occurred at an hour and then 10 minutes before the succeeding automatic Windows Update download and execution of the v5.49 version, it appears these may have been triggered by the previous failed executions, though we have nothing else here to confirm this is true.

It's possible the trigger was simply the roughly daily execution of Windows Update itself, since if this detected an older version in the System32 folder it would automatically perform that update and execution sequence.  If the system was turned on each day shortly before doing the earlier manual scans, it wouldn't be surprising if the Windows Update check would occur soon after, though the 1 hour delay on the 14th isn't fully explained by this.

In any case, I think we've gotten wound up in trying to explain a pointless effort, since as we've both mentioned previously, re-executing a tool that's typically only updated once a month and provides a limited set of detections is a complete waste of time.  That's especially true since the automatic monthly scan seems to operate properly, even replacing the tool multiple times if it's been improperly replaced with an outdated version.

Why the manual execution of the installed tool fails to run appears to be a mystery, but who cares if the primary function of the monthly scan works fine anyway?

Rather than try to figure out why manual execution is failing, RikDatta should simply use an alternative on demand scanner like the Malwarebytes Anti-Malware we've both (all?) recommended, since this would provide both a second opinion for the most commonly encountered malware, as well as the PUPs that MBAM is known to be more aggressive at detecting.

This entire thread has been an exercise in futility.

Rob