MSE For Vista Now Shows XP Nag Screens

[crazyal12]

13 hours ago, VistaLover said:

... But @dencorso did provide usage hints:

When you unpack the attachment, you'll find a wget.exe binary; the way the batch file is written, wget.exe needs to be in your %PATH% (... environment variable, read more in Wikipedia ); if you don't want to manually add it to %PATH%, you can place that binary inside a directory already in %PATH%: @dencorso's suggestion was

%windir% = %SYSTEMROOT%

which should default to "C:\Windows", if your OS is indeed installed in the C drive...

The second line of the .cmd file changes your working directory to your %TEMP% folder ("Temporary Files" folder, should default to "C:\Users\<YourUserName>\AppData\Local\Temp"), where, of course, there's no wget.exe to be found :

pushd %temp%

This is why it is imperative you place wget.exe in a directory Windows already has in %PATH%, so it would know where to invoke it from...

Apologies for possibly sounding a bit harsh (... rest assured I mean well), but, unless you have some sort of learning disabilities (which if true, I profusely apologise for), almost everything new one wants to learn about is already there in the web, accessible with a bit of searching...

Hope I've helped!

I've cut and pasted them into the Windows folder and that seems to work, I then put a shortcut to the MSEUPD_Vista.cmd file onto the desktop for easy updating.

12 hours ago, Vistapocalypse said:

Have you even tested your real-time protection at AMTSO? I am now using a third-party antivirus because there is more to online security than getting pretty green colors in your 6-year-old MSE client.

 

I'm just using it on this older laptop as its lightweight and doesn't use up much system resources unlike some I've used in the past.

Which lightweight modern alternative would you recommend? I know most people would say to upgrade to Windows 7 at-least, but to be honest its a bit of a hassle for a secondary machine.

Edited July 24, 2019 by crazyal12

[VistaLover]

2 minutes ago, crazyal12 said:

I've cut and pasted them into the Windows folder and that seems to work, I then put a shortcut to the MSEUPD_Vista.cmd file onto the desktop for easy updating.

... Only wget.exe needs to be in %PATH%; hence, you could have left the batch file (*.cmd) inside a directory of your choice (or place it on the desktop); but whatever tickles your fancy...

[dencorso]

2 hours ago, crazyal12 said:

I've cut and pasted them into the Windows folder and that seems to work, I then put a shortcut to the MSEUPD_Vista.cmd file onto the desktop for easy updating.

That's perfect. There's no need to change anything from what you've done

2 hours ago, VistaLover said:

... Only wget.exe needs to be in %PATH%; hence, you could have left the batch file (*.cmd) inside a directory of your choice (or place it on the desktop); but whatever tickles your fancy...

Yes. But do *not* fix what isn't broken. Let things stay as they are.

2 hours ago, crazyal12 said:

I'm just using it on this older laptop as its lightweight and doesn't use up much system resources unlike some I've used in the past.

Which lightweight modern alternative would you recommend? I know most people would say to upgrade to Windows 7 at-least, but to be honest its a bit of a hassle for a secondary machine.

