Replies

Fair enough. You do not seem to trust Kaspersky. What about VirusTotal?

https://bit.ly/2CIAaL3
https://bit.ly/2uxfX6z
https://bit.ly/2HWyz80

(URLs shortened for the sake of legibility: append a ‘+’ sign at the end of each link to preview it. Assuming you trust bit.ly for that. 🙂)

You’re right, it is always a matter of trust(ing something). I simply pointed out that the AV vendor also mentioned their own tiny standalone tool as an alternative way to check (if anyone’s interested).

Offline binary execution – which can be monitored and analyzed in a controlled environment (with security safeguards in place) – might be a better choice (if not safer, at least a little less risky) than putting real data into a website.

1 user thanked author for this post.

ve2mrx

-For separate updates, CBS handle files per assembly component version, update package version does not matter at all

you can install 10 SSUs, CBS is smart enough to make the latest one with higher components version to be effective

in this case: KB4490628 v6.1.7601.24383 < KB3177467 v6.1.7601.23505

Thank you!!! Now it suddenly made sense. 🙂

I just dig into the first “main” .mum (of the “package chain”, let’s put it this way, overlooking the fact that the whole package contains multiple .mum files) and didn’t realize that the “final” Servicing Stack version was both at the end of the “package chain” (in the last .mum) and also in the package contents (in the very own name of the sub-directories!).

But you meant

“KB4490628 v6.1.7601.24383 > KB3177467 v6.1.7601.23505″

right? 🙂

– SSUs are always safe, Windows users should accept this fact and stop struggling about to install them or not

He he… Point taken. 🙂 But I was not struggling (or expecting anyone here to go into the lengths I did), just testing. 😉

– removing the permanence tag is what made KB3177467 to be removed,

Yes.

editing KB4490628 mum file has no effect here

Right. In this case, I simply edited it for “compliance” (and to describe it correctly as a “Security Update”).

separate update package name = no direct relation or effect (SSUs)
chained update package name = auto supersedence (W10 CUs or W7 Monthly Rollups)

I see. That explains why KB4490628 won’t remove KB3177467 (only new, updated releases of a given package – or an updated, different package that embedds that one as one of multiple dependencies [chained updates] – may actually remove it).

abbodi86, once again: Thank You. I was wrong. I didn’t understand correctly a few important things about the package supersedence model. You posted perfectly: shortly, but enlightening – and generously shared invaluable knowledge (we grasshoppers try to learn something new each day… you taught me a lot, today). 🙂

2 users thanked author for this post.

Elly, RDRguy

Hi abbodi86,

I do realize KB4490628 is a separate update from KB3177467 (not only because the KB numbers are different), but shouldn’t the former be replacing (superseding) the latter?

And, if so, isn’t the incremental version numbering relevant?

In which case yes, the exclusive tag DOES have an interest here and yes, installing multiple SSU versions with conflicting version numbers MIGHT be causing undesired side-effects (of which the fact of the KB4493132 “EOL nagging update” not being consistently offered is a minor issue, compared with the potential problems that might arise due to the SSUs conflicting and blocking each other).

You are totally right in the assumption that, under “normal” circumstances, SSUs are usually safe and should be installed prior to other security and cumulative updates. I also admit having the wrong info: in fact, I already wrote before that I’m NOT an MVP – just another dude here trying to help people – and, therefore, I lack the skills and expertise required to fully grasp the technical complexity and subtle inner details of how XML works (and Microsoft uses it). Therefore, please correct me and help us to better understand and handle this complex subject. I do appreciate reading and learning from the valuable comments and knowledge that you and other MVPs kindly share with us! 🙂

I am truly sorry for over-complicating things up (I really tried not to…) but, right now, from what I’m able to understand about the inner details of how SSUs work I can not endorse your recommendation to promptly install KB4490628 (SSUv3) ASAP. Instead, I can only recommend people to WAIT and see if Microsoft releases an updated (fixed?) version of the SSU – that will automatically handle and fix what, in my view, is a complete mess.

Most of our readers should stop reading right now and decide if they should, or should not, install KB4490628 (SSUv3) immediately or, at least, wait until we’re at MS-DEFCON 3: what follows below is not for the faint-hearted.

You see… I was actually able to create a working, updated version of my Windows 7 system with SSUv3 *ONLY* and SSUv2 removed (my “beta testing” branch). Here’s how:

cd %WINDIR%\servicing\Packages
takeown /F Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5.mum /A
takeown /F Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2.mum /A
cacls Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5.mum /E /G BUILTIN\Administrators:F
cacls Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2.mum /E /G BUILTIN\Administrators:F
notepad Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5.mum

Removed the ‘permanence=”permanent”‘ attribute of the <package> tag, saved the .mum file and exited Notepad. Then,

notepad Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2.mum

