Win 8.1 KB5004296 won't integrate error

this is getting absurd!
now I'm getting all kind of weird errors ,like
"this file has been externally modified" (that I fixed, re-copying the .msu packages)
or
"this file is not available fot use on this machine" (I don't know what the hell does this mean). the files ARE THERE!. maybe some stupid permissions thing is acting up)
(all of this after windows asked me to reboot to fix some errors on the drive structure, that might have messed something up).
The drives are OK, by the way, it's just logical errors.

edit: tried again...it seemed to go be going ok, the first update integrated ok (4589212), then it continued with 5004296, did a quick run, changed the status to "partial" and then after a minute or so, NTLite crashed (elegantly though, with a massage saying to send the .dmp and .log files to an emal address). the status bar showed the same message i had seen before, about the file being "externally modified" and that now "it's inaccessible" (or words to that effect).
this is really driving me crazy.

update:
SFC and DISM found errors, but for some or other reason, couldn't fix them, so I've had it and I'm doing a clean install from the latest working image I made with NTlite (upto build 19043.1110).
 
Last edited:
KB5004296 has servicing stack in it, tool supports integrating it on its own.
This was just for the quick test, I do integrate everything auto-selected by NTLite in its online update lists.

It's not about the updates, if you knew what kind of testing I do with 15 NTLite's in parallel integrating 15 images on the same machine, would not believe it after experiencing those issues you had with basic integrations.

So that is why this is so interesting to me, I hope it won't end up as some kind of hardware problem.
My guess is still it was a driver from 8.1 being migrated to Win10.

Let me know how the clean one does tomorrow.

Thanks for the feedback.
 
Now even the clean install failed half-way through!
I'm gonna try a different flash drive and try again...
(the win81-->win10 upgrade I did it using the ISO I had previously created with Ntlite, not the USB drive, in case you were wondering)
 
Last edited:
nuhi said:
Confirmed the issue as described under Win 8.1 RTM (no updates to the host - installing updates now).
Something about MSI.DLL not supporting offline integration with the latest Win10 servicing stack.

Did you update that 8.1 host to the latest updates?
If so, then Microsoft abandoned it, or it's a temporary bug in the servicing stack.
Click to expand...

ssu-19041.1145 cause the offline servicing to fail on any Host OS down 19041
i.e. it will fail on Win10 14393 or 17763 (tested myself), or 18362 (not tested but reported by others)

that MSI.dll error is harmless and not the cause
 
thanks for confirming that it will not work under win81 anymore.

Finally succeeded with the fresh install. After I finish setting everything up, I'm gonna try again (Integrating KB5004296, which is what started this whole mess)
 
Ok, so I finally got the host up and running, no problems, no BSODs, all updates installed (upto build 19043.1151).
So I tried to do the integration again, but still didn't work!
I used:
KB4589212-v2
KB5004296
KB5004331

4589212 integrated OK
5004296 skipped. At first it did a short pass and changed the status to "partial", then it did a second pass (20%...44%...74%...), took about 10 or 15 minutes and the status changed to "skipped"
5004331 integrated ok

After it finished with 5004331, a message popped with the following error:

Error 0x800710fe '[4350] This file is not available for use on this machine.' default (WHAT THE HELL DOES THIS MEAN???????)
Could it be that the HD is crapping out??? no SMART ERRORS whatsoever.
Could it be a deffective SATA Cable?

I know FOR A FACT that the .msu package is ok, because I used it earlier to update the host and it went just fine.

what do I do with the logs? should I zip them? can I attach them directly to a post?

Scratch that, I attached the zipped logs.
 

Attachments

  • NTLite Logs.zip
    1.6 MB
update: since I don't give up easily, I tried yet again, but this time I put KB4598481 back in the mix and this time IT WORKED. KB5004296 was integrated correctly. Although After it had finished the 4 updates, it went back to KB5004296, with "Integrating #2 : KB5004296" on the status bar and again going "20%..." and then finally "done". then it moved on to the tweaks and finally saving the changes until DAMN, another error:
"Error in the image operation
the image might be unsable and the edition must be rebooted after a reboot
C:\users\Jorge\Appdata\local\temp\NLTmpMnt01\Windows\WinSxS\amd64_system.core_b77a5c5c561934e089_4.0.15805_none_ef0211859fcd584d\System.Core.dll
[577] Windows can not verify the digital signature of this file. A recent hardware or software change could have installed a file with an incorrect or damaged signature , or it could be malicious software from an unknown source". three or four similar errors appeared after that.
(I'm translating, the messages are in spanish)

and then it stalled at 43% saving the changes to the image.

I also attached the logs to this post.
 

Attachments

  • NTLite Logs 2.zip
    39.8 KB
Wait!
I think I found something: i have several copies of the Windows ISOs, turns out the copy I'm using as source has different hashes from two other copies...maybe it's corrupted and that is all the problem. I'll replace it witht the correct one and try again

This is really strange. I recopied the file from the good source and now the hashes matched. But, After a while, i checked the hashes again and they didn't match anymore!!
It's like something is corrupting the file, even after copying and passing the hash-check.
Failing HD???
Maybe it's time for HDD regenerator to check the drive!
 
Last edited:
jvidal said:
Wait!
I think I found something: i have several copies of the Windows ISOs, turns out the copy I'm using as source has different hashes from two other copies...maybe it's corrupted and that is all the problem. I'll replace it witht the correct one and try again

This is really strange. I recopied the file from the good source and now the hashes matched. But, After a while, i checked the hashes again and they didn't match anymore!!
It's like something is corrupting the file, even after copying and passing the hash-check.
Failing HD???
Maybe it's time for HDD regenerator to check the drive!
Click to expand...
Also double-check the downloaded updates, they are even more likely to corrupt.
If using NTLite to maintain the update cache, then press Verify on the update downloader window, it checks for expected hashes.

Redownload image from here using MS tool, and retry. Answer in it not to upgrade, but download ISO instead.
 
abbodi86 said:
ssu-19041.1145 cause the offline servicing to fail on any Host OS down 19041
i.e. it will fail on Win10 14393 or 17763 (tested myself), or 18362 (not tested but reported by others)

that MSI.dll error is harmless and not the cause
Click to expand...
Ah, nice to know, hopefully they fix it. Let me know if you expect them to fix it.

Then obviously this is what confirmed worked from the 14393.0:
- extract KB5004296 MSU to get the individual KB5004296 CU CAB deep from it, without the SSU
- extract previous CU KB5004237 the same, but instead take only the SSU-19041.1081-x64.cab
That combo works, previous SSU + latest CU on pre-19041.
- then optionally update SSU

Will automate if they don't fix soon or reports start piling up.
 
The downloaded updates are ok, I used those to update the host, no problems.
There's something really weird going here.
I checked the hash of the iso and it didn't match the backups I had (which are ok, I verified them using a tool called "Windows and office genuine ISO verifier". I copied the iso from the backup and checked the hash again, it matched. But, after a while, the iso just sittign there, I checked the hash again and it changed. how the hell is that possible?
My ideas are:
The hard drive is failing (although it passed HDD Regenerator, no errors)
The SATA cable is deffective
RAM Errors, althouhg it passed over 10 hrs in memtest-86. Now running through Goldmemory and it found errors...mmmm that could be it...
The CPU has gone bad.

I'll keep testing.
Edit: since the PC has two 8GB modules, I stopped the process and removed one, to test each module by itself, to try to isolate the problem.
If both fail (what are the odds of that?), maybe then it's not the memory modules, but the memory controller (which is integrated into the CPU)
 
Last edited:
nuhi said:
Ah, nice to know, hopefully they fix it. Let me know if you expect them to fix it.

Then obviously this is what confirmed worked from the 14393.0:
- extract KB5004296 MSU to get the individual KB5004296 CU CAB deep from it, without the SSU
- extract previous CU KB5004237 the same, but instead take only the SSU-19041.1081-x64.cab
That combo works, previous SSU + latest CU on pre-19041.
- then optionally update SSU

Will automate if they don't fix soon or reports start piling up.
Click to expand...
But, If you are running the latest version of 21h1 on the host (19043.1151) this is not a problem, right?
 
Well, After endless and countless tests, I decided to replace the memory and try again, this time I succeeded (also trying the latest version of NTLite in the process).
I noticed the new approach to package extraction, which takes a little bit at the begining, but then re-uses the already-extracted packages for integration into subsequent windows editions, nice feature.

One thing I did notice is that after the process is done, when you close NTLite, it takes A HUGE amount of time to delete the extracted packages. WAY TOO MUCH, like 15 minutes or so. If that could be sped up, it would be awesome!
 
Thanks for the feedback, 15 min deleting seems a bit excessive, maybe an antivirus in the background?
Plus you can decide not to delete it, choose the third caching option.

Btw for abbodi86 and anyone caring for older hosts, Microsoft released a fix kb5005260, more info.
 
nope, no AV. It's just that the extracted packages contain several thousand files and it just takes way to long to delete them (it's a regular HD, not an SSD)
Not deleting them is pointless, it just would be accumulating garbage in the HD,because the next time I use NTlite, I, won't need them anymore, because I would be integrating new updates...

BTW, 5005260 is not just for older hosts, it applies to 21H1 as well.
 
I just finished integrating the latest updates, there were over 88.000 files in the NlTmpUpdExt folder.
There's gotta be a better way to handle the deletion of such a huge number of files...

edit: this time it went a lot faster, it was ready in under 7 minutes
 
Last edited:
nuhi said:
Thanks for the feedback, 15 min deleting seems a bit excessive, maybe an antivirus in the background?
Plus you can decide not to delete it, choose the third caching option.

Btw for abbodi86 and anyone caring for older hosts, Microsoft released a fix kb5005260, more info.
Click to expand...

The new SSU KB5005260 still fail for offline servicing under Windows < 19041
 
You must log in or register to reply here.
Back
Top