Bork Tuesday, Any Problems Yet?

A driver again.
If you're inclined to do some digging, you should search for the last occurrence of that code in both setuperr and setupact log files. A couple of lines above this last occurrence should be a line that says 'will return 0' (errors always begin with 0x...) and will contain the exact driver. This line will also contain another code which says why the driver returned 0.
This is what I have gathered (and filtered) based on Microsoft recommendations for debugging setup errors (the links I already posted here).

 

1809 still hasn't been offered on one of my machines and I'm in no hurry to try and force it.

 

It becomes a habit that each cumulative update (today's KB4471332) is only installed on the second attempt. At least it does so automatically and without breaking anything. Always the same error code 0x8024200d.

 

I don't know why you guys are in such a rush to get v1809... is there any particular feature you want that's not available in v1803? Also, in the time you spent troubleshooting all the errors, you could have clean installed 1809 a looong time ago...

 

The same happend for me with KB4471332. It failed with the same error on the first attempt, but installed fine the second time. This was on a clean install of build 1809 which I did today.

 

For me, it repeats with each CU since the fall upgrade, 3 CU since then and 3 errors. 100% success ...

 

Update errors have nothing to do with upgrades or clean installs... I had almost no errors since version 1607.

 

I can only speak for myself....
Not exactly a rush, but I simply never had issues with Windows Updates. So I always install them on time, no matter if they are feature or cumulative.
[EDIT]

I know that this may sound strange to some, but troubleshooting is often a way to learn something new.

 

Same here. As soon as an update/upgrade is available, I go for it. It's my general approach (stay up to date) regardless of hardware, software, operating system etc.

 

My newer Intel 8th gen Dell XPS 13 updated Win 10 Home via KB4471324 from v1803 build 17134.441 to 471.

But my older ThinkPad Yoga Win 10 Pro was offered the feature update to v1809 build 17763.194.
After a bad start 'We couldn't install some updates because the PC was turned off' (WTF?), and a few hours, I had ...

• A new Windows 10, and new Windows 10 Setup entries in the Windows Boot Menu.
• Bluetooth issues (mouse)
  
• Custom library folders removed

but most importantly, issues with Macrium Reflect Home 7 (even after reinstalling and creating new rescue media e.g. unable to create images - looked tike VSS issues) which is a non-starter for me, so rather than troubleshooting, erred on the side of caution and reverted to v1803.
This machine is Pro so have set feature updates to 'Semi-Annual Channel' deferred for 365 days for now, till I have the stomach to sort it out.
Rerunning WU and getting same updates as my first machine, KB4471324 ...

 

That is still an issue? Does it include data stored in them?

 

No, the source folders are unaffected - just the added library entries are gone. Not serious, just shouldn't be ...

And one wonders what other undiscovered problems await. Some desktop shortcuts to portable apps were also affected ...

 

I tried installing 1809 three times.Upgrade Assistant failed and reverted changes twice.Clean install worked but then desktop,mouse froze.Reinstalled 1803 from backup.There has to be a driver issue but all drivers are up to date.I just wonder if Intel Modern drivers will be made for older systems because this is a Toshiba Satellite and even reverting to a older graphics driver from Toshiba website did not work.

 

Moral of the story - "if it ain't broke, don't fix it"

 

No go on this error code, 0xC1900101. Only place it exists is in rollback directory setuperr and setupact log files. There is zip reference to driver files in those logs.

As far as Panther directory setuperr and setupact log files, note this that has been posted previously:

DU DU::CDUSession::Search: Failed to set WU internal configuration property for targeted scans. hr = 0x80070057
2018-12-11 16:38:47, Error CONX 0xd0000034 Failed to add user mode driver [%SystemRoot%\system32\DRIVERS\UMDF\uicciso.dll]
2018-12-11 16:38:47, Warning CONX Failed to add driver [C:\WINDOWS\system32\DRIVERS\UMDF\uicciso.dll]
2018-12-11 16:38:47, Error CONX 0xd0000034 Failed to add user mode driver [%SystemRoot%\system32\DRIVERS\UMDF\uicciso.dll]
2018-12-11 16:38:47, Warning CONX 0x00000002 RegQueryValueEx failed, keyName ({193a1820-d9ac-4997-8c55-be817523f6aa})
2018-12-11 16:38:47, Warning CONX No user mode driver path found under the registry key.
2018-12-11 16:38:47, Warning CONX 0x00000002 RegQueryValueEx failed, keyName ({2c0a6c48-3046-7713-a07b-18ab5d813333})
2018-12-11 16:38:47, Warning CONX No user mode driver path found under the registry key.
2018-12-11 16:38:47, Info CONX End CDriverMap::GetDrivers
2018-12-11 16:38:47, Warning CONX Stop Time: 21:38:47.812
2018-12-11 16:38:47, Info CONX End CDriverMap::GetDrivers
​

Appears to me the driver add is failing because the noted directory path is missing in the noted registry keys? So it may be that this relates to actually a borked 1803 upgrade perhaps?

-EDIT- Again appears the bug is in 1803 in that the path name references WUDFhost.exe - a valid WUDF driver. Unless this reg key is coded improperly:

 

Use the Media Creation tool to download the ISO and you don't need to make a bootable USB and just install from the ISO after unzipping it and click on Setup.exe https://go.microsoft.com/fwlink/?LinkId=691209

 

Thanks for the help but my instinct is telling me to wait this out for a while.

 

Update got stuck at 98% during installation for very very long time (blue screen - don't turn off PC).

Had to shutdown by pressing the power button. After turning ON the PC the update finished.

 

It's just too suspicious that you will have the same generic driver error code and a reference to the same uicc driver as XIII. Especially because his is an older hardware and yours is I assume newer. If ghosted USB drivers are the cause, as I suggested earlier, then everyone would have a failed update.
I think, because the same happens in 2 sepearate cases, that these log entries you both show has nothing to do with the cause of the update failure and I feel we are looking at the wrong thing. More info is needed here.
As I understand it (and I say this based on official info as I never actually troubleshooted this), log files are full of different errors and most are benign and part of the normal update process (most are security related, missing permissons until the update enters the SafeOS phase i.e.). So the vast majority of these errors will not break the update. As you see in XIII's spoiler in post #4806, the errors return 2. The cause of the error has to say that it will 'return' the error with a 0 (false) value to be critical and result in a 0x... code that will display on screen.
Have you tried to search if anything in these logs returns 0? The reason I am insisting on this is XIII's spolier - I see that the functions return the values, and I have a strong hunch that at least one of them has to return a 0.

 

Probably not. My motherboard dates to 2008.

As far as the registry keys involved, I believe those date back to my Win 7 build. I upgraded it to Win 10 when Win 10 was released. What I think this is about:

is it appears 1809 is looking for something like: C:\WINDOWS\System32\drivers\UMDF to be there to add the uicciso.dll.

What is interesting is WUDFhost.exe located in System32 directory and reference in the registry keys is a valid WUDF driver. Or, WUDFhost.exe actually should be located in C:\WINDOWS\System32\drivers\UMDF or copied from the System32 directory to there.

All the above leads me to the belief that Microsoft is the culprit here with an untested and borked 1809 Feature upgrade. Or and again when the 1803 upgrade occurred, the registry keys in question were not properly updated.

-EDIT- Just checked all the other services listed in WUDF registry key. They all uses this path, C:\WINDOWS\System32\drivers\UMDF except the two error flagged registry keys. Believe we have found the culprit.

 

What would be the fix/workaround then?

 

Still pondering what to do.

This reg key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WUDF, contains the following value, DefaultHostProcessGUID, which points to the Services entry, {193a1820-d9ac-4997-8c55-be817523f6aa}. So at this point, the services reg key reference looks valid.

Resolution revolves fully determining what the resolution of this error message "No user mode driver path found under the registry key" involves for the two numeric value keys being flagged.

How about someone who has upgraded to 1809 post a screen shot of the values shown under this reg key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WUDF\Services\{193a1820-d9ac-4997-8c55-be817523f6aa}​