Windows – How to create windows 8 boot partition on drive that never had one

Goodness sake, be careful!

It sounds like not "all is lost", but it also sounds like you only vaguely know what you're doing, and are proceeding. That is a recipe for "all is lost".

To elaborate, it sounds like you're able to access the vast majority of your data, but you're having troubles booting, which is a much simpler fix overall. But if you're not careful, you could easily lose the vast majority of your data.

First, it will help to make sure you know some basic terminology. The MBR is the first sector on a disk. The "MBR"-style of laying out partitions can handle drives up to 2 TB, and it looks like you're dealing with a drive smaller than that, so you might indeed be using an MBR and not the newer GPT format.

The two main jobs of an MBR are to have some initial boot code (instructions that the computer follows), and having 64 bytes of information to store details for up to 4 partitions (each partition table entry is 16 bytes).

Those 64 bytes of information can be pretty important. If you get some of these details wrong, operating systems may not properly understand some details about your partitions. And since operating systems typically write to disks, such misunderstandings can result in writing incorrect details that damage your ability to access data. So, being careful here is pretty critical.

A "partition" is basically a set of boundaries. You specify the starting sector, and either the ending sector or the size. Either way, you get a starting boundary and an ending boundary.

A "volume", sometimes called a "filesystem", stores your actual data. A volume needs to exist within the boundaries of the partition.

Now what typically happens is that an operating system looks at a partition, and assumes that a volume starts right at the beginning of the partition. Also, the partition specifies a "type", which is meant to be a strong clue about which style of volume is being used.

If the operating system can't find the volume, there are multiple possible reasons. One is that the partition's starting sector is wrong, and so the start of the volume isn't being properly found. Another possibility is that an improper "type" is being used, so the operating system doesn't know how to interact with the volume it is using. Another possibility is that the volume is damaged, and so the operating system is unable to find a volume that matches some details that the operating system checks for.

