Fighting an Unwanted Windows 10 Upgrade at Reboot

Summary

Windows 10 inserted itself into my system, so that the Win10 logo and Setup screen were among the first things I saw upon booting my system. I spent two days trying to figure out how it got there. Although I was never entirely sure, it looked like the culprit was a Windows 10 ISO that I had installed onto a YUMI multiboot drive. I had never actually used the Win10 ISO; apparently its mere existence was enough to propagate Win10 onto one or more drives. The following discussion provides a step-by-step account of the efforts I made and the possibilities I pursued, in an attempt to get rid of the Windows 10 infection. It also suggests some precautions. Note that this account includes some instances of uncertainty and confusion, as I attempted to understand what kind of problem I was dealing with and what I could do in response.

Discussion

I had taken all the appropriate precautions, as far as I knew, and even taken some that were perhaps inappropriate. I had installed and configured GWX Control Panel, to prevent Microsoft from forcing the Windows 10 upgrade onto my Windows 7 system. I had shut off Windows updates, having concluded that the Microsoft malware was more certain to get past my antivirus program than was any other virus that I had yet encountered. I had finally accepted that, after all the moderate words and well-meaning interpretations, Microsoft was, in fact, evil: that it was demonstrating a willingness to hurt people, to the point of threatening businesses and even jeopardizing life-dependent systems, in order to increase its own profits. On that basis, I had researched Linux as an alternative to Windows. I had even cursed the American government and legal system that were somehow unable to protect millions of consumers, for more than a year at this point, from Microsoft behavior that departed so dramatically from what people could reasonably expect of a software company. (There had been lawsuits, but as of this particular morning, they had not yet helped me.)

Despite all those precautions, upon rebooting my system on what I thought would be just an ordinary day, I found myself facing the dreaded Windows 10 logo, with its sinister blue on black:

win10-logo

After a moment, that logo gave way to the Windows 10 Setup screen shown here:

windows-setup-screen-3

Of course, I did not want to install Windows 10. It seemed I would need to stop this silliness before it proceeded any further. Therefore, I did not click the Next button.

Instead, I tried a few other things. One was to boot into Linux. I had previously prepared a YUMI multiboot drive — that is, an installation of a number of programs and operating systems on a single USB thumb drive. I used that to boot Linux Mint 17.3. Note: booting from a USB drive could require the user to hit F2, DEL, F12, or some other key during bootup. Doing so might open the BIOS, which could then be reconfigured to allow that sort of function key intervention; or it might bring up a boot menu, where the user could then choose which device to boot. The exact steps required here could vary from one system to another. On mine, it was F2 to open the BIOS settings, and then F8 to bring up a boot menu. (This was an ASUS H97-PLUS motherboard running the ASUS UEFI BIOS Utility.)

When I did manage to boot Linux from the YUMI drive, I found that, for some reason, the system was just crawling. I wasn’t sure whether the slowness was related to the Windows 10 hijack, but I made a note to myself to reinstall that Linux with the YUMI option to install to RAM. That way, I hoped it would be slow at first but then fast thereafter. The barebones Linux Mint Xfce seemed most useful for this purpose, and I was also glad that I had configured the YUMI installation to allow some space to remember my settings, because I was going to be running Xfce several times before I was done, and I appreciated not having to reconfigure Firefox every time I wanted to use it.

In Linux, I opened the file manager and looked at the C:\ drive. On my Windows system, I had named C to be PROGRAMS, so it was visible by that name in the Linux file manager. There, I looked particularly for the hidden folders that people said Microsoft would force onto my system: C:\$Windows.~WS and C:\$WINDOWS.~BT. But those did not seem to exist on my system. In the Linux file manager, I went into File > Search, allowed it to update its search database, and ran case-specific searches in the PROGRAMS partition for those names. Still nothing. I concluded that either those files or folders had not yet been downloaded to my machine, or else the Windows 10 files they contained had already somehow been installed, and the original $Windows downloads had then been deleted.