I do recommend it precisely because it's lightweight and unobtrusive. I've used it on my main machine since Oct 2016, when Avast took over AVG and suddenly decided to EoS all versions of AVG but the latest. Up to then I had been using (paid) AVG 2011 which, with various things turned off was reasonable IMO for use. In fact I've never got any malware in any of the machines I use/mantain, since before 2001. However, I did get a prufusion of false positives with AVG, along this time, and none at all with MSE. It's too bad I cannot keep using it anymore on XP... fact is most of my machines running XP (I've got 5) nowadays are powerful enought to do it using MBAM 3.5.1.2522, but for my Eee PC 900 (a single core Celeron M 353 ULV @ 900 MHz machine), which for now remains just with the unupdatable MSE, while I think what to do...

In any case, my 2¢ is: too much paranoia is bad for the user's health and does not make your machine safer, but does slow it! YMMV, of course.

[VistaLover]

On 7/23/2019 at 7:59 AM, dencorso said:

That batch was offered as an example, to be tweaked as needed.

... In the good ol' days (prior to July 2019) when Windows Defender in Vista would receive definitions updates via Windows/Microsoft Update, WU would create a System Restore Point before installing the new definitions file; that SRP would be named "Windows Defender Checkpoint" (or something similar, memory fails me now...  ) and those automated restore points had saved my "behind" when I wanted to revert some unwanted/inadvertent change on my machine.

I have also the following setting checked:

but this is only to revert changes applied by WD (and I always have to "Permit" them myself beforehand...).

Unfortunately, and I understand this is highly unwise, I'm not in the habit of creating manual restore points in a frequent schedule; of course, the OS itself would create one when it thinks it's needed, however I have found this task to be performed in a very fickle fashion; with me not receiving Windows Updates anymore, and not installing/uninstalling applications that often, I've found that it may take the OS many days to auto-create a RP...

So I looked into ways of implementing the automated creation of a SRP alongside the automated (but manual!) update of WD via my WDUPD_Vista.cmd batch file, inspired by its MSE counterpart kindly offered by @dencorso (few posts previously...).

Research has landed me on

https://www.winhelponline.com/blog/create-system-restore-point-script-windows-10-8-7-vista-xp/

and their VBScript linked to in their "Method 3: Restore Point creation using Script" (slightly modified by yours truly!):

'""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
'Script to create a System Restore point in Windows 10, 8, 7, Vista and XP
'Created on May 10 2008 - Revised on Oct 13 2016
'© 2008-2016 - Ramesh Srinivasan. http://www.winhelponline.com/blog
'""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
If GetOS = "Windows XP" Then CreateSRP
If GetOS = "Windows Vista" Or GetOS = "Windows 7" Then
	If WScript.Arguments.length =0 Then
  		Set objShell = CreateObject("Shell.Application")
		objShell.ShellExecute "wscript.exe", """" & _
  		  WScript.ScriptFullName & """" & " uac","", "runas", 1
	Else
  		CreateSRP
  	End If
End If

If GetOS = "Windows 8" Or GetOS = "Windows 10" Then
	If WScript.Arguments.length =0 Then
  		Set objShell = CreateObject("Shell.Application")
		objShell.ShellExecute "wscript.exe", """" & _
  		 WScript.ScriptFullName & """" & " uac","", "runas", 1
	Else
		const HKEY_LOCAL_MACHINE = &H80000002
             	strComputer = "."
            	Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
             	strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore"
             	strValueName = "SystemRestorePointCreationFrequency"
             	oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName, 0  
  		CreateSRP
		oReg.DeleteValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName
  	End If
End If

Sub CreateSRP
	Set SRP = getobject("winmgmts:\\.\root\default:Systemrestore")
	
	If GetOS = "Windows 10" Then
		sOut = SRP.createrestorepoint ("Manual Restore Point", 7, 100)
	Else
		sDesc = "Windows Defender Update Restore Point"
		If Trim(sDesc) <> "" Then
			sOut = SRP.createrestorepoint (sDesc, 0, 100)
		End If
	End If
		
	If sOut <> 0 Then
		WScript.echo "Error " & sOut & _
		  ": Unable to create Restore Point."
	End If
End Sub

Function GetOS    
    Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
    	".\root\cimv2")
    Set colOS = objWMI.ExecQuery("Select * from Win32_OperatingSystem")
    For Each objOS in colOS
	strOSName = objOS.Caption
        If instr(strOSName, "Windows 7") Then
        	GetOS = "Windows 7"    
        ElseIf instr(strOSName, "Vista") Then
        	GetOS = "Windows Vista"
        ElseIf instr(strOSName, "Windows XP") Then
      		GetOS = "Windows XP"
	ElseIf instr(strOSName, "Windows 8") Then
      		GetOS = "Windows 8"
	ElseIf instr(strOSName, "Windows 10") Then
      		GetOS = "Windows 10"
        End If
	Next
End Function

Of course, I then had to visit

https://stackoverflow.com/questions/11899730/running-vbscript-from-batch-file

to learn how to incorporate this in my batch file...

The important thing here is that the SRP creation be fully completed prior to wget (finishing) downloading file mpas-fe.exe (or perhaps prior to file mpas-fe.exe being executed).

I am torn between two variants:

@echo off
start /min /wait cscript "create_restore_point.vbs"
if not exist mpas-fe.exe start /min /wait wget -O mpas-fe.exe https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe
if exist mpas-fe.exe start /min /wait mpas-fe.exe 
del mpas-fe.exe

and

@echo off
cscript "create_restore_point.vbs"
timeout /t 15 /nobreak
if not exist mpas-fe.exe start /min /wait wget -O mpas-fe.exe https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe
if exist mpas-fe.exe start /min /wait mpas-fe.exe 
del mpas-fe.exe