changed the ‘releaseType=”Update”‘ attribute to ‘releaseType=”Security Update”‘, added the

<mum:packageExtended xmlns:mum="urn:schemas-microsoft-com:asm.v3" exclusive="true"/>

tag right above (before) the closing </package> tag, saved the .mum file and exited Notepad. Finally, I removed SSUv2:

dism /online /remove-package /packagename:Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5

and now I’m left with (a properly installed?) SSUv3 *ONLY*:

C:\>dism /online /get-packages /Format:Table|findstr KB3177467

C:\>dism /online /get-packages /Format:Table|findstr KB4490628
Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2
| Installed | Security Update | 2019/03/27 01:23

Under Control Panel > All Control Panel Items > Programs and Features > Installed Updates, KB4490628 is listed as

Security Update for Microsoft Windows (KB4490628)

with no “Uninstall” option (as expected, because it is a permanent update).

I tried WU: it appears to be working well. I rebooted and tried again: all OK.

Isn’t that how we should expect KB4490628 to behave like? 🙂

1 user thanked author for this post.

RDRguy

Following my previous post on this topic a quick, preliminary “sneak peak” into the binary not only confirms abbodi86‘s disclosed findings (here and here) but it also provides additional insight: the IsBlockedSku built-in check appears to be dormant for now (it will only kick in once the metadata.json file is updated with a new BlockedSkus section – which doesn’t exist, yet).

The initial .cab file (dated Mar 20, 2019) was also re-released (on Mar 22, 2019). Its contents remain mostly the same (including the metadata) but the new cabinet is smaller (69Kb instead of 108Kb) due to a couple of subtle, tiny changes:

-A slightly different picture for the nag screen (a different, zoomed in laptop, slightly rotated/distorted using a lower resolution – an (un?)intentional “subliminal message” to make Windows 7 look “uglier” when compared to Windows 10?) and

-A different URL. The initial link

https://www.microsoft.com/windows/reasons-to-upgrade-to-a-new-windows-10-pc?OCID=win7_app_omc_win

changed to

https://www.microsoft.com/windows/windows-7-end-of-life-support-information?OCID=win7_app_omc_win

meaning that while Windows 7 users were previously redirected to

https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information
(a land page primarily focusing on the EOL support information)

they will now be redirected to

https://www.microsoft.com/en-us/windows?OCID=win7_app_omc_win
(a land page primarily enticing you to buy a new Windows 10 PC)

This subtle, but enlightening shift of focus (from presenting EOL support information first, at the top of the page to a page that dives straight into a blatant consumer marketing campaign) raises a few red flags, if you ask me – contradicting PKCano’s optimism (it sure looks like GWX v2.0 is coming up… hopefully I’m wrong). IMHO it is a very good reason to hide, block and ignore KB4493132.

Regarding the speculation about the weird triggering conditions of the KB4493132 update being offered only to some (apparently, not all) users sharing the same targeted OS editions, similar settings and the same installed patches, RDRguy’s reply was right on the spot:

“Maybe having the Mar servicing stack update installed triggered being offered KB4493132.”

Indeed.

Unfortunately for RDRguy, his decision to go ahead and install the March Servicing Stack Update (SSU) KB4490628 (despite Woody’s MS-DEFCON system advising to wait and hold back while we’re still at MS-DEFCON 2) might have been a really bad idea.

Back in October, I posted about the KB3177467 (SSUv2) release. Well, it appears that Microsoft “messed up” (?) – big. Again.

You see, KB4490628 (the 2019 SSUv3 package, digitally signed with and using a build date of February, 2019) is version 6.1.1.2, marked – wrongly – as an “Update” Package (like SSUv1 was) and not – rightfully, as expected – as a “Security Update” Package (like SSUv2 was).

Meaning, the version numbering increment got messed up again: SSUv1 was v6.1.1.1, SSUv2 was v6.1.2.5 and SSUv3 is now v6.1.1.2!

Problem #1: Because KB4490628 (SSUv3) is missing the extended package ‘exclusive=”true”‘ metadata tag, it will NOT remove KB3177467 (SSUv2) automatically.

Thus, if you install KB4490628 (SSUv3) you will mess up your Windows 7 Servicing Stack and end up with both KB4490628 (SSUv3) and KB3177467 (SSUv2) installed.

Problem #2: Worse, keeping both installed will throw you into a jar of pickles and create a conflicting issue between the two

C:\>dism /online /get-packages /Format:Table|findstr KB3177467
Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5
| Installed | Security Update | 2018/10/10 01:23

C:\>dism /online /get-packages /Format:Table|findstr KB4490628
Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2
| Installed | Update | 2019/03/27 01:23

or three (if you kept SSUv1) packages:

C:\>dism /online /get-packages /Format:Table|findstr KB3177467
Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.1.1
| Superseded | Update | 2016/09/22 01:23
Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5
| Installed | Security Update | 2018/10/10 01:23

