InterLinked
Content Type
Profiles
Forums
Events
Posts posted by InterLinked
-
-
6 minutes ago, Vistapocalypse said:
Yes, it does sound like SIW2 was talking about updating definitions from within the UI - something that wasn’t possible in July 2019 (at least not without SHA-2 support, which I did not have then). If manual installation is still possible, it’s worth mentioning that “do-it-yourself” methods of automation were discussed earlier in this thread. However, none of this changes my mind about the client’s lack of effectiveness.
I just manually installed 2 days ago so unless something has changed since then, that works great.
0 -
1 hour ago, VistaLover said:
Hi @SIW2
When I first quickly read your post as an e-mai notification, I must have got it wrong
, believing that the "is not working" bit meant that the whole app itself somehow stopped working ; this doesn't seem to be the case, most fortunately!
The "it cannot install the definition update." bit I believed it to mean that the MANUALLY downloaded "offline" standalone defs updater, file mpam-fe.exe, ceased being able to be run/installed; that doesn't seem to be the case, either...
By "It was fine yesterday" do you actually mean that before August 9th, 2020, MSE on your Vista SP2 install was able to (automatically/manually) fetch and install updated MSE definitions via Microsoft/Windows Update (that's what the "Check for updated definitions" setting does)? If affirmative, that would be the first such mention... On my own system, MS/WU quit fetching anything in mid-July of last year, and that included Windows Defender (WD) defs updates... Installing SHA-2 code-signing support to the system, alas, did not change things...
You obviously have SHA-2 code-signing support installed, if you were able to get current (prior to Aug 9th) defs updates installed; but that support augments Vista's build number to 6.0.6003, and WU (when it worked) gave it the cold shoulder; that's why I'm quite sceptical of your report..
In any way, Error 0x80244019 when checking manually for defs updates in MSE is because dear M$ has shut down the WU infrastructure for Windows Vista
; this has been reported and detailed elsewhere in the MSFN forums... (EDIT: @Vistapocalypse posted while I was in the middle of composing this message...)
The only solution is to download manually (e.g. once daily) the standalone updated definitions installer, mpam-fe.exe, from MS's security portal:
https://www.microsoft.com/en-us/wdsi/defenderupdates
and run that file to get you up to date...
(Scroll down to the MSE section and select the bitness of installed MSE; download and run file mpam-fe.exe)
Please report back, MSE on Vista SP2 shouldn't be dead yet!
@Dylan Cruz , what is the situation there?
I manually install the definitions, though I don't do it everyday, only now and then. I installed definitions 2 days ago so my MSE right now is still happy about that.
What's weird is Vista 64-bit definitions are now called mpas-fe.exe... typo on Microsoft's part?? It's also only half the size of the previous mpam-fe64 that I had.
I do indeed get the same error described when trying to auto-update in MSE. I haven't tried auto-updating MSE at all recently on any OS except W7 where it still works AFAIK.
This is the other link I had for definition updates, which is the one I used last time, which gives me a 107 MB mpam-feX64 for 64-bit: https://support.microsoft.com/en-us/help/971606/how-to-manually-download-the-latest-definition-updates-for-microsoft-s
It is slightly larger (about 1 MB) than the one I installed 2 days ago, which was about 106MB. Having some difficulty trying to get it to run but I've been having trouble getting pretty much everything to run lately on there so I won't give up yet. Eventually, it might work.
0 -
4 hours ago, Vistapocalypse said:
Now that MSE 4.4 is seven years old, an opposing viewpoint on the importance of green colors comes along.
As Ben said, it's purely cosmetic. I know it's not adequate; I just wanted to do it because I can. I don't run any antivirus at all on Windows 2000 and haven't had any issues, so XP + MSE seems like a decent combo to me. I'll never be able to update MSE again, so why be updated with its colors?
I thought Windows 10 Defender was annoying, but I was on Vista the other day and extracted a 7Z file from MSFN and MSE 4.4.304 promptly removed the files.... guess it's trying to send me a message
0 -
8 hours ago, VistaLover said:
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.exeALL 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...
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...)
Thanks, @VistaLover - this really clears a lot of things up, even though I did manage to get somewhere at last.
Eventually, I figured out that mpam-fe.exe was no longer compatible with XP as you said and my attempts to extract MpSigStub and all that failed as well. I ended up finding the last compatible mpam-fe.exe (~475 days old now) and running that. Old, but better than nothing. I'm not kidding myself that this is adequate for XP, but it's better than nothing, I figured. Now, my MSE is yellow instead of red - sometimes, it's even green!
No issues at all on Vista. I have 4.4.304 there and manually running the definition worked well.
0 -
25 minutes ago, asdf2345 said:
We've been using a fork of Chromium, it comes with a portable version, or a silent installer, both of which work on Vista
I tried a portable version of Iron 70 just now and that does not seem to like me, either.
So only a portable version of a specific Chromium browser is working, but no other Chromium browsers like Chrome/Iron are working?
0 -
OK, I gave up, since I wasn't getting anywhere with this - I replaced the system32 version and all is well again.
I will play around and see if the stability of anything else is adversely affected, though my guess is it probably doesn't matter at all.
0 -
How have people here been installing Chrome?
I've been trying to install SRWare Iron 70 and not been having any luck. Ditto for Chrome 70. I'm wondering if there's a simpler way than trying to use Application Verifier on a trace of files.
Maybe not possible but how are people installing their programs exactly?
0 -
1 minute ago, win32 said:
It can be anything. Just make a new text document and rename it to winword.exe.local. and yes, repeat.
Unfortunately, it still doesn't work with a winword.exe.local and dssenh.dll in there,
It's odd that others have not had this issue though, which seems rather bizarre.
Would it be prudent to just replace the system32 one or keep trying to find a different way? My Dependency Walker didn't show dssenh.dll at all, but neither did Dave's and his works...
0 -
1 minute ago, win32 said:
you can create a *.exe.local file for each office application
What is this file supposed to be exactly?
Just copy winword.exe for instance and name it winword.exe.local ? (+Repeat for excel and powerpnt?)
I've already got dssenh.dll in the office14 dir.
0 -
On 6/14/2019 at 4:00 AM, Ben Markson said:
For anyone still struggling to bite the bullet by installing a replacement to MSE (so far I'm finding them all downright scary if not outright destructive and it is just reminding me why I switched to MSE in the first place) these MSE registry changes seem to do two things.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Signature Updates] "ASSignatureDue"=dword:0000016d "AVSignatureDue"=dword:0000016d...where 16d = 365 days
They stop the 2001 Event ID errors for Microsoft Antimalware, plus - and this did surprise me - my MSE has turned from orange back to green. This is deceptively comforting as it is obviously purely cosmetic. Even so MSE is not entirely useless as it is still doing its job even as the signature files become increasingly out of date.
I'm guessing this gives 365 days before MSE thinks the 1.293.2807.0 definitions are too old. I'm also guessing the value could be increased even further.
Ben.I just used e42 for 10 years instead of 1 or 2
My MSE is green right now, after a reboot, so we'll see if it goes yellow again. If/when it does, I'll just run this reg script!
0 -
Just now, daniel_k said:
You need to do some tests.
I did earlier and things SEEMED to work with the system32 one replaced,
THen again I have no idea what this DLL file does or what programs use it.
Just now, daniel_k said:
I'm not sure if that DLL is also used for connection purposes or local encryption only.
In the mean time, I would search for any other registry setting that changes DLL search path.Those were the only 2 I saw
The odd thing is Dependency Walker doesn't even show dssenh as a loaded DLL...
0 -
2 minutes ago, daniel_k said:
Did you restart Windows?
Yup, no difference, even with both set to 0
Thoughts on system32? What's the downside of that?
0 -
Changed another related reg setting I saw there, no effect.
At this point, I'm wondering if it would be best to just go back and replace the system32 one. Obviously the Office14 way is simpler if it works, but since it's not, is there any real downside you can see to replacing the system32 one?
0 -
6 minutes ago, daniel_k said:
Pretty sure you have a CWDIllegalInDllSearch registry entry.
http://web.archive.org/web/20141212220002/support.microsoft.com/kb/2264107
Probably it was added to SP4, as it isn't enabled by default.Checking now... if I have it, can I just delete it?
UPDATE: Mine is set to "1"
- 1 (Blocks a DLL Load from the current working directory if the current working directory is set to a WebDAV folder)
Office14 isn't a WebDav folder, so I'm not sure what the deal is here...
Even when set to 0, I still have the issue so this doesn't seem related?
0 -
15 minutes ago, daniel_k said:
I have no idea what is going wrong on your system.
I've just copied dssenh.dll to the Office folder. That's all.I'm wondering if it's because I have SP4 and all that or not,
Do you have all of the POS updates and everything?
0 -
5 minutes ago, Dylan Cruz said:
Unfortunately, I don't see it there
What happens if you run Dependency Walker on winword.exe? @Dave-H
I don't see it loading dssenh.dll at all for me there, do you?
0 -
2 minutes ago, Dave-H said:
I'm only working from my very faulty memory here, but is that dll listed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs?
IIRC, if it is there programs will always use the version in system32. If it's there, remove it and try again.
Unfortunately, I don't see it there
0 -
23 minutes ago, Dylan Cruz said:
Did you have to reboot? it didn't work after I copied it in there once the system file was back
EDIT: I rebooted and it's still broken... ?
Do I need to enable DLL redirection or something, so it uses the DLL in Office14, not system32?
It's still broken for me unless I replace the system32 copy
0 -
6 minutes ago, Dave-H said:
Yes, works fine with the older file just in the Office program folder, no need to change the system file!
Did you have to reboot? it didn't work after I copied it in there once the system file was back
EDIT: I rebooted and it's still broken... ?
0 -
2 minutes ago, Dave-H said:
That file doesn't exist by default in the Office program folder, only in \system 32.
Putting any version in there should not be a problem.
Whoops, I replaced the system32 one
Let me change it back! Office worked with that, but who knows what else that could've broken... better to do it that way!
0 -
1 minute ago, Dylan Cruz said:
Were you able to do an online, live replace?
Seems Replacer might be required here...
Used Replacer, it works!
Thanks @daniel_k - this is great!
0 -
4 minutes ago, daniel_k said:
Actually, it shouldn't be installed.
You are just "providing" an older and working copy of the DLL for Office to work with.Were you able to do an online, live replace?
Seems Replacer might be required here...
0 -
1 minute ago, daniel_k said:
@Dave-H and @Dylan Cruz
I've fixed it!
Found an easy way to fix Office 2010 and not break TLS updates.
Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14.
That's it.Hey, that's awesome!
Seems like I already downloaded that, let me see if I have that.
So installing the update isn't enough, a manual DLL override is required?
0 -
4 hours ago, IntMD said:
Wouldn't tell to uninstall. Some programs relies on windows' own crypto lib and the benefit far outweight the cons IMO. also let's make sure somebody else verifies this.
Turns out you CAN have your cake and eat it too, actually:
Thanks to @daniel_k for figuring this out:
Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14.
If that doesn't work, copy it into system32 using Replacer and reboot
1
, believing that the "
; this doesn't seem to be the case, most fortunately!
; this has been reported and detailed elsewhere in the MSFN forums... (EDIT: 
.)
MSE For Vista Now Shows XP Nag Screens
in Windows Vista
Posted
Yeah, I still haven't been able to get mpam-fe64.exe to do anything of late... this might be something weird going on actually,
I don't know what, exactly, but it's possible others with MSE are also having similar issues.
I don't actually have MSE installed on my W7, just Defender (native), and that updated its definitions fine when I told it to. Seems something Vista-related is going on.