Mathwiz

Kind of sets a bad precedent: the whole justification for "activation" was to prevent casual copying; i.e., installing your copy of Office on more than one machine. Maybe we should have seen this coming, but supposedly, activation wasn't intended to force you to upgrade your software when you bought a new machine and wanted to transfer old software to it.

I was specifically after the "certutil.exe" utility. AFAIK it's only available as part of the full package. Edit: Although thanks Heinoganda for listing the two files I (and 99% of us) really needed. Unfortunately I'd already installed the whole thing. Anyway, I have it now - along with a boatload of other utilities I'll never use in my "Administrative Tools" folder.

Sometimes I wonder about Microsoft. I downloaded the "Server 2003 Admin Pack" from Thomas S's link and ran the .exe. Turns out the first thing it does is ask for a directory. I thought installers were supposed to know where to install themselves! So I picked C:\Program Files\Microsoft, and it extracts a few files into that directory and quits. One of those files is a .msi, presumably the "real" installer. The others are a readme and a .vbs script. What the heck is that for? The readme doesn't say. Luckily "apver /?" (from a command prompt) does. It returns your Windows version in ERRORLEVEL So, not really relevant. I finally just ran the .msi, and wondered why Microsoft didn't just include the other two files in it, and download that to start with, avoiding the need to go through all that extra rigamarole. Running the .msi seems to have installed everything successfully, but I don't really know for sure what it installed or where! (Edit: Certutil.exe was installed in C:\Windows\System32.) There are no new options in the Start / Programs menu.

Hmm.... Happened to me thrice on July 6, but not since. If it happens again I'll try the solution at the link.

I'll give it a shot if you know of a good test page for it.

I take your point. An unpatched Firefox exploit could be used to take over its process while browsing, and MSE wouldn't see it. I'm risking the chance of running into malware that exploits a security hole before I get around to downloading one of Roytam's builds that patches the hole. (I'll see how well his builds run before I consider excluding their processes too; maybe I'll be lucky and one will run just fine with no exclusion.) I just wanted to point out that there's some risk when you make any exclusion, particularly one published on the Internet. It's sort of an open invitation for malware authors to target MsMpEng.exe, knowing that there will be a few vulnerable systems out there. That said, I bet you haven't tried using an XP system running MSE with the Todoist Web page open in Firefox. For a few weeks I thought someone had replaced my CPU with a 486! Besides, as Dibya said, most of today's malware won't run on XP anyhow. The risk of malware exploiting a newly-discovered security hole but also running on XP isn't zero, but it's probably rather small.

Thanks! That tip is the same thing Heinoganda suggested, but somehow it seems more authoritative when it's been posted at "tweaking.com" (especially with a note that MSE has a bug that causes it to repeatedly scan itself). For me, excluding the huge firefox.exe process was enough to tame MSE, but the "troublesome" processes might be different on each PC. This should work for all MSE users. Of course I guess the downside is that applying it opens up the possibility of a virus infecting MsMpEng.exe itself, but I'll take my chances.

So should we copy the old u152 jfxwebkit.dll over the u181 one, or will that cause other problems?

Haven't tried this myself yet, but after installing .NET 4.0, try the following two commands from an elevated command prompt: cd C:\Windows\Microsoft.NET\Framework\v4.0.30319\ ngen update You'll get some error messages but it's been reported to significantly improve boot-up time. Don't know for sure, but you may need to redo that after applying .NET 4.0 updates, so you may want to put it in a .bat file.... Also suggested: disabling (or setting to manual) the Microsoft .NET Framework NGEN v4.0.30319_X[86/64] service, but I don't know if that will prevent your new app from running. Worth a try if the above doesn't help. As to why this works, here's the best explanation I found:

Haven't tried that yet. Setting firefox.exe as an exception really helped though. I wonder if there was some change with 52.9 that MSE just didn't like? Doesn't seem like 52.8 was nearly as bad.

More info on this: it seems to be Firefox (I have version 52.9) that really sets MsMpEng.exe off. If I leave it alone, MsMpEng.exe will eventually drop to zero CPU, and then everything seems OK until I do anything in FF, even something as simple as opening a new tab (and before I've even chosen a Web page to browse). At that point MsMpEng.exe's CPU skyrockets. So, simple (but not really satisfactory) solution is to exclude firefox.exe process? I assume MSE would still scan I anything downloaded.... Maybe a better solution would be to move to one of Roytam's builds....

Yes, I'm seeing the same error, now that I've tried that (right-click and click "Properties"). A workaround might be to click the padlock icon to the right of the address bar. This also lets you view the site's certificate, but doesn't seem to run the same buggy code.

This site is intermittently refusing my attempts to post with a "403 Forbidden" message. Obviously this one got through.... Anyhow, it's not that simple; MSE created a service (which I can't seem to edit) to run MsMpEng.exe and set it to start automatically. I might could get it to run at "below normal" priority, but I would first need to prevent it from starting at "normal" priority.

I think I could live with it if MsMpEng.exe could somehow be persuaded to run at "Below Normal" priority, so it didn't slow everything else down so much. As it is, I may need a more lightweight browser, at least.

Last few weeks, MsMpEng.exe has been using more and more CPU, to the point where it's really slowing down my VM: Is anyone else seeing anything like this? I tried RUAE followed by re-downloading the latest definitions, but it didn't make any difference.

