Can't integrate .NET Framework 3.5 anymore...

Rainstorm

Rainstorm

New Member
Messages
19
Reaction score
1
Hello,

first of all, I work only on .wim files because I use the Windows Deployment Tool from windows Server.
Usually, I integrate the ".net Framework 3.5" cab via the update integration tool, and it always worked.
Now, when I backup the image file, NTlite gives me an error. Please see the screenshot.
I can't find any information about the error code so I'm stucked.

error.jpg

Thanks for help ! :)
 
Came here to post this. I also couldn't integrate it using the template for the latest publicly released ISO for Windows 10 (21H2)
 
did u take that cab file from sxs folder? if not, use the iso's netframework file from sxs folder
 
I just realized my error was a bit different. I used the template feature in NTLite which did add a cab file from the sxs folder

Integrating: .NET Framework 3.5 (includes .NET 2.0 and 3.0) 10.0.19041.1 - Error 0x80070057 - [87] The parameter is incorrect.
 
crypticus said:
did u take that cab file from sxs folder? if not, use the iso's netframework file from sxs folder
Click to expand...
Yes, the files come from the SXS folder. As I said, it used to work.
I tried on 21H1 Sep update, 21H1 Oct update, 21H1 Nov update and the new 21H2 (out 2 days ago), but it doesn't work. I thought it was a temporary bug but it's persistant and I'm pretty sure that the problem doesn't come from the sources or the .net cab file.
 
if you downloaded iso from uupdump u might already check the box "integrate net framework 3.5" sooo if its already there maybe thats the reason. i also recommend getting iso's from there since u can add updates and netframework.
 
I'm not the OP but I have the same issue and I downloaded my 21H2 ISO directly from Microsoft. Are you replying with those answers because you are unable to reproduce the issue yourself, or are you just trying to help without doing too much work? That's totally understandable btw - I sometimes try to provide insight about topics I'm familiar with but can't be bothered to test it because I'm not struggling with it.

This issue in particular is quite simple and not too time-consuming to reproduce though, not that I'm asking you to since you're not the developer. All you have to do is load up the latest Windows 10 21H2 iso downloaded from Microsoft, load it up in NTLite, go to Updates -> Add -> Template ->.NET Framework 3.5, Go to Apply -> Process.

You get the error from just that with no other presets or anything. NTLite 2.3.1.8454
 
garlin : Do you mean "NTLite.log" ? I don't have any other log file.

crypticus : Nope. I got a Visual Studio access so I can have directly any source of any product from the Microsoft Universe but I suppose that you already know that.

toomuchpie : Yep ! I get this error exactly as you explained it.
 
There should be NTLite_dism.log under AppData\Local\Temp, since DISM does the actual integration. If you don't have one, check the end of NTLite.log for error messages.
 
Thanks for the report.
Not only .NET package, by the screenshot it looks like all of them failed in some ways.

The host servicing stack does not support this version of Windows.
For example looking at the log and online, it gives this.

In the log it states you're using Win10 1607 as the host, and 32-bit Win10 21H2 as the target.
Tested fresh full unpatched Windows 1607 host + the mentioned image and .NET only, and yes got the error.
Then updated host 1607 with the latest updates, same.

Another idea is the 32-bit architecture, read somewhere that the integration on it was broken from time to time.

Do the integration from Win10 21H2, be it by upgrading the host or in a virtual machine if you don't want to upgrade.


If anyone else is still having the problem with this new information, let me know how.

Thanks.
 
All updates failed (got by the automatic update) but it was always as it, except for .net package. Now, even the .net package can't be integrated.
I work on the x86 and x64 Windows .wim files and I've got the same problem on both.

In the log it states you're using Win10 1607 as the host, and 32-bit Win10 21H2 as the target.
Click to expand...
I'm not sure to understand about the host ...
But each time I got a new install.wim file from an original ISO, I remove the old one and copy the new one, then I edit it. And of course, I have to reconfigure all options I need, each time too (a few job so it's ok). :D
So where can I see something about the Windows 10 1604 ??
 
Each image or update requires a minimum servicing level (DISM version), and your host is lower than that level. This requires you run NTLite on a version of Windows closer to the target version.

Nuhi's workaround is running 21H2 (unedited) inside a VM, load NTLite there and do the integration. Yes, that's a lot of work. But some versions of DISM cannot be transplanted because of host compatibility.

Newer Windows can integrate old Windows, but not the other way.
 
garlin said:
Each image or update requires a minimum servicing level (DISM version), and your host is lower than that level. This requires you run NTLite on a version of Windows closer to the target version.

Nuhi's workaround is running 21H2 (unedited) inside a VM, load NTLite there and do the integration. Yes, that's a lot of work. But some versions of DISM cannot be transplanted because of host compatibility.

Newer Windows can integrate old Windows, but not the other way.
Click to expand...
Ahh, I don't use W10 but 2016 Server Essentials. That's why I didn't understand about v1604.
It's easier for me as I work with the deployment service tool of Windows Server too.

However I confirm that I didn't any problem when I worked with wim files from v18xx, v19xx or v20xx isos, even if the host is a "1604" ....
I'll try on a 21h2 vm soon and check that.

Thanks
 
Server 2016 is based on W10 1607.

Depending on your DISM, it can tolerate a few versions later but where it stops is hard to guess. This why people just say "use the newer version of Windows". There is no cheat sheet showing which versions are too high. It's just luck when it works ¯\_(ツ)_/¯
 
Everything is ok with NTLite on W10 21H2. So it was certainly due to my 2016 Server, too old to still work like I need.
Going to try on a 2022 Windows Server ... :)
 
Rainstorm, releasing a workaround for this Windows limitation tonight, so if you don't want to upgrade, it should work anyway.
 
nuhi said:
Rainstorm, releasing a workaround for this Windows limitation tonight, so if you don't want to upgrade, it should work anyway.
Click to expand...
Thanks ! :)
But it's already done (This server is used for NTlite and various tests so ...). And I confirm it's ok with the 2022 Windows Server, seen as a v21H2 Windows.
However I think this problem wil be back in several months if it stays as a v21H2. So your workaround should be useful.
 
OK.

Done, uploaded in the build 8500+.
Let me know if now works better on older hosts.

Thanks.
 
You must log in or register to reply here.
Back
Top