none
Windows 7 Installer Fails Mysteriously

    Pregunta

  • Trying to install Windows 7 but cannot get past an error that says the following:

    Setup was unable to create a new system partition or locate an existing system partition. See setup log files for more information.

    Where in the world might setup log files be found?

    In this case, fortunately, the target computer has multiple Windows 7 systems that are working fine. They are in fact being booted from the same System Partition which seems to be working fine. The boot drive has 4 primary partitions. The first (active) partition is the System Partition, the 3 others each contained an instance of Windows 7 that worked fine until I tried to re-install one of the partitions. The Windows Installer allowed me to reformat the target partition prior to deciding that it couldn’t perform the installation. How’s that for quality system design work? Interestingly, even though the error message says the System Partition could not be located the Installer did remove the Windows Boot Loader entry for the Windows 7 System that used to be booted from that altered partition. Therefore, I’m pretty skeptical about the accuracy of the error message. There is good reason to believe that it has nothing to do with the System Partition.

    Of course I’ve been wrestling with various Windows Operating Systems for many years and this is something I’ve come expect. If you have any question about why one might want to run their computers using multi-boot this experience provides as good an answer as there is.

    The reason for doing this re-install is to capture a system that is functioning well and preserve it in the event that something untoward happens, as eventually always does, to the source partition. The technique being employed involves using WinPE and ImageX to make an installable image (i.e., .wim type file) of that good system. This image is then used to replace the standard “install.wim” file used by the Installer. Insofar as my custom installation image (i.e., my install.wim file) is pretty large (e.g., this one is bit larger than 10GB (but I’ve done this with images that are almost 30GB) I’ve been using a USB drive formated with NTFS for running the Windows 7 Installer. This is in fact the technique used to install both the second and third instance of Windows 7 running on this computer which makes it even more mysterious why this error is all of sudden appearing.

    Is it possible that anyone might be able to elaborate on causes for such a problem? If not, is there such a thing as a setup log? My Installer is on a writable disk but a search is unable to find any files updated on the date this error occurred located anywhere on that disk.


    • Editado SnookRed viernes, 11 de mayo de 2018 1:49
    viernes, 11 de mayo de 2018 1:46

Respuestas

  • A little dart throwing seems to have succeeded in resolving this problem.

    It seems that the BIOS for this computer used a nested style for setting the boot priority.  It seems that the basic (i.e., highest) level setting involved choosing device groups where groups are types of devices (e.g., floppy, optical, HDD, Net).  Then within each group the specific devices installed could be prioritized.  Within my HDD group the secondary drive which contained NO bootable/primary partitions was specified to have the highest priority.  I suspect this reflects the likely scenario where this drive was once the only drive installed.  Then when an SSD was added, which became the boot device, it ended up having lower priority.

    Changing this sequence to specify the highest priority for the actual boot device solved the problem being discussed herein with the Windows Installer.  However, I'm quite certain that this setting has not been altered since the Windows Installer was used to install 3 prior instances of Windows 7.  Therefore, this does not explain why all of a sudden the Windows Installer failed in this manner.  That remains a mystery.



    • Editado SnookRed sábado, 12 de mayo de 2018 15:38
    • Marcado como respuesta SnookRed sábado, 12 de mayo de 2018 15:39
    sábado, 12 de mayo de 2018 15:36

Todas las respuestas

  • Hi Snook,

    It seems you have multiple Operating System installed on your computer.

    Please follow this article to troubleshoot firstly

    https://neosmart.net/wiki/setup-was-unable-to-create-a-new-system-partition/

    Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    If the issue persists, please collect the setupact.log and setuperr.log file for analysis. These log files located in

    %systemroot%\Panther.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    viernes, 11 de mayo de 2018 7:34
    Moderador
  • Not sure what you might be thinking when saying multiple Operating Systems.  It would be accurate to say that I have multiple instances of the same Operating System (Windows 7 Pro) installed in what is commonly referred to as a multi-boot setup.

    I'd found the referenced article on my own prior to posting this thread and had attempted the first of the 2 suggestions which did no good before initiating this post.  I cannot do the second suggestion without factoring in other considerations.  Most significant is the fact that I already have 4 primary partitions defined on the drive.  Three of the 4 are still working correctly which includes the System Partition and I don't want to risk harming it.

    It has occurred to me that I could add another internal drive to the computer which could then be used to try and create a new System Partition in a way that wouldn't harm the one I have that is working fine.  Absent some reasonable explanation for what is wrong now this would amount to dart throwing with your fingers crossed.

    Not sure what %systemroot% you might be referring to.  If there is such a thing on an installation disk a more definitive explanation on how to identify it is needed.  Please recognize that according to the search function of Windows Explorer there were NO files modified on the date the Installer was executed.

    viernes, 11 de mayo de 2018 16:55
  • OK, I found the log files.  It seems that the Installer runs like WinPE or, possibly, it might be preferred to put that the other way around.  Anyway learning how to escape to command prompt was helpful and allowed me to locate the writable RAM disk which contains a directory named Windows\Panther.

    The setuperr.log file was empty.  I have the setupact.log file but not sure what I can do with that.  It looks to me like the relevant entries are the following:

    2018-05-11 15:12:58, Info                  IBSLIB CanBeSystemVolume: Volume at disk [0] offset [0x100000] doesn't meet criteria for system volumes...
    2018-05-11 15:12:58, Info                  IBSLIB DiskRegionSupportsCapability:Disk [0] is BLOCKED against capability [CanBeSystemVolume] for the following reasons...
    2018-05-11 15:12:58, Info                  IBSLIB LogReasons: [BLOCKING reason for disk 0: CanBeSystemVolume] The selected disk is not the computer's boot disk.

    In that, disk [0] offset [0x100000] is the first primary partition on the first disk.  It seems to have concluded that this is NOT the computer's boot disk.  That partition shows in Computer Management/Disk Management as Active and is called a System Reserved Volume.  There is one secondary internal drive installed on this computer but contains no primary partitions (only extended partition with logical drives) and therefore cannot have an ACTIVE partition.  That is to say there is only one permanently installed (non-removable) drive with an ACTIVE partition.

    For whatever it might be worth, I'm writing this from the same/problem computer and it was booted from that disk/partition.  Now, it would be true that when running the Installer the computer was booted from another disk.  Isn't that the way it has to work?

    It is possible that I'm misinterpreting the log file and I'd be glad to provide it to whomever is better at such interpretation.

    Another possibility, now that I know how to shift into a command prompt, is to learn if there is a way to clear this up prior to starting the Install?  For example, can I use diskpart to explicitly set the partition to active.  Problem of course is that may not be what is meant by "the computer's boot disk".

    viernes, 11 de mayo de 2018 20:04
  • A little dart throwing seems to have succeeded in resolving this problem.

    It seems that the BIOS for this computer used a nested style for setting the boot priority.  It seems that the basic (i.e., highest) level setting involved choosing device groups where groups are types of devices (e.g., floppy, optical, HDD, Net).  Then within each group the specific devices installed could be prioritized.  Within my HDD group the secondary drive which contained NO bootable/primary partitions was specified to have the highest priority.  I suspect this reflects the likely scenario where this drive was once the only drive installed.  Then when an SSD was added, which became the boot device, it ended up having lower priority.

    Changing this sequence to specify the highest priority for the actual boot device solved the problem being discussed herein with the Windows Installer.  However, I'm quite certain that this setting has not been altered since the Windows Installer was used to install 3 prior instances of Windows 7.  Therefore, this does not explain why all of a sudden the Windows Installer failed in this manner.  That remains a mystery.



    • Editado SnookRed sábado, 12 de mayo de 2018 15:38
    • Marcado como respuesta SnookRed sábado, 12 de mayo de 2018 15:39
    sábado, 12 de mayo de 2018 15:36