Bork Tuesday, Any Problems Yet?

Thanks. That confirms that the warning messages have nothing to do with the uicciso.dll driver creation issue. The 1809 reg key values are identical to that shown in 1803.

My next step will be probably to download 1809 .iso via MediaCreators tool and run the setup.exe from there to see if that works. It appears to have the most success when Feature upgrade problems surface.

 

Alright, let's dig some more
There are uicciso files in the driver repository folder (located in windows\system32\driverstore\filerepository\uicciso.inf_amd64_<random number>). A dll and an inf (you can manually install and uninstall the driver). Inf file says, among other things -

Code:

[Strings]
ManufacturerName="Microsoft"
DiskName = "Uicc Iso Installation Disk"
WudfRdDisplayName="Windows Driver Foundation - User-mode Driver Framework Reflector"
DeviceName="Uicc Iso Device"

So this is a driver related to peripheral devices and ISO files. Most probably used only for the upgrade process, that's why none of us has it installed. There is no info online, and search results are littered with unresolved issues.
But whether the failure by the update to 'add' this driver is expected, and not really the cause of update failure, I dare not speculate. As I said I feel that a piece of info is missing.

 

@itman,
I don't like linking to this kind of discussions, but this one may have some sense in it. What do you think of it?

 

I think you might just be on to something here. A bit of background.

Prior to 1803, I never had virtualization enabled on my old Gigabyte AMD BIOS. Only enabled it to get Core Isolation to work in 1803. And when I enabled Memory Protection, my Realtek audio didn't work anymore. Installing a Win 10 driver from the Microsoft Catalog solved that issue.

I initially thought Hyper-V might be an issue in the initial 1809 upgrade failures but never saw any web postings related to it. Also it appears the upgrade failures occurred at the tail end of the upgrade processing which would point to the establishment of the virtual environment in 1809.

Bottom line - it is safe to assume that 1809 includes additional Hyper-V protections and those just might not be compatible with these old BIOS's virtualization implementations. So when I try the next 1809 upgrade via .iso setup.exe option, I will definitely first disable virtualization in my BIOS.

 

Hm. I wonder whether the laptop I'm struggling with even offers virtualisation...

But I will check when I get my hands on it again!

 

Here is another reason to avoid "check for updates" in Windows 10
https://www.ghacks.net/2018/12/14/here-is-another-reason-to-avoid-check-for-updates-in-windows-10/

 

Who wants to go see what they do at Microsoft? We all just want to use our computers without all the drama!

 

I knew that, I remembered you mentioning it somewhere (perhaps in this thread) recently and immediately made the connection with the reddit link I gave. I have an old laptop of about the same age and would've trashed it to try this out, but I'm very busy these days.

Nothing to add here, my thoughts exactly.

A bit of online digging for "dell latitude d620 vt-d" yielded several discussions on Dell forums that gave the positive answer. As I get it, the CPU supports it, you may have to update BIOS version to see the setting.

 

Tenforums also has a tutorial on how to upgrade Win 10 using a prior downloaded .iso file resident on your hard drive here: https://www.tenforums.com/tutorials/2267-upgrade-windows-10-a.html . Begin at Step 5) in the tutorial assuming you have already downloaded the upgrade .iso file. I did so using the MediaCreator tool. Also ensure you click on the "Mount" link on how to properly mount the .iso. The most important point here is to ensure the setting to keep your existing apps and files is check marked.

The above bypasses any need to create a bootable USB drive or DVD. It also appears this method has the highest chance of success.

 

Continuing the discussion of if 1803 Hyper-V is the culprit in these 1809 upgrade failures is strange behavior I have observed with it enabled. In Process Explorer, Secure System process shows in a suspended status. However checking same using Win Task Manager shows such is not the case. I have to date attributed this PE status to an issue with PE but who knows? There might be more to the inconsistency.

What I do know is old motherboard BIOS implementation of virtualization far precedes current Hyper-V use in 1803. I do know I have encountered multiple web postings of old issues with Hyper-V on Win Server OSes in regards to Gigabyte AMD BIOS implementation of virtualization. So just because a MB BIOS supports AMD-V for example, doesn't imply there might not be issues with the vendor's firmware implementation of virtualization.

 

I have suspected this one for a while and the update status is transparent to the user. Case in point.

A couple of weeks ago, I received my first every blue screen on Win 10 1803 after the system had booted and been used for a period of time. Traced the issue back to a JMicron Raid driver used for CD/DVD drive SCSI emulation. There is not per se a Win 10 driver for this device. My best guess is Microsoft delivered to me a 1809 beta driver which crashed my 1803 build. They "gathered and transmitted diagnosis" on the incident and then promptly rolled back the beta driver.

As Woody previously stated, we Home users are nothing more than "cannon fodder" for Microsoft.

 