where file create_restore_point.vbs is placed adjacent to the .cmd script.

@dencorso, your opinion on this would be highly appreciated (along with any other alternative you might be able to suggest ); many thanks in anticipation

Edited July 30, 2019 by VistaLover

[dencorso]

start  /min  /wait  causes a new CMDBox to be opened, minimized (viz. /min) and the command to be run inside this new CMDBox, while causing the original CMDBox to wait for this command to finish (viz. /wait), before going on to the next command (= next line). So the 1st scrip guarantees the .vbs run by cscript has finished before running wget and that wget has finished (which is fundamental) before attempting to run mpas-fe and that it also has finished, before deleting it. So one can be sure things will happen in the desired (and needed) order.
The second script, OTOH, starts the .vbs and waits 15 seconds before proceeding. But in highly multitasking systems as the NT-OSes are, one cannot really be sure that 15s will always be enough. So I think the 1st script is best. My 2¢ only, of course.

[VistaLover]

14 hours ago, dencorso said:

So one can be sure things will happen in the desired (and needed) order.
(snipped)
So I think the 1st script is best.

Thanks

14 hours ago, dencorso said:

The second script, OTOH, starts the .vbs and waits 15 seconds before proceeding. But in highly multitasking systems as the NT-OSes are, one cannot really be sure that 15s will always be enough

... So, it may well be just a case of increasing the time interval to, say, 45 or 60 (sec) ? Anyhow, first variant it is then...

[dencorso]

The point is any guess to what "enough" is has some chance to be wrong in some unforeseen situation, once in a blue moon... OTOH, "until it ends" may vary widely, but *never* fails. In fact this is more a philosophic question than an actual one, it all depends on whether failing in, say, 0.001% of the time is good enough or a deal breaker.

[InterLinked]

This thread has been most helpful, thank you! Installed MSE on my Windows Vista x64 and it promptly refused to do anything. Installed the 4.4.304 version and no issues, since. I ran the latest definition from the Microsoft website for 64-bit today and now it's up to date and humming smoothly, wonderful!

Any thoughts on this situation for XP? I installed the 4.4.304 version for XP as well and that part works, but trying to run the 32-bit definition install just says:

"mpam-fe.exe is not a valid Win32 application"

 

Do MSE definition updates no longer work on Windows XP???? If that's the case, what was the last definition update that did, so I could at least get it as much up to date as possible?

I am trying to install the latest 32-bit definitions from: https://support.microsoft.com/en-us/help/971606/how-to-manually-download-the-latest-definition-updates-for-microsoft-s

Anyone on XP SP3 with MSE 4.4.304 having issues installing those 32-bit definitions?

Edited August 8, 2020 by Dylan Cruz

[Vistapocalypse]

The thread Microsoft security essentials and Windows XP was closed in June 2019, and certainly not due to lack of trying.

I also doubt the wisdom of relying on the 2013 client version to protect Vista. Can definitions be updated? Yes. Does that mean you now have effective real-time protection? My conclusion was No. To be sure, I did manage to capture one screenshot of real-time protection functioning properly (see bottom of my July 17, 2019 post on page 3 of this thread and note system tray notification at lower right) - but unfortunately that was often impossible to reproduce, so I adopted Avast 18.8 instead.

[InterLinked]

6 minutes ago, Vistapocalypse said:

The thread Microsoft security essentials and Windows XP was closed in June 2019, and certainly not due to lack of trying.

 

I had a hard time ciphering through it all. I got 4.4.304 installed as indicated, but I'm just confused about why it says not a valid Win32 application, which doesn't seem to be the issue discussed there.

These are the definitions we're talking about here, the 64 bit version of which work fine on the same 4.4.304 in Vista. So I'm wondering what's amiss - perhaps the definitions do no longer support XP, in which case what are the newest ones that do work, so I can use those?

 

6 minutes ago, Vistapocalypse said:

I also doubt the wisdom of relying on the 2013 client version to protect Vista. Can definitions be updated? Yes. Does that mean you now have effective real-time protection? My conclusion was No. To be sure, I did manage to capture one screenshot of real-time protection functioning properly (see bottom of my July 17, 2019 post on page 3 of this thread and note system tray notification at lower right) - but unfortunately that was often impossible to reproduce, so I adopted Avast 18.8 instead.