I assumed that it would be necessary to reinstall an earlier image of my C drive, so as to get rid of the Windows 10 installation. I had made images using Acronis True Image Home, and I had a copy of Acronis on the YUMI drive, so I used that to restore that earlier image. I didn’t want to do this. I had not made an image for three months. It seemed that there hadn’t been many changes, but ironically I had decided that this would be the day when I would finally make an updated image. Too late for that! But it turned out that this step achieved nothing. After restoring the earlier image and thus wiping out my most recent system state (which, in retrospect, I should have imaged anyway, just in case), I found on reboot that the Windows 10 logo and setup screen were still there.

So now it seemed that the Windows 10 change was residing somewhere other than drive C. I guessed that Microsoft must have screwed up my GRUB menu, or whatever it was that enabled my system to give me a choice of dual-booting into either Windows 7 or Linux Mint. That should have been obvious to me earlier, because that dual-boot menu was gone. So now, it seemed, I would have to fix the boot menu.

I started by trying another tool on my YUMI drive: Boot-Repair-Disk. The default setting on this tool had been useful, in the past, for fixing dual-boot problems. Unfortunately, it didn’t work this time. I was tempted to reinstall Linux in a dual-boot arrangement, because that would presumably restore the dual-boot menu, and perhaps that would help me figure out where the problem was. But before trying that, I wanted to see if I could get a clearer understanding of what I needed to do, in order to repair what Microsoft had corrupted.

To that end, a search led to a number of sources that assumed I already had Windows 10 installed. For example, one webpage advised me to use BCDedit within Windows 10 to fix the problem. Alternately, Microsoft suggested using Bcdboot — again, from within a running Windows system. It was difficult to find advice for those who had not yet proceeded with the Win10 installation.

A revised search led to a Linux Mint forum discussion that recommended Super Grub2 Disk. I added that to the YUMI drive, booted the system with it, and found myself looking at this menu:

sg2d_2-02s1-beta1_main_menu

I started with the “Detect and show boot methods” option. After a few seconds, it showed me what it had figured out. There was a listing of eight entries that referred to “msdos,” which I assumed meant Windows of some sort. Then there was a heading, “grub.cfg – Extract entries,” and under that it displayed more or less the GRUB menu that I had previously seen when I booted the system, with options for Linux Mint and Windows 7 among other things. I arrowed down to the Windows 7 entry and hit Enter. That worked. Easy: now I was in Windows 7, with no sign of Windows 10. That’s what I should have done in the first place.

Now I needed to get rid of whatever Windows 10 had done to my boot menu, so that in the future I wouldn’t see that Windows 10 setup menu anymore. I started by running GWX Control Panel. It provided buttons that offered to open the C:\$Windows.~WS and C:\$WINDOWS.~BT folders — which, as I could see, did exist on my system now, even if they hadn’t been there before. (They were dated today, so apparently I hadn’t just inadvertently restored them when restoring that earlier Acronis drive image.) I selected them and hit Shift-Del to permanently delete them. But, of course, they could come back at any time. It appeared that GWX Control Panel couldn’t be controlled from the command line, so there didn’t seem to be a way to make it visible onscreen automatically in a batch file scheduled to run every day. But there were two other things I could do: (1) I could customize the system tray (at the bottom right corner of the screen), by clicking on the little Up arrow at the left edge of that tray (assuming the GWX Control Panel icon wasn’t already visible), selecting Customize, and changing the setting for GWX Control Panel to “Show icon and notifications,” and (2) I could insert a batch command that would at least open the relevant folder every day, as a reminder to take a look at the GWX Control Panel. The batch command looked like this:

start "" "C:\Program Files (x86)\UltimateOutsider\GWX Control Panel\"

I hoped those steps would be helpful. (Later — consistent with what others had said — it appeared that Microsoft was taking active measures to defeat GWX Control Panel, so it was good that I had that folder opening up daily.) But those steps did not resolve the problem of the screwed-up boot menu. Now that I was running Windows, it seemed I should be able to use one of the methods (above) that weren’t available from Linux or bootup. I had no reason to think that Boot-Repair-Disk would work from outside Windows now, but perhaps Bcdedit or Bcdboot would do it?

