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]
|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
-
A protocol question about KB 4099950
- This topic has 262 replies, 36 voices, and was last updated 5 years, 7 months ago.
Viewing 47 reply threadsAuthor-
-
Yes, it was tweaked on April 17th.
-
The metadata was tweaked. The patch itself was not.
1 user thanked author for this post.
-
-
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
-
@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.
-
-
1 user thanked author for this post.
-
-
-
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.
-
-
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?
-
-
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?
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
11 users thanked author for this post.
-
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). -
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.
-
-
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.
-
-
-
-
-
-
Because DEFCON system includes all versions of Windows, not just Win7. And Woody has made the exception for Win7 because of the impending (possible) exploit of the Total Meltdown vulnerability.
-
See Woody’s new post at April Patches Infested with a Slew of Bugs, Most of Which Were Finally Contained
Non-techy Win 10 Pro and Linux Mint experimenter
-
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-after1 user thanked author for this post.
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.
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 23H2
Installed on 10/19/2022
OS build 22631.27151 user thanked author for this post.
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.
-
Yes, KB4099950 did not make it back to WU after second revision
@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.
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 beforeAnswer 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.
-
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?
-
-
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.
-
-
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.
-
-
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:
- KB4099950
- KB4088875
- KB4100480
So now, what I need to do to clean up this mess is, in order:
- UNINSTALL KB4088875 – Reboot
- UNINSTALL KB4099950 – Reboot
- INSTALL KB4099950 from Catalog – Reboot
- INSTALL KB4093118 from Windows Update – Reboot
Correct?
Is it OK to leave KB4100480 – or did I completely waste my time earlier this month?
-
Yeah, the would be the official route
1 user thanked author for this post.
-
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.
-
-
-
-
-
-
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.
-
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.
-
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.
-
-
Neither of those answer my direct questions.
1 user thanked author for this post.
-
-
-
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
-
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.
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.
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????1 user thanked author for this post.
-
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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux -
-
“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.
-
-
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.
-
-
-
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 fix3 users thanked author for this post.
-
-
-
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/Prudent patcher
4 users thanked author for this post.
-
-
Perhaps related to this Reddit discussion. Reddit user netwarrior20 is purportedly a Microsoft Escalation Engineer assigned to this issue.
-
Yes, it is correct, but this is incomplete.
I find it weird that virtualisation companies like VMware and Citrix explained the issue in detail when first noticed and why it happens, while Microsoft does not explain it correctly even after 7 years, although the other companies have the info obviously confirmed by Microsoft before being published.First time when the pci.sys was modified in Windows 7 /2008 R2 SP1 causing this issue.
https://support.microsoft.com/en-us/help/2550978/0x0000007b-stop-error-after-you-replace-an-identical-iscsi-network-adaAlmost full details and workarounds here, still the best article about this subject.
https://kb.vmware.com/s/article/1020078Same root cause in different context affecting Citrix products:
https://support.citrix.com/article/CTX128750 (Hyper-V related)
https://support.citrix.com/article/CTX219905
https://support.citrix.com/article/CTX221733
https://support.citrix.com/article/CTX129743This issue has been widely known and addressed by Enterprise administrators according to the situation, most of the times likely by using Device Manager and removing Ghost NICs, after which the remaining NIC was getting the desired configuration.
Why Microsoft decided to address it now with a widely distributed patch remains a mystery. -
-
I found another good technical reference: Improved iSCSI Boot Resiliency with changes to Plug and Play behavior in Microsoft KB2344941.
1 user thanked author for this post.
-
-
-
I found another good technical reference: Improved iSCSI Boot Resiliency with changes to Plug and Play behavior in Microsoft KB2344941.
KB2708857 is the latest independant hotfix with most recent pci.sys version before Convenience Rollup KB3125574
-
You got a mention on the Citrix discussions site 🙂
https://discussions.citrix.com/topic/354677-pvs-61-now-requires-kb-2344941-or-kb-2550978-cant-install/1 user thanked author for this post.
-
-
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.
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.
-
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.
-
@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. -
-
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.
-
-
-
-
-
I have a Reddit account. What would you like to ask?
1 user thanked author for this post.
-
-
1 user thanked author for this post.
-
-
-
“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.
-
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.
-
Questions for netwarrior20:
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?
1 user thanked author for this post.
-
Good questions! Wonder if we’ll get any answers….
https://www.reddit.com/r/sysadmin/comments/8ba4sm/patch_tuesday_megathread_20180410/dy2wvdh/
-
-
I never absorbed that site or how it works or mean
seems pretty casual 😀1 user thanked author for this post.
-
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.
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.
-
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.
-
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 -
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.
-
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. 🙂
-
-
-
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-afterhttps://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.
-
@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.
-
-
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.
-
-
-
-
-
-
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.
@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.
@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.
-
pci.sys 6.1.7601.21744 or later
1 user thanked author for this post.
-
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 successfullyWin 7 SP1 Home Premium 64-bit; Office 2010; Group B (SaS); Former 'Tech Weenie'1 user thanked author for this post.
-
Afterward, install the April Rollup of SO
1 user thanked author for this post.
-
-
That should have been an OR, not of
Rollup OR SOAnd the March too.
1 user thanked author for this post.
-
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.
-
-
-
-
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 successfullyWell, 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.
-
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.
-
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.
-
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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux
-
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.
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
-
@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.
-
-
@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.
-
-
-
-
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.
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.
-
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.
-
-
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.
-
-
-
-
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.
-
-
-
-
@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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux -
-
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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux -
-
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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux -
@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.
-
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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux1 user thanked author for this post.
-
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.
-
-
… 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.
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.
-
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.
-
“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.“
-
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-188207uninstalling 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
Another response from netwarrior20.
Four questions:
- 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?
- 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?
- Does Microsoft know that KB4099950 has been unavailable in Windows Update since approximately April 17?
- Is Microsoft aware that the documentation for KB4088878 stating that KB4099950 is applied automatically when installing KB4088878 is incorrect?
Answer:
- We have seen some customers uninstall the March update, reboot, and see the settings come back again.
- If the issue has already occurred (IPs already lost) then uninstalling March update and installing re-released 4099950 + March update is the guidance.
- 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.
- I am not aware that this is a mistake. I’ll query this with the team this next week.
Again, any contrary opinions?
-
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! 🙂 -
Got it.
https://www.reddit.com/r/sysadmin/comments/8ba4sm/patch_tuesday_megathread_20180410/dy4auuw/
Reddit /sysadmin seems to be quite worthwhile, just hard to wade through and (in the fine Reddit tradition) blossoming with bottom-of-the-gene-pool posts.
-
-
…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.
-
‘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.
-
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) -
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.
@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.
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. ( ;-
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 21.1
Group A:
Win7 Pro x64 SP1 Haswell, 0patch Pro, dual boot with Linux, mostly offline
Win7 Home Premium x64 SP1 Ivy Bridge, 0patch Pro,offline
Win 10 Pro x64 v22H2 Ivy Bridge, dual boot with Linux1 user thanked author for this post.
… 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.
-
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
-
@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.
-
-
-
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
-
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.
-
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.
-
-
@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.
-
-
-
-
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.
-
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.
-
@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. -
-
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.
-
-
-
@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.
-
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.
-
-
-
@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.
-
-
@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.@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
-
@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. -
@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
-
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)
– RebootKB4099950 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.
-
-
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.
-
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.
-
-
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!
-
-
-
-
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.
On permanent hiatus {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.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
online▸ Win11Pro 22H2.22621.1992 x64 i5-9400 RAM16GB HDD Firefox116.0b3 MicrosoftDefender
-
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.
-
@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.
-
@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.
-
I believe that the KB article for KB4088878 is wrong on that aspect.
1 user thanked author for this post.
-
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
RebootInstall Arp security only and IE11 cumulative update
Reboot -
