Tests of KB4099950

Topic

New Reply

I have done some tests of KB4099950 on a Windows 7 x64 virtual machine.

Test #1: Created a SlotPersistentInfo registry key in an appropriate location as a test. File pci.sys on computer is v6.1.7601.17514. Ran KB4099950 catalog file windows6.1-kb4099950-x64_245d5aaf7d50587297825f9176be166c47ad10f7.msu. SlotPersistentInfo registry key was deleted (technically it was actually renamed).

Test #2: Created a SlotPersistentInfo registry key in an appropriate location as a test. File pci.sys on computer is v6.1.7601.17514. Installed KB4088878 and rebooted. SlotPersistentInfo registry key was still present, contrary to what the KB4088878 article implies would occur. Installing KB4088878 caused pci.sys to be v6.1.7601.24056. Ran KB4099950 catalog file windows6.1-kb4099950-x64_245d5aaf7d50587297825f9176be166c47ad10f7.msu. SlotPersistentInfo registry key was purposely not deleted according to the pciclearstalecache.txt log file, presumably because the version of pci.sys is too high.

Discussion: If the fix wasn’t successfully applied before installing KB4088881, KB4088875, or KB4088878, there perhaps is nothing that you can do to fix the issue except one of these:

1. Restore an image made prior to installation of KB4088881, KB4088875, or KB4088878.

2. (Speculation) Restore a system restore point made prior to installation of KB4088881, KB4088875, or KB4088878.

3. Fix manually.

5 users thanked author for this post.

walker, ch100, amraybt, abbodi86, Elly

Reply | Quote

Replies

The old version of vbs script will also be able to resolve the issue, since it doesn’t check pci.sys version

here it is, slightly enhanced:
https://pastebin.com/rgv0brjW

1 user thanked author for this post.

ch100

Reply | Quote

abbodi86 wrote:

The old version of vbs script will also be able to resolve the issue, since it doesn’t check pci.sys version

here it is, slightly enhanced:
https://pastebin.com/rgv0brjW

@abbodi86’s version is the real thing, fixing what Microsoft left half-way in their published vbs script in the KB3125574 support article.
Microsoft’s script for example does not display the message informing the users that it is all clear or the opposite (in certain conditions I assume, it does not display at all in my tests).
Also Microsoft’s script does not take action to clear the key if the pci.sys was already patched. Why? It is true that the patched version is supposed to ignore the SlotPersistentInfo key, but still… The idea of the script is to remove undesired functionality, which is actually PCI Express specification standard, so it is not necessary a Microsoft bug. It becomes a bug in context though.

I will make a little contribution here with few PowerShell commands, which allow a degree of control and are simple to understand:

– Open PowerShell/PowerShell ISE as Administrator
– Type Get-ChildItem “HKLM://System/CurrentControlSet/Enum/PCI/*/*/Device Parameters/SlotPersistentInfo”
This will tell the user interactively if there is any SlotPersistentInfo key which needs to be deleted
– Type Get-ChildItem “HKLM://System/CurrentControlSet/Enum/PCI/*/*/Device Parameters/SlotPersistentInfo”|Remove-Item and Enter

Note: The idea comes from this web site which posts the commands above as a script
http://virot.eu/convenience-rollup-kb3125574-with-bonus-powershell-w7-w2k8r2/

2 users thanked author for this post.

MrBrian, abbodi86

Reply | Quote

Here is the older version of Microsoft’s script that I believe was the starting point for abbodi86’s script.

Reply | Quote

@abbodi86
I’ve only just caught up with this thread and it has been revealing. QUESTION: Is the desired end result of installing KB4099950 and KB4088875/KB4088878 (i) that pci.sys is updated from 6.1.7601.17514 to 6.1.7601.24056 and (ii) that no SlotPersistentInfo key exists in the Registry? If so, then I had not previously known about condition (ii).

Using regedit, I have just searched my registry for SlotPersistentInfo keys and found that none exist. If the sole objective of your .vbs script is to delete all SlotPersistentInfo keys, then I presume now that I don’t need to run it. Yes?