To find out, I opened a command window. One way to do that was to hit WinKey-R and type CMD. (WinKey was the key with the Windows logo, presumably appearing on most modern keyboards, down near the lower right and/or left corners of the keyboard.) At the command prompt, I typed these commands with the usual way of getting information: “bcdboot /?” and “bcdedit /?” Both of those commands ran successfully, so I did have those two programs on my system. Bcdboot was recommended by Microsoft (above), and its help information was much briefer, so I decided to start with that. But as I reviewed its webpage, I saw that I did not entirely understand what it was suggesting, and also that it pointed toward EasyBCD.

I vaguely recalled having a good experience with EasyBCD at some time in the past, and I saw that it offered a GUI rather than the command line. I downloaded it from Softpedia and installed and ran it. As I clicked through its various tabs, I saw that it said Windows 7 was the only entry in the Windows bootloader, and that its bootloader path was C:\Windows\system32\winload.exe. That made me wonder whether Windows 10 had installed a new winload.exe. But no, if that were the case, my restoration of the older drive C image would have taken care of that. I had run “sfc /scannow” since restoring that image; had that perhaps restored the original winload.exe? I was tempted to reboot and find out, but I didn’t want to have to go back through the Super Grub2 Disk process (above). So I proceeded, in EasyBCD, to Add New Entry > Linux/BSD > Type: GRUB 2 > Name: Linux Mint > Drive: Automatically locate and load > Add entry. I was tempted to go with that, but then I saw EasyBCD’s BCD Backup/Repair tab. There, I decided to try the “re-create/repair boot files” option. I selected that and clicked Perform Action. It didn’t seem to change anything that I had just done; I wasn’t sure what it might have accomplished.

I decided to try rebooting. Unfortunately, there was still no boot menu. Instead, the Windows 10 logo and setup dialog were still there. My efforts so far hadn’t fixed anything. It occurred to me to try something I hadn’t tried before: I clicked on the X at the upper right corner, to close the Windows Setup dialog. It asked whether I was sure I wanted to cancel the Windows installation. I said yes. But that just rebooted and put me back in the same place. So now I started back through the Super Grub2 Disk procedure after all. Now I saw what EasyBCD had achieved: it had added a “Neosmart Linux” option to the Windows Boot Manager screen — but that screen was not coming up when the system was first booting. This made me wonder whether perhaps the Windows 10 installation material had gotten inserted into the BIOS, where presumably it would be safe from whatever I might do with these Windows utilities. I rebooted and went into the BIOS (F2 at bootup, on my system), but I didn’t really know what to look for, and didn’t see anything obvious. Another search led to nothing of immediate relevance.

I shut down the computer, opened the case, removed the screw holding the mSATA drive on which this computer’s drive C was located, and physically removed that drive from the computer. With all other drives connected as before, I started the system. The Win10 logo did not appear. This seemed to confirm that the Win10 installation was on that mSATA drive. So it seemed that I should be able to get rid of it by wiping that drive. I put the mSATA drive back in place. (Incidentally, this step, by itself, took about 20 minutes. The mSATA drive was buried down at the motherboard level, secured by a tiny screw that was difficult to put back into place without disassembling other items from the motherboard.)

I went back through the Super Grub2 Disk process, got back into Windows 7, and went to Start > Run > diskmgmt.msc. This confirmed that the mSATA drive contained the Windows 7 installation plus the Linux installation. I spent a couple hours trying to make good backups of those two installations. I was able to make an Acronis image of the Windows 7 installation pretty quickly. I was not successful in an attempt to move or copy the installed Linux files to another drive using the Linux Mint live CD: I kept getting Permission Denied errors. I thought I recalled that Knoppix would avoid that problem, but apparently not: it took a while to install that 4GB monster onto the YUMI drive, and in the end it wasn’t any better. I tried to use Clonezilla to make a backup of the Linux installation, but it kept having problems. I booted the system with Linux Mint on the YUMI drive, and tried using Mint’s System > Backup Tool option to create a backup of the Linux installation. That tool was odd: after an initial flurry of activity, it went quiet. The first time it did that, I aborted it. The second time, I let it continue. But after 15 minutes, I killed it again. I was unable to resize the Linux partition in Windows; but in Linux Mint on the YUMI drive, after some tinkering around, I got Gparted to do it. So then the partition was small enough to use Acronis — which, I believed, would insist on doing a sector-by-sector backup (i.e., no compression) for a Linux ext4 partition.

