NOT. Installing Windows isn’t a piece of cake. The cake is a lie!

Why do I say that? Well, because Windows installs have not been going well for me recently. It all started with this message:

Windows cannot install required files. The file may be corrupt or missing. Make sure all files required for installation are available and restart installation.

I was installing Windows 7 via a flash drive. The installer finished the step where the files are moved, then stopped and showed the error message.

This particular flash drive had worked previously, so I don’t know why it would have been corrupted, but just in case I tried another flash drive, also a Windows 7 installer.

Same message.

Being the math genius I am, I deduced that 10 > 7, so I figured Windows 10 might just do the trick. So I tried a Windows 10 flash drive I had on hand.

Same message. Huh.

I reformatted the flash drive and got the freshest copy of Windows 10 available, even fresher than my newest mixtape, straight from Microsoft using the media creation tool. I ran the installer.

Same message. Sigh.

Strange.

So clearly the problem here isn’t the flash drive or the files on the flash drive. The problem was something with the computer. But what?

In the past, I have run into a few odd booting problems. Sometimes it was legacy vs UEFI boot, sometimes it was 32-bit vs 64-bit… there are a number of different options to try toggling to see if you can get something to work.

I toggled everything I could find. No dice. It just refused to work.

So I tried to find some log files. Sometimes log files contain the error message that will actually help you, even if the graphical interface doesn’t display it. So I looked up where Windows stores log files during the install process.

I looked at two log files. The first one more or less told me something went wrong, and that I should check another log file. Thanks, first file.

The second file seemed very helpful at first. It gave a hint as to the actual problem:

dism.exe returned error code 0x17.

dism.exe is apparently the Windows tool that deals with Windows images – installation images, that is. Apparently it can verify if an image has all the right files. It makes sense that the error would come from this tool.

Error code 0x17. What is error code 0x17? I couldn’t figure it out. I couldn’t find any search results, and as far as I can tell, the dism.exe error codes aren’t actually documented. Or, it returns standard Windows error codes, such as you can see here. I don’t fully understand standard Windows error codes. They are documented, which is nice, but it seems odd to group all error codes of all Windows programs in the same place. In any case, here is error code 0x17:

ERROR_CRC: Data error (cyclic redundancy check).

So presumably it read data from someplace and detected the read was bad. But the flash drive worked fine with other computers. And I am not completely sure this error message was actually correct, because slightly about that line in the log file was another line that said file not found.

What file wasn’t found? I don’t know. It literally doesn’t tell you what file wasn’t found, it just says file not found. I don’t know what I am supposed to do with that information – it isn’t like I know what files are needed for installation.

I never did figure out why Windows wouldn’t install on this computer. My best guess is that the hard drive had gone bad. But prior to me installing Windows on it, it was actually running completely normally using Ubuntu. Maybe I had particularly bad timing and it was a bad drive after all.

Not for the first time, either.

Most of the time, operating system installs just work. But sometimes, they just don’t work, no matter what you try.

Most of the time, the issue can eventually be resolved either by using different install media or by booting to it differently. At times, this uses rather unconventional methods, like only working via USB 2.0 and not USB 3.0.

In most cases, I find the ideas for these fixes by searching online. And, most of the time, the fix has no apparent relation to the problem. For example, when I was working on the Windows install from before, the fix for one forum poster was to boot in UEFI mode. Sadly, the computer I was installing on predated UEFI, so there was no such fix for me.

I think I first encountered USB 2.0 vs USB 3.0 while installing Ubuntu. USB 3.0 installs just wouldn’t work for me – they all booted into busybox. Busybox is a sort of primitive recovery terminal used as a fall-back when the main operating system fails to boot. There was probably a way to find the problem using it, but who has the time? So I searched online instead. Somebody suggested booting it via USB 2.0 instead.

Why would that change anything? I don’t know, but it did. And it has for me in other situations as well.

Similarly, I have had OS installs where having another flash drive connected somehow messed up the install process.

I once had a fun case where I was trying to dual boot Windows and Kali Linux. As it turns out, this is, to say the least, not recommended, in part because Kali Linux isn’t intended to be used as a daily driver operating system in the first place. But I tried it anyway.