The background to all this, elaborated in another thread, is that, on the 8 April 2018, I installed KB4099950 (from the catalog) followed by a reboot before I installed KB4088878 (from the catalog). The suggestion was that the reboot might have recreated the SlotPersistentInfo keys after KB4099950 had deleted them. Well, that doesn’t appear to have been the case unless the subsequent installation of KB4088878 somehow deleted any that had been recreated.

Reply | Quote

TonyC wrote:

@abbodi86
I’ve only just caught up with this thread and it has been revealing. QUESTION: Is the desired end result of installing KB4099950 and KB4088875/KB4088878 (i) that pci.sys is updated from 6.1.7601.17514 to 6.1.7601.24056 and (ii) that no SlotPersistentInfo key exists in the Registry? If so, then I had not previously known about condition (ii).

Using regedit, I have just searched my registry for SlotPersistentInfo keys and found that none exist. If the sole objective of your .vbs script is to delete all SlotPersistentInfo keys, then I presume now that I don’t need to run it. Yes?

The background to all this, elaborated in another thread, is that, on the 8 April 2018, I installed KB4099950 (from the catalog) followed by a reboot before I installed KB4088878 (from the catalog). The suggestion was that the reboot might have recreated the SlotPersistentInfo keys after KB4099950 had deleted them. Well, that doesn’t appear to have been the case unless the subsequent installation of KB4088878 somehow deleted any that had been recreated.

@TonyC I will try to reply on behalf of @abbodi86
First thing is that I hope you are actually only trying to understand this issue better for learning/researching purpose, as we have already reached together a conclusion in another thread where you confirmed that everything is OK on your side.
On reddit, someone claiming to be a Microsoft insider explained and this makes sense, that the SlotPersistentInfo is deleted temporarily until the pci.sys version is upgraded. The new pci.sys version does not take the registry key in consideration. This is the reason why the machine must not be rebooted between the installation of KB4099950 and the other patch upgrading pci.sys.

@abbodi86’s script does the same thing like KB4099950, except that it deletes the key, regardless of the version and this is in fact better to avoid complications. There is no point in verifying the version before deleting the key other than maybe to avoid a one off driver repair under which the registry key would be recreated and potentially require one more reboot, but this is only speculation.
On a side note, I am amazed that @abbodi86’s post where this script was posted did not raise more interest, because this is better than everything that Microsoft posted on this subject, although it is based on Microsoft’s original script posted in the KB3125574 support article in the original version.
Going back to your situation, you told me elsewhere on this forum that you have a wired card, never had the duplication of NICs and this is the case for most users with similar configuration. You do not own a PCI Express card and as such the SlotPersistentInfo is not created at all. That key is specific only to those PCI Express cards, likely some of the wireless cards on most common desktops and laptops.

The idea in the standard is that even if you replace a PCI Express card with another one identical as firmware and type in the same slot, the PCI Express cards are still identified as different according to the standards and not because this is what Microsoft wants. PCI cards (not PCI Express) do not have the same behaviour, although they are slot sensitive and when replaced, need to be placed in the same PCI slot to maintain the previous settings. However, this PCI Express behaviour creates side effects and Microsoft decided by upgrading pci.sys to discontinue the implementation of that part of the standard. The registry key is still created in the process of installing the card (by the driver I believe), but the software ignores that part.
By upgrading the pci.sys version, Microsoft actually treats the PCI Express cards in the same way like PCI cards.

3 users thanked author for this post.

MrBrian, TonyC, abbodi86

Reply | Quote

As @ch100 thankfully explained, the abcense of SlotPersistentInfo keys and no NIC issues, means you are good to go

Reply | Quote

https://www.catalog.update.microsoft.com/Search.aspx?q=KB4088878 Lists a last updated date of 4/4 for KB4088878. How come Microsoft hasn’t built in kb4099950 to the March and/or April updates by now?

Reply | Quote

How come Microsoft hasn’t built in kb4099950 to the March and/or April updates by now?

