some of the id's used with vivetool are enabled now under service in beta CU to remove the id that you set it vivetool /reset /:........ /priority:user if you dont put user at the end it will reset the defaulted key aswel you just got to go through the list and look for user and check if theres a same id as service enabled
Anyone else had an issue after updating a stock 22621.1 to the LCU and applying the 23H3 enablement update, they can no longer use an install.esd file? Using install.esd the setup throws a C0000005 error and says files can't be found no matter the sku, but a search says it could be an unauthorized memory access, too. I have updated the boot and winre.wim files to 22621.2420 using KB5036567 (safe-os dynamic update patch, secure boots and smaller than LCU). I tried a full LCU on winre, still failed. Yet to try the LCU on the setup out of time constraints. I did find out I can at least compress the winre.wim into an esd-type LZMS:26 file and everything installs great, however my install.wim still eliminates fat32 at 4.4GB and I'd like to figure out the cause or potential remedy. It isn't generating common log information (dism/cbs.log, panther directories) that suggests what's going wrong.
No problems, i do this daily and all works fine. For compressing install.wim > install.esd I use the regular settings for dism = recovery or wimlib-imagex = LZMS solid. Never compressed winre.wim to winre.esd (that could be one of the causes it can't be serviced by WU) and when the install.esd >4GB you can split it (this only works for win 11 setup): Code: Dism.exe /Split-Image /ImageFile:install.esd /SWMFile:install.swm /FileSize:4000
Thanks for the reply. I should specify I applied the updates in offline servicing, all of them. I'll resort to a split install if necessary, hopefully it works. But before then, going to test what paths for errors I have left so I don't make them again. The compression of winre.wim with LZMS:26 (recovery/solid) was simply out of throwing my hands up at the problem that already existed. It worked out, and while it could cause troubleshooting issues, every attempt I have made to resolve the error code during initial setup has used stardard LZS:15 for .wims. I have tried DISM and winlib, tried two different machines and a hyper-v. It would appear none of my recent images can actually do esd right now. Perhaps something somewhere is a source of corruption, like the versions of the DISM or winlib used in conjunction with other applications and libraries that did not ship with those versions. I am now creating a fresh autopatched image from UUPDump as esd to see if the issue resolves. However it seems that their boot.wim contains the LCU by default, did not use the setup DU, but did use the safe OS DU. Going to try an iso with my current .esd files and this boot.wim first.
Setup DU mainly updates the ISO:\sources folder with the files inside, not a dism update but simply extract/copy/paste/drag content to ISO tool..
24H2 is already out, is it possible to find an upgrade package or need to upgrade from full scale installation media?
Noted. I never dealt with dynamic patches before, was trying to save space as the LCU bloat is already huge. ESD files are working with this boot.wim, not sure what exactly changed but the LCU on the boot.wim seemed to matter.
2024-04 Cumulative Update for Windows 11 Version 23H2 for x64-based Systems (KB5036893) Live on WU 2024-04 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 23H2 for x64 (KB5036620) Live on WU
It would seem I spoke too soon. It all installed under the UUPD boot.wim, but now I get "something went wrong" during OOBE and can't create an account. Gotta love the complete uselessness of most error messages. **** it, I'll deal with the big wim. I am sick of rebuilding over and over for days all day.
You seem to blame all on the install.esd, what would install.esd have to do with oobe, it already is applied at that time, sometimes we get an error about oobe region.... or something, usually the retry button will work and you can go on. And why don't you show us what you ran and such to see what is going wrong exactly?
Something greatly disagrees with the boot.wim and esd at the moment, that's all I know. I don't have the free time to diagnose much more but here's this. First it wouldn't install, then there was no amount of retrying going to break through that OOBE. Couldn't even enter audit. I opened settings and tried to make an account, again sum ting went wong. Event Viewer was throwing system.typeloadexception and was not available. Powershell was throwing "one or more errors...cannot read pslinemodule." Then I go back to my small boot.wim and all is well again, minus not being able to use ESDs or else get c0000005 in winpe setup. I did however notice I didn't not apply the setup DU, as applying it caused OOBE to break. Among my last tests will be the new boot.wim and no setup DU. Life calls, for now, however. Here's my unattend debris. I tried without it and with it, and with some things commented out, using an unrecorded combination of boots and winre's I thought I was keeping track of. The registry settings other than DefaultUser are already in the boot/install.wim combo that works, prior to applying them again via unattend as I'm trying to make it all in unattend over time. The base64'd reg entries in the unattend xml are for DefaultUser. It all goes on a tested, minimized pro/enterprise build that after compression comes to around 3GB storage space pre-application. As It's working now and I have other things to do, I can't say when I'd be able to test any recommendations. I'm midway through rebuilding the base but the patching and gutting is surgical and takes half a day straight.