This is an off topic question... @abbodi1406, is there any way to display dll Message Strings in cmd? Or how to catch the message related to that kind of path? @%SystemRoot%\system32\InstallService.dll,-201
I am wanting to get the list of services in offline images. I only get the short names via reg query, but I would like to get the Full name, descriptions and dependencies. SC online only Get-Services online only I didn't find anything related to Offline. Do you have any tips?
You can use 7z.exe to extract string.txt from assosiated mui file (or dll file itself if it doesn't have mui files) and read the specified number string e.g. Code: 7z.exe e C:\MountDir\Windows\System32\en-US\InstallService.dll.mui -o. string.txt -r -aoa for /f "tokens=1*" %%a in ('find "201" string.txt ^|findstr /b 201') do set "var=%%b" set "var=Provides infrastructure support for the Microsoft Store. This service is started on demand and if disabled then installations will not function properly." but that might not work correctly for all langs (unicode characters... etc)
Does it have to be that perfect? even MS don't follow their recommendations sometimes and now they advise (with sloppyness) to add LCU to winre.wim , although that method is not working always what can be done for uup-converter: - if LCUwinre=0 ; winre.wim will get SafeOS DU only, and no LCU (even if SafeOS DU not present) - if LCUwinre=1 ; winre.wim will get LCU only, and no SafeOS DU - if SkipWinRE=1 ; winre.wim will be updated directly as boot.wim (no SafeOS DU or commit/save to other index) skipping SafeOS DU for boot.wim in other scenarios is still debatable
why LCU only without SafeOS DU when MS integrates SafeOS DU + LCU in 22000+ builds? I think LCUwinre option should work exactly as in W10UI and it's getting complicated for UUP dump, maybe it's better to detect build number and integrate updates based on build number winre.wim <22000: SafeOS DU only without LCU at all winre.wim 22000>=: SafeOS DU + LCU and I think boot.wim should get everything but SafeOS DU in any cases no, I'm happy with W10UI, there's just no consistency between both scripts
So it's fine for boot.wim to get both too? the suggestion is the same W10UI routine for winre.wim LCUwinre option was added to solve such differentiation
I never saw SafeOS DU in boot.wim in MS ISO in 19041+ builds boot.wim gets only SSU+EP+General+LCU (I think it's better to keep this order) and winre.wim is different in Windows 10 (+Server 2022) and Windows 11 Windows 10 / Server2022: SSU+SafeOS DU Windows 11: SSU+SafeOS DU+LCU my suggestion: in boot.wim always integrate everything except SafeOS DU, it will be SSU+EP+General+LCU in any scenario in winre.wim integrate updates based on build number: SSU+SafeOS DU if <22000 SSU+SafeOS DU + LCU if >=22000 LCUwinre: always forcibly integrate LCU in any scenario. for example it will integrate LCU in <22000 builds or we will follow MS documentation just like in W10UI: boot.wim gets only SSU+EP+General+LCU (except SafeOS DU) in any scenario winre.wim gets only SSU+SafeOS DU in any scenario LCUwinre: forcibly integrate LCU in any scenario this way we can manually enable LCUwinre for 22000>= builds or when MS will say us to do so I prefer MS documentation way, but it's not ideal for UUP dump because MS integrates LCU into winre.wim in 22000>= builds, autodetect is better
Both are WinPEs, if SafeOS DU+LCU works for winre.wim it will work for boot.wim it's small update anyway
no idea what to test because there's no changelog winre.wim updates exactly like in W10UI probably we need to change config file on UUP dump based on build number and enable LCUwinre for 22000 and later builds still not a fan of SafeOS update in boot.wim, that's why I prefer W10UI didn't get the point of CustomAppsList2.txt, original one was fine
Yeah, sorry about no changelog i will change the behavior to always add LCU to winre.wim for +22000 build the idea is that you can customize CustomAppsList2.txt and not worry about accidental overwrite for CustomAppsList.txt upon converter extraction (from current uup dump or manually)
Am there just thinking about The original MVS from January Windows 10 22h2 and the UUP version Have different versions of the efi version. I check with the original MVS and download UEFI Shell 2.2 are the same) they have the same hash values the version of the UUP is not compatible with an MVS Why UUP does not use the original MSDN efi files ?