According to:

https://support.microsoft.com/en-us/help/4088878/windows-7-update-kb4088878

After you apply this update, a new Ethernet Network Interface Card (NIC) that has default settings may replace the previous NIC and cause network issues. Any custom settings on the previous NIC persist in the registry but aren’t used.
This issue is resolved by KB4099950 which will be automatically applied when installing this update

Static IP address settings are lost after you apply this update.

This issue is resolved by KB4099950which will be automatically applied when installing this update

Has anyone verified that just installing 4088878 will cause the automatic application of 4099950?

Edit to remove HTML. Please use the “Text” tab in the entry box when you copy/paste.

Reply | Quote

It’s included in the April cumulative update.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

The question is still relevant. KB4088878 is the Group B Security only patch and in this case to stay in Group B you would not want to install the April rollup (cumulative) update.

For those staying in Group B with Jan and Feb 2018 patches already installed, the question is: Is installing only these updates via the catalog (not windows update) sufficient?

1. the March 2018 Security only update (KB4088878) and
2. the April 2018 Security only update (kb4093108) and
3. the IE April 2018 cumulative update (kb4092946)

The KB4088878 KB article suggests yes, because that article states that KB4099950 will be automatically installed prior to the installation of KB4088878, and the other patches from march appear included in KB4093108.

1 user thanked author for this post.

DrBonzo

Reply | Quote

I installed 4088878 last month then using a power shell command searched for 4099950.  It hadn’t been bundled with 4088878. So unless a change has occurred with 4088878 my guess it still needs installed by itself. I haven’t had any networking issues without installing 4099950. So should I install the updated version of 4099950 now before I install Group B April updates?

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

1 user thanked author for this post.

MrBrian

Reply | Quote

The change occurred on 4/4 with the re-release of KB4088878. The patch itself (and its SHA1 fingerprint) didn’t actually change (but the release date from the Windows Catalog was updated to 4/4), the KB article was updated to state that KB4099950 would be automatically installed. Prior to this date instructions to install 4099950 manually first were present.

I suspect that the backend patch dependencies were changed to force 4099950 as a required dependency to force it’s installation first (that is what the current KB article now states).
https://support.microsoft.com/en-us/help/4088878/windows-7-update-kb4088878

Reply | Quote

I installed 4088878 after the 4/4 update. So, do I have 4099950 on board even though powershell search says I don’t? Would I have to install 4099950 by itsel to have powershell search see it as being installed?

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

Reply | Quote

“The KB4088878 KB article suggests yes, because that article states that KB4099950 will be automatically installed prior to the installation of KB4088878”

The KB4088878 KB article text is wrong according to my test #2 in the first post.

1 user thanked author for this post.

Elly

Reply | Quote

That is the root of my question. If you installed 4088878 after 4/17 without previously installing 4099950 then there should/would be evidence of C:\Windows\Logs\PCIClearStaleCache.txt being created regardless if 4099950 showed up in the patch list.

Reply | Quote

This tends to be very confusing. Based on MrBrian’s initial post, if I hadn’t installed 4099950 before 4088878 and my network wasn’t a problem (because I didn’t have static IPs nor changed any default settings) then do I even need to install 4099950 at this time? And, if I don’t, will there be any issues if I decided to utilize static IPs or change network settings in the future?

I had planned to install 4099950 before Group B patches for April but I’m not so sure anymore based on this thread.

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

1 user thanked author for this post.

JDeC

Reply | Quote

I also intended to test KB4099950 delivered through Windows Update, but it still wasn’t available through Windows Update as of a few hours ago.

 

 

2 users thanked author for this post.

walker, geekdom

Reply | Quote

MrBrian wrote:

I also intended to test KB4099950 delivered through Windows Update, but it still wasn’t available through Windows Update as of a few hours ago.

Is KB4099950 rolled into KB4093118 (April Monthly Rollup)?

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

Reply | Quote

See https://www.askwoody.com/forums/topic/patch-lady-we-just-got-a-new-update-for-april/#post-184436.

