Bork Tuesday, Any Problems Yet?

Can't you simply uninstall it by going to the App & features setting? It should be listed there.

 

Still no Win 10 1809 via WU on two machines (one 8th Gen Intel) ... it's nearly 1812 .

 

Mine too. I got fed up and went to download 1809 using the Windows 10 Update Assistant

Now everything's running smooth

 

I did - twice - and Win Update will immediately download and install it on the next boot. @_Nikopol was lucky in that it appears it wasn't reoffered to him. Rather than manually blocking the Win Update, I just disabled the scheduled task portion of it since I see no reason it should be running constantly.

BTW - you get this update if you have manually or third party wise tried to prevent a Feature Upgrade.

 

"Knock on wood" it appears I finally got rid of KB4023057. I also have no doubt now this is related to any attempt to block the 1809 or for that matter, any Win 10 Feature Update.

I opened up OOSU10 and reversed the previous block it set on Feature Updating. I then uninstalled KB4023057. I also for good measure, deleted the schedule task it created. Rebooted and whalla, no attempt to redownload KB4023057 via auto Win Updates as had occurred in all previous deletion attempts of it. Checked the C:\Program Files\rempl and it is empty except for the log folder.

Let's see what tomorrow's cold boot brings ………

-EDIT- Above was "wishfully thinking." Bugger reinstalled as part of Win Update checking. Appears only way to stop it is via the "hide" Win Update method.

 

Nope

 

3 different machines updated fine using the Windows Upgrade Assistant, but a very old Dell Latitude D620 is failing each time with error 0x800704C7.

Unfortunately most search results on this error lead to Microsoft answer forums with the usual trivial and useless answers from MVP’s.

Who here can do better?

 

I'll take this one please!

So, 0x800704C7 means it's a win32 error, more info, so we check the error here, and what do we get?

ERROR_CANCELLED = 1223, -- (#04C7)
-- The operation was canceled by the user.

Some food for thought for your troubleshooting

 

Woa I thought such a list doesn't exist! Thank you!

 

In addition to Floyd 57's reply -
Which Windows version? Windows 7? Windows 8.1? And if Windows 10, which version? I don't think 0x800704C7 is limited to Windows 10.
Which update or updates did you try to install? Do you know specifically which update resulted in error 0x800704C7? Perhaps that could be relevant information.

 

Lol I literally googled the error and ended up there after like 10 mins, u guys should only ask questions if u've spent at least 30 mins googling and didn't find the answer

 

I spend a total of (probably about) 48hs googling on windows errors since 2016. (That's when they've made this) I never found this nor was it mentioned anywhere. And I think of myself of someone who tends to find things via google pretty fast. (Well, if I put myself into relation to all people I personally observed googling)

 

Official info on error codes:
https://docs.microsoft.com/en-us/windows/desktop/debug/system-error-codes

Another thing you should check is the installation logs, setupact.log in this case (if the installation fails during the downlevel phase):
https://docs.microsoft.com/en-us/windows/deployment/upgrade/log-files

 

Thank you for the list of error codes!

I was trying to update Windows 10 1803 32-bits to Windows 10 1809 via Windows Upgrade Assistant.

I’m currently removing all the remnants of that attempt (so several logs are already gone) and will try a USB flash drive created by the Windows Media Creation Tool next.

If that fails as well I have some logs to inspect.

 

USB doesn't work for upgrading from 1803 to 1809, I tried, it tells you that... it doesn't work and you need to do the upgrade while your pc is booted
Ofc you can still try if you want to, you're gonna have to mount the iso anyway afterwards to upgrade so it doesn't hurt too much burning it to a USB 1st, you can also download the .iso and use rufus

Why is the windows 32-bit btw?

 

Another failure: 0xC190010 – 0x20017 The installation failed in the SAFE_OS phase with an error during BOOT operation.

(This was via running setup.exe on a USB flash drive from a booted Windows 1803)

Additionally in the Windows logs: event 7009, a time-out (30,000 seconds) while waiting to connect to service nicconfig.svc.

PS: I have to use 32-bits Windows because the CPU (Intel T2300) is 32-bits.

 

This is in Event Viewer.
You need to take a look at the setupact.log file in C:\$Windows.~BT\Sources\Panther.
As the link above suggests, open the log file and search for the result code (0xC190010 in the second attempt, 0x800704C7 in the first). This will show more codes that should help to pinpoint the issue.

 

The fourth attempt (with Broadcom network stuff disabled, as some people on the internet suggested) also failed, without an error code unfortunately.

I only have been able to save two log files for this failed attempt. What can/should I look for?

 

Which ones?
Have you read the link I posted regarding 'log files'? It explains exactly which files you need to open (setupact & setuperr), what to look for and what to expect. It even gives an example.

 

These:

Code:

setupact.log
setuperr.log

Unfortunately reading the links you provided is still a "next action"...

I have no error code and the texts "abandon" or "abort" do not occur in these files.

 

I can see how that can be a problem.
You have to reproduce the issue (using the Upgrade Assistant again or starting the offline upgrade from a USB drive i.e) and get the error code and the log files.

Regarding this exact code -

https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolution-procedures

[reason for edit] added 'and the log files' in italics

 

This was the failure cause twice during the initial 1809 rollout. Tried in vain to find the driver/s in question w/o success. Also I do not have Safe Boot enabled on my current 1803 build.

 

In second XIII's attempt, the upgrade failed during the boot to SafeOS phase (2nd phase out of 4 - 0x20017).

I'd disable the offending device (I'll assume it's a NIC) in BIOS and proceed with the offline update. And deal with the driver later. If nothing helps, there is always Macrium.
But I'd certainly double check with the log files first as there may be more 'offending' devices there.

 

That's exactly what I did in my fourth (failed) attempt (Broadcom NIC disabled, both the driver and in BIOS)