Just updated. A screen opened warning that XP & Vista would no longer be supported beyond this release. Edit: For "unofficial" support beyond FF 52.9, Roytam's XP-compatible builds of Basilisk/Serpent 52 or New Moon 28 (soon to be in beta) would seem to be good bets.

Looks like MSFN is using a self-signed certificate for some of the content of their emails. I don't get their emails so I don't know. You can fix the first "!" by clicking "Install Cert" and installing the certificate as a trusted root certificate, but I don't think that will fix the last "!". As for OE8, there is none; the closest is probably Windows Live Mail (2009 version). You'll need the offline Windows Live 2009 installer. It's very similar to OE6, except with a more "Vista-esque" appearance. At least it will migrate your OE6 emails, unlike many other email clients.

You can disable the RC4 cipher with RegEdit. Navigate to the "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" key and create a new DWORD value named "Enabled". Leave the value at 0. You can disable the 3DES cipher the same way. That will make howsmyssl.com happy, but when I tried it, I could no longer access MU; so I re-enabled 3DES. It isn't that insecure....

I checked my own system, and the mshtml.dll file from KB4230450 is installed there. (Fearing the typical long wait from MU, I had downloaded and installed KB4230450 directly from the Microsoft Update Catalog, and didn't rely on MU to find it.) Given its later date, it probably has some security fixes beyond KB4316682, since we know TLS 1.2 support is included in both updates. It seems KB4316682 is superseded by KB4230450. But if folks installed KB4316682 and relied on MU/WU/AU to find the latest updates, they would have missed KB4230450 due to the version number mix-up, so they should now download and install it manually from the catalog. It will probably all shake out next month anyway, when the next Cumulative IE8 Update or Security Update is released. The version numbers probably won't stay the same next time....

Another solution might be a bare drive along with this ezDISK HDD dock: https://www.amazon.com/ezDISK-EZ0330-docking-station-compatible/dp/B0755P3R4H It has a switch to select 512-byte or 4K-byte sector sizes with AF drives. For XP use, just set the switch to 4K, plug in a nice, big, bare drive, and partition and format it as desired. For some reason it claims a 10TB limit. Not sure what that's about (I'd think it would work up to 17TB, if you could find a bare drive that big).

My experience was that the latter update did not stop TLS 1.2 from working, but apparently it doesn't enable TLS 1.2 either; you still must install the former update. The latter update is apparently "cumulative" only for security fixes; the former is "cumulative" for enhancements too, and MS must consider TLS 1.2 support an "enhancement." IOW, MS's use of the word "cumulative" is a bit misleading. Edit: Never mind; I either missed or misread @Dave-H's post above, where he said KB4230450 was enough to enable TLS 1.2. I installed KB4316682, and that was also enough to enable TLS 1.2. Furthermore, @antiproton reported that KB4230450 wasn't offered after installing KB4316682, so apparently there's nothing new in KB4230450 that wasn't in KB4316682 from a few days before. So why two different updates then? I suppose it's still possible that KB4316682 included something that KB4230450 didn't; but if so, it wasn't TLS 1.2 since that was included in both. Sometimes MS just makes no sense at all....

So it appears you need both KB4019276 and KB4316682 for TLS 1.2 in IE8, and if you've installed those two, you probably don't need KB4230450. But you'll still need next month's cumulative security update, and you'll still need to install it manually to avoid the hours/days(/weeks?)-long wait for AU/MU/WU to offer it. I didn't want to wait to see if KB4230450 would be offered, so I went ahead and installed it manually last Tues. (I had already installed KB4316682 and confirmed that TLS 1.2 worked.) Apparently I didn't need to do that, but it didn't hurt anything (TLS 1.2 still works). I had installed KB4019276 back on 28 Nov. At least that's what Add/Remove Programs tells me.

It's weird that KB4230450 was released just a few days after KB4316682. Both are IE8 cumulative updates, so (in theory) KB4230450 should include everything that KB4316682 did; at least that's my understanding of the word "cumulative." But I never checked the contents so I don't know for sure. I just installed KB4316682, then found KB4230450 had been released and installed it too. Nor did I check whether either/both of those also include everything KB4019276 did, but since @Dave-H already had that one installed it shouldn't matter. Anyway, if he didn't install KB4316682, it's probably worth checking IE8 (bypassing ProxHTTPSProxy temporarily) to see if TLS 1.2 is working. Just visiting good ol' https://www.howsmyssl.com should do the trick. If it isn't, go ahead and install KB4316682 and check again. Inquiring minds want to know!

I've had RC4 disabled for some time and never had an issue. But disabling 3DES blocked access to Microsoft Update :(

If true, my concern is that M$ would do a "rush job" to get the necessary updates in before April 2019, and we'd wind up with a buggy update just as support ended. I would not consider TLS 1.2 unsafe. It's surely the best widely-supported protocol at present. TLS 1.3 is still mostly experimental. The ultra-paranoid can disable all cipher suites except AES 128 and AES 256. (Edit: I found I also had to leave 3DES enabled in order to get Microsoft Update to work!) Start regedit and go to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers and you will find a subkey for each possible cipher. Create a DWORD value named "Enabled" under each one (except AES 128 and AES 256) and leave its value at 0. You can also disable the MD5 hash under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes the same way.