1 user thanked author for this post.

geekdom

Reply | Quote

Tests #3 and #4: Repeated tests #1 and #2 except ran (elevated) Catalog download pciclearstalecache_1c944f48bfb21d88a2054683abcd02327ecf6b37.exe instead of windows6.1-kb4099950-x64_245d5aaf7d50587297825f9176be166c47ad10f7.msu. Results for both tests were the same as tests #1 and #2.

Conclusion: pciclearstalecache_1c944f48bfb21d88a2054683abcd02327ecf6b37.exe contains version checks on file pci.sys.

Reply | Quote

Some information from my experience.

I installed KB 4099950 (it was still offered by WU at the time) and KB 4093118 on April 14 at the same time through WU. This was before the re-release on Apr 17. On the PCs involved, the pci.sys file was not updated according to the .txt file that was present in the Windows\LOGS folder.

I have had to go back and uninstall the KB 4099950 that was installed on the 14th and re-install the version released on the 17th for the pci.sys file to be updated. So it appears the bundling was not correct until after the 17th.

3 users thanked author for this post.

MrBrian, DrBonzo, geekdom

Reply | Quote

I did something similar but a bit different.

on 4/8 I installed 4099950 from WU and then 4088878 (March Security Only). I did NOT get a log file but I did get an updated pci.sys file. Then on 4/18 I ran just the .exe file that had been included on 4/17 in the 4099950 revision. After running, I got the Log file that simply informed me what version of the pci.sys file I had.

I haven’t attempted anything with the April updates, yet.

I have not had any networking, connection to internet, or IP address issues of any kind before or after doing what I described above.

Since I did not uninstall and then reinstall 4099950, I’m wondering if 4099950 really got installed properly. It seems to have installed properly given the presence of the Log file and the updated pci.sys file, but I’m still wondering.

It also seems to me that in a sense it’s a moot point whether it installed correctly or not, since I have not had any networking issues.

1 user thanked author for this post.

MrBrian

Reply | Quote

MrBrian wrote:

I also intended to test KB4099950 delivered through Windows Update, but it still wasn’t available through Windows Update as of a few hours ago.

MrBrian
When I did an update check on April 13 KB4099950 was offered and checked.
When I did an update check on April 18 Kb4099950 was gone.
My updates remain the same today as they did April 18.
My computer is rolled back to December 2017 (rolled back Jan and Feb)
Never downloaded anything March or April for that matter.
Screen shot of both updates.
Windows 7 Home Premium SP1 64 bit

2 users thanked author for this post.

geekdom, MrBrian

Reply | Quote

Oh My!  Please tell me if I am understanding this.  (Group A, Windows 7 64-bit) Since I don’t have KB4088875 installed, I don’t have to install KB4099950 because when I install the April Rollup it will be included. (Am I wrong in reading that if we get the April Rollup from Windows Update it includes KB4099950 but doesn’t include it we get the Security rollup from the Catalog?).

In addition, I’m the one who had the BSOD _pool etc.  Will the fix for that, KB4099467 also be included in the April Rollup?  HELP!!!

Reply | Quote

My goodness, this is confusing!

Some background, I did what was recommended at the time: install KB4099950 through Windows Update prior to installing March Roll-up KB4088875.  I did the installation on April 1st (no fooling!).

The end result:

1. My version of PCI.SYS is 6.1.7601.24056
2. There is no C:\Windows\Logs\PCIClearStaleCache.txt on my system.
3. The SlotPersistentInfo registry key exists

So what do I need to do?  Uninstall and reinstall KB4099950?  Run abbodi86’s script?  And if so, in what order do I do those things?

Microsoft has never re-offered me KB4099950 through Windows Update.  Although I did download (but not install) windows6.1-kb4099950-x64_245d5aaf7d50587297825f9176be166c47ad10f7.msu

Please advise.  Thank you.

1 user thanked author for this post.

DrBonzo

Reply | Quote

Safe route:
uninstall both KB4088875 and KB4099950
install KB4099950 (from WU or MSU file)
install March April Rollup