https://news.softpedia.com/news/windows-10-version-1809-now-available-for-more-users-524263.shtml
"The update was then re-launched in November, and Microsoft said at that time that it was embracing a more cautious approach, meaning version 1809 would only become available to devices when they are considered to be fully supported, even when a manual check for updates was performed."

 

Using WuMgr and checking for update using "Offline Mode" and "Download wsusscn2.cob" and "manual download/install" I FINALLY got a notification about cumulative updates. (I never got them through normal WU)
I also just killed UsoSvc and WaaSMedicSvc because I don't need them anymore. I changed the permissions of the registry keys to only my user account. This should stop it from being reactivated, I hope.

I can't tell you guys how much I frigging love WuMgr! It's so liberating! You should use it too.

 

This has nothing to do with the article from the ghacks, which talks for "C" or "D" releases in general and not for the 1809 upgrade.
=

 

Happy to report folks that I finally successfully installed 1809.

Don't know if it was disabling virtualization in the BIOS, doing an in-place upgrade via disk resident .iso file, or both. I would say the later.

What I do know is I will never ever attempt a Win 10 Feature upgrade via Win Updates again. The in-place 1809 upgrade took a little under an hour. In fact, the subsequent 1809 Win Updating took almost as long to perform. Now for the best part of all. My 1809 build is almost identical setting and feature wise to my 1803 build. Immediately running OOSU10, only a handful of settings had to be reestablished; telemetry, Cortana, etc.. All my custom IE11 settings were the same, environment variables the same, etc..

Will keep virtualization in the BIOS off until tomorrow's cold boot to ensure no upgrade glitches surface then. If all is OK, will then reenable it and set on Core Isolation memory protection and see how that goes.

 

Also I am seeing web postings that all is not well as far as 1809 Core Isolation option. Below is a recent Redid posting noting that Memory Integrity is no longer working on PCs with later hardware configurations:

https://www.reddit.com/r/Windows10/...rted_there_may_be_an/?st=jppxlx35&sh=85c521db

 

It seems I killed my windows update to such an degree that I can't even use WuMgr anymore because the "Windows Update" service won't start. (I never touched this one)
Unfortunately I forgot to make registry key backups before changing the two other services irreversible.

Can someone please help me with this? I need a .reg of "UsoSvc" and "WaaSMedicSv".
(Win 10 pro 1803 17134.471) from Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\***

Edit: The windows update troubleshooter doesn't seem to find anything wrong with the three services not starting at all. great programming

 

Start value for UsoSvc = 2 and WaaSMedicSv = 3.

Also windows update service name is wuauserv and its start value = 3.

 

Nah, I need the RequiredPrivileges key of them and the correct permissions since I borked them too.
Edit: Of course I put in "everyone" with full rights, but I still get Error 87 "The parameter is incorrect" when trying to start it. I have to say that it worked yesterday. The error has event ID 7000

Edit: A restart just fixed wuauserv. So I'm ok. No idea why it was bonked temporarily.

 

Because restarts tend to do that, reset the permissions if they're missing...

 

But they're still the same. Man, windows is a bunch of weird.

 

If you didn't delete em, yes they'd still be the same, since they wouldn't be missing in this case

 

Unfortunately I don’t see it in BIOS, and I can’t find a newer version (than A10).

 

It appears Dell purposely hid the setting in the BIOS: http://mathy.vanvoorden.be/blog/2010/01/enable-vt-x-on-dell-laptop/ . Have no idea if the utility noted would work on Win10 since it appears it was written for XP. -EDIT- Looks like the utility is no longer on the Dell web site. You could contact Dell to see if there is a later ver. of the utility or if there is a keyboard key entry sequence that can be used to unlock hidden BIOS settings.

 

Well I enabled virtualization in my BIOS and its apparent that MS hasn't thoroughly tested the device security feature in 1809. Note that I have not even tried to enable memory protection in core isolation yet. What is occurring is a dual BIOS reload. At boot, BIOS screen shows, etc.. Then the black screen with the Windows logo. Then a return to the BIOS initialization processing with finally a successful boot into Win 10 1809. This behavior did not occur in 1803. One possible explanation is this old Gigabyte motherboard does have a dual BIOS setup. Of course, the second BIOS is only a backup for the primary. Borked 1809 might be recycling through both BIOS's before it boots.

At this point I don't dare try to enable memory protection. When I did that on 1803, it crashed the BIOS initialization with a machine check. Traced the problem back to my BIOS memory bus settings to allow DDR3-1600 memory to run on an officially only AMD DDR-1333 motherboard. Had to remove the setting which resulted in my DDR3-1600 memory running as default DDR3-1333. And that is only the beginning of the Win 10 1803 Core Isolation/Memory Protection charade. With it enabled, sleep mode no longer worked and had to be disabled with memory protection enabled.

So the short of Microsoft's "new and improved' kernel memory protections is they will probably only work w/o issue on very recent motherboards and default BIOS settings.