C:\>dism /online /get-packages /Format:Table|findstr KB4490628
Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2
| Installed | Update | 2019/03/27 01:23

Now, sit tight and get comfortable (this is tricky – and messy): the KB4493132 “EOL nagging package” is version 6.1.2.2. See where this is coming (and what the side effects might be)?

The apparently “random offering” of KB4493132 might be related with the installed SSU version(s). There might be dragons. And multiple, unforeseen conflicts coming up.

Microsoft’s (bad? intentional?) decision to increment version numbering by “rolling back” from SSUv1 up to SSUv3 (OVER SSUv2, which has a HIGHER value than SSUv3!) may very well be messing up the Windows 7 Servicing Stack (again) and creating additional conflicting scenarios.

Regardless of what you did with SSUv1 after installing SSUv2 (I simply removed it, because I still don’t see any point in keeping a superseded leftover; others preferred to keep it, like GTP did – but it really doesn’t seem to matter, at all), installing SSUv3 “as it is” right now is, IMHO, a bad idea and a risky move. If you happen to do so you WON’T be able to uninstall SSUv2 (since it has a HIGHER version than SSUv3) and you WON’T be able to remove SSUv3 neither!

Once KB4490628 (SSUv3) is installed, the commands that could be used to remove SSUv3 and SSUv2

dism /online /remove-package /packagename:Package_for_KB4490628~31bf3856ad364e35~amd64~~6.1.1.2
dism /online /remove-package /packagename:Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5

will both fail miserably with a 0x800f0825 error.

To revert back the situation you will need to resort to System Restore or a previous image backup.

Currently, we can only hope for the best (that Microsoft will eventually realize the goof (?) and re-release a new, fixed KB4490628 (SSUv3) update with a proper version number of 6.1.2.6 or above).

On the other hand (conspiracy theories aside), Microsoft might as well do nothing: intentionally or not, the KB4490628 (SSUv3) might be Redmond’s way to pass the message along, loud and clear: “-Time’s up, R.I.P. (EOL support) Windows 7!”

Right now, I’m just as clueless as anyone else about what will happen. Fixing KB4490628 (SSUv3) is probably not a top priority to Microsoft. That leaves us (users) with the “choice” (decision) to upgrade, or not, the Servicing Stack (from SSUv2) to SSUv3.

If we don’t (and we keep relying upon SSUv2), will WU (or, alternatively, the updates downloaded directly from the Microsoft Catalog) continue to work? For how long? 🙁

5 users thanked author for this post.

Elly, RDRguy, OscarCP, ve2mrx, woody

@WildBill:
You could have also just scrolled down the Kaspersky blog post up to where it reads:

