• A protocol question about KB 4099950

    Home » Forums » Newsletter and Homepage topics » A protocol question about KB 4099950

    Author
    Topic
    #187286

    Two questions  keep popping up — and as far as I can tell, we don’t have any definitive answers. KB 4099950, you may recall, is supposed to be a prec[See the full post at: A protocol question about KB 4099950]

    7 users thanked author for this post.
    Viewing 47 reply threads
    Author
    Replies
    • #187290

      These are the questions I’ve been mulling over on what to do. I installed KB4099950 on 04/09. I thought it was tweaked on April 17?

      • #187293

        Yes, it was tweaked on April 17th.

        • #187300

          The metadata was tweaked. The patch itself was not.

          1 user thanked author for this post.
    • #187296

      Woody,

      I think the answer to your question may lie in the following conversation between myself and abbodi86:

      https://www.askwoody.com/forums/topic/tests-of-kb4099950/#post-186496

      • #187304

        So, as of two days ago, @abbodi86 was recommending that you uninstall KB 4099950 prior to installing KB 4093118.

        But I wonder, given the changes to KB 4093118 metadata on Monday night, if that precaution is still necessary?

        • #187307

          @abbodi86 said I could uninstall/reinstall KB 4099950 or run his script as an alternative.  I chose the latter.

          2 users thanked author for this post.
    • #187301

      @woody
      What a timely post!! I am just sitting here with the new release of KB4099950 sitting on my desktop…I have been mulling over the decision to uninstall the older version and install the newer…in preparation for KB4093118. My finger has been on the “switch” for awhile now…just hoping that any moment a definitive answer would miraculously appear in a post or in the replies, or rather instead to wander into the darkness unaware…anyway I suppose I will just rest my finger for a bit longer and see what may pop up here!! 🙂 Thank you for your enduring devotion.

      A ship in harbor is safe, but that is not what ships are built for. --John Augustus Shedd

      • #187392

        @Individualist and all,
        Hello All Fellow Sufferers: I have just installed KB4093118 (Group A, Win7,64bit, Svc.Pak1). You may recall that I am the fellow sufferer that had to previously uninstall KB4093118 because of getting the Stop error OxAB when logging off. I have just logged off three times with no problems.

        My history — rolled back to December. Installed 4100480. Installed 4099950 on 4/23 from Catalog.
        Installed 2099457 on 4/25 from Catalog.
        So far so good. I figure even if I do get an intermittent OxAB it’s better than worrying about the Total Meltdown — and it was not the kind of BSOD where the whole computer was unusable — it just flashed the screen and then fixed itself (if this is making any sense — I don’t have the correct verbiage).
        So for now I am seeing no problems and am patched! However, am looking over my shoulder obsessing about what horrors May will bring.
        Big (((hugs)) to Woody and everyone who has shared their experiences. I am forever grateful to you all.

        2 users thanked author for this post.
        • #187411

          @Peacelady
          Yes, I do remember you quite well, as your ‘boat’ was of a similar make and model as mine, and I gathered the courage to sail into the unknown based upon your experience, though fortunately for me the waters were less choppy than it appears yours were!! Thank you…as comments / replies such as this in regards to real life experience and outcome have as great an impact on decision making as do all of the other posts, comments, questions and replies do. I am feeling a bit more reassured as each day goes by…as I am approaching a threshold of saturation of information. I appreciate your reply, and shared experience. 🙂

          A ship in harbor is safe, but that is not what ships are built for. --John Augustus Shedd

          1 user thanked author for this post.
    • #187306

      Woody….makes sense that 9950 is now included in the Rollup.  About the same time it came out, 9950 disappeared from my available updates.  Good thing I hadn’t installed it.  I’m on the verge of installing 0480 and 3118 for Win 7.  Given the Total Meltown threat, this seems prudent.  Despite being at Defcon 2, do you agree?

      • #187309
        1 user thanked author for this post.
        • #187320

          Aaaaaaargh! I thoroughly confused and I’m not hip to what you all refer to when you talk about “running a script”. Should I uninstall and install the post 04/17 version of 4099950? I haven’t done any other patches, with the exception of KB4100408 on 03/30, since Feb. I’ve never had KB4088875 or KB4088878 installed. Win 7 Pro x64 i7 Haswell Grp. A

          • #187322

            That’s precisely why I don’t recommend running Abbodi86’s script.

            It’s a great script, but normal Windows people shouldn’t be required to run a script….

            3 users thanked author for this post.
            • #187332

              Am I giving Microsoft too much credit to assume that since the average user is not aware nor following this issue with *950 that the newer version would therefor be included in KB4093118?

              A ship in harbor is safe, but that is not what ships are built for. --John Augustus Shedd

            • #187335

              KB 4099950 is bundled with the April Rollup KB 4093118.
              However, if you installed KB 4099950 before the April 17th revision, it may not be installed correctly.
              If you did this, I would recommend that you uninstall KB 4099950 and reboot prior to installing the April Rollup KB 4093118.

              3 users thanked author for this post.
            • #187339

              Ahh…the answer I have been searching for…Thank you kindly Mr.PKCano. I appreciate your time and efforts here.

              A ship in harbor is safe, but that is not what ships are built for. --John Augustus Shedd

            • #187346

              KB 4099950 is bundled with the April Rollup KB 4093118. However, if you installed KB 4099950 before the April 17th revision, it may not be installed correctly. If you did this, I would recommend that you uninstall KB 4099950 and reboot prior to installing the April Rollup KB 4093118.

              Do you agree with @abbodi86 that running his script first eliminates the need to uninstall KB 4099950 and reboot prior to installing the April Rollup KB 4093118?

            • #187353

              I do not know what abbodi86’s script does, but…
              I don’t recommend running a script for the average user.

              3 users thanked author for this post.
            • #188200

              @abbodi86‘s script does what Microsoft’s script in KB3125574 support article does and in addition fixes few issues with the original script.
              It is technically not @abbodi86‘s script, but Microsoft’s script, enhanced by @abbodi86 and I can confirm that it is enhanced well.
              But the regular end users should not be concerned with it.
              However I am asking this forum and the supporters of the so called Group B method.
              Why is this method still promoted and supported when it was determined for a number of times that it is not reliable, unless supported by enterprise tools? Susan Bradley even called it Group B(usiness). And even so, it is not desired and implemented anywhere in enterprises with knowledgeable administrators, unless bound by certain policies or directions from management.
              Why is the Group B method promoted to regular end users while very good scripts are at the same time considered beyond their knowledge and capabilities to understand?

            • #188418

              However I am asking this forum and the supporters of the so called Group B method. Why is this method still promoted and supported when it was determined for a number of times that it is not reliable, unless supported by enterprise tools?



              @Ch100
              ,

              Your questions deserve solid answers, and not the (unprintable) ranting that gets triggered in me over this issue. I went off and did the ranting in private (mostly). I’ll do my best to answer you, although I do not expect agreement.

              The second question, first… I remember theoretical discussion here about Microsoft having a bug in a Security Only update, but fixing it in the Monthly Rollup and not in a Security Only update. I don’t remember it actually happening… but if it did, I probably did not have issues with that particular bug, because I am fully up to date with Group B Security Only patching. Was there something else that made it seem unreliable? My personal experience is that I have a stable, clean (no mal-ware), reliable and useful Windows 7 laptop that has out performed the W10 computers of family and friends. They have had so many problems that only one continues on W10 to this day. It may be because they all had budget computers to begin with, but they followed your recommendation to automatically update, going from their original OS versions, and continued until their machines were rendered useless by Microsoft. By avoiding telemetry patches to begin with, and then following Group B, I have exactly what I want in an OS. I would purchase another 10 years of Windows 7, if Microsoft would make it available, but I will never have W10 in its existing available versions. I consider it malware of the worst kind… it pretends to do good things, for our own good… while harvesting data and utilizing it for their own commercial (not OS support) interests. So, to recap… (sorry for going out on a rant)… following Group B allows telemetry prevention to be maintained, and results in a stable system, not the unreliable one you deem it to be.

              Why this method still promoted and supported is because there are ethical, moral, and real-world safety concerns that many of us are passionate about defending. How many companies must have their data stolen before you are convinced that having it harvested and in the cloud is not a safe alternative? For someone who is being stalked, having data stolen can be life threatening. It isn’t just identity theft, money loss, or an inconvenience… and why can’t Microsoft or you see that?

              When I was in high school I scored in the top 1% nationwide, in math, mechanical perception, etc… but in advancing math classes I was teased, bullied, and otherwise made clearly known that I didn’t belong there, despite having overcome obstacles to get enrolled in them in the first place… so, no, I’m not techy, and I never had the chance that my male peers did to go into science, engineering, or tech… but I did date and marry those guys, sort of learning and watching from the side-lines. That happened to a lot of smart and talented women.

              A lot of progress has been made in educating and hiring women. But many women hit the same invisible wall that I did… being female was enough that my ideas in management meetings were not-remarked on, but a male co-worker with less experience was told that it was a great idea (two weeks later, same all male except me group, after I gave all of them the idea). I wasn’t being harassed at that time (but I could tell you some stories!), simply unheard and uncredited. To this day, at the US patent office, applications with a female name are rejected at a much higher rate, and stricter limits are applied (making them less valuable) than those of their male, or even neutral named peers. A simple name change, without any other factual changes, greatly increases acceptability. So… women have historically (yes, I’m old) been limited in being educated in the first place… and to this day, they face unconscious bias. The tech industry is especially bad in this respect… so that many of the women who do manage to get education and training and hired, find the workplace mileau uncomfortable and unrewarding. Therefore, women’s ideas about giving back to the community, what is necessary for privacy and safety, and nurturing and growing rather than bullying and extorting for profit have been largely ignored by Microsoft and other tech competitors. We are used to being ignored, and go about taking care of business, anyways. For me, that includes following Group B updating. If there are people, male or female, that want to buck that trend, and make tech more understandable, safer, more secure, and accessable to all, more power to them. I am pretty sure that if circumstances were different, I’d be technically proficient. I’m capable and smart, but am now limited by my cultural upbringing, finances, accessibility, age, and disability. Given the social impact of technology, and having a fundamental respect for people, I share what I do know, and it makes a positive difference within my various communities. I will do what needs to be done to see that tech works for people, not for corporate interests. As my physical world narrows in opportunity, I’ve had the time to focus on my computer, and the world it opens up to me. Somehow, after being discouraged from getting the education, working full time for over three decades, maintaining a house, supporting and raising kids, coping with chronic pain and disability for a quarter century, and expectations (disappointingly unfounded) that Microsoft would do the right thing and let me use my computer as I see fit, tech wasn’t that important to me. Circumstances have changed. Now it is my life-line to a better, larger world. I can’t afford to ignore it. In the long run, neither can my friends and family, no matter how busy they are. My grandchildren will have a basic tech literacy… and I would hope other people will too.

              A slightly different take… There are the survivors of a whole bunch of indigenous communities across the world who can vouch for how the ‘successful’ business people exploiting them caused problems for those who weren’t exterminated in the first place. Extraction and exploitation is a devastating business model for any but the most wealthy and entitled, and I would expect that many people would protest and work against it, when and where-ever it is identified. I’m thinking reciprocal power and mutual benefits would be appropriate. Translated to Microsoft? That they respect my decision to to turn off telemetry, and use the product I paid them for (their benefit) as I see fit. They don’t, but I don’t need their permission… I used to think it was a mistake rather than a well thought out decision, and I protested, thinking they would listen. They don’t care about the consequences of their actions on any but those with corporate power and influence, despite it being relatively easy and painless for them to rectify. They intend to force a user model, and harvest and profit from the data, deliberately exploiting their users. Is it any wonder that the people aren’t ‘buying’ it? The more the tech is translated into every day language, the less acceptable Microsoft’s business model and OS changes are to personal computer and small business users, and the more ways we are finding to avoid it, despite increased time, effort, frustration, and doubling down by Microsoft. We don’t have to volunteer to be manipulated and victimized. I’m not.

              If I give in this reply a larger social context to Microsoft’s failings, and why their direction should be subverted, I have little hope of being actually acknowledged, validated, and listened to. I’d like to offer this article from Quartz at Work, Your Company’s Slack is Probably Sexist, which details the communication styles and differences between genders, and how it affects productivity and workplace decisions. The tech field is overwhelmingly biased, and I, as a woman, see no reason why I should support those values. I’ve fought my whole life against it. It is, however, absolutely awesome to be asked for an opinion, instead of being dismissively addressed… Open, inclusive, discussion, despite disagreement, here at the Lounge, is something all of us benefit from.

              I’m hoping I’ve communicated a little of my passion, reasoning, and commitment in following Group B updating, and supporting others to do the same. Its the right thing for me to do, no matter how difficult,  or unreliable, or unsupported Microsoft makes it for me. I’ve given up on them listening…

              Ch100, you have a strong foundation of technical (Microsoft in particular) knowledge… how is it you don’t see how valuable it is, not for your paycheck, but to make a difference in the lives of less technically able people, to free them and support them in making their own choices? Lives are made better and safer and more productive when all people have safety, a voice, and choice. The Lounge here, with all the questions and discussion and answers, from all different backgrounds, is invaluable. Until I was an MVP and moderating anonymous replies, I, myself, had no idea of the diversity of culture represented here. Across the world there is a thirst for real knowledge, not marketing sap… people want to know, despite the country they come from, their politics, their native language (and kudos to all of you for whom English is a second language), and gender. They want to engage… and they take what they learn back to their families, their communities, their businesses, their cultures… they want and deserve operating systems and tech that allow them to prosper and flourish… not to subjugate and control them. We need real tools, not distracting toys that allow our pockets to be picked, for our communities and families to benefit.

              As a typical woman (see the article I linked to above) I’m going to apologize for writing so much… sigh… and I tried so hard not to rant…

              But… at no time take that for weakness… or think that because my stance is undermined or devalued or sure to fail, that I need validation from Microsoft or any techy. Ultimately, it is my decision how to use the tech in my life.

              Group B it is!

              Non-techy Win 10 Pro and Linux Mint experimenter

            • #188435

              Elly, thank you for replying, but you have to be aware that what this Group B style of patching in an unmanaged environment does is to maintain an illusion for unsuspecting people who have no idea what they are doing. It attracts a ton of users on this site, but this is something that unfortunately does not produce any good outcome.
              I appreciate @PKCano going to extreme efforts trying to keep the system alive on unmanaged systems, but there are limitations in what can be achieved on said unmanaged systems.
              For those concerned about telemetry, being in the so-called Group B is not the answer. The only feasible way to control the amount of leaked personal information while at the same time being on the Internet is the one used by Noel and presented here in detail in many instances. However, how many users here would be able to follow and configure that sort of setup? The other good alternative is to forget about computers and spend the time fishing (not phishing).

              2 users thanked author for this post.
            • #190566

              The fact that my lil’ol’ Win 7 PC has been humming happily without software issue for the last three years on a “Group B” updating routine is, I suggest, a good outcome for me personally and it is certainly no illusion!

              3 users thanked author for this post.
            • #187821

              @PKCano:   When I did the install of KB4003118 to try to get my mess straightened out, there was no  KB4099950 showing, so I don’t have the “new version”, unless it pops up on one of my “check updates”.   Hoping that it will all be well.   Thank you again for all of the guidance you provide to us all.   🙂

            • #187822

              The newer KB4099950 and KB4100480 are  bundled included in KB4096118, so they won’t show up as separate updates.

              1 user thanked author for this post.
            • #189412

              @PKCano:  I don’t have that update you referenced:  KB4096118

              I checked for updates yesterday, and have not checked again, however I won’t know until I do a check.    Is this just a “regular” update for Win 7 x64?  Can’t seem to locate any information by doing a search.

              I’m puzzled as to which OS this applies to, and is it for Group A or Group B (or Win 10).  Thank you for any light you may be able to cast on this one.

            • #189414

              Sorry, that’s my typo. It should be KB 4093118 the April Rollup.

        • #187357

          PKCano…I had seen that, but it doesn’t address the question….if installing the April updates is a viable option, then why are we still at Defcon 2?

    • #187311

      W7x64 Home GrpB
      Since my initial install was before April 17, I uninstalled the older, then installed the newer as per the MS instructions …
      https://support.microsoft.com/en-us/help/4099950/nic-settings-are-replaced-or-static-ip-address-settings-are-lost-after

      1 user thanked author for this post.
    • #187321

      I used google translate, so hopefully it’s all clear…

      I installed kb4099950 on April’s Patch Tuesday en installed the rollup of that month the same day. Before that I already had the March rollup installed. No problems with any of those updates. Today I uninstalled kb4099950 because it was the “old” version, rebooted my system and searched for updates. The only one showing up was the Preview of May. So I went to the Catalog and installed kb4099950 manually. After that rebooted again, looked if the log-file was there (yes!) and everything has been fine ever since.

      2 users thanked author for this post.
    • #187347

      I installed the newest KB 4099950 4/18. Do I uninstall it before I install KB 4093118 since it has 4099950 included? I’m lost again.

      Edition Windows 11 Pro
      Version 22H2
      Installed on ‎10/‎19/‎2022
      OS build 22621.1105

      1 user thanked author for this post.
      • #187355

        You don’t need to uninstall anything. Just install the Rollup – you’ll be fine.

        3 users thanked author for this post.
        • #187385

          It worked and as far as I can tell the computer is A-ok. Thank you PK.

          Edition Windows 11 Pro
          Version 22H2
          Installed on ‎10/‎19/‎2022
          OS build 22621.1105

          2 users thanked author for this post.
    • #187350

      While looking a solution for dwm.exe issues after install of yet any rollup/preview of 2018 I maybe tested all options concerning KB4099950 available of its both old & new revision including its install/uninstall before & after install of either KB4093118 or KB4093108.

      Well, there were neither any issues nor any difference. So KB4099950 finally removed.

      BTW here is a list of my currently hidden updates when KB4099950 is absent – Win7 March Rollup KB4088875 & Preview KB4088881 vanished upon KB4099950 removal.

      2018-04-25-Wed_1_M4300SSDHiddenUpdatesOf11Total_1OfWin103OfTelemetryKB4056894KB4057400KB4074598KB4075211KB4091290KB4093118KB4093113

      Attachments:
      • #187510

        Yes, KB4099950 did not make it back to WU after second revision

        audit-2018-04-24-04-25-26

        Attachments:
    • #187358

      I recall some discussion over the past two weeks, regarding the file differences between the two KB4099950 versions. Most of the focus seemed to center on the appearance of PCIClearStaleCach.txt in the Windows/Logs directory. Apparently, this wasn’t happening for some and maybe not all from the initial version. Unfortunately, I didn’t check for it until after I installed the 2nd version and it was there. Seems like it might be something worth checking, if any have doubts.

    • #187361

      @YP Question 2

      I just check to see the log file was generated in  C:\Windows\Logs, from other’s postings.  Since I had the log file from March updates,  I just installed April security & IE updates.  I did not reinstalled 40999450.

      I used @SueW & MrBrian’s recipe on April 9 to update my systems to March updates.

      1 user thanked author for this post.
    • #187368

      I installed 4099950 from the catalog on April 17th BUT I did that about 10:30 (est) in the morning, would it be a good idea to delete and reinstall 409950 since the revision wasn’t announced until later that afternoon?

      • #187513

        The MSU have not changed since first release, if it’s used for installation then you are good to go

        2 users thanked author for this post.
    • #187379

      Answer 1: Yes, current revised WU KB4093118 (or running directly from MSU file) eliminate the need for KB4099950, with one condition:
      March Rollups or first release of WU KB4093118 must not installed before

      Answer 2: April Security-only update does not contain pci.sys, so it’s not affected with the mess and can be installed safely

      it’s the March Security-only that need to be uninstalled/reinstalled if KB4099950 was not properly installed

      10 users thanked author for this post.
      • #187400

        Answer 1: Yes, current revised WU KB4093118 (or running directly from MSU file) eliminate the need for KB4099950, with one condition: March Rollups or first release of WU KB4093118 must not installed before.

        So, to make sure I’ve got the latest info…  You are now recommending your previous safe route of: uninstall both KB4088875 and KB4099950.  And then you want us to install the latest KB4093118?

        • #187402

          @alpha128
          The advice is still the same, only that it is updated with the latest developments.
          What you were doing before following @abbodi86‘s advice is still valid and about the only way.

          • #187406

            @ch100

            What I did before was take his “short route” of running his script.  I don’t think I did any harm, but running the script doesn’t seem to be the best method in the light of current events.

            • #187413

              It is still OK to run the script.
              What @woody says is that it shouldn’t be required for less technical users, but if you are OK with it, then it is OK.
              The only reason to run KB4099950 if the issue related to the registry key is resolved using a different method than the Microsoft patch is to satisfy the metadata condition for later patches, nothing more.
              So a simple way to do this, even if technically is not required, but to have consistent Windows Update experience is to manually install the latest KB4099950, msu version, from the Catalog.
              I don’t want to confuse anyone more than necessary, but following what @abbodi86 says is 100% safe and correct, but if it is too complicated to follow for being too technical, follow Susan Bradley’s advice for this instance and in general for any other patching purpose, which is more in line with what most users should do.

            • #187417

              It is still OK to run the script. What @woody says is that it shouldn’t be required for less technical users, but if you are OK with it, then it is OK. The only reason to run KB4099950 if the issue related to the registry key is resolved using a different method than the Microsoft patch is to satisfy the metadata condition for later patches, nothing more. So a simple way to do this, even if technically is not required, but to have consistent Windows Update experience is to manually install the latest KB4099950, msu version, from the Catalog. I don’t want to confuse anyone more than necessary, but following what @abbodi86 says is 100% safe and correct, but if it is too complicated to follow for being too technical, follow Susan Bradley’s advice for this instance and in general for any other patching purpose, which is more in line with what most users should do.

              I don’t have a problem with running scripts. So all I need to do now is manually install the latest KB4099950, msu version from the Catalog – prior to installing the April Rollup? I don’t need to uninstall either KB4088875 or the old version of KB4099950?

              If so, that’s great news because I did already download, but not install, KB4099950 from the Catalog.

            • #187424

              I would say that you should follow what @abbodi86 says.
              Before running the updated KB4099950, msu version, you should uninstall the old KB4099950 and the March 2018 updates, all of them if you installed multiple updates belonging to that month.
              January 2018 and February 2018 patches are reliable and there is no need to be uninstalled before installing manually the updated KB4099950 (optional, but still best practice) and next the April 2018 update.

              This is all to have reliable WU detection moving forward, not strictly because you have to do something that was not done by the script provided earlier by @abbodi86.

            • #187446

              I would say that you should follow what @abbodi86 says. Before running the updated KB4099950, msu version, you should uninstall the old KB4099950 and the March 2018 updates, all of them if you installed multiple updates belonging to that month. January 2018 and February 2018 patches are reliable and there is no need to be uninstalled before installing manually the updated KB4099950 (optional, but still best practice) and next the April 2018 update. This is all to have reliable WU detection moving forward, not strictly because you have to do something that was not done by the script provided earlier by @abbodi86.

              What I did on April 1st (no fooling!) was install these updates in this order, which was Microsoft’s recommendation at the time:

              1. KB4099950
              2. KB4088875
              3. KB4100480

              So now, what I need to do to clean up this mess is, in order:

              1. UNINSTALL KB4088875 – Reboot
              2. UNINSTALL KB4099950 – Reboot
              3. INSTALL KB4099950 from Catalog – Reboot
              4. INSTALL KB4093118 from Windows Update – Reboot

              Correct?

              Is it OK to leave KB4100480 – or did I completely waste my time earlier this month?

            • #187507

              Yeah, the would be the official route

              1 user thanked author for this post.
            • #187549

              Yeah, [that] would be the official route

              OK.  Thanks for the confirmation. (Although I hate rolling back updates.)

              Microsoft slogan 1990’s: “Where do you want to go today?”

              Microsoft slogan 2010’s: “One out of three ain’t bad!”

              1 user thanked author for this post.
            • #187647

              Yeah, [that] would be the official route

              OK. Thanks for the confirmation. (Although I hate rolling back updates.) Microsoft slogan 1990’s: “Where do you want to go today?” Microsoft slogan 2010’s: “One out of three ain’t bad!”

              Or “We’ve only just begun” (to screw with your mind)

      • #187405

        “it’s the March Security-only that need to be uninstalled/reinstalled if KB4099950 was not properly installed”

        Sorry, this is confusing. Had installed kb4099950 on 4/06 @ Defcon 3 along with 4100480. Did not install kb4088878, March Security Only, until 4/10 after no issues had been reported for a few days. DID uninstall and reinstall kb4099950 from the catalog (and ran the included .exe as well), per MS instructions later in the day on 4/17.

        So…, what am I missing here??? 🙁

        • #187435

          I also had installed (in this order): 4099950, 4088878, 4099467, 4100480 and 4096040 via downloading from MS catalogue  all before 4/9.   Do I need to uninstall 4099950 before downloading and installing April Security only update 4093108 (Win 7 x64)?  Or do I just need to download and install 4093108?….and then download and install (via MS catalogue) IE 11 April security update 4092946 ?  Thanks in advance for clarifying.  Appreciate the help.

          • #187442

            See @abbodi86 ‘s answer here. You need to uninstall Mar SO 4088878 and 4099950. Then reinstall 4099950 first , reboot, before the security only patches through April.

            1 user thanked author for this post.
            • #187447

              Sorry, I’d like to hear the definitive reasoning behind this from him as MS gave no such instruction in the bulletin re:kb4099950 and reinstallation…, and BTW kb4088878 contains kb4099950 as well. More than blanket statements needed here IMO.

              1 user thanked author for this post.
            • #187450

              I suspect that some of us are making this more confusing than necessary – and I include myself in doing this!

              But, here’s what I don’t get:

              My understanding of KB 4099950 is that it’s sole function is to prevent connectivity issues such as network interface cards, IP addresses, etc. that potentially could have occurred after installing KB4088878, the March Security Only update (there may be other affected updates as well, but as Group B that’s the one I pay attention to). If that’s true, and I installed the pre April 17 4099950 followed by 4088878 and found no connectivity issues of any kind, then it seems as though either

              1) 4099950 installed “good enough” to prevent connectivity issues, even though it may not have installed “correctly”, or 2) my computer would not have had any connectivity issues anyway, even if I had never done anything with 4099950.

              But, in either case, it seems as though I don’t need to do anything more with 4999950, and, in particular, don’t need to install a post April 17 version of it. I have a properly functioning computer right now and don’t see a need to “fix” anything.

              This matters to me because I don’t trust anything from Microsoft to work correctly anymore, and that includes uninstalling, reinstalling, etc., etc., etc., and the less I do to my computer the better. Doing any of these is simply another thing to go wrong.

              It seems there are a number of us in this situation.

              I will also add that I don’t care at all about a functioning Windows Update – as long as it doesn’t download or install anything without my permission. I’m perfectly happy to do all my updating from the Microsoft Update Catalog. So, if the only reason for reinstalling 4099950 is to get metadata/supercedence to work properly, then I don’t care about 4099950.

              Is my thinking correct, or am I full of baloney?

              4 users thanked author for this post.
            • #187452
            • #187458

              Neither of those answer my direct questions.

              1 user thanked author for this post.
            • #187449

              Thanks. To clarify, we should then re-download and install the 499950 from the catalogue, then re-download and install Mar Security only update, then download and install the April security only update from catalogue?

              As an alternative, what happens if we keep everything as is (that’s been installed as noted above) and just download and just install the Apri security only update since existing 499950 and other above updates that were all installed before 4/9 haven’t resulted in amy bsod?

        • #187509

          If you installed KB4099950 directly from MSU file since the beginning, then you don’t need to change/uninstall anything

          If you installed KB4099950 from WU before April 17, you need to uninstall it, uninstall KB4088878, then install KB4099950 directly from MSU file, then install KB4088878

          2 users thanked author for this post.
          • #187572

            What is your reasoning behind uninstalling and reinstalling kb4088878? The MS tech in the Reddit discussion mentioned nothing about uninstalling rollups along with kb4099950. If it were important to do so, don’t you think he would have pointed this out if it were necessary???

          • #187630

            You are free to ask him that, and i sure he will tell you do so, unless he’s unaware about pci.sys dependency in PCIClearStaleCache.exe

            4 users thanked author for this post.
          • #188097

            What do I do if I rolled back to Dec. 2017 and didn’t install anything but office updates or anything non-security?

          • #188262

            Ok let me try again.  I have Windows 7 and am in Group B and I did read Woody’s article in ComputerWorld which led me here to abbodi86’s instructions, however, I never downloaded KB4099950 in the first place and I had already rolled back to Dec. 2017 last month which is why I wrote in the post above yesterday asking what do I do at this point since I never downloaded KB4099950??

            • #188265

              Download & install 4099950 (two files, double click on the .msu, it will execute the script in the .exe)
              Install all the Security-only updates you are missing.
              Install the latest IE11 Cumulative Update.
              Reboot.

              1 user thanked author for this post.
    • #187416

      After some hand-wringing and much head scratching I uninstalled the pre-April 17 KB4099950, re-booted. Turned Update back on and ran a check. 3 important updates ticked: KB4093118, KB2952664, and April MSRT. Just installed the revised 3118 only. Since I didn’t have any March Rollups or the first version of 3118 I think I’m in the clear. (?) Don’t usually do anything until the DEFCON level raises, but given the the potential for exploits I thought it the best course. Thanks to: Da Boss, PKCano, abbodi86, & the other knowledgeable members of the Woody Nation.

      2 users thanked author for this post.
    • #187420

      Windows 7 SP1 Home Premium 64 bit Group A
      Had rolled my computer back to December 2017.
      Ok, here’s what I did. 
      I installed KB40999950 msu file that I got from Microsoft catalog.
      I then rebooted my computer.
      I then installed the April Rollup kb4093118. (April 23 date from WU)
      Crossed my fingers and restarted my computer.
      No problem that I can tell. (whew!)

      but…..
      I did that PCI search on my computer and this is what I found….
      The version is not the same that PKCano posted the other day.
      PKCano posted: 4/23/18

      “Check “C:WindowsLogsPCIClearStaleCache.txt” after the install.  (kb4099950 from catalog msu file)

      pci.sys file version should be 6.1.7601.21744 or later and the cache removed”.

      taking a deep breath…
      did something go wrong????

       

      Attachments:
      1 user thanked author for this post.
      • #187474

        @dgreen:

        My C:WindowsLogsPCIClearStaleCache.txt is identical to yours.

        Like you, I’m Windows 7 Home Premium SP1 64-bit, Group A.

        I didn’t roll back and have rollups through February installed, so I installed KB4100480 on April 9 to mitigate the Total Meltdown bug.
        On April 18 I uninstalled the version of KB4099950 that I had installed using Windows Updates and then downloaded and installed the .msu file from the Catalog. When I saw that the pci.sys file version hadn’t changed, I thought that maybe the KB4093118 rollup would update it; but after reading your post I see that’s apparently not going to happen.

        At least, though, I’m encouraged by the fact that you haven’t experienced the network problems. I’m hoping that means that either KB4099950 did “work” or that our systems wouldn’t have been affected anyway.

        I plan to install the rollup in the next couple of days and will report my results.

        Linux Mint Cinnamon 19.3
        Group A:
        Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
        Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
        Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

        2 users thanked author for this post.
      • #187514

        Nothing wrong, the log indicate that KB4099950 fixed the issue

        6.1.7601.21744 is the minimum not problematic version of pci.sys

        3 users thanked author for this post.
        • #187760

          Nothing wrong, the log indicate that KB4099950 fixed the issue

          6.1.7601.21744 is the minimum not problematic version of pci.sys



          @abbodi86
          :
          For many (most?) people, running the latest (or any) version of KB4099950 seems to have updated their pci.sys file version to .21744 or above. However, that didn’t happen for several of us here, including dgreen in post #187420 and me. Ours remains unchanged at .17514. Both you and PKCano seem to suggest that we need the later pci.sys version to prevent the NIC problem, but you also say that the log indicates that the issue was fixed. Can you explain this a bit? Do we need a newer version of the pci.sys file or not?

          Linux Mint Cinnamon 19.3
          Group A:
          Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
          Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
          Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

          • #187762

            “For many (most?) people, running the latest (or any) version of KB4099950 seems to have updated their pci.sys file version to .21744 or above.”

            I believe that this is an urban legend.

            1 user thanked author for this post.
            • #187780

              MrBrian,
              1. So is it the rollup itself that is supposed to change the pci.sys version?
              2. If so, then if dgreen (in post #187420 above) checks his pci.sys file (not the Log file from 4099950), he should find a higher version, like KarenS?

              Thanks for your help in clarifying this!

              Linux Mint Cinnamon 19.3
              Group A:
              Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
              Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
              Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

            • #187841

              1. Yes. After installing the Windows 7 March 2018 Windows monthly rollup, Windows 7 April 2018 Windows monthly rollup, or Windows 7 March 2018 security-only update, and then rebooting, the file pci.sys should be at the version listed in the file lists available at Windows 7 SP1 and Windows Server 2008 R2 SP1 update history.

              2. Yes.

              2 users thanked author for this post.
          • #187834

            KB4099950 does not include or install pci.sys
            it just check the version of current instaled file, if it’s below 6.1.7601.21744 it apply the fix and delete the PCI SlotPersistentInfo registry keys
            otherwise, it just skip the fix

            3 users thanked author for this post.
            • #187861

              @abbodi86:
              Thanks very much for the explanation. I had been confused after reading other posts which seemed to suggest it was KB4099950 which actually updated the pci.sys version. Then I also hadn’t understood earlier that the PCIClearStaleCache.txt Log file wasn’t going to reflect the updated version after KB4093118 updated it. I really appreciate the help from you and MrBrian in clarifying that for me.

              Linux Mint Cinnamon 19.3
              Group A:
              Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
              Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
              Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

    • #187433

      Group A, Win 7-x64. I installed KB4088875 in March and KB4093118 in April, both in their original versions. I hid KB4099950 when offered in late March as it was offered unchecked via WU. I have therefore confirmed via my list of installed updates that KB4099950 has never been installed on my computer. My question is whether the cumulative May rollup will correctly install KB4099950 as that cumulative update should contain the latest version of KB4093118 which executes KB4099950. What is beyond my knowledge base is whether the metadata associated with the latest version of KB4093118 will prevent KB4099950 from installing when the May rollup detects a prior installation of KB4093118 (even if it was the original version released on April 10th). Any opinions would be most appreciative.

      • #187471

        The nic fix is included in the April updates so you can jump over the March cumulative update and install the April cumulative update.

        Susan Bradley Patch Lady

        4 users thanked author for this post.
    • #187441

      It would be nice if Microsoft would come up with one patch to fix all of this and tell us that this one patch will fix and correct all bad patches, wrong order installs, and what ever else is they messed up.

      3 users thanked author for this post.
      • #187473

        Microsoft would like non enterprise patchers to use the cumulative update patches rather than the security only.  If you want the security only I would uninstall https://support.microsoft.com/en-us/help/4099950/nic-settings-are-replaced-or-static-ip-address-settings-are-lost-after if you installed it before 4/17 and reinstall the new version.

        Susan Bradley Patch Lady

        • #187493

          Win7 Pro, 64bit, Group B

          i did install the March IE11 patch and MSRT, and the Meltdown patch KB4100480

          i’m still waiting for the all clear on the MARCH security only patch… or did i miss something?

          does this 4099950 have to be installed before installing the March Security Only patch also?

          thanks

        • #187500

          … and Enterprise patchers too, except for niche cases.

    • #187468

      Anyone care to speculate why Microsoft put version checks for pci.sys in KB4099950?

      3 users thanked author for this post.
      • #187478

        Anyone care to speculate why Microsoft put version checks for pci.sys in KB4099950?

        Do you have any ideas?

        Carpe Diem {with backup and coffee}
        offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
        offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.674 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
        online▸ Win11Pro 22H2.22621.1194 x64 i5-9400 RAM16GB HDD Firefox110.0b9 MicrosoftDefender
      • #187491

        Well, when I installed the pre-April 17 version of 4099950 from Windows Update, my pci.sys file (in Windows\system32\drivers) was updated from 6.1.7601.17514 to 6.1.7601.24056.

        The pre-April version of 4099950 consisted of only a stand alone file. When I later downloaded the post-April 17 version of 4099950 from the Update Catalog, it contained an additional file which was an .exe file, and when I ran that, I got a .txt file in Windows\logs telling me my pci.sys file was now 6.1.7601.24056 – which I already knew. The .txt file had one other statement, something to the effect that this pci.sys file version was consistent with KB 2550000 or later. (Unfortunately, I don’t have access to the computer I did this on right know, so I can’t read the .txt file; and it wasn’t exactly KB 2550000 but pretty close)

        So, it seems to this non-techie that the post April 17 .exe file is probably not doing anything other than mess with or fix metadata and is doing nothing as far as actually fixing the IP and NIC problems. Presumably, those latter problems were already fixed by the pre-April 17 4099950 version.

        This also leads me to think that if one doesn’t use Windows Update but instead downloads all updates from the Update Catalog, that uninstalling and then reinstalling is not necessary.

        3 users thanked author for this post.
      • #187499

        I replied in other threads. After a certain version, the pci.sys ignores the registry value causing problems. The registry value is not a bug, it is a part of the PCI Express standard and Microsoft did a strict implementation of the standard which causes problems. By patching, in fact that part of the standard gets ignored and the behaviour reverts to PCI, not Express. First time the pci.sys was patched in 2011, next in KB3125574. See my recent other posts for links and better explanations.

        1 user thanked author for this post.
        • #187503

          Bear with me here since I’m neither a computer scientist nor software engineer.

          I think you’re saying that there is a registry value that potentially causes the NIC and static IP issues. If the version of pci.sys is “old”, then that version of pci.sys pays attention to the registry value and an NIC and/or IP issue ensues. Conversely, if the pci.sys version is “new”, then that new version of pci.sys ignores the registry value and there is no NIC/IP issue.

          Since my pci.sys version was updated when I installed the pre April 17 version of KB4099950, this new version ignores the registry value and all is well. When I ran the .exe file that was added to 4099950 in it’s post April 17 version, apparently all that happened was that a .txt log file was generated which stated that the pci.sys file had been updated. But, since this was something I already new, it seems that running the .exe file was pointless, unless the .txt file that was generated in the Windows\logs folder is somehow acting as a script and somehow telling the computer – or perhaps “reminding” it – that a new version of pci.sys actually exists.

          This all seems to argue that uninstalling and then reinstalling 4099950 is not necessary, and that even the pre April 17 version of 4099950 is enough to prevent the NIC/IP issues.

          If true, this is important to me at least since these days it seems that the less that’s done to a Windows computer, the better that computer will be.

          3 users thanked author for this post.
          • #187558

            @drbonzo
            I have already repeated few times in other recent posts, and other MVPs did so as well, that the behaviour is exactly as you described it. The reason to reinstall KB4099950 is not functional for Windows, but to “clean” the Windows Update detection mechanism for future updates to be detected and superseded correctly.
            EDIT: Do not run the .exe directly, but the .msu to correctly fix the Windows Update detection mechanism.
            I think Microsoft has created far more problems than it resolved by releasing KB4099950, but it seems that there was no other reasonable way to fix the non-technical (“home”) users’ computers broken temporarily by the newer version of pci.sys.
            The technical users (not all, but those who have a certain level of skill) know how to fix the issue by removing in the correct order the ghost NICs with Device Manager by setting an environment variable to show all hidden devices.

            4 users thanked author for this post.
            • #187658

              ? says:

              is this the correct way to temporarily  “show non-present devices”.

              https://technet.microsoft.com/en-us/library/ff184583.aspx

              thanks

               

            • #187668

              It is one correct way, but not what most people would do.
              Microsoft’s recommendation sets the variable per user, per session, but not per machine. When the session is closed by the user logging off, the variable will disappear and next time needs to be set again.
              You have to be logged on as an administrator of the local machine for what follows.
              Try this (set per-machine). Right-click on My Computer from Start Menu, select Properties and from there select Advanced System Settings. You can reach this item from Control Panel/System which is equivalent.
              Under Environment Variables, System variables enter:
              DEVMGR_SHOW_NONPRESENT_DEVICES and set value 1.
              Click OK and next time when you open Device Manager, you will see the hidden devices.
              The value will stick between reboots.
              The procedure is useful only for Windows 7 / 2008 R2 Server or previous versions.
              Not useful anymore in Windows 8 and later as an incomplete variation is already implemented and not tweakable.

              1 user thanked author for this post.
            • #187709

              ? says:

              excellent, and thank you, sir! as i have always run as admin i haven’t thought the user session implication(s). i’m way behind on windows 8, 8.1 and 10. still trying to figure out 7, and am anxiously awaiting ubuntu 18.04lts to see how it runs because complying with the “new” microsoft model is not an option.

    • #187492

      Reddit user netwarrior20 is purportedly a Microsoft Escalation Engineer assigned to this issue. Here are netwarrior20’s comments at Reddit: https://www.reddit.com/user/netwarrior20/comments/.

      • #187613

        Is there anyone with a Reddit account (or willing to make one) willing to ask netwarrior20 questions at Reddit?

        • #187673

          I have a Reddit account. What would you like to ask?

          1 user thanked author for this post.
          • #187691

            Please ask him whether IHO there is any reason/need to uninstall either March Security update after uninstalling kb4099950 and reinstalling from the catalog as the MS suggestion doesn’t mention the need.

            FWIW, I removed and replaced kb4099950 from the catalog on 4/17 per MS instructions but nothing else. Not aware of any network problems and Win 7 Pro x64 Group B humming along just fine, touch wood! 😉

            For the heck of it, turned on Windows Update and ran a check and was offered kb4093118, the MSRT, Defender update and the old telemetry patch and (5) Office 2010 patches; hid the rollup and telemetry and turned WU back off for now. Since I was offered the April rollup, would appear to me that WU isn’t broken.

          • #187740

            “I have a Reddit account. What would you like to ask?”

            Any questions that you or other AskWoody users want answered :).

            1 user thanked author for this post.
          • #187843

            Questions for netwarrior20:

            1. For those that are experiencing either of the two networking issues introduced in the March 2018 Windows 7 updates, does uninstalling the problematic update(s) (and then rebooting) undo the issues a) never, b) sometimes, or c) always?

            2. For those that are experiencing either of the two networking issues introduced in the March 2018 Windows 7 updates, what is your recommended procedure for fixing these issues, assuming that one has physical access to the affected computer?

            1 user thanked author for this post.
      • #187631

        I never absorbed that site or how it works or mean
        seems pretty casual 😀

        1 user thanked author for this post.
        • #187669

          Ask me about the amateurism on answers.microsoft.com if you think reddit is too bad 🙂
          Maybe we should recommend patchmanagement.org as a site with poor rendering, but high quality discussions.

          1 user thanked author for this post.
    • #187532

      https://www.computerworld.com/article/3216425/microsoft-windows/microsoft-patch-alert-april-patches-infested-with-bugs-but-most-are-finally-contained.html

      If you’ve installed the earlier, buggy version of the NIC and static-IP defending patch KB 4099950, do you need to uninstall it before proceeding?

      https://support.microsoft.com/en-us/kb/4099950

      This update must be installed before you install KB4088875 or KB4088878.

      If you have previously installed KB4099950 prior to April 17, 2018 please uninstall the older version of KB4099950 and reinstall to assure you have the most recent version.

      2 users thanked author for this post.
      • #187620

        But that begs the question of whether it’s necessary to uninstall the old KB 4099950 (if you have it) before installing this month’s Cumulative Update. That isn’t clear at all, at least to me.

        If it’s necessary, then I have to tell a whole bunch of folks (who aren’t particularly interested in technical stuff) precisely how to manually identify and clobber the old version, before they’re ready to release this month’s Automatic Update.

        3 users thanked author for this post.
        • #187633

          There is no new or old version of KB4099950 or KB4093118, the binaries is exactly the same since the release, only the extra WU/WSUS data differ

          KB4093118 alone is very enough to fix the issue, whether you have KB4099950 or not
          KB4099950 is just MSU wrapper for PCIClearStaleCache.exe, which is part of KB4093118

          4 users thanked author for this post.
          • #187676

            OK…

            So what would you recommend for the typical Win7 user who doesn’t have Automatic Update turned on, prior to installing this month’s (current version of the) Monthly Rollup? Do they need to look for KB 4099950 in Update History, and delete it if they find it?

            1 user thanked author for this post.
            • #187685

              Probably not, if the user is completely non-technical. They should keep installing whatever comes on top of the existing patches.
              For anyone else, uninstall KB4099950 only if it is not the latest version. This is only to make WU detection and supersedence interpretation a little bit more reliable. The word “reliable” needs to be seen in context. 🙂

              2 users thanked author for this post.
    • #187623

      If anyone’s interested in testing and has VMware, here are some purported methods to create this issue: https://blog.scottlowe.org/2011/11/25/problem-with-vmxnet3-driver/.

      • #187677

        Good idea!
        Just a word of warning. The tests have to be performed on the enterprise version of VWare product which is vSphere. The product is free for this purpose, but still require available and supporting hardware. Does not install on top of Windows, it is a stand-alone virtualisation product/hypervisor.

    • #187646

      As a person who uses Windows 7 X64, and follows Group B Security Only updates, If I go ahead and follow the latest information about what need to be done to install KB4099950, this will be the 4th install of this update for me.

      1. The first time I installed KB4099950 (April 8), it was suggested that I go ahead and install a second updated & unchecked copy I was given in WU (First copy April 1 & second update April 7). Because woody had moved to Defcon3, on April 8 I took the given advice and went ahead and installed KB4099950 using WU. That same day I installed the following March updates in the following order: KB4099950, KB4088878 & KB4099467 together before rebooting, and then finally KB4090640. All went well.

      2. The 2nd time I installed KB4099950 was on April 16 after reading numerous Askwoody posts reporting an issue with the WU version of KB4099950. It was reported that the issue was not present in the catalog version and should installed instead of the one offered in WU. Knowing that KB4099950 was a precursor to installing KB4088878, I chose to restore my system to just prior to the March updates. That way I could go ahead and install the catalog version of KB4099950 along with the other updates in the same order I used originally… Both the restore and the reinstall of the updates went off without a hitch…

      3. The third time was on April 24. On April 17 an updated catalog version of KB4099950 was offered and Microsoft stated the following about the new update:

      A. This update must be installed before you install KB4088875 or KB4088878.
      B. If you have previously installed KB4099950 prior to April 17, 2018 please uninstall the older version of KB4099950 and reinstall to assure you have the most recent version.

      After the announcement about the April 17 update, there was much discussion here on Askwoody about the proper way to go about replacing the pre April 17 version of KB4099950. Between what Microsoft had posted, and the various advice given as to why there was no need to restore my system like I’d previously done to reinstall KB4099950, I went ahead and uninstalled the exiting version and then installed the new version without a hitch.

      4. The Forth installation of KB4099950 has yet to take place because now there seems to be new updated trains of thought as to what needs to be done to install it correctly.

      A. CH100 states the following: I would say that you should follow what @abbodi86 says. Before running the updated KB4099950, msu version, you should uninstall the old KB4099950 and the March 2018 updates, all of them if you installed multiple updates belonging to that month.

      https://www.askwoody.com/forums/topic/a-protocol-question-about-kb-4099950/#post-187424

      B. Susan Bradly states the following referencing Microsoft: Microsoft would like non enterprise patchers to use the cumulative update patches rather than the security only. If you want the security only I would uninstall if you installed it before 4/17 and reinstall the new version.
      https://support.microsoft.com/en-us/help/4099950/nic-settings-are-replaced-or-static-ip-address-settings-are-lost-after

      https://www.askwoody.com/forums/topic/a-protocol-question-about-kb-4099950/#post-187473

      C. Abbodi86 state the following: Answer 2: April Security-only update does not contain pci.sys, so it’s not affected with the mess and can be installed safely it’s the March Security-only that need to be uninstalled/reinstalled if KB4099950 was not properly installed

      https://www.askwoody.com/forums/topic/a-protocol-question-about-kb-4099950/#post-187379

      To say the least this is all very confusing to me. It appears to me that each of the 3 recommendations is indicating something different about how to correctly install the new version of KB4099950.

      Help sorting this all out would be appreciated….

      5 users thanked author for this post.
      • #187692

        @twbartender – I’m a non-techie, but here’s my take on 4099950.

        1) 4099950 is not a security patch; so if you don’t install it you haven’t made yourself vulnerable to a security threat.

        2) the only thing the new version of 4099950 does that the old version didn’t is “fix” metadata so that Windows Update might be more reliable/accurate in what it offers to you. So, if you don’t care whether Windows update offers you the “correct updates” then you don’t need the newest version of 4099950. (See post#187676 from Woody above and ch100’s reply)

        3) the only reason for installing 4099950 before installing other updates (Rollups or Security Only) is to prevent potential NIC/IP problems which might arise due to the Rollup or Security Only installation. It’s entirely possible that your computer would not experience the NIC/IP issues even without installing 4099950.

        So, it seems to me that if you have any version of 4099950 and the March Rollup or Security Only updates and your computer is working fine, then you’re set to either install the April Rollup (which has 4099950 imbedded in it anyway) or the Security Only patch (which is apparently not affected by NIC/IP issues anyway)

        I personally don’t care if Windows Update works or not, since I do almost all of my updating straight from the Update Catalog. Ironically, the reason I find myself interested in the 4099950 issue is because for some reason I decided to install 4099950 from Windows Update instead of from the Catalog!

        The above is the approach I’m taking unless someone with serious street cred tells me I’m an idiot. 🙂

        EDIT: I want to add that I believe the important thing as far as preventing NIC/IP problems is the presence of a pci.sys file in the Windows\system32\drivers folder that has a version number of 6.1.7601.21744. My old version was 6.1.7601.17514 but my new version after installing the new 4099950 is 6.1.7601.24056.

        3 users thanked author for this post.
        • #187695

          DrBonzo, your reply was helpful for me because I haven’t installed 4099950 at all. I have installed security only + IE + Office updates through March in addition to 4100480 to mitigate Total Meltdown. I haven’t experienced any networking issues. So, do I need to install 4099950 at all? I’d prefer to avoid uninstalling 4088878 to install the latest/greatest 4099950 if I can. Thanks for all responses.

          Edit: I just went to retrieve the latest 4099950 from the Catalog in order to have it for safe keeping (just in case) and I saw the following exe file pciclearstalecache_1c944f48bfb21d88a2054683abcd02327ecf6b37.exe

          This was included with 4099950. Is it supposed to be run as well????

          Group L (Linux Mint 19)
          Dual Boot with Win 7
          Former
          Group B Win 7 64 bit

          • #187703

            In my opinion you don’t need to install 4099950 IF you don’t care about being offered correct updates from Windows Update.

            You might also want to check that your pci.sys file is “new”. See my edit to my post you just replied to. Although I personally would be tempted to leave your system as is since it’s working! But, I don’t know if having an old version might cause a problem on down the road.

            1 user thanked author for this post.
          • #187706

            That .exe file is what got added to 4099950 when the new version of 4099950 came out on 4/17. I believe that all it does is fix metadata/supersedence so that the likelihood of Windows Update offering correct updates to your computer increases. I believe that it does nothing to fix potential NIC/IP issues. But it seems that you don’t have any NIC/IP issues anyway (since you haven’t installed any version of 4099950 and your computer’s working fine). So, I don’t think you need to run the .exe file. As you said, though, it’s probably a good idea to have that file handy just in case.

          • #187715

            So, what one should do with that executable?

            I have asked it more than once here, so far no answers.

            Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

            MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
            Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
            macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

        • #187707

          @DrBonzo

          Thanks for your reply, it’s much appreciated. For me it isn’t a matter of should I be bothered installing KB4099950. It’s more a matter of the sheer volume of different and sometimes conflicting advice that’s been given out over the last 3 weeks on how to deal with the update. I don’t know how to prevent it, but I do know there are a lot of other non techies out there who are at least as confused as I am when it comes to looking for non-conflicting answers on how to deal with KB4099950.

          Just to be clear:  I mean no disrespect to any MVP or fellow member who freely pass on their vast knowledge to help the other  members. For that I am very grateful.

          1 user thanked author for this post.
      • #187840

        @twbartender
        Thank you so much for venting your frustration over the saga of KB4099950. I feel exactly the same. I don’t know which way to turn at the moment. There has been so much advice provided over multiple threads and I am thoroughly confused.

        1 user thanked author for this post.
    • #187693

      @YP

      Perhaps a simply statement version pci.sys  should be at least xxx.xxx would clear up some of the confusion.  I believe @abbodi86 did mentioned version earlier; I can’t find it right now.  I thought woody also somewhere.  May I ask @abbodi86 to comment or repost the version.

      Many thxs to all, and hope Ixm not off base.

      1 user thanked author for this post.
      • #187699

        pci.sys 6.1.7601.21744 or later

        1 user thanked author for this post.
        • #187737

          pci.sys 6.1.7601.21744 or later

          Ugh.  I’m one of the folks who downloaded 4099950 from the Catalog on April 8th, and installed it, along with March’s Updates.  My pci.sys version shows 6.1.7601.17514, an older version.

          Looks like I better uninstall 409995 and then download/reinstall the newest version of 409995 from the Catalog [Last Updated 4/17/2018] to update the pci.sys version number.

          For what it’s worth, here’s the content of the text file (PCIClearStaleCache):

          Path = C:\windows\system32\drivers\pci.sys
          pci.sys file version is 6.1.7601.17514
          Pci.sys indicates KB2550978 or later KBs *NOT* installed
          Deleting the PCI SlotPersistentInfo registry keys…
          Deleted PCI SlotPersistentInfo registry keys successfully

          Win 7 SP1 Home Premium 64-bit; Office 2010; Group B (SaS); Former 'Tech Weenie'
          1 user thanked author for this post.
          • #187741

            Afterward, install the April Rollup of SO

            1 user thanked author for this post.
            • #187744

              install the April Rollup of SO

              Thank you, PKCano.  I’m “assuming” you mean April SO, and not Rollup 🙂

              Win 7 SP1 Home Premium 64-bit; Office 2010; Group B (SaS); Former 'Tech Weenie'
            • #187745

              That should have been an OR, not of
              Rollup OR SO

              And the March too.

              1 user thanked author for this post.
            • #187933

              Last night, in my post above ( #187737), the version number I had found was 6.1.7601.17514, from the PCIClearStaleCache text file.

              After reading through the “New” comments today, I decided to go directly to C:\Windows\System32\drivers\pci.sys.  This time I right-clicked and selected “Properties.” Under the ‘Details’ tab is noted the version number.  It is the same version that TonyC and others have posted — 6.1.7601.24056.  And as PKCano posted later ( #187864), the version was updated by installing March’s SO update (which I had on April 8).

              Many thanks to PKCano, MrBrian, DrBonzo, TonyC, and others for posting their processes and results!  I’m thinking that I do not have to uninstall and reinstall after all.

              Win 7 SP1 Home Premium 64-bit; Office 2010; Group B (SaS); Former 'Tech Weenie'
              1 user thanked author for this post.
        • #187862

          After installing the previous version of KB4099950, along with the March security only update + others, on the 8 April 2018 @MS-DEFCON 3, my pci.sys is 6.1.7601.24056. (KB4099950 was downloaded from the Catalog.) Does that mean that I don’t need to do anything despite Microsoft’s advice to uninstall the previous version of KB4099950 and install the new version?

          I’ve just taken a look at PCIClearStaleCache.txt in C:\Windows\Logs and its contents are:

          Path = C:\Windows\system32\drivers\pci.sys
          pci.sys file version is 6.1.7601.17514
          Pci.sys indicates KB2550978 or later KBs *NOT* installed
          Deleting the PCI SlotPersistentInfo registry keys…
          Deleted PCI SlotPersistentInfo registry keys successfully

          Well, as stated above, my pc.sys is at the 6.1.7601.24056 level, NOT 6.1.7601.17514, so the information in this file is wrong. Does this mean that I should follow Microsoft’s advice after all?

          1 user thanked author for this post.
          • #187864

            The later version of pci.sys was installed by the March Security update after 4099950 fixed the problem
            Deleting the PCI SlotPersistentInfo registry keys…
            Deleted PCI SlotPersistentInfo registry keys successfully

            2 users thanked author for this post.
            • #187876

              So, are you saying that, in my case, the KB4099950 that I downloaded from the Catalog and installed on the 8 April 2018 actually performed correctly? … and therefore I don’t need to do anything else?

              And thank you for informing me that it was the March security only update that installed the later version of pci.sys. Having read elsewhere that KB4099950 did not do it, I was beginning to wonder what did.

              1 user thanked author for this post.
            • #187924

              I believe that you’re OK. I also believe that the log file incorrectly reported the pci.sys file version. A few other posters have reported the same error. If you’ve verified that your pci.sys file version really is the new version – and it sounds as though you have verified this – then I think you’re OK.

              1 user thanked author for this post.
            • #187968

              @DrBonzo:

              I also believe that the log file incorrectly reported the pci.sys file version. A few other posters have reported the same error.

              Just fyi, looking at MrBrian’s (and abbodi86’s) recent postings in this thread (for example this series starting at https://www.askwoody.com/forums/topic/a-protocol-question-about-kb-4099950/#post-187766 and this one starting at https://www.askwoody.com/forums/topic/a-protocol-question-about-kb-4099950/#post-187762), it’s not that the log file is an error.

              MrBrian and abbodi86 explained that KB4099950 doesn’t update the pci.sys file but only checks it and takes action in the registry if needed. So, the PCIClearStaleCache log file just reflects what KB4099950 did before the April roll-up (or March security-only or roll-up) updates the pci.sys version.

              I didn’t understand that earlier and thought that the log file would show the updated file version, which is not the case (or at least wasn’t the case for those of us who had the .17514 file version earlier). That’s why one has to check the pci.sys file version in C:\Windows\System32\drivers to verify that the file version has been updated.

              Linux Mint Cinnamon 19.3
              Group A:
              Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
              Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
              Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

              2 users thanked author for this post.
            • #188011

              Yes, I believe you are correct. I did not totally understand what the patch did.

              2 users thanked author for this post.
      • #187700

        I believe pci.sys needs to be 6.1.7601.21744 or later; the last 5 digit number will be higher for a newer version.

        1 user thanked author for this post.
    • #187721

      (Win7 Professional, 64bit,Svc.Pk 1 Group A). Yesterday I reported that I had 4100480 previously installed and 4099950 installed on 4/23 from catalog, and 4099467 installed 4/25 from catalog and YESTERDAY INSTALLED APRIL ROLLUP KB4093118. Everything is still PERFECT! No Stop errors OxAB and have been logging off a lot.
      My question: Please forgive my ignorance: I’m not tech savvy enough to understand the exe version of 4099950 – what I installed from the catalog was: 2018-04-update for windows 7 for x64-based systems (KB4099950). Is this sufficient or is there another version?
      I hope my good fortune with the April Rollup is encouraging.

      • #187725

        In the process of the manual installation of KB4099950 (.msu) you will see a brief flash of a command prompt as it executes the script in the .exe file. All you have to do with the two files is double click on the .msu

        • #187728

          @PKCano
          Thanks so much for the speedy reply. Since I’m Group A with no former experience of the catalog I found the download procedure a little awkward. At any rate, would you say that the file that I did install is sufficient? Everything is working and I’m reluctant to fuss with it anymore if I don’t have to. Thanks for all you do for us!

          • #187731

            You should be fine.
            Hopefully, after the April updates are behind us, things will settle back to “normal” again.

            I don’t think it’s time yet to be thinking about the microcode/firmware updates. And I suspect the installations I have on hardware will be WAY too old to even hope for them. I suspect many of you are in the same boat.

            FWIW, I bought my first Mac (13″ MacBook Pro – the one with the slot CD drive) in 2011. Early dual core i7, 4GB RAM and 512GB HDD. I upgraded to 16GB RAM and 512GB SSD a few years back. The screen is still beautiful, it runs XP/Win7/Win8.1 VMs and the latest MacOS. Ant the updates are seamless and no stress. If it had been a Win laptop, I’d have bought 2 newer ones by now. But it still runs fast.
            I stay with Win (all versions from XP to Win10 1709 and Insiders) to be able to help where it’s needed. And Windows has certainly been in need of help lately!

            1 user thanked author for this post.
        • #187735

          Curious PKCano,
          When I downloaded 4099950, I also had to download the exe file that was included with it. Otherwise, the only file downloaded was 4099950, no exe. And, from what I’m interpreting, you only need to double click 4099950 to install both?? Thanks.

          Group L (Linux Mint 19)
          Dual Boot with Win 7
          Former
          Group B Win 7 64 bit

      • #187730

        I’m not tech savvy enough to understand the exe version of 4099950

        It could be that you aren’t seeing .exe or .msu file extensions, because they are hidden by default in Windows. You can enable seeing the file extensions by:

        Go to start button and click on a file… that opens Window Explorer.

        Click on Organize, then Folder and Search Options.

        Open the View tab.

        In the advanced section uncheck “Hide extensions for known file types” and click apply. You should see the file extensions at the end of file names after this.

        When you look at your files, again, the extensions should be visible.

        It is a good idea to know what file type you are dealing with… one of the first things I learned from Woody… years and years ago.

        Non-techy Win 10 Pro and Linux Mint experimenter

        3 users thanked author for this post.
        • #187750

          @Elly
          Thank you so very much! I opened Windows Explorer – it was slightly different in Windows 7 — the route was Start, All Programs, Accessories, etc. I unchecked “Hide extensions for known file types”. I then went to the MSU and took a look and saw that there are indeed two files for 4099950. I saved them both in “downloads”. Unfortunately, I don’t know which version I installed on 4/23 because I deleted that file after installation. Is there any way for me now to know which version I installed? If not, should I uninstall it and reinstall the msu version? Or is this all moot since the KB4093118 April rollup installed from Windows Update yesterday would have the proper version of KB4099950.
          Thanks again Elly — I’m learning so much from the generous people here. 🙂

          1 user thanked author for this post.
          • #187752

            There is only one 4099950. The .exe file has a different name. So you installed the right one on 4/23.

            1 user thanked author for this post.
            • #187754

              @PKCano
              Blessings to you for this good news! I’m disgusted with myself for this obsessing over KB4099950. The only bright spot in all of this is I am learning more about my computer and in the future I’ll be in a better position to at least understand what you kind people are saying and to then implement your instructions!

              2 users thanked author for this post.
          • #187753

            My understanding is that 4099950 automatically gets installed when 4093118 gets installed. So, you should be fine as far as 4099950 is concerned.

            1 user thanked author for this post.
    • #187734

      Thank you DrBonzo;
      OK, so as I mentioned above, I haven’t installed 4099950 and I don’t have any networking issues. I’ve checked my pci.sys file and it’s 6.1.7601.24056 dated 4/8/18. I’m assuming the pci.sys file is new enough given the other numbers mentioned in this thread. So, given this, can I simply skip 4099950 and continue onward with security only, IE, and Office April updates?

      I just hope down the line, I don’t have to rely on WU alone for security patches and this potentially botches it up.

      Since 10/2016, I’ve utilized only the AKB2000003 security and IE 11 identified updates.

      Thanks everyone for all your expertise. These are difficult days for Win 7.

      Group L (Linux Mint 19)
      Dual Boot with Win 7
      Former
      Group B Win 7 64 bit

      • #187738

        We are both in exactly the same place right now, patchwise. I’m going to wait until Defcon3 before installing the April Security Only and IE11 patches.

        If you’ve been doing Security Only and IE11 updates since 10/2016, then you’re not very reliant on Windows Update, and I would think you’ll be fine.

        1 user thanked author for this post.
    • #187758

      KB 4099950 is bundled with the April Rollup KB 4093118. However, if you installed KB 4099950 before the April 17th revision, it may not be installed correctly. If you did this, I would recommend that you uninstall KB 4099950 and reboot prior to installing the April Rollup KB 4093118.

      Okay so I followed your instructions today but I am not sure if was the right thing to do.

      (Window7 x 64 Group A) I HAD the original version of KB4099950 (installed on April 8th) so I uninstalled per your instructions (did NOT have March rollup installed), rebooted pers your instructions and then installed the April rollup KB4093118. Upon checking my pci.sys file version (finally figured out how) hours after doing all that and it says this:

      Path = C:\windows\system32\drivers\pci.sys

      pci.sys file version is 6.1.7601.17514

      Pci.sys indicates KB2550978 or later KBs *NOT* installed

      Deleting the PCI SlotPersistentInfo registry keys…

      Deleted PCI SlotPersistentInfo registry keys successfully

      I am under the understanding that the pci.sys version is supposed to be higher than that. So obviously the rollup did not give me the updated version of KB4099950.

      What do I do now??????? Someone PLEASE ADVISE ME!!

      1 user thanked author for this post.
      • #187761

        You probably ran the instance of KB4099950 that produced that log file before you installed KB4093118 and rebooted.

        1 user thanked author for this post.
        • #187763

          MrBrian, I am not sure what you mean by that??? Can you clarify?

          • #187766

            The info in the log file produced by KB 4099950 is probably correct info for the time that that instance of KB 4099950 was installed by you. Later, you probably installed KB4093118 and rebooted, after which the pci.sys version should be newer.

            1 user thanked author for this post.
            • #187769

              The log file says it was made today at 4pm. I UNINSTALLED the oldest version of KB4099950 but did NOT install the new version because according to PKCano it was included in the April rollup KB4093118. Immediately after uninstalling the updated I rebooted as per instructed and immediately upon rebooting I installed the April rollup and rebooted again. It has been hours since I have done this and when I figured out how to check the log that is what I got.

            • #187771

              Installation of KB4093118 should run the equivalent of KB4099950 before KB4093118 installs. Thus the same logic holds.

            • #188399

              @Mr.Brian:   Please tell me what this “pci.sys” is?  I have never heard of it previously until now.  My OS is Win Home Prem., x64, Group A.  Thank you for all of the up-to-date information you keep us all informed of, as always.   🙂

            • #188403

              pci.sys is a file that has received some attention here in the past few months due to two networking issues introduced in the March 2018 Windows 7 updates. If you follow Woody’s directions though, you shouldn’t need to concern yourself with it.

              1 user thanked author for this post.
        • #187764

          @MrBrian:
          So are you saying that if she looks at the actual pci.sys file in the drivers file, she would see a higher version?

          Linux Mint Cinnamon 19.3
          Group A:
          Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
          Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
          Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

          2 users thanked author for this post.
          • #187767

            @jburk

            How would I do that?????

            • #187772

              KarenS,

              What I did is this:
              Using Windows Explorer, go to C:\Windows\System32\drivers.
              Scroll down to pci.sys,
              right-click the file name,
              click Properties, and
              click the Details tab.

              What I see there is Product version 6.1.7601.17514, but I haven’t installed KB4093118 yet, just the latest version of KB4099950.

              I don’t know if this is the right way to check the actual file version. Maybe MrBrian can let us know if it is or if there’s someplace else we should look.

              Linux Mint Cinnamon 19.3
              Group A:
              Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
              Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
              Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

              2 users thanked author for this post.
            • #187775

              @jburk

              I can open Windows Explorer but I don’t see c:\Windows\Systems32\drivers in the list of options to click on.

            • #187779

              Under C:, scroll down to the Windows folder.
              Expand the Windows folder (click the litte arrow on the left) and scroll down to the System32 folder.
              Expand the System32 folder, scroll down to the drivers folder.
              Expand the drivers folder and scroll down to pci.sys.
              Then right-click pci.sys and continue as described above.

              Linux Mint Cinnamon 19.3
              Group A:
              Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
              Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
              Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

              2 users thanked author for this post.
            • #187782

              @jburk

              Thank you so much for your detailed instructions I FINALLY got to where I needed to be and found that my pci.sys version is 6.1.7601.24056 which is exactly what MrBrian said it should be.



              @MrBrian
              Thank you to you as well for your help.

              Sorry for all the questions but I feel safer now and I can go to sleep not worrying about this anymore.

              1 user thanked author for this post.
            • #187784

              KarenS,
              So glad to hear this, both for you and for me, after I install KB4093118! Thanks to MrBrian for clearing this up.

              Linux Mint Cinnamon 19.3
              Group A:
              Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
              Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
              Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

              1 user thanked author for this post.
            • #187776

              @jburk07: That is correct :).

              After the first reboot after installing KB4093118 on Windows 7, the pci.sys version should end in 24056.

              5 users thanked author for this post.
            • #187778

              The pci.sys file is located in the following path:

              C:\windows\system32\drivers\pci.sys

              Then look at the information details of the file to find its version.

               

              Edited for HTML. Please use text tab for copy/paste in reply box.

              1 user thanked author for this post.
          • #187768

            I think so indeed.

            3 users thanked author for this post.
    • #187871

      … I will also add that I don’t care at all about a functioning Windows Update – as long as it doesn’t download or install anything without my permission. I’m perfectly happy to do all my updating from the Microsoft Update Catalog. …

      As someone in Group B, I do care about how well Windows Update functions. Each month, after installing the security only update and the IE11 cumulative update from the Catalog, I am supposed to switch to Windows Update for the remainder of my updates.

      1 user thanked author for this post.
      • #187925

        I understand your point of view!. I’ve developed the view over the last 1.5 years that the less I depend on Windows Update the better off I am. It was a bit tedious to find the other patches I wanted (for .NET, occasionally), not at all bad once I got used to doing it.

    • #188060

      Call me Bwanna.

      There seems to be little help for those with W7 in Group B this month. Most posts focus on Group A advice.

      Here is the situation:

      1. Security-only updates (and IE 11 updates) have been installed successfully through February 2018.

      2. KB 4099950 was then installed prior to April 17 using the .msu file, followed by KB 4088878 (March security-only update) and KB 4099467 (fix for potential BSOD).

      3. KB 4100480 was then installed using the .msu file.

      4. Finally, KB 4096040 (March IE 11 update) was installed.

      THIS RESULTED IN THE LOSS OF MY INTERNET CONNECTION (caps for emphasis only) and required a restore to get the connection back.

      5. After the restore, I repeated steps 2, 3, and 4, and all was okay. However, no March security-only update is currently installed.

      Now, what should I do about the April security-only update? FYI, the pci.sys is currently reading as 6.1.7601.17514 but apparently should be 6.1.7601.21744 or higher.

      Woody, PKCano, MrBrien, Susan B., or other knowledgeable individual, I would greatly appreciate the answers to the following questions:

      1. Since I’m strictly in Group B, and the March security-only update nixed my Internet, should I just skip March and go ahead and try the April security-only and IE 11 updates?

      2. Will the April security-only update change the needed pci.sys file or do I need to do something else for that? (The above information should guide your advice.)

      Any specific directions how to proceed would be appreciated. I, of course, will follow AKB2000003 recommendations once I know what to do.

      Thank you,
      Bwanna

      • #188068

        If the earlier copy of 4099950 is still installed, uninstall it.
        Reboot
        Download the latest version of 4099950 and install it. (download two files, double click only on the .msu file, it will install the .exe in the process)
        Reboot
        Install Mar and Apr SO and the Apr IE11 Cumulative Update. You can get them from AKB2000003.
        Reboot.
        Install whatever else you want from Windows Update.

    • #188155

      Response from netwarrior20 on Reddit.

      Question: I’m trying to put together recommendations for folks who are ready to use Auto Update to install the April Monthly Rollup. Big question is whether “typical” users need to look for KB4099950, check to see if they have the old or new version and, if it’s the older version, uninstall it. Is that necessary, given the republished KB4093118? Also, for those who uninstall the old KB4099950 and install the new 40999950, is there any reason to uninstall the March Monthly Rollup, prior to installing the April Monthly Rollup?

      Answer: If users are going to install the new 4093118 for April then they don’t need to be concerned about 4099950 even if already installed. 4093118 also contains the exe and will run it prior to booting based on the version of pci.sys already present.

      Users do not need to uninstall the March rollup regardless of whether or not they plan to install April. Again the only thing that counts is that the exe is run if deemed necessary, so if it runs via new 4099950 or via re-released April update (easier path) all will be good.

      Any diverging opinions?

      4 users thanked author for this post.
      • #188202

        Not diverging opinion. Only coming with further explanation for those still confused about what the newest (third) release of KB4093118 bundled with KB4099950 does.
        – While installing, KB4099950 assesses the version of pci.sys
        – If the version is lower than a certain version, it executes and deletes the registry value which causes issues. After that proceeds with the installation of KB4093118 and the updated pci.sys among other things.
        – If the version of pci.sys is higher, then KB4099950 does nothing and proceeds with installing KB4093118, including the updated pci.sys
        – At reboot, the registry key deleted is recreated because it is created anyway if missing, regardless of the patches. However, because now the version of pci.sys is above the known problematic version, the registry key is ignored and no longer creates problems.

        Feel free to add version numbers and the name of the registry value if needed.

        The sequence is sensitive to timing issues and this is the reason why in some instances it is desirable to perform the manual installation of KB4099950 in advance. For most people who are up to date and with WU in good working order should be fine though.

        3 users thanked author for this post.
        • #188269

          “At reboot, the registry key deleted is recreated because it is created anyway if missing, regardless of the patches. However, because now the version of pci.sys is above the known problematic version, the registry key is ignored and no longer creates problems.”

          According to this netwarrior20 comment (my bolding), those registry keys still do serve a purpose:

          “The script does indeed clear all the entries. This is to prepare the system for when the new pci.sys loads upon next boot.

          Simultaneously on next boot after the cache is now properly read (that’s the fix) and no new adapter instantiated, the existing adapter is now re-cached. That’s what you’re seeing with the new entries. The purpose of the new cache entries is to prevent a new adapter from being instantiated should the MAC address on the existing instance change.

          2 users thanked author for this post.
      • #188241

        The second part of answer is not accurate

        – The whole NIC/Static IP issues occur when new pci.sys version is installed without clearing old (stale) SlotPersistentInfo registry cache

        – The fix tool PCIClearStaleCache.exe is programmed to delete the SlotPersistentInfo cache only if pci.sys version is below 6.1.7601.21744

        – When March rollup KB4088875 is already installed, it bumps pci.sys version to 6.1.7601.24056, which would prevent PCIClearStaleCache.exe from applying the fix

        and his other answer support these states 🙂
        https://www.askwoody.com/forums/topic/a-protocol-question-about-kb-4099950/#post-188207

        uninstalling March update and installing re-released 4099950 + March update is the guidance.

        of course all of this does not matter is the machine does not suffer or contain stale SlotPersistentInfo cache

        2 users thanked author for this post.
    • #188195

      Windows 7 sp1 x64.

      Getting a bit confused now..

      I had Jan, and Feb SO patches installed, then rolled back as per patchlady’s advice. I never installed March’s patch, deciding to wait for April’s update and see where to go from here.

      So is it simply a case of running Jan and Feb again, then applying KB 4088878 for March and KB 4093108 for April? Does that mean I’d be patched against meltdown/spectre (again) and Total meltdown?

      I’d like to think so, but it all looks such a mess now I’m wondering if I’m maybe better just sitting where I am.

      I’ve kept up with things so far, but the last 2 months just seem like a minefield, you’re damned if you do, and damned if you don’t. It seems a case of choosing the lesser of two evils right now.

    • #188207

      Another response from netwarrior20.

      Four questions:

      1. For those that are experiencing either of the two networking issues introduced in the March 2018 Windows 7 updates, does uninstalling the problematic update(s) (and then rebooting) undo the issues a) never, b) sometimes, or c) always?
      2. For those that are experiencing either of the two networking issues introduced in the March 2018 Windows 7 updates, what is your recommended procedure for fixing these issues, assuming that one has physical access to the affected computer?
      3. Does Microsoft know that KB4099950 has been unavailable in Windows Update since approximately April 17?
      4. Is Microsoft aware that the documentation for KB4088878 stating that KB4099950 is applied automatically when installing KB4088878 is incorrect?

      Answer:

      1. We have seen some customers uninstall the March update, reboot, and see the settings come back again.
      2. If the issue has already occurred (IPs already lost) then uninstalling March update and installing re-released 4099950 + March update is the guidance.
      3. The first release of 4099950 was not recognized to have an exe if deployed via WSUS or WU. It was then re-released and since then is available via WSUS or WU. I haven’t heard of this update recently missing from WU.
      4. I am not aware that this is a mistake. I’ll query this with the team this next week.

      Again, any contrary opinions?

      6 users thanked author for this post.
      • #188240

        If I may say that those who followed Woody up to this point should be OK and should keep following Woody’s posts and recommendations.
        Those who installed early various patches against Woody’s MS-DEFCON system recommendations, they are those who need to tweak their updates in order to fix their WU.
        I should point out that Woody’s style of MS-DEFCON is too defensive for me personally, but I assume responsibility for my updates in test machines and adjust accordingly. At this stage I follow Windows 7 as hobby only, as I consider Windows 7 out-of-date, compared to Windows 10.
        For those who require specific instructions, Woody’s system proved once again fail-proof! 🙂

        3 users thanked author for this post.
      • #188270

        @Woody: Thank you for posting my questions :).

        Could you please inform netwarrior20 that KB4099950 has in fact been missing from Windows Update since around April 17?

        2 users thanked author for this post.
    • #188212

      Win 7 Pro Haswell 22 nm. Group B. Up to date as of March updates.

      Uninstalled 4099950 (originally installed from WU on 8 April, so old version) and 4088878 (installed afterwards from catalogue). Rebooted. Then re-installed 4099950 (catalogue version, .msu and .exe) followed by the same 4088878 (.msu). Rebooted. All as per Abbodi86’s advice – thanks, also to everyone else here.

      Did this about an hour ago – so far so good. Although both the .msu and .exe files for 4099950 were in the same folder, I didn’t the .exe script flash on momentarily as expected. However, I might have blinked at the time! Will just have to take it on faith that it executed OK. (BTW, I wasn’t having any problems before doing this, but I just wanted to ensure that this didn’t cause any problems with April updates, which I intend to install tomorrow if still no problems.)

      One question (slightly OT): Running .msu updates invokes the Standalone Installer. The first thing it does is go away for 5-6 minutes “Searching for updates on this computer” – even though I already clicked on the update to run. Then it asks me if I want to run the update I clicked on in the first place!?!? Anyone know why it does this?

      Thanks again!

      Dell Precision 3630 w/32 GB RAM, 500 GB (C:), 1 TB (D:)
      Window 10 Pro x64
      Internet: FTTC (Fibre to the Kerb)

      • #188216

        …invokes the Standalone Installer. The first thing it does is go away for 5-6 minutes “Searching for updates on this computer”… Anyone know why it does this?

        Is your internet connection disabled before you run the installer? I know it can sometimes take a little while to check, but the confirmation of the update you are wishing to install is your standard chance to make sure you’re doing what you thought you were doing.

        4 users thanked author for this post.
        • #188239

          Thanks Kirsty. I assumed that the last part was an “are you sure” check. I was mainly curious about why it had to search for updates when I had already specified the update required by double-clicking on its .msu file.

          I hadn’t disabled my internet connection. And it did say it was checking for updates “on this computer”. So I assume that it was searching my computer for that update. Perhaps double-clicking the .msu file just invokes the installer and passes to it the KB number of the patch (from the .msu file). Then the installer searches the PC for the .msu file for that patch – which would be a rather circular way of doing things!

          Dell Precision 3630 w/32 GB RAM, 500 GB (C:), 1 TB (D:)
          Window 10 Pro x64
          Internet: FTTC (Fibre to the Kerb)

      • #188275

        ‘One question (slightly OT): Running .msu updates invokes the Standalone Installer. The first thing it does is go away for 5-6 minutes “Searching for updates on this computer” – even though I already clicked on the update to run. Then it asks me if I want to run the update I clicked on in the first place!?!? Anyone know why it does this?’

        See my comments at Turn off Windows Update if you want to force-feed individual patches.

        4 users thanked author for this post.
        • #188452

          Thanks for your response. As I understand it, you are suggesting that the “searching” delay may occur if the use of the standalone installer happens to coincide with a WU scan. As this has happened for me every time I have installed a .msu patch over the last year or so, I am not sure that it is a coincidental clash. Rather, it seems that the standalone installer is INVOKING the search (as I think @ch100 is suggesting).

          While the search delay is a bit annoying, it doesn’t take that long. So I will just accept it in future.

          Thanks again.

          Dell Precision 3630 w/32 GB RAM, 500 GB (C:), 1 TB (D:)
          Window 10 Pro x64
          Internet: FTTC (Fibre to the Kerb)

          2 users thanked author for this post.
          • #188456

            You’re welcome :).

            What also happens is the update evaluates whether it is installed and installable on the given system.

            2 users thanked author for this post.
            LH, Elly
          • #188465

            Yes, msu actually contains a basic repair sequence too.
            But Group B and its supersedence is outside online WU (is known only to enterprise updating tools like WSUS and even there is buggy, inconsistent at times and as such not recommended unless forced by circumstances outside the control of the technical staff like compliance regulations or poor management instructions) and for this reason it may produce unpredictable outcome.
            This is the reason why msu runs for a longer time for those not fully patched (not in Group A).
            The workaround is to disconnect the network as it was mentioned here many times, but as I see it, is an extension of not patching correctly.

            1 user thanked author for this post.
      • #188445

        @LH Being in the so-called Group B makes you unpatched for purpose and intent of the msu stand-alone installer. You may actually find patches being applied without your knowledge just to bring your WU to consistency.
        Group B style of patching is not reliable unless managed by an enterprise grade system like WSUS or SCCM or equivalent third-party.

        1 user thanked author for this post.
    • #188287

      MrBrian, 1. So is it the rollup itself that is supposed to change the pci.sys version? 2. If so, then if dgreen (in post #187420 above) checks his pci.sys file (not the Log file from 4099950), he should find a higher version, like KarenS? Thanks for your help in clarifying this!

      jburk07
      Just want to let you know that I actually found the higher version.  I was looking in all the wrong places!
      BTW, not that it matters really, but I’m a she not a he. ( ;

      4 users thanked author for this post.
      • #188366

        @dgreen,

        Sorry for my pronoun mistake and thanks for the correction! I, too, am a “she” and should have kept my references gender-neutral. 🙂

        I’m glad your file version is correct. Your post was one of the ones that helped me understand, with the assistance of MrBrian and abbodi86, that the log file was not the place to look for the updated pci.sys version since it wasn’t what changed that version.

        By the way I think our machines are somewhat similar since your posts have also been helpful in the past (for example, when you posted that your restore points began disappearing without reason, my laptop did the same thing – and still does). So, thanks again for your posts.

        Linux Mint Cinnamon 19.3
        Group A:
        Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux
        Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro
        Win 10 Pro x64 v21H2 Ivy Bridge, dual boot with Linux

        1 user thanked author for this post.
    • #188306

      … The first release of 4099950 was not recognized to have an exe if deployed via WSUS or WU. It was then re-released and since then is available via WSUS or WU. I haven’t heard of this update recently missing from WU. …

      (Win7 x64 Group B) What I don’t understand is this. I downloaded the first release of KB4099950 from the Catalog on the 8 April 2018. The download comprised a single .msu file. So, from all external appearances, that release of KB4099950, deployed from the Catalog, did not have an associated .exe either. And yet it still appears to have worked on my system (according to the contents of PCIClearStaleCache.txt) when I installed it before the March security only update.

      The second release, which I downloaded for inspection on the 25 April 2018, comprised both a .msu file and pciclearstalecache.exe. How is it that the first release of KB4099950 worked without a .exe (apparently) while the second release requires an explicit .exe?

      (As far as I have been able to gather from various posts on the subject of KB4099950, the two .msu files are identical. They are certainly the same size.)

      2 users thanked author for this post.
      • #188331

        Per Abbodi86:

        – The whole NIC/Static IP issues occur when new pci.sys version is installed without clearing old (stale) SlotPersistentInfo registry cache

        – The fix tool PCIClearStaleCache.exe is programmed to delete the SlotPersistentInfo cache only if pci.sys version is below 6.1.7601.21744

        – When March rollup KB4088875 is already installed, it bumps pci.sys version to 6.1.7601.24056, which would prevent PCIClearStaleCache.exe from applying the fix

        Non-techy Win 10 Pro and Linux Mint experimenter

        • #188338

          @Elly
          I don’t think that answers the question. I’m in Group B and I installed the first release of KB4099950 (from the Catalog) BEFORE installing KB4088878 (the March security only update), which also “bumps” pci.sys to 6.1.7601.24056.

          When KB4099950 was installed, my pci.sys was at 6.1.7601.17514 but, after installation, PCIClearStaleCache.txt tells me that the PCI SlotPersistentInfo registry keys had been deleted. So, if there was no associated pciclearstalecache.exe with the first release of KB4099950, what deleted the PCI SlotPersistentInfo registry keys?

          1 user thanked author for this post.
          • #188357

            KB4099950 already include the exe since the beginnning, and running the msu file directly would execute it

            the problem was never in KB4099950 itself, it’s in the way it got delivered through WU

            4 users thanked author for this post.
        • #188447

          @elly


          @abbodi86
          has never advised people in the so-called Group B. Moreover, @abbodi86 considered the Preview updates as being production grade most of the times and he knows it well and why and I am in full agreement with this. Following @abbodi86 while being in Group B can and will produce inconsistent results.

          • #188455

            This question wasn’t about Group B updating, although I see that I, SueW, and TonyC are all Group B. The issue with KB 4099950 affected both those doing the Monthly Rollups, and the Security Only Rollups. How it to implement the solution does vary with the two groups… I was quoting Abbodi86’s findings and understandings about the situation, not declaring that Abbodi86 was supporting or not supporting Group B with them. Abbodi86 and MrBrian did extensive testing KB 4099950 and found that Microsoft’s own documentation was inaccurate, so those of us with lesser technical experience might be excused for trying to figure out what it all means, and applying it to our individual situations. There is less specific Group B testing, and we are a smaller group… but there is implicit logic in programing and data… things are less than random, and much can be learned when things don’t work as expected. My answer quoting Aboddi86 was not because I’m following him, but because the information on KB 4099950 was knowledgeable and tested. Maybe you could answer TonyC more specifically and clearly than blaming it on Group B updating? You certainly do know more than I do about this subject.

            Non-techy Win 10 Pro and Linux Mint experimenter

            • #188467

              Abbodi86 and MrBrian did extensive testing KB 4099950 and found that Microsoft’s own documentation was inaccurate, so those of us with lesser technical experience might be excused for trying to figure out what it all means

              We all tried the same, regardless of the level of technical experience. It was quite complicated to figure out for anyone interested, Microsoft’s own people included. They actually created the problem which should have been addressed much earlier, in Service Pack 1 in 2011 when it was already known.

              3 users thanked author for this post.
            • #188496

              I found following the testing process quite fascinating… and I know I’m treading where non-techies probably shouldn’t… and I lack awareness of many aspects of the issue… but I think that for people trying to understand how their computer reacts, and not just follow along blindly, this was a great learning experience. I really appreciate the patience and focus of all who contributed. Kudos to you.

              At the same time, I am highly sympathetic and identify with all the confused voices out there… breathing a sigh of relief that their computer is working properly after following the path set out by experts. Thank you.

              Non-techy Win 10 Pro and Linux Mint experimenter

              1 user thanked author for this post.
            • #188470

              Maybe you could answer TonyC more specifically and clearly than blaming it on Group B updating? You certainly do know more than I do about this subject.

              The indirect suggestion made to @TonyC, as it was mentioned in the post that he/she is in Group B, was to update correctly and move over to Group A to have full support.

            • #188575

              @ch100
              Concerning @abbodi86 never advising people in so-called Group B, it was actually Woody’s article of the 27 April 2018 that pointed Group B people to @abbodi86‘s post. I quote, “For those of you who are spitting in the patching god’s face and manually installing Security Only patches (the “Group B” approach), I wish you well and point you to @abbodi86’s instructions.”.

              Your recent comments in this thread and the use of phrases such as “so-called Group B”, in conjunction with Woody’s comment quoted above, are all beginning to sound a little hostile towards the Group B approach. Is this going to be a continuing trend?

              1 user thanked author for this post.
            • #188828

              the use of phrases such as “so-called Group B”, in conjunction with Woody’s comment quoted above, are all beginning to sound a little hostile towards the Group B approach

              Naw. Group B is just my shorthand. And I would submit that it’s Microsoft that has been hostile to the So-called Group B approach.

              There are lots of good reasons to avoid Group B. It’s become an increasingly onerous and confusing approach.

      • #188359

        The .msu contains the .exe. There is no need to do anything with the .exe.

        2 users thanked author for this post.
        • #188582

          @MrBrian, thank you. But that still begs the question, if the .msu contains the .exe, why did the second release of KB4099950 on the 17 April 2018 provide the .exe explicitly along with the .msu? On the face of it, this looks like duplication.

          1 user thanked author for this post.
          • #188634

            I believe the .exe was added to the Catalog when the exe became bundled with the update in Windows Update.

          • #188653

            It was explained by @abbodi86 few times that it is for the use of the Enterprise tools.
            Regular users are normally not supposed to use the Catalog, but entirely Windows Update.
            The Catalog is for Enterprise users as well.

    • #188304

      ATTENTION: PKCANO…. NEED HELP

      RE: Your post #188068

      Group B, W7

      First of all, thank you for responding to my questions in post #188060 (“Call me Bwanna”).

      I followed your instructions to the letter, and everything seemed to progress appropriately, but the final result was the same as I experienced with the March updates earlier in the month–I completely lost my wireless internet connection and had to do a system restore to get it back. Thus, all of the updates you suggested, and I installed, are now gone.

      I believe the security-only update for March (KB 4088878) is the culprit since this is what happened earlier in April when I installed it in response to the March updates. Then, I had to also do a restore to get my wireless internet connnection back.

      In short, the update process you outlined when followed on my W7 computer removed my wireless network adapter. It didn’t show any more in device manager. Windows troubleshooting didn’t help. It tried to (unsuccessfully) install a device driver.

      My question now, pkcano, is what do you suggest I do regarding the updates so as to preserve my wireless connection/adapter?

      Thank you
      …Bwanna

      P.S. After doing the updates, the pci.sys file changed to the appropriate version, but of course, it reverted due to the restore.

      • #188311

        The only thing I can suggest:
        If the old version of 4099950 is installed in the restored PC, uninstall it.
        Reinstall the later version (don’t reboot)
        Skip the Mar SO and install the Apr SO + IE11 CU. See if that works without losing the network connection.

        4099950 is supposed to fix the network problem. You might find something useful here if that is not successful.

        1 user thanked author for this post.
    • #188340

      To PKCano (regarding post 188311)

      From “Call me Bwanna” (post 188304)

      I took your latest advice and …

      1. Reinstalled KB 4099950 (the old version had been “uninstalled” due to the system restore.

      2. Skipped the March SO but reinstalled the April SO + IE11 CU.

      I am happy to say this did not remove my internet access or wireless adapter this time. Therefore, it appears the problem was with KB4088878 (March SO update).

      I checked my pci.sys file, and it is now 6.1.7601.17514, ostensibly due to not installing the March SO, which would have updated it to a later version.

      In conslusion, things appear to be working okay now, although I am concerned about what security issues persist without the March SO update and if the older version of the pci.sys file will be a problem later.

      I will check out the website you mentioned. If anything else occurs to you or anyone else at Woody’s that would allow me to add the March SO update without losing my network adapter, please let me know!

      You can call me Bwanna.

      Thank you very much, PKCano, for your prompt responses and clearly stated recommendations. I appreciate your assistance and time. I wish I could say the same for MS.

      • #188361

        I believe that the best time to install KB 4099950 is immediately before installing KB4088878, without a reboot in between. If you’re willing to try again, uninstall KB 4099950, install KB 4099950 from the Catalog (do not reboot), then install KB4088878, then reboot.

        4 users thanked author for this post.
        • #188449

          @mrbrian
          Certainly without a reboot. Otherwise it would deny the effect of having KB4099950 run manually. I may have advised differently in the past, but now things have been clarified especially since you posted the reddit information which while incomplete, when combined with what we know from this site, clarifies the sequence of installation now included in KB4093118.

          3 users thanked author for this post.
        • #188617

          (Win7 x64 Group B)
          I thought I was in the clear on this but now you’ve got me worried again. Unless I am told otherwise, I prefer to reboot after applying each update. It’s in my nature to consolidate as I go along.

          On the 8 April 2018, @MS-DEFCON 3, I installed KB4099950 (downloaded from the Catalog) and then rebooted. True, KB4099950 didn’t tell me to reboot after it had completed but, for the reason given above and because nobody was telling me not to reboot at the time, I did reboot. The contents of my PCIClearStaleCache.txt are:

          Path = C:\Windows\system32\drivers\pci.sys
          pci.sys file version is 6.1.7601.17514
          Pci.sys indicates KB2550978 or later KBs *NOT* installed
          Deleting the PCI SlotPersistentInfo registry keys…
          Deleted PCI SlotPersistentInfo registry keys successfully

          I then installed KB4088878 (the March security only update) and KB4099467 (to prevent a BSOD) before rebooting again. KB4088878 left my pci.sys file at the 6.1.7601.24056 level. I have not yet applied any of the April updates.

          Could someone please tell me what are now the negative consequences on my system after having rebooted directly after installing KB4099950 instead of waiting until I had installed KB4088878?

          As far as I am aware, my system is working well.

          • #188636

            Disclaimer: I have been unable to personally test this issue, so the best I can do it rely upon what others have written.

            Microsoft employee netwarrior20 has commented that the registry keys that KB4099950 deletes (or renames) can be recreated after running KB4099950 and rebooting. Thus, perhaps some of those registry keys were present when you installed KB4088878.

             

            3 users thanked author for this post.
            • #188839

              And do we know what might be the consequences if those registry keys were present when I installed KB4088878?

          • #188646

            @TonyC
            If you don’t have side-effects which in this case means the creation of the second NIC, you have nothing to worry. You probably don’t even need KB4099950 in that case and at least half if not more of the users here don’t need it, because of their hardware technology which is not affected, but it won’t harm anyway.
            I would be more concerned about keeping the illusion of updating according to the so-called Group B, a concept initially conceived by Woody in confusing times around October 2016, which served its purpose at that time, but was largely abandoned by virtually everyone since.
            Don’t you find an issue that most people with concerns and various problems related to Windows Update are those who update according to Group B schedule?

            1 user thanked author for this post.
            • #188676

              Don’t you find an issue that most people with concerns and various problems related to Windows Update are those who update according to Group B schedule?

              A little objectivity here…

              I checked through Defcon 3 Apply April Patches, and then combined that with Recovering From 2018 Updating for Win 7 Group B.

              There were 50 questions from Group A and only 22 questions from Group B.

              Group A was most likely to repeat a question posted earlier, and need reassurance when they had no bad results.

              Group B folk were more likely to help each other, and post positive results (I didn’t count those for A or B, only questions and problems) of their updating.

              Group B tends to be more knowledgeable, have more thorough and longer discussions, and show a willingness to help regardless of the Group status of other posters.

              I do have concerns about the viability and safety of Group B, if only because you tend to make blanket, and unsupported comments about safety and being subject to unknown updates (and I do respect your breadth of knowledge and experience, so those accusations do concern me) . If specific problems were identified, maybe they could be addressed and managed by the Group B-ers, whose goal is to have a secure and stable OS and are willing to do a little more than others to see that it is.

              Just because car manufacturers would prefer that I take my vehicle to the dealership for repairs doesn’t mean I wouldn’t get better results from my local repair shop. I’m just glad the dealerships don’t follow Microsoft’s example and aren’t hi-jacking cars out of our driveways in order to take them for maintenance at their convenience, or trading them for other cars they’ve decided that will work better according to their assessment of our needs, and stick their chosen radio station to start playing as soon as I get in and try to drive, just because they say so. Hey, Microsoft would even start taking them when I’m at work, or shopping, and leave me a little text… hopefully not ‘something’s wrong’…  It would be a business opportunity for securing packages, and providing seating and sales of snacks and drinks, in parking lots everywhere. I’m sure there would be no inconvenience or outrage that people would have to wait until that better than ever car is returned…

              Oohh! And I had promised myself to stay objective and not go on a rant! Head hung in shame…

              Non-techy Win 10 Pro and Linux Mint experimenter

              5 users thanked author for this post.
            • #188679

              Elly:

              Your observations regarding Group A and Group B might do well as a separate topic.

              Carpe Diem {with backup and coffee}
              offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
              offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.674 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
              online▸ Win11Pro 22H2.22621.1194 x64 i5-9400 RAM16GB HDD Firefox110.0b9 MicrosoftDefender
            • #188846

              @ch100
              Thank you.

              Well, I haven’t noticed any side effects, but I haven’t gone digging around in Device Manager or wherever I should be looking. I certainly have an physical Ethernet network interface card in my system which connects via an Ethernet cable to my router/hub, but I don’t know whether its settings have been changed. And my system does not have a static IP address; I use DHCP.

              I shall contemplate your remarks on the other matter.

            • #189016

              @tonyc
              I would say that you don’t have to be concerned about the NIC side-effects any more.
              I know that only PCI Express NICs are affected and while not knowing your actual hardware, as far as I know, most PCI Express implementations on laptops and desktops tend to be on Wi-Fi cards and not on the wired NICs. Servers are likely different, implementing PCI Express more widely. This is another reason to move on in preparation to the next month’s updates and forget about this issue which concerned most of us in this very long thread.
              Thanks for taking in consideration the other issue.

              1 user thanked author for this post.
    • #188426

      @dgreen, Sorry for my pronoun mistake and thanks for the correction! I, too, am a “she” and should have kept my references gender-neutral. I’m glad your file version is correct. Your post was one of the ones that helped me understand, with the assistance of MrBrian and abbodi86, that the log file was not the place to look for the updated pci.sys version since it wasn’t what changed that version. By the way I think our machines are somewhat similar since your posts have also been helpful in the past (for example, when you posted that your restore points began disappearing without reason, my laptop did the same thing – and still does). So, thanks again for your posts.

      jburk07
      Regarding my restore points disappearing.  I did a lot of research and found that this apparently was a problem with Windows 7 for many people.
      When I replaced my hard drive back in Nov. 2017 and Windows 7 was reloaded, all I did was increase my disk space usage for restore points.  Never had another problem.

      2 users thanked author for this post.
    • #188460

      @TonyC and SueW– I’m groaning over this one, trying to translate what Aboddhi86, Ch100, and MrBrian have discussed.

      The .msu files, as you have seen, are identical and functional. What doesn’t work is the metadata. That wasn’t changed until 4/23.

      – The fix tool PCIClearStaleCache.exe is programmed to delete the SlotPersistentInfo cache only if pci.sys version is below 6.1.7601.21744

      And yet it still appears to have worked on my system (according to the contents of PCIClearStaleCache.txt) when I installed it before the March security only update.

      So, if you installed KB4099950 while your pci.sys version was below 6.2.7062.32744…ie: before the March Security Only update was installed, it would have cleared the cache, and you would go merrily on your way. I could be wrong, but I think the updates to pci.sys were in KB4088881, KB4088875, or KB4088878. For those that installed the updates to the pci.sys version first, the cache would not clear, and KB4099950 would not work properly… which is what the .exe in the newer version fixes?

      I’d be happy to have some more techy expertise here… but that is how I understand it so far.

      Non-techy Win 10 Pro and Linux Mint experimenter

      2 users thanked author for this post.
      • #188463

        @elly
        I think what you presented is correct… up to here (the bold character statement only):

        For those that installed the updates to the pci.sys version first, the cache would not clear, and KB4099950 would not work properly… which is what the .exe in the newer version fixes?

        The cache would not clear if the pci.sys version is newer, like the one installed in the March or April 2018 updates. There is no difference in behaviour between new and old KB4099950. The only difference is in tweaking the sequence of applying the patches in the bundled update, while the effect would be the same if installed in the same sequence.
        The thing to be considered is if there are no side effects, there is no reason to do anything with KB4099950. The fix applied would be temporary, until the next reboot to give the opportunity to update pci.sys without being influenced by the cached registry value. After reboot the cache is recreated anyway, but it is not taken in consideration by the newer pci.sys which ignores it. The reason it is recreated is different and does not affect the creation of the second undesired NIC for some type of hardware, which is PCI Express NIC.
        See also @Mrbrian‘s post where it says do not reboot immediately after running KB4099950 and before installing the actual update which updates pci.sys.

        2 users thanked author for this post.
        • #188472

          @Ch100-

          Thank you for your further explanation…

          Your current link for MrBrian goes to his profile, rather than the post you are talking about, but I’ll go with MrBrian having said not to reboot between the patches.

          Are you saying that the new KB4099950 (or rather the .exe file with it?), does the same thing automatically for the sequence of applying the bundled patches as MrBrian’s manual fix… and the problem is with how it affects the NIC (network interface controller), specifically affecting PCI Express NIC so that NIC settings are replaced or static IP address settings are lost if the sequence of applying the bundled patches isn’t done properly?

          Non-techy Win 10 Pro and Linux Mint experimenter

          • #188476

            This was the original issue with the early releases. It did not always apply the sequence properly. Only the sequence of applying KB4099950 was tweaked and not the content. The best to apply is always the KB4099950 msu and not the exe which is what @abbodi86 among others mentioned repeatedly here.
            What I say applies only to KB4093118 which is the monthly rollup 2018-04 and which bundles KB4099950. I cannot comment about the Security Only update as I don’t know and as you know I don’t have an interest in analysing it, as it is only a subset of the full rollup.

            To summarise one more time:
            – Apply the KB4099950 msu
            – Do not reboot yet
            – Apply whatever patch is desired which updates pci.sys (assuming none of those was applied before)
            – Reboot

            KB4099950 can be applied at any time without any harm, but it will not do anything if the pci.sys was already updated previously by one of the patches. This can be seen in the log file created under C:\Windows\Logs

            For anyone else, not interested in the details, using Windows Update as recommended by Woody and following MS-DEFCON is the best option.

            2 users thanked author for this post.
      • #188473

        Here’s some empirical information. On April 8 I installed 4099950 from Windows Update followed by 4088878 from the Update Catalog, with no reboot in between. My pci.sys file went from .175114 to .24056. Everything went well, no NIC/IP problems. I did this on 2 Win 7 machines.

        Over the last few days I ran the .exe file that explicitly showed up in the post April 17 version of 4099950 in the Update Catalog on each of these machines. This produced a log file that told me I had the .24056 version of pci.sys, but nothing about deleting any registry items. Then on each machine I installed 4093108. Everything is still fine, no NIC/IP problems.

        I don’t know whether this clarifies anything or not. Perhaps I just have a couple machines that wouldn’t have been affected by the NIC/IP issue anyway.

        I wonder if MS will ever issue an update that will do the uninstall and subsequent reinstall of 4099950?

        1 user thanked author for this post.
        • #188477

          I wonder if MS will ever issue an update that will do the uninstall and subsequent reinstall of 4099950?

          There is nothing to install/reinstall as KB4099950 only runs an executable deleting a registry key when required. Installing/uninstalling refers only to the metadata flagging that the exe was run.
          If pci.sys was already updated, then there is nothing more to be done, regardless if the second NIC was created or not.
          KB4099950 is only a hack and Microsoft created this problem by releasing it. It was much better not to release it at all and instruct the affected users how to reset their NIC by using Device Manager where required. Most systems administrators who deserve that title have already known about this issue since at least KB2550978 in 2011.

          2 users thanked author for this post.
    • #188487

      This is a question for @abbodi86

      I am in group B. I have Win7 SP1  Home Premuim 64 bit. I installed KB4099950 on April 16 from the Catalog along with  KB4088878 and KB4099467. Could you please tell me if I have to uninstall any of them (and in which order) before installing April’s patches. I am very concerned about rocking the boat because as things stand everything is fine with my computer. Your assistance would be greatly appreciated.

      Thank you.

      EDIT html to text

      • #188546

        If you installed KB4099950 first, then you are good to go

        if you want to be sure, check the contents of C:\Windows\Logs\PCIClearStaleCache.txt

        2 users thanked author for this post.
        • #188610

          Thank you @abbodi86 for your prompt answer.

          It is a great relief that I am good to go. To be perfectly clear, I did install KB4099950 first from the catalog. Out of curiosity, I am okay because I installed, although before the seventeeth, from the catalog and not from WU?

           

    • #188871

      @SueW
      Yesterday (29 April 2018), I received a follow-up reply email for your post #188624 in this thread. It was a reply to my post #188617. The email contained a link to your post but, when I clicked it, the post was not found. I’ve searched for the post by other means but I cannot find it. Did you decide to delete it?

      • #189329

        @TonyC, Yes, I decided to delete my post as @MrBrian had responded after me, and it was more helpful than mine 🙂

        Win 7 SP1 Home Premium 64-bit; Office 2010; Group B (SaS); Former 'Tech Weenie'
    • #188952

      This is “Call me Bwanna” again.

      Relevant Posts Numbers (questions and replies):

      188060, 188068, 188304, 188311, 188340, and 188361.

      I have followed PKCano’s and MrBrian’s suggestions exactly but to no avail.

      Everytime I install the March Security-only update KB 4088878, I completely lose my internet connection and my wireless adapter is gone (it doesn’t show in Device Manager even when viewing hidden devices). I uninstalled the update and the problem presisted. I had to do a restore to get back my internet connection/adapter. I’ve tried the suggested “fixes” several times, but none works. By the way, I’m Group B with W7 Home.

      I welcome any new suggestions since I am concerned that I am not fully patched for March, although I am for April and months previous to March from a Group B perspective.

      If there is no solution, I might have to consider Group W going forward. I hope not.

    • #189001

      I apologise if this has been covered before but I have not seen it mentioned here. In reference to the NIC and static IP address issues, the KB article for KB4088878 (the March 2018 security only update) states for each issue (and I quote) “This issue is resolved by KB4099950 which will be automatically applied when installing this update”. Is this true? If it is, then why did so many people, including myself, explicitly install KB4099950 before installing KB4088878?

      On the other hand, the KB article for KB4099950 states (and I quote) “This update must be installed before you install KB4088875 or KB4088878.”. Is this a case of Microsoft being inconsistent? Or are both statements true and there is some hidden, unwritten subtlety behind them?

      • #189011

        @anonymous:   These updates are so complicated, at times, that I don’t know which end is up.  Just trying to keep up with the latest posts, and most of what I am seeing relate only to the Windows 10 mess.   I would like to be able to get “everything” that relates to ALL of the updates, however I’m not quite certain how to do that without getting a “reply” to something I’ve left a “reply” on a message or 2 so that I will be made aware when something new is posted, however there must be an easier way  (so that I perhaps will get the list of recipients without getting an email for each and every one).     Would appreciate a “tip” on how it can be done without replying to a posting…..   Seems I’m missing something here.    All “great ideas” will be appreciated.   Thank you.    🙂

        • #189041

          walker

          I hear you – it can become overwhelming.  I can only tell you what seems to work for me.  I made a separate GMail account just for getting the emails sent to me that I have “subscribed” to.  I get no other emails on it.  I read the replies that get sent to this email, delete the stuff that does not apply to me — and the rest I put in “labels”, e.g. KB4099950,  How To, KB4099467, etc.  When I read something that is of interest to me, I click on the link at the bottom of it and look at it on the blog to see any “likes”, etc.  When I am then on the blog I also check the “Recent Replies” as sometimes there are categories of interest that I have not subscribed to.  Now that the April Rollup is done for me, I’ll be deleting all the emails that apply to anything that I have already incorporated.

          In addition, I had the BSOD problem with logging off — and I just realized that if I don’t log off and use “switch user” it not only prevents the BSOD it has the additional benefit of keeping me logged in on the blog site so that I don’t have to sign in every time I visit the site.

          I hope this is of benefit and that others will share their tips.

          All the best!

          2 users thanked author for this post.
          • #189415

            @Peacelady:  Thank you for the good idea!   I think I may try that one, if I can only find the time!   I need to get away from Yahoo, with all of that rigamarole going on.    Will let you know if I’m successful in getting into the Gmail.   Sounds like a good idea to me.   Thank you for sharing!     🙂

            1 user thanked author for this post.
      • #189044

        Did you notice that Woody refers to it as the Carnak Patch here and here?

        Non-techy Win 10 Pro and Linux Mint experimenter

        • #189416

          @elly:  What, exactly IS the Carnack Patch??   I keep trying to figure that one out.

          • #189464

            Carnak the Great (late-night host imaginary character) gave the answer first and the question after.

            The March Monthly Rollup (KB4088875) was offered March 13, 2018. About three weeks later, KB4099950 was offered. It was to be installed before KB4088875 was installed.

            Carpe Diem {with backup and coffee}
            offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
            offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.674 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
            online▸ Win11Pro 22H2.22621.1194 x64 i5-9400 RAM16GB HDD Firefox110.0b9 MicrosoftDefender
            2 users thanked author for this post.
      • #189050

        More seriously, I know Woody told us how to deal with it in his April patching instructions, but I wish someone would concisely summarize, in minimum technical terms, what it was all about- why, how, What The !!!! (ooh… bad word! That was close…). I have wrestled with it, asked questions, and read all kinds of things… and ended up confusing myself even more…

        That doesn’t mean inquiring minds don’t want to know…

        Non-techy Win 10 Pro and Linux Mint experimenter

        1 user thanked author for this post.
        • #189515

          @Elly , I’ll give it a try in the way I write things.

          Despite gathering telemetry to assist with troubleshooting, different tasks go to different teams that do not communicate with each other or rely on data collected. Maybe even they find that collection to be unreliable and therefore useless. So Microsoft either cannot or chooses not to know the current status of the PCI version installed and the conflict it may be causing. But they have tickets that say a large enough sample has a conflict, so they create a method to establish a log tailored to this case and call it KB4099950.

          A large part of the ensuing confusion, stress, and misunderstanding comes from the mistaken idea of what KB4099950 actually does. Permit me to bypass the task of actually attributing each statement to an individual, I apologize for my unprofessionalism here. Nearly all of my knowledge on this item comes from the AskWoody Lounge, most from a dense thread among three MVPs discussing this subject in an intertwined manner. Other voices also contributed, and more gave instruction to me by their questions that caused a new angle to become apparent to me. Thanks to all involved, apologies for not doing the legwork to cite you by name.

          KB4099950 does not install any actual patch. But it does perform several individual operations including: locate the driver involved; report the version installed; confirm a reported status against a required check; executes some form of logic based on this new data; and in my case, deleted the relevant keys; reported success in that operation; then created a log to record each of these steps that could be read in turn.

          This created a temporary condition within the system; whereby a successful update to the driver could be performed by the next operation, as long as that was done before the next bootstrapping function of the system. The ‘boot’ function will recreate the ‘unfixed’ condition and result in this driver failing to update yet again.

          Here is the commonly misunderstood part. That log, PCIClearStaleCache.txt, does not describe the finished condition. It contains all that information collected during the set-up to the fix, not the eventual installation of the new driver by the next operation.

          This is why that log reports the ‘old’ version, but when you view properties for pci.sys after, it displays the newly installed version number. There is no logic or command to go back and rewrite, amend, or delete that log. It is a useful flag to prove the ‘fix’ happened, but it does not report the finished status. Looking at the properties of pci.sys gives that assurance.

          If you run KB4099950 again, after you have already been patched to current, it will overwrite that log rather than amend it. So if your log actually reports as up to date, that means you did not need to run it the last time you did. But it does not hurt anything either because the logic would have recognized the new condition and left the relevant keys intact. Please any MVP who recognizes any mistakes by me here, please point it out.

          Eventually, for GroupA at least, all of these steps were performed under a single patch applied. perhaps it should have been done that way from the beginning. I take from that the solution was not yet a known quantity when Microsoft had us test it for them. Separating the steps would permit telemetry to better discern the failed step, if they bothered reading the telemetry submitted that is.

          3 users thanked author for this post.
          • #189608

            @Cascadian,
            Thank you for the summary. I’m saving that one… and then will read back through the testing posts. I’m betting they will make more sense within that context. I appreciate your effort, and I had an “ah-ha!” moment.
            Many thanks.

            Non-techy Win 10 Pro and Linux Mint experimenter

            1 user thanked author for this post.
      • #190008

        I believe that the KB article for KB4088878 is wrong on that aspect.

        1 user thanked author for this post.
    • #189048

      So I’ve been on Group B forever. I’d like to stay there with security-only patches. I see instructions to install KB 4099950 and select security-only patches.

      However…. I last installed updates in October. How do I get fully up to date? Do I need to do anything before running the msu file from KB 4099950?

      Thanks!

      • #189051

        Download your patches ahead of time. You can get them from AKB2000003.
        Download KB 4099950 from the Catalog.

        Install Oct – Feb Security only patches (no reboots )
        Install KB 4099950 (no reboot)
        Install Mar Security only
        Reboot

        Install Arp security only and IE11 cumulative update
        Reboot

        2 users thanked author for this post.
    • #189560

      … This created a temporary condition within the system; whereby a successful update to the driver could be performed by the next operation, as long as that was done before the next bootstrapping function of the system. The ‘boot’ function will recreate the ‘unfixed’ condition and result in this driver failing to update yet again. …

      Well, as I have mentioned before in this thread, I installed KB4099950 and then rebooted before I installed KB4088878 (the March 2018 security only update). Afterwards, PCIClearStaleCache.txt reports that pci.sys was at 6.1.7601.17514 but, looking at the properties of pci.sys, it is now at 6.1.7601.24056. So, it appears that, even though I rebooted after installing KB4099950, KB4088878 still successfully updated pci.sys. Can you account for that? (I still haven’t installed any of the April 2018 updates.)

      • #189718

        Hello TonyC, no, I cannot account for that.

        The comment you quote was my best effort at distilling what I’ve learned from reading, rereading, catching a misunderstood part, and seeing that same mistake made by many others; then writing it out in one narrative. It is possible that I still have it wrong. That is why I asked for error checking within the comment.

        I can describe an effect I’ve noticed in myself over the years. When I have not yet grasped the true understanding of a process, I might observe it several times and think I know what order events happened. But then something clicks, and I see that I had perceived it wrong all along. My own experience does not indicate the same happens for you in this instance or at any other time.

        It is also reasonable to say I still do not have it described correctly.

    • #189568

      Well, as I have mentioned before in this thread, I installed KB4099950 and then rebooted before I installed KB4088878 (the March 2018 security only update). Afterwards, PCIClearStaleCache.txt reports that pci.sys was at 6.1.7601.17514 but, looking at the properties of pci.sys, it is now at 6.1.7601.24056. So, it appears that, even though I rebooted after installing KB4099950, KB4088878 still successfully updated pci.sys. Can you account for that? (I still haven’t installed any of the April 2018 updates.)

      If you install KB4088878, there will be an updated version of pci.sys on your system (6.1.7601.24056) regardless of whether you did or did not install 4099950.

      Now, I imagine your question is, did rebooting after installing 4099950 mess things up?

      I haven’t read anything definitive that says you “must not reboot” before installing 4088878. What abbodi said a few days ago was this:

      There is no need to reboot after installing kb4099950 as matter of fact, it’s better to install kb4099950 then March security-only, then reboot

    • #189581

      I’ve just read through this in an attempt to make sense of it and I’m not sure I’m any wiser.

      I have computers that don’t, and never have, had any version of KB4099950 or KB4093118.  March updates are installed and no ill affects experienced.

      Since it seems that KB4093118 encompasses KB4099950 I approved (the latest incarnation of) KB4093118 only (to one test PC to begin with)

      Beforehand I checked pci.sys and it was at 17514.  After install of KB4093118 and the reboot it requested, pci.sys is at 24056.  This seems to indicate it’s worked as expected.

      The appearance of PCIClearStaleCache.txt with content

      Path = C:\Windows\system32\drivers\pci.sys
      pci.sys file version is 6.1.7601.17514
      Pci.sys indicates KB2550978 or later KBs *NOT* installed
      Deleting the PCI SlotPersistentInfo registry keys…
      Deleted PCI SlotPersistentInfo registry keys successfully

      also seems to indicate all is well.

      So why is WSUS still offering KB4099950 to install for this PC?   I expected that to disappear as it is no longer needed.

      Do I now approve KB4099950 – it sounds like it may do nothing anyway now?
      Alternatively decline it?

      And for the rest of the network, should I approve KB4099950 first, then KB4093118?

      Thank you for any help you can offer.

      Andrew

    • #189655

      Group A with 2 computers both Win7 SP1.

      First computer monthly updates up to February, only March update was KB4100480 installed on April 9. On April 11 installed KB4099950 from Catalog and on April 17 allowed April update KB4093118 from WU.

      PCIClearStaleCache.txt contains:
      Path = C:\Windows\system32\drivers\pci.sys
      pci.sys file version is 6.1.7601.17514
      Pci.sys indicates KB2550978 or later KBs *NOT* installed
      Deleting the PCI SlotPersistentInfo registry keys…
      Deleted PCI SlotPersistentInfo registry keys successfully

      The pci.sys file is 6.1.7601.24056.

      Second computer as above EXCEPT April update KB4093118 not yet installed and pci.sys file is 6.1.7601.17514.

      I would be grateful for answers to the two questions;

      1. Am I OK to do nothing more with the first computer for now as 4099950 appears to have done its fix and 4093118 appears to have updated the pci.sys file?

      2. With the second computer is it OK to just allow the install of 4093118 from WU (which hopefully will then update the pci.sys file as happened with the first computer)?

      Thanks

      • #189657

        1. Am I OK to do nothing more with the first computer for now as 4099950 appears to have done its fix and 4093118 appears to have updated the pci.sys file?

        Yes

        2. With the second computer is it OK to just allow the install of 4093118 from WU (which hopefully will then update the pci.sys file as happened with the first computer)?

        Uninstall KB4099950
        Reboot
        Install only KB4093118 from Windows Update. It now contains KB4099950

        2 users thanked author for this post.
    • #189665

      Many thanks PKCano for the speedy reply.

    • #189826

      Am I right in thinking that either order of the latest versions of KB4093118 and  KB4099950 is ok now then, if neither installed previously?

      • #189830

        Install only KB4093118 from Windows Update. It contains KB4099950 already.

        • #189841

          Thanks for clarifying that.

          KB4099950 is still being offered by WSUS after KB4093118 is installed.  So I’ll just decline  KB4099950 then.

    Viewing 47 reply threads
    Reply To: A protocol question about KB 4099950

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: