Likely you messed with certs other than the SKU ones. And the system didn't like it. Just follow my instructions and once you added the additional SKUs, to go back and forth slmgr /ipk <correct-SKU-KEY> and replace the \windows\branding folder is all you need to do. Now try sfc /scannow then slmgr /rearm, but if everithing fails the in place upgrade is likely the best path. It takes some time, but the PC does all the work.
It's the "many more" that concerns me. Whatever... did you try the sfc /scannow + slmgr /rearm ? When that was supposed to happen? In place upgrades works in 2023 just like it worked in the DOS days and is usually a bullet proof procedure, on modern windows (vista+) you just can't do in place upgrades starting from a bootable media. All you have to do is to launch the setup from a booted OS. It just works, believe me. Just take care of uninstalling any 3rd party antivirus/antimalware sw (if any) before starting with the in place upgrade. The worst that can happen is that, if anything fails, the old (untouched OS) is restored.
@pm67310 - I apologize, I missed your post initially (above the fold). After nothing else worked, I did an in-place upgrade. I don't know when this started working again because I had many nightmares in Win8/Win10 attempting in-place upgrades that were previously my go-to option for these situations. Fortunately the in-place upgrade worked great with the GVLK, retained all installations, and I am now running again. I'm posting this follow-up so that if others search for the Error: 0x80041005 Type mismatch (SWbemObjectEx) I hope this thread may help them. Thank you all for your insight.
Yes, I've tested with and without a reboot -- at least 20 to 30 times. In the CLI text I provided, I had created that for easy illustration; however, after it didn't work, I did the same thing w/reboot. Then attempted the same thing again w/ a variety of different attempts. I've used this same process in the past without problems -- however -- it appears the Error: 0x80041005 Type mismatch (SWbemObjectEx) -- is not rectified by this.
I still suggest to go for the in place upgrade path. But clearly you have still a messed up spp folder, try to replace it with the one taken from a xxxxx.1 iso, but do that offline, from a parallel OS or from win PE. Replace also the C:\ProgramData\Microsoft\Windows\ClipSVC, just to be sure
Thank you, just above https://forums.mydigitallife.net/threads/win10-corrupt-activation.86692/#post-1781763 - I mentioned that I was forced to do the in-place upgrade. However, in the future (or for others that stumble upon this thread) -- I'm very interested in your suggestion. Can you clarify whether I'm understanding this correctly? Interpretation of your Suggested steps: Boot to an offline WinPE OS Delete C:\Windows\system32\spp\store\2.0\tokens.dat Delete C:\ProgramData\Microsoft\Windows\ClipSVC Copy from the original Windows install to C:\Windows\system32\spp\store\2.0 Copy from the original Windows install to C:\ProgramData\Microsoft\Windows\ClipSVC Reboot to original OS slmgr /rilc slmgr /ipk <<KEY>> slmgr /rearm Thank you for your help. I hope this will benefit someone in the future.
Being offline I would replace both the whole folders ClipSVC and SPP (i don't think is necessary to play with both tokens.dat file in that scenario). In my experience is not enough to stop the services, I never investigated further but I think there is some kind of hardcoded anti tampering that spot you even if the services are down. Just a guess, I repeat, but I was never able to recover a situation like this being online.
@acer-5100 - Thank you, I have updated the post just above, based on your reply. Let's hope this can help someone else that stumbles upon this thread