Once I had those images of the Windows 7 and Linux partitions, I rebooted into Linux Mint on the YUMI drive and used its Gparted again, this time to wipe and recreate those partitions. Next, I used Acronis to restore the backup images. Then I rebooted the system. To my shock and dismay, the Windows 10 malware was still there. I did not understand that. To my knowledge, I had erased the partitions on the mSATA drive, after verifying that that’s where the Win10 malware was located. I guessed that maybe Win10 was running from the BIOS or UEFI, but was only coming to life, at bootup, when the system contained a Windows 7 (or perhaps 8 or earlier) installation. That possibility occurred to me when, this time, I clicked Next at the Windows Setup dialog, and made my way to a set of options that included a button that would apparently allow me to change my UEFI Firmware Settings on reboot. I took that option. The system rebooted and, sure enough, I was in the BIOS setup utility. It seemed that perhaps I should have enabled the BIOS/UEFI administrator password.

In the BIOS, I tried restoring the default settings. The BIOS warned me that this would disable Intel Virtualization Technology, change SATA mode from RAID to AHCI, and set Boot Logo Display to Auto instead of Disabled. Those were settings that I had changed away from default for various reasons. I said OK. So now I had the default BIOS settings. The system rebooted. Now there was nothing: no option to boot Win10, Win7, or Linux. The YUMI drive would boot if it was plugged in, but otherwise I got a “missing operating system” error. I rebooted, intending to use the YUMI drive to run Boot-Repair-Disk. But, whoa, this was spooky: the Win10 logo was back. It was haunting me! But it was only there if I let the system try to boot naturally; I was still able to get into the YUMI drive options if I hit F2 and then chose the YUMI drive from the devices listed in the BIOS setup utility. I went back into the BIOS and undid the changes made by the reversion to default settings. That seemed to make no difference.

The BIOS said it was running version 2603. I went to the support page for my motherboard and saw that the system already had that version installed. I downloaded it anyway, put it onto a USB drive, and “updated” the system with it. On reboot, I got a message: “Please enter setup to recover BIOS setting. Press F1 to run SETUP.” It seemed to me that, if Win10 had burrowed its way into the BIOS, this update should have gotten rid of it. So I hit F1, adjusted the several BIOS items mentioned in the previous paragraph, saved those changes, and rebooted. Without the YUMI drive plugged in, I got “missing operating system.” With the YUMI USB drive plugged in, first time, I got the YUMI boot menu. Second reboot, I got the Win10 logo. Same as before.

I wondered what would happen if I tried booting the system with a bootable drive that had not previously been used on this computer, so that it could not have become infected with the Win10 virus. On another computer, running Windows 7 and GWX Control Panel, and showing no signs of Win10 infection, I created a bootable YUMI USB drive. Then, on the target computer, I disconnected and unplugged all drives and started it up. That just put me into the BIOS setup utility. Its boot menu said, “The system cannot find any bootable devices.” I plugged in this newly created bootable USB drive and rebooted. The system automatically booted the YUMI USB drive. Rebooting did not change this. So it seemed my hypothesis was incorrect: Win10 was not infecting bootable drives from the BIOS.

I tried again to boot the original YUMI USB drive. With no other drives connected, the Win10 virus started up. So my previous impression was correct: Win10 had infected the YUMI drive. That was regrettable. I had nearly 30GB of installed programs on that drive. If I could not figure out how to remove the infection, I would have to wipe and reconfigure that drive. That would take another couple of hours.