That looks like a Vista screenshot - I just installed 4.4.304 today and I have the latest definitions so mine is all up to date.

I'm entirely aware that MSE will probably never offer adequate, realtime protection, but that's not really what I was looking for anyways. More just something lightweight that was better than nothing, since my brain is my primary antimalware!

Of course, if there's a newer version than 4.4.304 that works on Vista still, I'd be open to hearing about it - but it seemed the consensus on that thread was there was not.

 

[InterLinked]

20 hours ago, Vistapocalypse said:

The thread Microsoft security essentials and Windows XP was closed in June 2019, and certainly not due to lack of trying.

I also doubt the wisdom of relying on the 2013 client version to protect Vista. Can definitions be updated? Yes. Does that mean you now have effective real-time protection? My conclusion was No. To be sure, I did manage to capture one screenshot of real-time protection functioning properly (see bottom of my July 17, 2019 post on page 3 of this thread and note system tray notification at lower right) - but unfortunately that was often impossible to reproduce, so I adopted Avast 18.8 instead.

So I tried the procedure but it doesn't seem to be doing anything:

Get the old good pe_patch.exe.
Rename mpam-fe.exe to TEMP.EXE
Use PE_PATCH to change "Sub-System Version" from 5.2 to 5.1
Use the reliable n7epsilon's PEChecksum.exe v. 1.4 to correct the PE Checksum. (or ModifyPE)

This is the command-line to use in a CMD Box: PEChecksum -c TEMP.EXE
Rename TEMP.EXE to mpam-fe.exe and run it.

 

I couldn't find PEChecksum, the file is no longer available, but ModifyPE works in XP. I changed Sub-System Version from 6.0 to 5.1 then clicked Save.

then I ran:

@echo off
cd /D "%~dp0"
modifype.exe TEMP.EXE -c
pause

Now, running the file, I don't see the "not a valid Win32 application" error, but nothing at all seems to happen. Thoughts?

Edited August 9, 2020 by Dylan Cruz

[Vistapocalypse]

3 minutes ago, Dylan Cruz said:

Thoughts?

My first thought is that you should use an antivirus for XP that can still receive definition updates. My second thought is that you should be posting in the Windows XP forum instead of the Windows Vista forum. 

[InterLinked]

3 minutes ago, Vistapocalypse said:

My first thought is that you should use an antivirus for XP that can still receive definition updates. My second thought is that you should be posting in the Windows XP forum instead of the Windows Vista forum. 

There is a thread there but for some reason, it's closed to replies. Not sure how they would feel if I started another one.

[Vistapocalypse]

Maybe resurrect Which Antiviruses are Known for a Fact to be Working on XP SP3 as of 2019?

[VistaLover]

On 8/8/2020 at 10:10 PM, Dylan Cruz said:

Any thoughts on this situation for XP? I installed the 4.4.304 version for XP as well and that part works, but trying to run the 32-bit definition install just says:

"mpam-fe.exe is not a valid Win32 application"

Do MSE definition updates no longer work on Windows XP ????

If that's the case, what was the last definition update that did, so I could at least get it as much up to date as possible?

I am trying to install the latest 32-bit definitions from: 

https://support.microsoft.com/en-us/help/971606/how-to-manually-download-the-latest-definition-updates-for-microsoft-s

Anyone on XP SP3 with MSE 4.4.304 having issues installing those 32-bit definitions?

On 8/8/2020 at 11:35 PM, Dylan Cruz said:

I had a hard time ciphering through it all. I got 4.4.304 installed as indicated, but I'm just confused about why it says not a valid Win32 application, which doesn't seem to be the issue discussed there.

These are the definitions we're talking about here, the 64 bit version of which work fine on the same 4.4.304 in Vista. So I'm wondering what's amiss - perhaps the definitions do no longer support XP, in which case what are the newest ones that do work, so I can use those?

9 hours ago, Dylan Cruz said:

Now, running the file, I don't see the "not a valid Win32 application" error, but nothing at all seems to happen. Thoughts?

First thing I want to say is that I agree with @Vistapocalypse that your query ("How to get MSE running on XP SP3 in August 2020") does NOT belong in this thread...

But having seen your failed attempts at this endeavour being spread at various places in the MSFN forums, let me "put you out of your misery" ( ) by offering you an abridged version of the story of MSE on XP (more detail can be found towards the last pages of the relevant thread linked to by @Vistapocalypse ) :