On my system, which is using GPT and that might cause some slight but significant differences, the "System" drive is the small drive (under a gigabyte), and my important data is stored on the large partition which shows up as a "Primary" type. The "System" type is not assigned a drive letter (although that isn't too hard, or problematic, to change... I would recommend assigning it a high drive letter, like S:, rather than C: or slightly higher. I also recommend avoiding X: since I think the Windows boot disk likes to use that.)

Since your System volume isn't even showing up, to me that suggests that it is damaged. You might need to restore that, providing a fresh copy of the boot files. This might not be something as easy to fix as using BCDEdit, which basically just tries to make slight changes. Your best bet may be to simply re-install the operating system (even to the same drive), which should accomplish a couple of things: placing a fresh (and not-updated) copy of Windows on your hard drive (which may be able to just overwrite, possibly even in-place, your current installation) and adjusting the ability to boot.

There might be an easier/simple way, but I recommend preparing for the possibility that there isn't.

However, I strongly advise you to get a full backup first. If at all possible, I even advise you to not just back up a few files that seem important, but to get a "forensic"/"bit-for-bit" image of the entire drive (onto another drive that is at least as large). That way, you can be comfortable that you're not going to lose your important data while you try to make any changes, and that you can revert in case any attempts go awry.

Having looked over your conversation with GuitarPicker, I am not as worried about your DVD drive showing up as it does. I think that just happens as a result of your boot partition not being detected; if your boot partition were detected, the DVD would automatically be assigned a higher drive letter without a problem. Using SET ID may indeed be helpful (and to find an existing ID, also known as a type, you can SELECT a partition and then say DETAIL PARTITION). But you did say, "I tried again to delete the boot partition with diskpart and recreated it". The problem here is that when you deleted the boot partition, you effectively told the computer to stop keeping track of any data on that partition, such as the critical data used to boot. Then, even if you did create a new partition and volume that are classified as the correct "type" for a boot partition, you still lack that bit of data that is used to boot the operating system. The typical way of getting that data onto a boot drive is called "installing the operating system".

While there might be some way to just transplant such boot data from another computer, some of the data may need to be placed in specific sectors on the volume (a picky detail which is not usually a concern except when dealing with boot files), and so this might or might not be quite as easy as just trying to do a basic copy. In other words, such a transplant has potential for troubles that make this approach not recommended for novices.

Note: I did read your comment about going from Win7 to Win10. You might be okay to just install Win10 over your existing drive, and if you're lucky then maybe your existing licensing might even get preserved, in which case you might not even need to fuss with going through the Windows 7 installation. But, for goodness sake, to make sure you don't introduce yourself to any worlds of new hurt, don't even think of trying that before making your backup. I know that such a task may be an annoyance (especially of money needs to be spent), but I'm re-stressing that issue because sometimes backups are even more worthwhile to make than average, and this is one of those times. So, I strongly advise you to do the wise thing, which is to make that investment in time/energy/supplies before any further mucking.

I adapted @merle's answer by using the approach documented on MSDN.

It shows drives:

• without drive letters
• mounted to a folder
• with drive letters

Sample output:

DriveLetter                    DevicePath               VolumeName                                       
-----------                    ----------               ----------                                       
                               \Device\HarddiskVolume5  \\?\Volume{a2b4c6d8-0000-0000-00000100000000000}\
E:\                            \Device\HarddiskVolume9  \\?\Volume{a2b4c6d8-1234-1234-1234-123456789abc}\
C:\Mounted\My-Folder-Mount\    \Device\HarddiskVolume13 \\?\Volume{a2b4c6d8-1234-1234-1234-123456789abc}\

PowerShell script:

$signature = @'
[DllImport("kernel32.dll", SetLastError=true)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool GetVolumePathNamesForVolumeNameW([MarshalAs(UnmanagedType.LPWStr)] string lpszVolumeName,
        [MarshalAs(UnmanagedType.LPWStr)] [Out] StringBuilder lpszVolumeNamePaths, uint cchBuferLength, 
        ref UInt32 lpcchReturnLength);

[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr FindFirstVolume([Out] StringBuilder lpszVolumeName,
   uint cchBufferLength);

[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool FindNextVolume(IntPtr hFindVolume, [Out] StringBuilder lpszVolumeName, uint cchBufferLength);

[DllImport("kernel32.dll", SetLastError = true)]
public static extern uint QueryDosDevice(string lpDeviceName, StringBuilder lpTargetPath, int ucchMax);

'@;
Add-Type -MemberDefinition $signature -Name Win32Utils -Namespace PInvoke -Using PInvoke,System.Text;

[UInt32] $lpcchReturnLength = 0;
[UInt32] $Max = 65535
$sbVolumeName = New-Object System.Text.StringBuilder($Max, $Max)
$sbPathName = New-Object System.Text.StringBuilder($Max, $Max)
$sbMountPoint = New-Object System.Text.StringBuilder($Max, $Max)
[IntPtr] $volumeHandle = [PInvoke.Win32Utils]::FindFirstVolume($sbVolumeName, $Max)
do {
    $volume = $sbVolumeName.toString()
    $unused = [PInvoke.Win32Utils]::GetVolumePathNamesForVolumeNameW($volume, $sbMountPoint, $Max, [Ref] $lpcchReturnLength);
    $ReturnLength = [PInvoke.Win32Utils]::QueryDosDevice($volume.Substring(4, $volume.Length - 1 - 4), $sbPathName, [UInt32] $Max);
    if ($ReturnLength) {
           $DriveMapping = @{
               DriveLetter = $sbMountPoint.toString()
               VolumeName = $volume
               DevicePath = $sbPathName.ToString()
           }

           Write-Output (New-Object PSObject -Property $DriveMapping)
       }
       else {
           Write-Output "No mountpoint found for: " + $volume
       } 
} while ([PInvoke.Win32Utils]::FindNextVolume([IntPtr] $volumeHandle, $sbVolumeName, $Max));