My recent investigation suggested that the infection on the original YUMI drive could not have come from the BIOS. So it must have come from one of the hard disk drives (HDDs) or solid states drives (SSDs) that I had previously connected to the system. It could have come from the mSATA drive, but only if my steps of repartitioning and restoring the files on that drive from Acronis image backups were not sufficient to remove it from that drive. Otherwise, it must have come from one of the other HDDs or SSDs. But none of those were bootable. The implication here was that it would spread to any drive. That was dismaying, because without thinking I had now plugged the original YUMI drive into my laptop, intending to look at its contents. The worry here was that, in doing so, I might have infected the laptop. I removed both from the laptop and booted the desktop again repeatedly with each. The behavior persisted: the new YUMI drive did not conjure up the Win10 parasite, but the original YUMI drive did, as before. This may have implied that the virus was best or only able to spread when some event caused some executable file to run — that, hopefully, it would not spread automatically to every disk in sight.

To test that, I plugged both the old and new YUMI USB drives into the desktop and rebooted it, with no other drives connected. On the first reboot, the Windows 10 logo came up. I unplugged the old YUMI drive and rebooted. With only the new, previously uninfected YUMI drive plugged in, the system would not boot. It went immediately into the BIOS setup utility. It showed the new YUMI drive as UEFI only, where before it also showed it as its ordinary self. The UEFI entries in the boot menu, I had found, were not bootable. At any rate, it tentatively appeared that the act of booting an infected drive might be sufficient to trigger the virus to make changes in other connected bootable drives. The theory in this case would be that the old YUMI drive was already infected, and that it reinfected that newly recreated mSATA drive when I had both connected at the same time.

To clarify this, I downloaded a beta version of the YUMI software that would hopefully create a UEFI-compatible YUMI drive. I tested that. It produced a message:

Secure Boot Violation

The system found unauthorized changes on the firmware,operating system or UEFI drivers.

Press [OK] to run the next boot device,or enter directly to BIOS Setup if there are no other boot devices installed.

Go to BIOS Setup > Advanced > Boot and change the current boot device into other secured boot devices.

I was not familiar with the concept of Secure Boot. A search led to a How-To Geek explanation that this was simply a means of securing the BIOS against malware that might seek to install itself without the user’s permission . . . seriously. I rebooted, went into BIOS setup > Advanced > Boot > Secure Boot. It said that Secure Boot State was Enabled. It was greyed out; I couldn’t change it. A search led to a Microsoft TechNet article indicating that I could disable Secure Boot, if I considered that essential, by going to the place I had just gone, but that I might also need to change something else, perhaps in the Compatibility Support Module (CSM) area adjacent to Secure Boot. I tried that. Setting CSM to Disabled gave me a warning message in poor English. I was not entirely sure what it was saying. A search led to a Wikipedia article indicating that CSM emulated the older BIOS type of environment (replaced by UEFI), so as to permit older operating systems to run. A Microsoft article said that UEFI was supported by some versions of Windows Vista and Windows 7; apparently UEFI was more completely supported by Windows 8 and 10. That article said, confusingly, that, “To use the CSM, Secure Boot must be disabled.” But both had been enabled on my machine. Not sure what that was about. I tried setting the CSM to Auto rather than Enabled. That didn’t seem to help: Secure Boot was still grayed, and on reboot I still got the same error message. I set CSM back to Enabled and tried setting the Boot From Storage Devices option to Both, Legacy OPROM First instead of just Legacy OPROM First. That didn’t help. I wasn’t sure it hurt — the infected USB drive still booted the Win10 Setup screen — so I left it as it was, at least for now.

I tried a different search. This led to Computerworld article that made me think I might have been safer with Steve Gibson’s Never10 than with GWX Control Panel — that Never10 might have prevented the initial infection that had now made my machine unusable. Another post offered this opinion:

[O]nce Windows 10 cancer has infected the system BIOS it will never be fixed. I’m guessing motherboard replacement is the only fix. . . . [A]pparently the Windows 10 root kit checks periodically and when it sees the EDID is good it “fixes” the situation by writing corrupt code and bricking the LCD again.