Short route:
download the script, rename extension as .vbs, and run it, then reboot

i would test short route myself, but i never had the SlotPersistentInfo registry key, neither before or after

Reply | Quote

abbodi86 wrote:

Safe route: uninstall both KB4088875 and KB4099950 install KB4099950 (from WU or MSU file) install March April Rollup Short route: download the script, rename extension as .vbs, and run it, then reboot i would test short route myself, but i never had the SlotPersistentInfo registry key, neither before or after

I tested the short route for you, with the following results:

1. No change to PCI.SYS (still 6.1.7601.24056)
2. Still no C:\Windows\Logs\PCIClearStaleCache.txt on my system.
3. The SlotPersistentInfo registry key no longer exists
4. According to the script output, “Your system is ready to install the updates”

So is that it?  Am I ready to install the April Roll-up when the time comes?

1 user thanked author for this post.

abbodi86

Reply | Quote

The vbs script don’t create a log file
yes, hopefully, you are good to go

1 user thanked author for this post.

alpha128

Reply | Quote

abbodi86 wrote:

The vbs script don’t create a log file yes, hopefully, you are good to go 

That’s what I wanted to hear!  Thanks!

 

Reply | Quote

@ch100
First and foremost, I would like to thank you for your patience in replying to me. You have been very kind.

ch100 wrote:

First thing is that I hope you are actually only trying to understand this issue better for learning/researching purpose …

Not really. I am still a little uneasy about whether my system is in a fit state to apply the April updates.

ch100 wrote:

… someone … explained … that the SlotPersistentInfo is deleted temporarily until the pci.sys version is upgraded. The new pci.sys version does not take the registry key in consideration. This is the reason why the machine must not be rebooted between the installation of KB4099950 and the other patch upgrading pci.sys. …

This still doesn’t make sense to me. If the new version of pci.sys takes no notice of the SlotPersistentInfo key, why must the key be deleted before KB4088875/KB4088878 installs the new version?

ch100 wrote:

… Going back to your situation, you told me elsewhere on this forum that you have a wired card, …

This is where we might get to the nub of my problem. I am a technical person. I have two degrees in Computer Science, one of which is a Ph.D.. And, before retiring, I worked for 37 years in the IT industry, mainly as a software specialist/consultant. With the exception of Vista, I have installed and maintained every client Windows system from Windows 98 through to Windows 7. All that said, my knowledge of computer hardware is very rudimentary and, basically, I treat any PC almost as a black box from the point of view of its hardware components and their drivers. So I am afraid that terms like “PCI card”, “PCI Express” and “PCI slot” don’t mean that much to me.

Yes, in another thread, I stated that my system has an Ethernet network interface card which is wired by Ethernet cable to my hub/router. I don’t have a wireless/Wi-Fi card. If I look in Device Manager, under “Network Adapters”, I see only “Realtek PCIe GBE Family Controller”. If I unhide devices, I see 12 other “network adapters”, but none of them look anything like “PCI Express”. I have opened a command prompt window as an administrator, set DEVMGR_SHOW_NONPERSISTENT_DEVICES to 1, and then started the Device Manager from the same command prompt window. I don’t think I saw any “ghosted” devices but, to be honest, I wasn’t at all sure what I should be looking for.

If I may paraphrase in my own words, I think what you are telling me is as follows. From what little you know of my PC, you believe that I don’t have a hardware component (e.g. a PCI Express card) that requires/uses pci.sys and, because of that, a SlotPersistentInfo registry key has NEVER existed on my system, which is the sole reason I cannot find it now. So, for my PC, running KB4099950 and the upgrading of pci.sys by KB4088878 were completely irrelevant and redundant actions. Correct?

A post in another thread mentioned something to the effect that, because I rebooted between installing KB4099950 and installing KB4088878, the metadata used by Windows Update might now be incorrect. Are you able to provide any reassurances about this?

All that said, my system appears to be working well and I have had no networking problems. On the other hand, I haven’t gone looking for problems in Event Viewer, etc.!

