Open theRoboxx opened 2 years ago
I am having the same time issue. I am using Windows 10 22H2. This there any workaround for this?
If you update your windows it will bloat your system.... dont do it. Install windows offline, use it for 2 years, instead of update wipe and install latest version again, simple. You dont need to update when your system works...
Might be related might need to file a new bug report and will do so if requested.
Windows updater no longer updates on windows 11 and my error code is 0x80004002. I followed the steps from a windows post involving shutting down services through the cmd prompt, renaming some folders and starting the services again. Tried the updater troubleshooter. Did what looks like some safe mode stuff to no avail! Not really a windows guy. I followed this tutorial
https://www.thewindowsclub.com/fix-0x80004002-windows-update-error-code
Not sure what else I can do to resolve the issue or provide more information. Will gladly do so if recommended. Thanks!
So I just manually downloaded the cumulative update and installed it. after doing so updates just fine. I'm going to reapply the privacy.sexy script I generated and see if I have update issues. will post pack with results after new updates come in.
Windows is updating again! My issue likely had nothing to do with privacy.sexy. not sure exactly what caused the issue but manually installing the cumulative update solved the issue for me. Hope this solves further issues for others.
Hi, this issue is likely due to DoSvc being recommended in older versions (see #173). The latest version of privacy.sexy (v0.12.4) has addressed this.
To resolve the issue, please do the following:
Disable "Delivery Optimization" service
script in the latest version of privacy.sexy.Next Steps:
Background:
Before this script was in recommended pool, after figuring out the side-effects, now, it's moved to Strict and a variant without side-effects (Disable peering download method for Windows Updates
script) is recommended instead.
If it solves your problem, please let me know, in that case we can document that this script breaks Windows Updates. If problem persists, it's hard to reproduce if the full script you executed is not provided, it would be helpful if one could share the breaking script.
Just FYI, I still ran into Windows Update issues (0x80004002) with version 0.13.2. Fixed by rolling back 'Disable "Delivery Optimization" service'
Just FYI, I still ran into Windows Update issues (0x80004002) with version 0.13.2. Fixed by rolling back 'Disable "Delivery Optimization" service'
Came here to say the same: on both W10 LTSC and W11 LTSC, using Disable "Delivery Optimization" service (breaks Microsoft Store downloads)
will also break Windows Update with 0x80004002.
I recommend changing the title/description to Disable "Delivery Optimization" service (breaks Windows Update and Microsoft Store downloads)
Used v0.13.6
I do not understand why this happens, I wonder if peer-to-peer updates forced upon Windows users now.
However, I will document the Windows updates breaking behavior and remove it from Strict pool.
Should this script stay under Disable obtaining updates from other PCs on the Internet (delivery optimization) or should I move it into separate category like "Privacy over Security => Disable updates". Because this category already has less intrusive ways to disable delivery optimization except disabling DoSvc
.
We already have "Disable automatic updates" but this new category would include scripts to disable doing updates anyway at all (including automatic and manual). I'm not sure best name would be in that case. "Disable updates" does not imply its impact, that it also covers non-automatic updates. Maybe a name like "Disable receiving updates from Microsoft", or similar.
Questions:
Depends on what you consider manual updates: while disabling DoSvc
would block manually checking for and downloading updates (because it blocks the download), it wouldn't block, say, manually running a .msu
file.
I would consider downloading/fetching updates part of Windows Update, i.e. the automatic updates part. So it could just be put under Disabled automatic updates
, I'd say.
Description
I'm not able to install the following update on my PC
2022-06 Cumulative Update Preview for Windows 10 Version 21H2 for x64-based Systems (KB5014666)
and receive the update error code 0x800f0988. This problem exists since I applied the "standard" rules from theprivacy.sexy-Setup-0.11.4
. After I tried many potential fixes from online sources (e.g. https://www.techpout.com/how-to-fix-error-code-0x800f0988-windows-10/), I installed an old backup from 2020 that contained only driver software. After that I installed the current windows updates and everything worked.Then I ran the script again but with only a few selected options. This is the terminal output which I got via copy+paste (if the tool stores logs of applied rules somewhere, please let me know, so I can post them here):
The following week(yesterday), the problem occurred again.
I started the PC and the windows updater showed me a new available update (KB5014666)* from June 28. I tried to install the update and it failed with error code 0x800f0988.
Previously, the update (KB5014699)* from June 14 didn't work for me when I tried the tool for the first time on the 20th of June.
*Reference for Windows 10 updates: https://support.microsoft.com/en-us/topic/june-28-2022-kb5014666-os-builds-19042-1806-19043-1806-and-19044-1806-preview-4bd911df-f290-4753-bdec-a83bc8709eb6
My conclusion is that the executed scripts block future updates from being installed.
How can I know which script caused this problem?
My next step would be to completely purge my system and install windows 10 from scratch, but maybe I'm missing something obvious.
OS
Edition Windows 10 Pro Version 21H2 Installed on 25.12.2020 (This is the clean backup from 2020) OS build 19044.1766 Experience Windows Feature Experience Pack 120.2212.4180.0
Reproduction steps
Additional information
Uninstalling Edge (chromium-based) didn't work for me as well.
I have three accounts on my PC. The scripts were executed from the administrator account. Could this be a problem?