That writer spoke of motherboard replacement (and also video card infection) in response to the question of whether a user could remove the ROM chips infected by Windows 10. The answer appeared to be no. ROM chips were potentially an issue because, as Wikipedia explained, “A firmware rootkit uses device or platform firmware to create a persistent malware image in hardware, such as a router, network card, hard drive, or the system BIOS.” If the Win10 infection was indeed a rootkit, I could not be sure where it might be. A hardware replacement strategy could require testing each piece of hardware, one at a time, on an uninfected system — and perhaps infecting that system in the process. It appeared that motherboard replacement would be an understatement: the more appropriate response would entail replacement of the entire system, probably selling this one at a discount as some would-be buyers might not favor a system in which any component was in any sense “infected” with anything. Another search, focusing on the concept of Windows 10 as a rootkit, led to an article in The Register that said Microsoft did in fact adopt malware techniques to push Windows 10. Unfortunately, I did not see any suggestions on how to eliminate the virus.

I was hoping that the firmware rootkit concept was wrong — that this was just a matter of one drive infecting another. There were two problems with that. First, it did not seem that the guy quoted above would have just been inventing things; he indicated that he had flashed the BIOS on his system multiple times without success. Second, it was worrisome that I now seemed unable to get the newer YUMI drive to boot. I decided to try flashing the BIOS again. At the same time, I reformatted the newer YUMI drive: I wiped out the supposedly UEFI-compatible installation on that YUMI drive and ran the older YUMI software. With the BIOS change, the newer YUMI USB drive was bootable and rebootable, without infection, on the desktop machine. So it seemed that the guy might not have considered that his problem was mutually reinfectious drives, not firmware rootkits.

After the BIOS flash, the Secure Boot option was still grayed out in the BIOS utility. A search led to a source who advised that the solution was to set Master and User passwords in the BIOS — to which the advisee replied that these instructions did not solve the problem. The search led to other sources of advice as well. But now I was not sure I needed to worry about that, not if the BIOS was not infected. So I put that concern on hold for the moment.

I decided to explore further the hypothesis that one drive was infecting another. I started by connecting one SSD, with no other drives connected. When I booted the machine, it just went immediately into BIOS. It did not even try to boot the SSD or give me a “missing operating system” error. I rebooted a couple of times, and also tried booting the SSD from the boot menu in the BIOS utility. Same result. So it seemed that the SSD was not getting infected with Windows 10. I unplugged that drive and tried each of the other data drives, one at a time, including the DVD drive (with no disc loaded). Same result in each case. These drives had all been connected at various times when I had been working with the older, infected YUMI drive and with the infected mSATA drive. I concluded that the virus was infecting only drives that it considered bootable.

It seemed that the virus was spreading from one bootable drive to another, and perhaps only when one or the other was booted. To test this, I left all other drives disconnected, and tested only the older, infected YUMI USB drive and the newer, uninfected YUMI drive. First, I verified that this remained their current status. Booting with only with the older one plugged in, I got the Win10 logo immediately; booting only with the newer one brought up the YUMI menu as expected. With that YUMI menu onscreen, I plugged in the older YUMI drive. I used the newer drive to load Linux Mint and, in Linux Mint, I played around a bit, including using the file manager to look at the contents of the two USB drives. Then I unplugged the older drive and rebooted. This activity did not seem to affect the newer YUMI drive: on repeated reboots, its YUMI menu still came up, as expected. Now I plugged in the older YUMI drive and rebooted. With both YUMI drives plugged in at the same time, the reboot brought up the Win10 logo; there was no YUMI menu. I allowed the infected drive to run until the Windows Setup dialog was onscreen, and then I unplugged the older drive and rebooted. The newer YUMI drive was fine; it still brought up the YUMI menu on multiple reboots. It had not been infected.