Reply | Quote

@tonyc
Sorry if I haven’t replied promptly as we seem to have this conversation spread over multiple threads.
The issue here is to avoid the creation of the phantom/ghost NICs until such a time when the pci.sys file is updated to one of the “good” versions.
One way to do this is by deleting the SlotPersistentInfo by KB4099950, one of Microsoft published scripts under KB3125574 support article or @abbodi86’s script which is an enhancement of the earlier Microsoft scripts. I would recommend only KB4099950 or @abbodi86’s script for those who want to understand better what happens and have more control. KB4099950 is good enough though, there is no need to run vbs scripts if not comfortable with the idea.
There are 2 main types of PCI cards currently. PCI (classic) and PCI Express (known also as PCIe). There was another one, largely abandoned and used only for graphics cards named AGP.
The idea is that PCIe has much higher performance, but this is not visible to the level of the common desktop or laptop motherboards.
The fast that you Realtek PCIe in Device Manager might indicate that you actually have a PCIe card, but that might only be a common driver.
There are also other reasons why you might not be affected by the phantom card issue as most users are not affected.
The bottom line is that we make too much of an issue from this patch which is not as problematic as it appears in the “fake” news, but nevertheless affects potentially a large number of virtualised servers. However, those servers maintained well enough and running on VMware and having one of the vmxnet variations of NICs should have been already patched by KB2550978 as recommended in multiple places by VMware. So the impact may not be as widespread as you may thing of it.
Again it all comes down to selective patching, hidden patches, unapproved patches… people who know better than the manufacturer of a product, but who claim compensation when things don’t happen their way.

1 user thanked author for this post.

TonyC

Reply | Quote

@ch100

Thank you for the explanation of PCI cards, but I am not sure how far that gets me.

I still suspect that the pci.sys on my system is not used and, as a result, a SlotPersistentInfo registry key has NEVER existed on my system. I’ve looked at the properties of the pci.sys (6.1.7601.24056) that was installed by KB4088878 (the March 2018 security only update) and it was last accessed on the 8 April 2018, which was the very day that I installed KB4088878. So it doesn’t seem that it has been used since then. Moreover, I’ve look at the properties of the previous version of pci.sys (6.1.7601.17514) and it was last accessed on the 21 November 2010, which was the day that I installed Windows 7 on my PC.

All that said, I’ve now successful installed the April 2018 patches and all is well. Time to move on.

1 user thanked author for this post.

jelson

Reply | Quote

TonyC wrote:

…. I still suspect that the pci.sys on my system is not used …. I’ve looked at the properties of the pci.sys (6.1.7601.24056) that was installed by KB4088878 (the March 2018 security only update) and it was last accessed on the 8 April 2018, which was the very day that I installed KB4088878. So it doesn’t seem that it has been used since then.

I’ve wondered about that “Accessed” time-date stamp too.  Just checked win32k.sys (since it gets used a lot):

• Created: Dec 7, 2017
• Modified: Oct 16, 2017
• Accessed: Dec 7, 2017

Reply | Quote

@MrBrian

Do you concur that kb4099950 is not needed for Group B patchers like Patch Lady mentioned? That there is no need to run that before the March Security Only Patch as the issue it addresses does not apply to those that patch using the security only patches?

If one skips kb4099950 but does run into issues after applying the March Security Only Patch, can kb4099950 be run at that point and still fix the NIC/IP error?

Reply | Quote

Hello,

I have installed all “Security Monthly Quality Rollup for Windows Server 2008 R2 for x64-based Systems” to 2018-08 manually because of install error.

Now my WSUS Shows that I need KB4099950 but fails to install. If I switch to get updates directly from MS Update Server. I donn Need this update.

Is KB4099950 included in the laters “Security Monthly Quality Rollup for Windows Server 2008” than April?

Reply | Quote

Yes, the PCIClearStaleCache.exe fix (KB4099950) is companion for all
Rollups since May

1 user thanked author for this post.

SueW

Reply | Quote