For some reason, Kali Linux was obsessed with the CD drive. This was odd, because I was installing from a flash drive. But it insisted that it was missing files in the /cdrom directory. So I symlinked the /cdrom directory to point to the flash drive instead. The install then proceeded normally. Or so I thought.

Right at the end, right before it told me to reboot, it said something like this:

Sorry, I was unable to install the bootloader. This means your system probably will not be here when you reboot. Sucks for you.

The installer was correct. I rebooted, and ended up in Windows instead of the grub bootloader. Still, in theory there is no reason you cannot install grub after the fact. So I booted from an Ubuntu flash drive and tried to install grub correctly.

Several hours later, I was successful. Well, at least at first. At some point when booting and rebooting into Windows and Kali, something happened with the bootloader, because the next time I rebooted I was met with this message:

Invalid Partition Table

The last time I saw this message, it was because I had a GPT-formatted (UEFI) drive and booted in BIOS mode, or vice versa (MBR booted in UEFI mode).

But at this point, I had sunk several hours into this project, and I just didn’t want to work on it more, so I left it.

A few days later, somebody was trying to use the computer. “How do you even use this thing,” they said. So I decided to take a look and see if I could recover to a bootable OS again.

I tried messing around with various boot options – UEFI, BIOS, back and forth a few times because why not. It works when plugging in USB drives, at least. Didn’t help, in this case.

Invalid Partition Table

At some point, after seeing this message too many times, I pressed some random key. And… booted into Kali Linux.

What?

I wasn’t sure if I wanted to reboot, because what are the odds I would find my way back into Kali? But I was curious, so I rebooted.

Invalid Partition Table

So what did I press last time? It took a while to find it, but apparently the magic key was enter. Every time you start the computer up, it prints this message. You press enter and boot straight into Kali.

Why? Beats me. I have a guess, though. I think it tries booting in some mode first, fails – something to do with the partition table – and then tries the second boot method in its list and succeeds. It is a bit confusing, because I am pretty sure it involves booting directly with UEFI into the partition, rather than going through grub.

It is odd to consistently boot into an operating system without knowing how you actually booted it. Somehow I didn’t figure out what was actually going on behind the scenes. Yet another unsolved mystery.

Installations are complicated.

That has been my experience, anyway. Honestly, it is impressive that installing operating systems works as well as it does, considering how many moving parts there are.

The thing that I keep seeing over and over again is that giving accurate error messages is apparently very difficult to do. At this point, graphical installers basically tell you “something happened” (looking at you, Windows) and just fail. What am I supposed to do about it if you don’t tell me what went wrong?

The interesting thing is that somewhere deep, deep within the machine, something very specific went wrong. Maybe there was a specific file missing, or perhaps a network connection didn’t initialize correctly. But that information doesn’t bubble back up to the surface where the user can see it.

For example, in my first story, the specific problem was that dism.exe returned error code 0x17. It wasn’t helpful to me in that particular situation, but in many cases it is. But the graphical installer didn’t tell me anything about an error code at all.

The reason for this, I suspect, is that properly communicating error codes is actually a lot of effort. Every individual program like dism.exe that plays a part in the installation process can probably fail in 100 different ways. The graphical installer cannot simply just explain what went wrong, because it doesn’t know every way that these individual programs can fail, or what caused them to fail in the first place.

And that is just the bigger picture. Individual programs have the exact same problem. Any given API function they call can probably also fail in 100 different ways, and they aren’t going to check every one of the failure conditions. Imagine a function call to create a file. Maybe the directory you create the file in didn’t actually exist. Or maybe it was locked. Maybe you didn’t have permission to access the directory. Maybe the directory is on a mapped network drive, and is no longer accessible. Maybe the operating system is just grumpy today and doesn’t want to do it anymore because nobody appreciates all the hard work it does and it deserves better.

So there are multiple levels of interactions going on. The graphically installer is just the highest level.

The installer probably just has a lists of tasks it runs. It doesn’t know anything about what the tasks do, it just knows how to run them and in what order. So when a task fails, all it really knows is that a task failed. The best it could do is just provide you the error code that triggered the failure that came from deep within.

But you know, users cannot see error codes these days. They might accidentally swallow them and choke to death, or something. Clearly, we need to use as few details as possible when explaining the problem, so we don’t scare away the users. That seems to be the Windows philosophy, anyway.

Oh well. Computers. Sometimes they just don’t work.