|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
Remember that KB that was updated to showcase that Microsoft was investigating the networking issues? https://support.microsoft.com/en-us/help/4103718
[See the full post at: Patch Lady – KB 4103718 no longer lists “investigation” note]
Susan Bradley Patch Lady/Prudent patcher
I installed it on my 7’s on the 12th, and yes I have Windows 7 64bit
Susan Bradley Patch Lady/Prudent patcher
You are right — I have been watching this update since it was released. I have been holding off updating since January 2018 because of the problems that MS are making with their updating.
I have 6 computers on a network — all with fixed IP addresses and running windows 7 Pro. I do not want MS messing with them.
mbhelwig
mbhelwig
That actually happens quite frequently: the support page lists an update date but the Update Catalog still lists the original release date (or some date that is earlier than the updated date on the support page). In any case, it’s probably a good idea to wait until Woody changes to DEFCON 3 or higher or to wait at least a few more days before installing either the Rollup or Security Only patches for May.
Edit: Just to be clear, the Update Catalog may still show the older date even though you will, in fact, be downloading an updated version of the patch.
Don’t confuse the update of the documentation, the update of the metadata, and the update of the patch’s code. You could have three different dates there. Just because the documentation was updated doesn’t mean the patch was changed.
Although the text of the document has changed, by eliminating that troubling paragraph on networking issues, the date of the document has not: it is still given as May 8th.
This is from the bottom of the document:
File information
For a list of the files that are provided in this update, download the file information for update 4103718.
I seem to recall something about changes to SMB1 in the updates this month. If you have an old printer, that might be what caused the problem. SMB1 was used by older printers, but was found to be vulnerable lately.
The KB was updated for the removal of the note. They made no change to the code.
A KB date change will not necessarily translate to a refreshed patch.
Susan Bradley Patch Lady/Prudent patcher
Being a little compulsive, I checked the file information for update 4103718, which is an Excel .cvs file.
I won’t say I was more thorough than doing a scan for file change dates… and the last changes were done April 23, 2018… with .manifest changes on May 4, 2018.
That wouldn’t indicate an actual change in the update, just a change in documentation?
Non-techy Win 10 Pro and Linux Mint experimenter
Just a change in documentation if last changes in archive were done April 23, 2018 and .manifest changes on May 4, 2018.
I consider that after Microsoft received feedback about possible problems with network drivers, they have reproduced installations and various behaviours on their Test virtual machines, issues didn’t catch and then they have just removed NIC issues info from description of KB4103718. Just my thoughts!
Funny beacuse the article on KB 4103712 still shows the same
“A stop error occurs on computers that don’t support Streaming Single Instructions Multiple Data (SIMD) Extensions 2 (SSE2).”
“Microsoft is working on a resolution and will provide an update in an upcoming release.”
I wrote a PowerShell script awhile back to report some detailed info about an update. The script connects directly to Windows Update servers so it must be run on a machine where the patch is applicable, in this case a Windows 7 machine. At the moment, it is telling me that LastDeploymentChangeTime for 4103718 is still 5/8/2018.
The script is available here:
https://www.mcbsys.com/blog/2015/11/print-detailed-windows-update-info/
I have installed it on 7 Win7s – three hardware installs and four VMs. Two were 32-bit and the rest 64-bit. Only one was Home, the rest a combination of Pro and Ultimate.
Didn’t have any problems (doesn’t mean there aren’t any).
The patches themselves are still dated 5/5/2018
Known issues with May Rollup KB4103718 were published: There is an issue with Windows and a third-party software that is related to a missing file (oem<number>.inf). Because of this issue, after you apply this update, the network interface controller will stop working.
Workaround is presenting.
https://support.microsoft.com/en-us/help/4103718/windows-7-update-kb4103718
Overnight here in Brisbane Australia (26/05/2018) the following appeared in the description of KB 4103718 May update —
“There is an issue with Windows and a third-party software that is related to a missing file (oem<number>.inf). Because of this issue, after you apply this update, the network interface controller will stop working.
1 To locate the network device, launch devmgmt.msc; it may appear under Other Devices.
2 To automatically rediscover the NIC and install drivers, select Scan for Hardware Changes from the Action menu.a. Alternatively, install the drivers for the network device by right-clicking the device and choosing Update. Then choose Search automatically for updated driver software or Browse my computer for driver software.”
So the Network drivers are still being messed up by MS update. A “third-party software” is referred to — but not by name. How nice of MS not to name what they think is the cause of the problem but not tell us. MS should look in their own back yard — or are they afraid of being sued?????
I have not applied updates since December 2017, and I will not be applying this one either until it is sorted.
mbhelwig
mbhelwig
…”and the torture never stops…”
OK, I’m definitely missing something here.
1. Am I to understand that if the “missing file” is on my PC, I shouldn’t (!?) have any issues?
2. What IS the full value of the missing file? There are 54 oem<number>.inf files on my system, all sequence numbered oem0.inf thru oem54.inf, but oem14.inf and oem13.inf are missing. All have dates starting in 2008, go to 2010, skip 2011,2012, and 2013, resume in 2014, skip 2015, and resume in 2016 and 2017. There are TWO copies of oem42.inf, one in the \windows directory, and one in \windows\system32 directory. Both have the same date and size.
3. If I had those two missing files, would I be in shape to patch without the turgid rigmarole of the workaround?
4. What, specifically, ARE the files missing that cause the problems? Just throwing out a “(oem<number>.inf)” designation seems to me to be an admission they don’t KNOW which file causes the issue.
Sheesh. If any sysadmin/engineer had been caught dispensing with this sort of flim-flam-flummery instead of identifying the missing files by name, and supplying them (this was 20 years ago), well, he’d be sorting floppies in Antarctica.
But then, I’m old. :)>>>>>
BTW, what kind of English is “…and a third party software…”? Should not the “a” be dropped, and names named? Something funny going on here.
Man, I have a three-Excedrin headache over all this!
Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty
@OscarCP-
I just expect a higher standard from MSFT, which is probably a mistake held over from years past. Also, I’m down to one mission-critical machine, and I have to be conservative.
And I never liked the “shotgun” approach; when an RF tech, I always troubleshot to the component level if I could. And I see no reason to accept that the experts up there can’t, except in certain rare, highly unique and circumscribed conditions. This may be one of them, and it may be not.
Hey, others have been more steamed up than me…by comparison I’m the soul of human serenity…you can hear it sloshing around inside me by the gallon. 
(Apologies to Robert Benchley)
Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty
Hi Nibbled, if I may call you that!
@bob99 here posting anonymously from a borrowed computer.
I just checked on the computer I’m currently using, and both the .inf files you’re missing go to two different Intel network driver files on this computer. One file is not in use, but the other is indeed the driver for the network card in use on this computer.
Basically, these oem##.inf files point Windows to the correct actual driver file for it to use to get the networking card up and running. In the case of this machine, oem14.inf points to the networking card’s actual driver, e1c62x64.INF, and it also points Windows to the .cat, or catalog, file where the rest of the networking card’s configuration info can be found. The other file you say you are missing, oem13.inf, belongs to an Intel 10/100 networking card which is not installed on this machine, so oem13.inf isn’t needed supposedly. Lotsa good info for Windows is contained in these .inf files.
You can look at their contents simply by RIGHT clicking on the file and then choosing “Open” at the top of the resulting pop-up menu. Yes, the word “open” should be listed in bold letters just like in this post, so the bolding isn’t mine for emphasis. However, please be very careful in exploring the contents of the file with Notepad, which is what should display the file’s contents by default since the file is just a simple text file for the system to use. Any changes inadvertently made to these files can potentially ruin its use by windows, rendering a device useless. Yes, for those wondering, you could even potentially “brick” your computer, causing a dreaded Blue Screen of Death (BSOD) if you were to ruin a keyboard driver, for example.
Now, on to more of an explanation of other things brought up in your post relating to why MS simply can’t just come out with the exact name of the missing file: There are a great many number of networking card manufacturers out there, and each one probably has their own separate .inf file for their card(s). MS in Redmond, where these bulletins are presumably written, simply has no way of knowing which one is the correct one for your machine. That number can change for each computer. So, to save words (one of their FAVORITE pastimes) they simply released a very terse explanation of the symptom and what the user can do to remedy the situation.
Yes, the above paragraph was a defense of Microsoft’s methods, but NOT an approval of their methods in any way, shape or form! I myself would rather they explain things better instead of relying on the consumer to “read between the lines”, as they currently do.
One final bit of advice for you, Nibbled: Please print out a copy of the the quote contained in post #194474 above, just in case you do lose networking after installing May’s rollup, KB4103718. BUT, as always, don’t do so until we get the go-ahead from Woody, or one of the MVP’s here says it’s OK to install the patch. Neither one has happened just yet.
For others reading this thread and who are in Group B, it would also be a good idea to print out those instructions from MS since, as has been noted previously on another thread, the security only patch KB4103712, has also had mention of networking issues identical to the rollup patch. This begs the question of why didn’t MS put the remedy for the networking issue on BOTH the rollup and the security only bulletins instead of just the rollup bulletin?
Thanks! You’ve given me a lot to think about! BTW, I did print out the workaround in case of a NIC disaster. From what can understand now, according to MSFT, some mysterious piece of third-party software causes 4103718 to nuke a perfectly good and properly running .inf file. An earlier misreading (while I was tired*) of it left me thinking that it was the absence of this .inf file before the Rollup was installed that was causing the problem.
(*”Never work on a computer if you are tired, hungry, rattled, or after 11 PM if you can help it”. –Nibbled’s First Law of Computing)
One thing I still don’t understand fully, since I am obviously in over my head here…
If I understand MSFT’s “Known Issues” statement correctly, I still fail to see why a properly configured and researched update, patch, Rollup, etc, should nuke a properly working .inf file in the first place… Yes, there are a great multiplicity of makers/drivers/NIC’s, etc, but I sure wish MS had a sign in each cubicle modified from the Epidemics, Book I, of the Hippocratic school: “Practice two things in your dealings with the User or Admin: either help or do not harm the patient.”
Hey, thanks for the education! And I am going to wait for Woody’s DEFCON 3 or lower. There are 54-odd of those .inf files, and I simply don’t have the time or the ocular power at my age to pore over each and every one and trace it back. :p
Again, many thanks.
Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty
You’re Very Welcome!
BTW, on my own machine, which I’m currently using, those files you thought you were missing, numbers 13 and 14, go to another completely different driver, not a network card. Just goes to show how different two different machines can be.
The borrowed computer I was using earlier today with post #194557 and mine (being used for this post) both have Intel NIC’s, but they’re both integrated into the motherboard. However, I have noticed that the drivers for the borrowed computer’s NIC and my NIC are identical, right down to the last digits of the drivers’ version numbers!
My computer is almost two years older than the one I borrowed earlier today for the anonymous post.
The apparent only real difference between them is the different file numbers for the OEM##.inf files. I haven’t gone digging through my computer’s inf files to see which ones are for the NIC just yet, as it’s getting late in my time zone, very close to 11 pm. 
(*”Never work on a computer if you are tired, hungry, rattled, or after 11 PM if you can help it”. –Nibbled’s First Law of Computing)
…and they dropped this bomb on a Friday before a 3-day US weekend.
Sweet. Reminds me of some press release strategy timing.
I’m going to hold off until someone finds the missing .inf file names causing the issue or Woody says go ahead, methinks. This “take a shot and here’s what to do if it doesn’t work” bit is just so not working for me.
Thanks to all who are doing the “Terrier Work” on this one, it’s really a mess, especially with the Win 10 issues and mud being tossed about now, too. I salute you all.
Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty
I installed KB4103712 Security-Only patch on a test system, then on the remaining systems that I look after. Those systems are W732 and W7/64, some older, some newer, and I have a mix of different networking hardware/software for testing. The patch installed without incident on all of them.
Third party software? I assume they did not name the the company/product because they are not working together on resolving the issue, or they are in disagreement over the results, or the tests are inconclusive. Sometimes it is an older version of the software that causes a problem, not the latest stable release. Third parties will send MS a copy of their latest stable release and of course when called out over an issue, will only test with their latest release.
Many home users and businesses run with older releases of third party software. Enterprises too.
From a security point of view it is not advisable, but stability is the higher priority for most.
Yes, I installed the May IE cumulative update on all the same systems. I install it first. I had no problems with it.
It looks like installing the KB4103718 rollup update on nearly all of my Win7 SP1 machines causes Windows Update to offer some “older” updates like KB3185319 for IE11 and thus “break” the WU supersedence chain.
after installing KB4103718, reboot and then do a Windows Update search, older IE11 updates like KB3183519 get offered as I’ve checked myself on a bunch of Win7 computers with KB4103718 installed. Hiding KB3183519 and doing another WU search afterwards will offer an older IE11 update like KB3175443.
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
Notifications