“Download an archive with the tool (.exe)”
(linking to https://kas.pr/shadowhammer)

By clicking that sentence you would have downloaded a .zip file containing a tiny (74kb) shadowhammer.exe binary: that standalone tool may be executed offline to quickly and easily check all your local MAC addresses at once and either give you some piece of mind

GOOD
Your machine is not affected

or give you reasons to be worried and ask for help, if the output is:

IMPORTANT
It appears you have been targeted! Please send us an email to shadowhammer[at]kaspersky[dot]com

No need to type in your MAC addresses online. And no ads. 😉

[PKCano]

The Bleeping Computer article sums up pretty much all of the relevant, known info about KB4493132. I’ll just add my 2 cents (wild guessing thoughts, I suppose).

IMHO people are right in assuming this is probably only the first version of the update: the .cab file metadata contents (metadata.json) suggest that multiple incarnations of the update are scheduled to be released, accordingly to a predefined calendar that, currently, appears to contemplate 5 phases:

-Phase 1 starting on April 18;
-Phase 2 starting on June 13;
-Phase 3 starting on August 29;
-Phase 4 starting on November 7 and
-Phase 5 starting on December 5.

Microsoft will probably release updated cabinets (eventually with other images and text) before each Phase starts.

The metadata also provides a tip on what might be the reason why not many users are “getting” this lovely Phase 1 retro payload (as Woody puts it) yet: Microsoft appears to be planning to push it worldwide using geofencing technology.

If I read it correctly (guessing through the tea leaves, as Susan would put it) the available metadata suggests that, for now, only selected Windows 7 users in Ukrain, Syria, Iran, Israel, Finland and Japan (and, eventually, Chile, Hawaii, India, France, Paraguay and… Spain?) are the “lucky” ones who might be offered with KB4493132 on Windows Update (there might be a few other places where that “offer” might pop up, depending on what those geofencing numbers actually mean):

uk-UA // [1] Ukrainian (Ukraine)
ar-SY // [1] Arabic (Syria)
syr-SY // [1] Syriac (Syria)
fa-IR // [1] Persian (Iran)
he-IL // [1] Hebrew (Israel)
fi-FI // [1] Finnish (Finland)
ja-JP // [1] Japanese (Japan)
122 // [2] 0x7A -> Chile? (0x007A = Mapudungun)
117 // [2] 0x75 -> Hawaii? (0x0075 = Hawaiian)
77 // [2] 0x4D -> India? (0x004D = Assamese)
131 // [2] 0x83 -> France? (0x0083 = Corsican)
241 // [2] 0xF1 -> ?
222 // [2] 0xDE -> ?
219 // [2] 0xDB -> ?
116 // [2] 0x74 -> Paraguay? (0x0074 = Guarani)
56 // [2] 0x56 -> Spain? (0x0056 = Galician)

References:
[1] Set languages and locales and Culture Names [C#]
[2] Appendix A: Product Behavior

The screenshots below provide a visual insight on how the nagging screens have been (slightly) changing over time.

A few additional notes:

1. The metadata info (pulled out from the .cab file) has remained pretty much the same (currently, version 5 – only a couple of entries have been removed since the initial post).

2. The actual changes lie within the sipnotify.exe binary and the two scheduled tasks, which are both installed and set up by the KB4493132 package itself (I’ve no direct links to the package itself other than the v2 binaries that abbodi86 kindly posted here and here) which may be easily blocked (script by abbodi86).

3. wsntls posted additional info about the Registry keys being used, here.

20190320 (Metadata v1)

20190322 (Metadata v1)

20190611 (Metadata v2)

20190827 (Metadata v4)

20191014 (Metadata v5)

20191105 (Metadata v6)

20191203 (Metadata v7)

So far, 5 different pictures were used:
-Two versions of an open laptop computer showing Windows 7 desktop on the screen (the first laptop picture was quickly replaced – probably because the laptop “looked too good” 🙂 so they replaced it by a more “distorted” picture of an older laptop model…);
-A line drawing of files being transferred between two laptop computers;
-A circular icon of lit light bulb and
-A circular icon with laptop computer and shield showing security being disabled.

• This reply was modified 3 years, 8 months ago by PKCano.
• This reply was modified 3 years, 7 months ago by Speccy. Reason: Updated information (screenshots, abbodi86 and wsntls additional info)
• This reply was modified 3 years, 7 months ago by Speccy.
• This reply was modified 3 years, 5 months ago by Speccy. Reason: Just added the last two screenshots and the picture's descriptions (for completeness)
• This reply was modified 3 years, 5 months ago by Speccy.

9 users thanked author for this post.

ve2mrx, David F, GoneToPlaid, RDRguy, abbodi86, Nibbled To Death By Ducks, Karlston, Cybertooth, woody

OK, here goes a less than brief (but, hopefully, enlightening and not too technical) explanation to help our puzzled readers out there while downloading 1809 (and 1903 and other, future Windows 10 ISOs)… 🙂

When executed, the Media Creation Tool creates a few temporary directories:

C:\$WINDOWS.~BT
C:\$WINDOWS.~WS
C:\ESD

The files at

C:\$WINDOWS.~WS\Sources
(keep in mind that ‘C:\$WINDOWS.~WS‘ is a hidden directory)

do seem to be referring to v10.0.17763.1… but digging into the main log file

C:\$WINDOWS.~WS\Sources\Panther\setupact.log

and searching for “Download Url” reveals that the OS image being downloaded by the tool is actually the v10.0.17763.253 one:

MOUPG GetWebSetupUserInput: Execute: Download Url X64 = [http(...)/17763.253.(...).esd].
Once the ISO file finishes downloading, if you “mount” it and take a closer look at its contents you will find that the tool downloads the v10.0.17763.1 “BASELINE” (ignore the tool’s Jan 8, 2019 date stamping – to match the KB4480116, OS Build 17763.253: it is misleading, because the files are digitally signed Sep 15, 2018… matching the timeline of the last preview builds and the public release of OS Build 17763.1 on Oct 2, 2018!) – and adds (only) 3 files to the ‘sources’ directory:

ws.dat
boot.wim
install.esd

Now open up an elevated command-line. Peeking into the first file (replace the X: below for the drive letter you’re “mounting” the ISO on)

type X:\sources\ws.dat
only adds to the confusion, because the first three lines of the output misleadingly read:

[WebSetup]
ClientVersion=10.0.17763.1
IsUpgradeNow=FALSE

The key point to figure out what’s going on here is to understand the nature of those other two files. By typing

dism /Get-WimInfo /WimFile:X:\sources\boot.wim|findstr "Name"
dism /Get-WimInfo /WimFile:X:\sources\install.esd|findstr "Name"
you learn that ‘boot.wim‘ is a container for both Windows PE and the Windows Setup and that ‘install.esd‘ is a compressed, encrypted copy of several OS “editions” in a protecting container (as noted here). In fact, these two files act as the core elements of how the “BASELINE” ISO gets “updated” to the more recent build being offered (currently, v10.0.17763.253)!

Thus, typing (again, replace the X: below for the drive letter you’re “mounting” the ISO on)

dism /Get-WimInfo /WimFile:X:\sources\boot.wim /index:1
and
dism /Get-WimInfo /WimFile:X:\sources\boot.wim /index:2
and
dism /Get-WimInfo /WimFile:X:\sources\install.esd /index:N
(with N being any integer between 1 and the total number of indexes, or OS “editions” included in your ‘install.esd‘ file – usually 7 or more)

confirms on all outputs (in the “Version” and “ServicePack Build” text lines) that, indeed, you’ve downloaded:

Version : 10.0.17763
ServicePack Build : 253

Last but not least: if you’re NOT planning to upgrade to 1809 yet, after you’re done with the ISO download make sure to get rid of (remove) those

C:\$WINDOWS.~BT
C:\$WINDOWS.~WS
C:\ESD

directories… 😉

7 users thanked author for this post.

Great Lake Bunyip, jaman57, JC Zorkoff, CADesertRat, b, Alex5723, RockE

At this point, no further details are publicly available regarding the vulnerability itself, but one could speculate that CVE-2018-8653 might very well be a revised, more thorough (or complementing) revision of the CVE-2018-8643 patch.

If that is true, these kind of vulnerabilities seem to be exploiting (and bypassing) VBScript execution policies and the root cause of the reported crashes might, indeed, be a conflict between the updated libraries and third-party applications that are using the IE engine for rendering web content.

In David’s case, apparently, that third-party culprit would either be Chrome (is he using the latest version?) or – more likely, especially after reading PKCano’s post – the AV (Bitdefender)…

2 users thanked author for this post.

David Beroff, woody

As PKCano correctly pointed out, besides updating version numbers, the only major differences between KB4483187 (datetime stamped Dec 15, 2018) and KB4470199 (datetime stamped Nov 14, 2018) are in the specific vulnerability being patched – namely, the mshtml.dll HTML Viewer library (both 64/32 bit versions) and the jscript.dll (both 64/32 bit versions) and jscript9.dll (64-bit version) JScript engine libraries.

NOTE: Incidentally, that could also mean that the proposed workaround might not fully cover the vulnerability on 64-bit systems…

There are a few other minor differences (the 32-bit iedkcs32.dll, iexplore.exe and sqmapi.dll files have updated its embedded certificates) but these are, from a functional point of view, irrelevant: basically, KB4483187 is an updated version of (replacement for) KB4470199, patching the specific, Javascript-related vulnerability.

Hi GoneToPlaid,

Thank you for your kind words. I do try to write clearly (considering English’s not my native language).

As for your last sentence, maybe I wasn’t clear enough after all because I never meant to suggest that it was necessary to remove SSUv1 first, before installing SSUv2 (in fact, as abbodi86 correctly points out that doesn’t make much sense: SSU are permanent updates and you can only remove SSUv1 – as I suggested – after installing SSUv2).

I meant two simple things:

1. If KB3177467 is not installed (at all), install SSUv2 (not SSUv1).
2. If KB3177467 is installed and it is SSUv1, install SSUv2 (over SSUv1) and remove SSUv1 afterwards.

There’s little point in keeping both SSUv1 and SSUv2 installed because SSUv2 superseeds SSUv1 by reclassifying the KB3177467 package: although the binaries are exactly the same, from now on Windows Update is going to check the SSU Package Type and look for a “Security Update” Package (SSUv2) instead of an “Update” Package (SSUv1) – or, as you simply put it, WU will look for the word “Security” in the package “friendly name”.

That’s why you don’t need SSUv1 anymore: in fact, “removing” SSUv1 when SSUv2 is already in place will merely “clean things up” (not actually “removing” anything but old/orphaned references). Also, you don’t need to keep backup copies of the SSUv1 installer at hand because if MS ever yanks KB3177467 again it will rather re-release it as a “SSUv3” (and increase the 6.1.2.5 version) rather than relying (as a fallback option) on the old 6.1.1.1 version.

As for the current status of this whole “mess”, we just moved to DEFCON-2 and I noticed our Patch Lady’s post and the Master Patch List indications for Windows 7 users but little, limited beta testing experimentation told me otherwise, so I’ll wait a little bit longer… No rush yet. 🙂

Edit to remove HTML (thanks PKCano)

Group A, Win7Pro-64_SP1, Intel Ivy Bridge (dual core) processor here.

Despite Susan’s feedback (thank you Susan!), for now I’ll wait and refrain from installing the Monthly Rollup (KB4462923) update.

Earlier this week I did a few little, limited beta testing experiments with my updated system and the other October’s updates: had no issues with the Security Only (KB4462915) update (good news for Group B) but after installing the IE Cumulative Update (KB4462949) I experienced a few random hang-ups and system freezes, apparently related with the standard Common Control dialogs – for e.g. a consistent trigger was opening IE and attempting to use the “Save As” dialog from a webpage. Maybe it was just coincidence, but removing KB4462949 fixed that.

Thus, since we’re at DEFCON-2 I’ll stick, for now, with what Woody and the MVP’s recommend: WAIT.

PKCano is absolutely right: help on this website should be clear, simple and useful to any Joe User out there. Rush is often a bad adviser.

More experienced users who are minimally able to figure out what’s going may, of course, provide further help or feedback: IMHO (and GoneToPlaid and others) it’s okay to go ahead and install KB3177467 (and probably KB890830, too) but readers should (please) keep in mind I’m not a MVP (just another dude here trying to help others) and (quoting PKCano’s wise words) MVPs say “We are still at DEFCON-1” which means WAIT.

3 users thanked author for this post.

GoneToPlaid, Elly, PKCano

Group A, Win7Pro-64_SP1, Intel Ivy Bridge (dual core) processor here.

Current status: Fully patched (up to Sep, 2018), plus (despite DEFCON-1) KB3177467 “SSUv2” and MRT 5.65 (Oct 2018) installed: all OK for now.

For those still trying to figure out what to do regarding the [KB3177467] “SSUv2 vs. SSUv1” question, here’s the deal: if KB3177467 is not installed yet, install SSUv2; if you have SSUv1 already, you don’t need SSUv2 but you may wish to install it and remove SSUv1.

To clarify: both versions of the KB3177467 package (SSUv2 and SSUv1, which can be found and downloaded from the Microsoft Catalog) are functionally identical: both contain a couple of compressed cabinet (.cab) files (the Servicing Stack Update (SSU) itself and a Windows Update Offline Scan file (WSUSSCAN.cab)) that, ultimately, lead to the installation of the same (v6.1.7601.23505) binaries.

Unpacking and carefully comparing these contents bring up a few minor differences (it’s Autumn: some XML “leafs” [tags] felt apart… :D) but, for any practical purposes, evidences suggest that the main (“major”, meaningful) differences between the two versions of the package are on the signature/datetime stamps and version numbers:

-The 2016 SSUv1 package (digitally signed with and using a build date of July, 2016) is version 6.1.1.1.
-The 2018 SSUv2 package (digitally signed with and using a build date of September, 2018) is version 6.1.2.5.

IMHO, to be safe and avoid (current and future) weird conflicting issues I think you should have one (and one only) of these packages installed – preferably, SSUv2 (although SSUv1 is probably fine, also – for now – if you already installed it, if all seems to be working fine and, particularly, if you’re not being offered SSUv2).

To verify what version(s) of the KB3177467 package you have installed type, from an elevated command-line prompt:

dism /online /get-packages /Format:Table|findstr KB3177467

For e.g. on a x64 system where the SSUv2 was recently installed (over the previously installed SSUv1) the output may look like this:

Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.1.1
                        | Superseded  | Update          | 2016/09/22 01:23
Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5
                        | Installed   | Security Update | 2018/10/10 01:23

in which case I’d say you should keep SSUv2 only and safely remove (with no ill effects and no need to restart) the old SSUv1, by typing:

dism /online /remove-package /packagename:Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.1.1

Once you do that (and only SSUv2 is installed), checking for updates on an up-to-date (Sep 2018 Rollup [Group A] or Dec 2017 Rollup + Jan-Sep 2018 Security-Only + Sep 2018 IE Rollup [Group [[A|]B]]) Win7 system will probably show only the expected, usual suspects (MRT*, and the 2018-10 Windows/.NET Framework Rollups) – which, as we’re on DEFCON-1, you should put on hold for now and avoid like the plague. 😉

*Yeah, KB890830 (MSRT) is probably okay, too.

5 users thanked author for this post.

Microfix, AusJohn, Ed, abbodi86, columbia2011

I am beta testing KB4093108 (so far with no ill effects), but you should probably wait.
I did not ran into any network issues because, as MrBrian correctly points out, the tcpip.sys file was not updated by KB4093108 (it’s still the one patched by the KB4074587 (2018-02) security-only monthly update):

http    .sys [v6.1.7601.24000] Updated only by KB4056897 (2018-01)
ole32   .dll [v6.1.7601.24000] Updated only by KB4056897 (2018-01)
spoolsv .exe [v6.1.7601.24000] Updated only by KB4056897 (2018-01)

tcpip   .sys [v6.1.7601.24024] Updated only by KB4074587 (2018-02)

authui  .dll [v6.1.7601.24052] Updated only by KB4088878 (2018-03)
mssmbios.sys [v6.1.7601.24056] Updated only by KB4088878 (2018-03)
pci     .sys [v6.1.7601.24056] Updated only by KB4088878 (2018-03)
zipfldr .dll [v6.1.7601.24056] Updated only by KB4088878 (2018-03)

winload .exe [v6.1.7601.24069] Updated by KB4093108 (2018-04)
wsnmp32 .dll [v6.1.7601.24080] Updated by KB4093108 (2018-04)
win32k  .sys [v6.1.7601.24093] Updated by KB4093108 (2018-04)
advapi32.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
kerberos.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
kernel32.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
lsasrv  .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
lsass   .exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
ntdll   .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
ntkrnlpa.exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
ntoskrnl.exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
schannel.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
user    .exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
wow32   .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
wow64   .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)

In a nutshell, if you followed Susan Bradley’s advice and have just rolled back to December, 2017 (like I did) you should start by doing a full image backup (if you haven’t done so yet) and then (downloading the standalone installers from Catalog):

1. KB890830 (MRT 5.59 [April 2018])
2. KB4093110 (only if Flash is being used -> will update it to 29.0.0.140)
3. KB4099950 (despite not having installed any March-related stuff yet at this point)
4. KB4092946 (cumulative security update for IE)
5. KB4054998,KB4054981 (only if .NET Framework is being used -> stick to v4.6.2, if possible, and avoid upgrading to v4.7.x)
6. Set the QualityCompat flag (never mind Microsoft saying it is not required anymore)

At this point, a full image backup is highly recommended: this will be your “safe” (stable, but inherently insecure – no Jan-Apr security-only updates yet) baseline.
Updating from this point onwards implies you’re entering the Twilight Zone (the 2018 patch madness for Windows 7) but, as Woody pointed out, the Jan-Mar updates have stabilized and are now mildy “safe”. Thus, you may wish to try this (non Woody/MVPs-validated, just my own experience – and I’m just another bloke here) “update as much as possible leading to the most stable and less buggy Windows 7 x64 system you may hope for right now” simple process:

7. KB4056897 (2018-01 security-only update). IMPORTANT: If you have an AMD processor, DO NOT reboot immediately once the installation finishes: install KB4073578 first! and then, reboot.
8. KB4078130 (only if you’ve upgraded your BIOS since January 1st, 2018 with the Spectre/Meltdown patching microcode – that will help with performance issues, by partially disabling the Meltdown mitigation which seems to be responsible for slowdowns, bugs and alike)
9. KB4074587 (2018-02 security-only update). Reboot.
10. KB4088878 (2018-03 security-only update). Reboot.
11. KB4099467 (if you happen to run into the “stop error 0xAB when logging off” issue – I haven’t, but there’s no way to guarantee you won’t)

At this point a full image backup is, again, recommended: this will be the (currently) “as much updated and less buggy as possible” baseline for your Windows 7 system.

Now, as we speak (April 14th, 2018) we still don’t know how “safe” KB4093108 actually is. If you’re not beta testing (like I am), wait. There might be dragons – huge ones, in fact (some of the updated files – win32k.sys, ntoskkrnl.exe, lsass.exe and others – are a big part of Windows’s core and, therefore, critical pieces of the system’s stability).

Also, keep in mind I’m deliberately not saying anything about Office updates (a whole other story on its own) or Windows 2008 Server R2 updates (not maintaining any, right now – and WSUS is another beast to tame).

Good luck everyone. 😉

4 users thanked author for this post.

flackcatcher, SueW, MrBrian, Elly

Group A, Win7Pro-64_SP1, Intel Ivy Bridge (dual core) processor.

Last night I went on to update my “20180407_201712+2018upd” baseline. Here’s the current status (as of today, Friday 13th, 2018 – lucky me…):

1. Stable branch [new “20180412_BASELINE” backup image]

Installed KB890830,KB4092946 – AOK (this will be my new “baseline” – the one I’ll roll back into in case anything goes wrong). KB4092946 supersedes KB4096040 with newer files: just ignore the weird version numbering (IE 11 now reads “11.0.9600.18977 update 11.0.56” instead of “11.0.9600.18954 update 11.0.57” – i.e. the build number increased as expected but the update version decreased, goodness knows why).

2. Current branch -> BETA TESTING [new “20180412_UPDATED” backup image]

Once “20180412_BASELINE” was in place I went on to fully update the system and installed the four security-only monthly updates (rebooting four times, once right after installing each one of these): KB4056897 (2018-01), KB4074587 (2018-02), KB4088878 (2018-03) and KB4093108 (2018-04). In the end, the good news are (for as crazy as it may sound) so far so good: WU is not “offering” me nothing but the 2018-04 Monthly Rollup (which I’m not going to install, so I hid it) and AOK (apparently). I’ll be using this branch for the next few days and keep my fingera crossed not to run into much trouble (if things go wild again, I’ll just roll back to “20180412_BASELINE”).

A few important tip notes:

TIP NOTE #1: To be fully updated I had to install all the four security-only updates, because they’re not cumulative (they don’t supersede the previous ones). After the bumps and itches earlier this year and the March madness I had decided to deliberate stick to an “outdated” system and wait until April. And so I did (because, well, a four-months gap is clearly too much. Enough is enough and, at some point, I will have to move forward. And Friday the 13th seemed to be just perfect ;)). I’ve also been keeping tabs on the differences between file versions. Using Microsoft’s own .CSV listings (linked at the bottom of each KB article) I built a simple Excel spreadsheet with four tabs and the file information details and gradually eliminate the superseded files from the previous months (my simplified, customized version of the Master Patch List). If you decide to (wisely) follow this “Group B over the Group A path” know that you will end up with an interesting hybrid mix – but a “safe” one, IMHO: with any luck you’ll be “protected” while (hopefully) not jeopardizing your system with buggy updates. And once a “good” Monthly Rollup comes up (will it?), you’ll just have to apply it to catch up (wouldn’t it be wonderful not to get into that ugly install-try-remove-try endless loop again?). To get a clear picture of what I’m talking about, the sample shortlist below enumerates a few files currently present on my “20180412_UPDATED” updated system (randomly chosen among some of the critical core pieces of the Windows Operating System):

http    .sys [v6.1.7601.24000] Updated only by KB4056897 (2018-01)
ole32   .dll [v6.1.7601.24000] Updated only by KB4056897 (2018-01)
spoolsv .exe [v6.1.7601.24000] Updated only by KB4056897 (2018-01)

tcpip   .sys [v6.1.7601.24024] Updated only by KB4074587 (2018-02)

authui  .dll [v6.1.7601.24052] Updated only by KB4088878 (2018-03)
mssmbios.sys [v6.1.7601.24056] Updated only by KB4088878 (2018-03)
pci     .sys [v6.1.7601.24056] Updated only by KB4088878 (2018-03)
zipfldr .dll [v6.1.7601.24056] Updated only by KB4088878 (2018-03)

winload .exe [v6.1.7601.24069] Updated by KB4093108 (2018-04)
wsnmp32 .dll [v6.1.7601.24080] Updated by KB4093108 (2018-04)
win32k  .sys [v6.1.7601.24093] Updated by KB4093108 (2018-04)
advapi32.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
kerberos.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
kernel32.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
lsasrv  .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
lsass   .exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
ntdll   .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
ntkrnlpa.exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
ntoskrnl.exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
schannel.dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
user    .exe [v6.1.7601.24094] Updated by KB4093108 (2018-04)
wow32   .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)
wow64   .dll [v6.1.7601.24094] Updated by KB4093108 (2018-04)