1. M$ continued to offer definition updates for MSE/WD on XP SP3 automatically through Windows Update  for approximately two years after the OS was EoS'ed !
 This fact alone upsets me tremendously to this day because we, Vista users, were not offered a single day of additional support by MS with regards to MSE! (the very last version of the app compatible with Vista contains a trigger/time-bomb that completely locks it after the OS EoS date! ) ; we're seeing the same thing again with EoS'ed Win7 SP1, which continues to receive MSE defs via WU!

2. When WU stopped offering MSE defs on XP, updated defs had to be manually downloaded from MS's Security Portal
https://www.microsoft.com/en-us/wdsi/defenderupdates
and applied by the user. Community enthusiasts and an esteemed member here in MSFN created automation for that procedure, so XP users were kept happy for a while longer...

3. Before I proceed with the story telling, let us focus on the offline defs file itself, mpam-fe.exe ; this is comprised of 6 constituents (you can extract the .exe with 7-zip)

mpasbase.vdm
mpasdlta.vdm
mpavbase.vdm
mpavdlta.vdm
mpengine.dll
MpSigStub.exe

ALL these files are digitally code-signed by MS against MS root certificates and are verified by the OS that they haven't been tampered with before they are allowed to be applied/update MSE; any attempt to modify these files renders them invalid; but more of that later...

.vdm files contain the actual antispyware/antivirus definitions, either in full (mpasbase.vdm, mpavbase.vdm) or delta (differential) formats (mpasdlta.vdm, mpavdlta.vdm); mpengine.dll is the most important constituent, i.e. the AV engine inside MSE which does get updated from time-to-time (and partly mitigates the fact that MSE itself hasn't been updated for quite a long while now... ) .

4. With a specific mpengine.dll update, M$ dropped a nuclear weapon on WinXP users of MSE, because the updated DLL contained new functions not found under XP, only under Vista+ (thankfully for us Vista users.. .)
You can probe yourself the mpengine.dll file under XP with Dependency Walker... 
Hence, newer/updated versions of mpam-fe.exe would not succeed in installing, after that failure MSE would revert to the last working defs+engine.

5. MSE on XP was then stuck with a stale version of engine+definitions and, as time went on, started nagging about that fact... As with all signature-based antimalware solutions, the software itself becomes ineffective at protecting you from the ever evolving online threats...

6. A desperate solution was given some consideration, that is using the last compatible mpengine.dll file coupled with updated .vdm files (extracted from an updated version of mpam-fe.exe), but this was actually "a hole in the water" kind of thing, because updated .vdm files also demand an updated engine to work, i.e. both are interlinked!

7. So here we are now: MSE on XP dead and buried!

8. In the following months, M$ introduced further changes to the defs installer, mpam-fe.exe:
8a : The "Subsystem version" value in the PE header was raised to 6.0 (Vista+); this is the main reason you get the

"is not a valid Win32 application"

error on trying to launch it; lowering that SubSysVer to 5.1 (XP) will accomplish NOTHING, because of two reasons: one is the incompatibility of the mpengine.dll with XP's kernel, discussed in 4 above; the other reason is:

8b: Starting on the weekend of 19/20 Oct 2019, the standalone mpam-fe.exe file as well as all of its constituent files are ONLY being code-signed with a SHA-2 digest algorithm; no matter what you do, you can't get SHA-2 support under XP (and on Vista SP2 you must install select WS2008SP2 updates, as I'm sure you know by now...). 

Do you now see why this quest of yours is totally futile? Please, lay it to rest...

As for some other points you made, M$ don't keep/offer an archive of deprecated mpam-fe.exe versions; in all honesty, what good would that be to anyone, security-wise?

In a total hypothetic scenario, you would need first an XP Extended Kernel solution that will restore XP compatibility to mpengine.dll , plus backporting SHA-2 code-signing support to XP; I've seen stranger things happen, but you shouldn't hold your breath on both of these...

9 hours ago, Dylan Cruz said:

I couldn't find PEChecksum, the file is no longer available

For the benefit of the whole community, I have re-uploaded that at below link:

http://s000.tinyupload.com/index.php?file_id=60954865039051356545

(included is a custom batch file; place the modified PE inside FixPEC folder and run .cmd; as with everything downloaded from the internet, please first scan with a reputed AV software; I can assure you the file that was uploaded by yours truly was safe...)

Edited August 10, 2020 by VistaLover