Win 7 Load Error "[18] There are no more files"

G

Ghred

New Member
So I extracted all files from the unmodified Microsoft Windows 7 64-bit SP1-U Media Refresh edition ISO, selected the Professional edition, and then pressed Load. But I always get the following error message:

Aborted - Image mount
<folder>\Sources\install.wim
[18] There are no more files.

Huh?


BTW: I'm running Win 7 Pro directly to do this, not a VM...
 
Last edited:
Check the iso's file hash to make sure its not corrupted. When loading a folder use the Folder option, when loading a wim only use the Wim option.
 
Kasual said:
Never heard of.

Have you checked the paths in settings and the GB's free?
Click to expand...

Yep, and everything looks/looked fine. But just in case, I set everything up on a drive with 2 TB free, and got the same error.

By the way, someone reported this issue with Win 10, but I don't know if that's relevant in this case. See here
 
Not sure what is causing this and how to reliably reproduce it, probably some unmount not completed or a previous mount being stuck somewhere, but occasionally being hit with the same issue

Annotation 2020-02-28 112406.jpg

on:
  • host W10 Pro x_64 1909 b18363.657
  • NTL 1.9.0.7330 x_64 portable mode
 
Would this be an ASUS box? Google suggests it's some pre-loaded security manager (ADSM) borking your files.
 
Error 18 means something went wrong with the underlying host WIM engine, more info here.
Let me know what you find, and if I can help, but please read my (nuhi) replies in the linked topic.
 
I read that thread prior posting in this one. As stated I cannot reproduce it reliably as it just occurs intermittently.

On such occasion checked whether more than NTL instance been running but it did not seem to be the case. Rebooted the host and the image directory for which the error exhibited prior the reboot did not so after the reboot. Thus and though without hard evidence I suspect that

TT9tWhD$q said:
probably some unmount not completed or a previous mount being stuck somewhere
Click to expand...

which could very well be caused by some protective mechanism like WS with tamper protection, device guard, app guard etc in play.

One thing is certain that is not caused by corrupted data in the image directory.
 
As it just happened again unchecked "verify image files" in the settings and the image loaded, thus it appears related to that check.

After rebooting the host the image would mount, with "verify image files" checked/enabled, thence the image would appear in order/ok.

The overlay for that setting ( "verify image files") states

Annotation 2020-03-07 150122.jpg

Since the image mounted after the reboot it would be sort of logical/imply that files are not corrupted or that the disk it bad, or would it?

That would leave the "faulty network connection" -> what is that about? Does NTL connects to some internet source to compare hashes in the image?
 
It seems being reproducable when having having aborted the application process of an image. Steps undertaken

  1. donwloaded W10 ISO
  2. unpacked ISO in a working directory (\working\w10_untouched)
  3. made a copy of that unpacked image \working\w10_untouched -> \working\w10_trimmed
  4. mounted that image (\working\w10_trimmed) and performed trimming, driver integration, update integration
  5. then made a copy of \working\w10_trimmed -> \working\w10_final
  6. mounted \working\w10_final and applied various other settings but aborted that process (the actual application)
  7. closed NTL
  8. deleted \working\w10_final (tried both ways - soft to recycle bin and hard not to recycle bin)
  9. made another copy of \working\w10_trimmed -> \working\w10_final
  10. tried to mount (fresh copy of) \working\w10_final but that produces the error
  11. tried to mount \working\w10_trimmed (source for \working\w10_final) and that produces the same error
It feels like as if file hashes/descriptors are somewhere stored/cached from the aborted process that then may produce the error even after a fresh copy been generated. Also renaming the fresh \working\w10_final does not help.
 
Last edited:
You must log in or register to reply here.
Back
Top