TIP NOTE #2: While I report that my system is AOK (regarding usability, stability and performance) keep in mind that this legacy system is not hardware-“patched” yet against the Spectre/Meltdown joke. My last BIOS update was back in November, 2017 (before all of the Spectre/Meltdown fuss). Recently, the BIOS manufacturer released a BIOS update, specifically meant to address the CVE 2017-5715 (Branch Target Injection, Spectre Variant 2) vulnerability – but I did not install it yet (the manufacturer documentation suggests that rolling back from this particular BIOS update might be possible, but I’m not that optimistic regarding BIOS updates: for now I’ll just wait and see), thus no new Intel microcode here, I guess. Those of you on the same boat but willing to take a chance (and follow that hardware upgrading “path”) should probably download the Jan 27, 2018 KB4078130 patch and install it right after the 2018-01 (KB4056897) security-only monthly update (before installing the 2018-02 (KB4074587) one): that extra step might (eventually) save you from pain…

TIP NOTE #3: Generally speaking, as a rule of thumb there are four regular updates that are usually “safe” to install (and easy to quickly revert without any ill effects, if anything goes wrong – which, luckily, doesn’t happen so often): a) MRT (KB890830, the Swiss-army Malicious Removal Tool that gets updated every month); b) Flash (only if you haven’t got rid of it yet, which you should – seriously); c) Cumulative Security Updates for Internet Explorer and d) .NET Framework (if you use it – and if you do, on Windows 7 I strongly encourage you to stick to the 4.6.2 version for as long as you can and avoid the 4.7.x branch, because that newer version introduced a lot of “improved” things related to the big “to Windows 10 evolution” that, from my own painful experience, simply seem to break too many things – really not worth the hassle).

Okay, that’s it (for now).

Good luck to everyone and, once again, kudos to the Pros (Woddy, Susan and all the other top-notch MVPs out there). 😉

2 users thanked author for this post.

jelson, columbia2011