That unexpected result made me wonder if there was something special about the older YUMI drive that caused it to be infected. One possibility was that it was targeted because, if I was not mistaken, it contained a full Windows 7 installation ISO. I plugged the older YUMI drive into the laptop and ran the YUMI software, clicking the Uninstaller box. That showed me what was installed. No, memory was not quite right: on this particular drive, I had installed many programs, but the only Microsoft items were a Windows 7 Repair CD and a Windows XP installation ISO. There were also some packages (e.g., Hiren’s Boot CD) that might have been built on a WinXP foundation. So there was a question of whether the Win10 virus was targeting XP as well as Win7 — or whether, instead, even a Win7 Repair CD would be sufficient to attract attention from the Win10 virus. To test that, I used YUMI to add a Windows XP x64 ISO to the new, uninfected YUMI USB drive. So now the newer YUMI drive had just two programs: Linux Mint and WinXP. Booting and rebooting the desktop computer with just that drive achieved nothing: I repeatedly got the YUMI menu. Booting with this both new YUMI drive and the older YUMI drive, I got the Win10 logo immediately. Booting and rebooting with just the new YUMI drive, I still got just the YUMI menu. Evidently the Win10 virus had not targeted WinXP. I used YUMI on the laptop to revise the new YUMI drive: remove the WinXP ISO and replace it with the Win7 Repair CD ISO. With that modification, the newer YUMI drive brought up the YUMI menu on repeated boots by itself. I rebooted and added the older, infected YUMI drive. That gave me the Win10 logo and Windows Setup dialog. I rebooted with just the newer YUMI drive. I still got the YUMI menu. So apparently the mere presence of a Windows ISO on an uninfected YUMI drive during bootup was not sufficient to propagate the virus. It remained unclear why the older YUMI drive had gotten infected, and what it would take for the newer one to become infected again.

For that matter, it was unclear why I could still bring up the YUMI menu (instead of the Win10 logo) on the older, infected YUMI drive, by hitting F2 at bootup to go into the BIOS utility, and using that utility’s boot menu to boot the YUMI drive. It appeared that the interruption in the desired process was happening after the BIOS identified the drive as bootable, but before it actually tried to boot it. And if the BIOS was the culprit, presumably it would interfere with a boot process initiated from its own internal boot menu. The possibility under consideration here was that, indeed, some other hardware on the system was infected, and that the infection would spread from that hardware to a bootable drive only when that hardware was used. But I had already run Linux from the new YUMI drive, so could it really be the video card? I tried to think of what else I might have done recently with the bootable programs on the old YUMI drive. Let’s see. I had used Boot-Repair-Disk, and its healing process included a requirement to go online, so possibly the network hardware or the online connection had polluted the older drive . . . but I hadn’t done that with the newer YUMI drive. I had run Clonezilla and other tools in Linux but, again, not with the newer YUMI drive.

As I browsed the list of programs available there in the YUMI boot menu, I saw something that should have been obvious to me: an option called “Install Windows_10_Pro.” I had missed that. It was there, in the first place, because it had seemed sensible to include the Win10 option on this Swiss Army knife of a YUMI installation. I hadn’t expected it to come alive and try to eat my system. I plugged that older YUMI drive into the laptop and took another look in YUMI. Sure enough, that Win10 ISO was on the older YUMI drive. I hadn’t tried installing it, but perhaps its mere presence explained why the older YUMI drive — and perhaps my entire system — had gotten infected? To investigate that, I installed that Win10 ISO on the newer YUMI drive. (I kept copies of all ISOs that I might want to install on YUMI drives, and the Win10 ISO was among them.)  I had to remove everything else to make it fit. So now the newer YUMI drive contained only Windows 10. I booted the desktop computer with that newer YUMI drive. The Win10 logo came up immediately.

Armed with that information, I used the YUMI software to remove the Win10 ISO from the older YUMI drive. I rebooted the desktop computer with only that older YUMI drive connected. Unfortunately, the Win10 logo came up anyway. So the drive did appear to have been corrupted, regardless of whether the Win10 ISO was the original cause. To verify that, I used the YUMI software to remove the Win10 ISO from the newer YUMI drive, and replaced it with Linux Mint. But removing via YUMI was not sufficient: the Win10 ISO had apparently sown its seeds across the newer YUMI USB drive. That is, after the ISO was removed, there were still several GB worth of files on that drive. The sources subfolder in particular contained a lot of information that didn’t belong on that YUMI drive, such as a file (in the sources\en_us subfolder) named oobe_help_opt_in_details.rtf (where “oobe” is Windows-speak for “out-of-box experience”) that began with these words: “When you set up Windows, you’ll be offered a set of Express settings . . . .” I verified that the older YUMI drive contained similar files. The conclusion was that the Win10 ISO was dangerous. I decided to rename and zip those files, in their storage location on the desktop computer, and to burn those zip files to archival DVD. That way, I would not reinfect my computer if, in a thoughtless moment, I shoved that DVD into the computer to see what was on it.

I was still not sure how the Win10 ISO on the older YUMI drive would have infected the newer YUMI drive or my Windows 7 installation on the mSATA drive. But I had already spent the better part of two full days on this unwanted project. It seemed the best I could do at this point might just be to insure that all working traces of the Win10 ISOs were removed from all of my drives. I hoped this would at last resolve this outbreak.

I reinstalled the mSATA drive and, with no other drives connected, I booted the system. I got “missing operating system.” I put Boot-Repair-Disk onto the newer YUMI USB drive, and tried using that to resolve the problem. I still got “missing operating system,” so I went into the BIOS utility and gave first priority to the USB drive. And that did it. I had my original GRUB menu back again. I checked it, and both Linux and Windows 7 booted and seemed to run normally.

So now I had some cleanup to do. First, I reconstructed the 30GB of bootable ISOs on the older YUMI drive, without including the Win10 ISO. I booted the computer with that YUMI USB drive to insure that it was not going to cause any more problems. I rebooted the laptop, to make sure it had not been infected by all this plugging and unplugging and modifying of YUMI drives. I set up Administrator and User passwords in the BIOS, though that didn’t do what I expected: it just imposed another entry password, which would not prevent Microsoft or anyone else from installing malware in the BIOS on the system when I was already logged into it. I installed Never10 in Windows 7. I wanted to delete the Neosmart Linux boot option that EasyBCD had installed, but neither EasyBCD nor msconfig nor anything else seemed to be finding it; I hoped that reinstalling Linux from scratch (which I was apparently going to have to do) would fix it, because an hour’s research into that didn’t provide any other solutions.

So that was fixed. The whole process took two full days — probably about 20 to 25 hours altogether. That was a really significant amount of my time that Microsoft had wasted. Now multiply that by thousands if not millions of users experiencing comparable upheaval. One thing for sure: Microsoft was teaching people to hate that corporation like never before.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Fighting an Unwanted Windows 10 Upgrade at Reboot

  1. Steve says:

    You need to understand the difference between UEFI-booting and normal ‘MBR’-booting.
    I would guess that your old YUMI USB drive contained a \EFI\boot\bootx64.efi file. This is the default boot file used by UEFI. I suspect that because you have Secure Boot enabled, the BIOS would always look for a signed bootx64.efi file and boot to that in preference to any other file.
    YUMI probably extracted the contents of the Win10 ISO to the USB drive. So the \EFI\boot\bootx64.efi file will have booted to \sources\boot.wim which is the Windows 10 Setup WinPE environment.
    These files may also have been present on your internal hdd.
    I suspect your Win7 was installed in MBR mode (not UEFI). So all you had to do was disable Secure Boot in the BIOS and set the boot option to boot to Legacy drive 0 so it did not try to boot from the \EFI\boot\bootx64,.efi file in UEFI-mode..
    To do disable secure boot, you may need to set a Master password (not User password!), disable Fast Boot option and then disable Secure Boot.

    • Ray Woodcock says:

      Thanks for that info, Steve. You’re right — if I had known more about all this, I wouldn’t have had to jump through so many hoops trying to figure it out. But I didn’t want to know about all this, or spend the hours to get to where you are on this issue. I mean, it’s great that you’re there, and I appreciate the help. But it’s still lost time to me.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s