Using VirtualBox to Run Software When Windows 10 Won’t

Note: this is the long version. The Summary has a short version. Another post may eventually provide a more detailed short version.

Contents

Summary
Introduction
VM Software
Options for Choosing and Installing the Operating System
Windows 7 Licensing and Activation
— Microsoft’s Violations of the License Agreement
— Appropriate Responses to Microsoft’s Overreaching
Cloning
— Clone vs. Copy vs. Appliance
— CloneVDI
Moving, Renaming, Copying, and Taking Snapshots
— Moving .vbox and .vdi Files
— Renaming the VM
— Copying the VM
Configuring the VM
— Windows Updates
— Miscellaneous Tweaks
— Access to Host Drives: Shared Folders
— Customized Start Menu: Using Programs without Installation
— Audio Playback Quality
Adding Programs
— Microsoft Office 2016
— Adobe Premiere Elements 12
— Cool Edit 2000
Wrap-Up

.

Summary

This post details the steps I took to create and configure a VirtualBox VM running Windows 7 on a Windows 10 host system.

The situation provoking this effort was that recent Windows 10 updates apparently made Windows 10 unable to run certain software that I used frequently. The idea was that I could run that software on Windows 7, in the VM guest system, even if it wouldn’t run in the Win10 host. If, as people said, I could also run the resulting VM in Linux, then I would have that additional level of protection against problems in Windows 10.

VirtualBox was commonly described as being one of the more user-friendly VM managers available. And, in some ways, it was. But much of the text in this post is devoted to reports on efforts to do things that should have been much simpler, such as copying, moving, and renaming VMs. I also found that substantial amounts of effort were wasted because I didn’t realize — I had to learn the hard way — that certain aspects of VirtualBox did not function as one might have expected.

Generally, this post traces the process through several steps: deciding to start with VirtualBox rather than VMware Player or other alternatives; deciding on Windows 7 as the guest operating system; dealing with complexities of Windows licensing and activation arising from efforts to copy and clone the VM; using the third-party CloneVDI tool to perform basic functions (e.g., VM testing, compacting, and resizing) that were still not standard features in VirtualBox; using snapshots; installing Guest Additions and otherwise tweaking the VM and the Windows 7 installation in it — to access data files on the host system, for instance, and to fix screen resolution; using portable programs on the host from within the guest; and installing and activating software without going online.

It developed that, at the time when I conducted most of this investigation, VirtualBox was having audio problems. That prompted me to consider VMware Workstation Player, as described in another post. I also did some performance benchmarking of VirtualBox in comparison to VMware and the Windows 10 host. By the time I was done with that, it seemed that VirtualBox may have been updated in such a way as to resolve those audio issues. If so, my comparison inclined me to use VirtualBox rather than VMware. It was also possible that, by the time I really needed a VM, containerization (e.g., Docker) would be making fundamental changes in the situation..

Introduction

I started this post in summer 2016. I shelved it to focus on using Windows 10. Now, in early 2018, I was circling back to it, due to problems with Windows 10. Specifically, as described in another post, it seemed that a recent version update, in Microsoft’s preferred Windows 10 operating system (OS), left my system unable to run Microsoft’s own Office 2016 software.

I did not absolutely need Office 2016. If necessary, I could transition to other office software that would run on Windows 10, such as LibreOffice, and I might actually gain in some ways. But I was not ready to make that transition. At present, I still wanted to be able to run Office 2016.

Most likely, I would be able to run Office 2016 on Windows 10, if I was willing to reset Windows 10 and then reinstall all my programs and settings from scratch. But I did not want to make that time investment now, and I certainly did not like the prospect that I would have to do it again and again, whenever Microsoft decided to tweak Windows 10 in a way that made it hostile to Office 2016.

Even worse, Windows 10 might itself become dysfunctional. It could cease to run outright, due to some future alteration by Microsoft or others; it could continue to be a magnet for hackers who might profit from its insecurities; it could fail, for whatever reason, to run software that I might want or need to use.

It made sense to look for a way to isolate my favorite software from the vagaries of Microsoft and its Windows 10 OS. One option would be to switch to Linux. Ten years earlier, for several years altogether, I was using Windows XP and a full load of Windows software in a VMware Workstation virtual machine (VM) in Ubuntu. I was not using much Linux software: then, and more recently, in 2016, my efforts to find satisfactory Linux alternatives to my favorite Windows programs, or to find ways to run those Windows programs in Linux, had produced mixed results.

Linux aside, another possibility would be to virtualize my favorite programs, so that they would run as if they had been designed as portable software. This could make sense if a portable program would avoid the roadblock encountered by some installed programs on Windows 10. But my efforts at virtualization had produced mixed results too.

If Windows 10 failed to run desired programs, another approach would be to run them in a VM on this Windows 10 host system, using Windows (XP or, more stably, 7) as the “guest” operating system (OS) — as, that is, the OS running inside the VM. A VM would have the advantage of portability. That is, if I ever ran into more severe problems with Windows 10, I could simply set up a double-boot Linux system and run the VM there, with the same Windows 7 guest system running the desired software.

A VM would have the drawbacks of slower performance and of more limited interactions with hardware. Yet I had been largely content with my system during those years of using the WinXP VM on Ubuntu. On balance, it made sense to explore the option of transitioning some of my programs to a Windows 7 VM.

VM Software

The first question was, which hypervisor should I use to create and run my VM? Performance-wise, various sources (e.g., Phoronix, 2015; LevelOneTechs, 2016) seemed to say that, on Linux, programs running in KVM or Xen VMs would perform at nearly the same speed as if they were running on “bare metal” (i.e., as if they were installed directly on the Linux operating system). Unfortunately, KVM and Xen were not available on Windows.

To update my previous investigation, a search led to confirmation (by e.g., How-To Geek, MakeUseOf, Lifewire) that Oracle’s VirtualBox and VMware’s Workstation Player (sometimes called simply VMware or VMware Player in this post) continued to dominate in the Windows world. These proprietary solutions had Linux versions as well, so the user would reportedly be able to use VirtualBox or VMware to run his/her Windows VMs on Linux machines. There would also apparently be the option of using KVM or Xen (among others) to run those VMs in Linux. Compared to the open-source KVM and Xen, VirtualBox and VMware reportedly offered features that KVM and Xen lacked, but also had the reported drawback of being slightly to significantly slower than bare metal, depending on task.

Between the two, VirtualBox was free, and there was also a free version of VMware. According to MakeUseOf (Lee, 2017), VirtualBox was somewhat more complicated, more buggy, and much slower than VMware Player. On the other hand, the free version of VMware did not offer snapshot and cloning capabilities, it was more difficult to get a VMware VM to run on different OSs, and the free VMware product did not have as many features as VirtualBox. How-To Geek (Hoffman, 2017) opined that “VirtualBox works very well, particularly on Windows and Linux . . . . We recommend starting out with VirtualBox.”

Pricewise, it was hard to get a straight story out of VMware. It looked like they were now charging $300 for a one-year subscription to Workstation 14 Pro, but Softpedia said only $250. VMware didn’t seem to be offering a free version of Workstation Player, but Softpedia had one for home and nonprofit use. A later search did find the VMware download page. On Softpedia, the free version of VMware had 4.3 stars from 420 raters, while VirtualBox got 4.7 stars from 410 raters. Although I had used VMware circa 2009, and had not regretted spending a couple hundred dollars for the paid version of Workstation, I had been working with VirtualBox most recently, in 2016; I liked its features; and the price was hard to beat. Therefore, I decided to start with VirtualBox.

Options for Choosing and Installing the Operating System

The next question was, which OS should I use in my VM? I didn’t have any particular need to run Linux or any other non-Windows OS. Among Windows options, I had liked Windows 7 most of all. It might have made sense to install Windows 10 in the VM, giving me two different Win10 installations, in hopes that at least one of them would run all of my software. But that might not work, and anyway then both the VM and the underlying native installation could have the same weaknesses. Windows 10 would also have privacy issues, and might also have different licensing issues. I decided to start with Windows 7.

The choice of Windows 7 would raise security issues. It wasn’t supposed to: Windows 7 was supposed to continue receiving “extended support” (i.e., security updates) until January 2020, though its “mainstream support (i.e., new features or tweaks) had ended in 2015. Unfortunately, in my experience and that of others, Microsoft was deliberately corrupting its updates in order to destabilize Windows 7, so as to force users to switch to Windows 10. Even without that corruption, I was not confident that Microsoft’s updates could be trusted to make Windows 7 entirely secure. So, if possible, for security reasons, it might be best to limit the VM so that it could not go online, except when absolutely necessary. If the VM had no Internet access, then presumably it would be vulnerable only through the host OS, be it Windows 10 or Linux. If its antivirus software was not going to be updated, it might be reasonable not to use any such software, providing a performance boost that a typically sluggish VM might need.

At this point, I became more aware that I actually had two different concepts in mind. On one hand, I did want to work up a simple Windows 7 VM, running just those programs that were not functioning in Windows 10. This concept was consistent with some parts of the previous post, where I created VirtualBox VMs in which I installed Windows XP and Windows 7 from scratch. In preliminary testing, with little if any software installed, both of those VMs seemed to work fine. The Windows 7 section of that post provided a list of steps I took to create the Win7 VM, in particular, and to customize it in a few basic ways that I found helpful. There was also the previously explored alternative of downloading a preconfigured VM that someone else (e.g., VirtualBoxImages, VirtualBoxes, Microsoft) had already created.

But on the other hand, would I be content with just a simple VM, running just a few programs that Windows 10 couldn’t run well, or would I rather find myself tending to do more and more of my work in the Windows 7 VM? The latter was certainly possible. Making Win10 unable to run Microsoft Office was a big deal for me. I did a lot of work in Office. Moreover, in my few months of using Windows 10, I had also seen other tools that it did not support; and at this writing Windows 10 had also ceased to run several other major programs, including Adobe Premiere Elements, my primary video editor.

If I did want a full-blown Windows 7 VM, with lots of software already installed, it seemed I might explore options for restoring or converting one of my old drive images of large and heavily tweaked Windows 7 installations. That would be a lot easier than reinstalling all that software from scratch in the VM. It might be the only option, if some old program or configuration existed only in that old system — if, that is, I no longer had program discs or any other source from which to reinstall a desired program.

As detailed in another post, unfortunately, I did not have good luck in my attempts to run VMs based on VHD files created by converting my Acronis drive image backups. The exploration described in that other post did leave open a few possibilities, if I wanted to do more tinkering and troubleshooting. But by the time I had spent some hours waiting on large and slow VMs to start up, struggle, and shut down, my feeling was that, if possible, it would be better to begin with a fresh Windows installation in the VM than to try to use a VM that carried the baggage of miscellaneous software I no longer needed, including some designed specifically for the long-gone computer on which it had been installed.

Windows 7 Licensing and Activation

A previous post describes the steps I took, in 2016, to create a minimal Windows 7 VM from scratch. I called it Win7 x64 Basic. Now I wanted to develop that minimal VM, to install and tweak software and otherwise customize the VM for my purposes.

Microsoft’s Violations of the License Agreement

Actually, I expected to go through several iterations, in the process of creating my new VM. Several of the following sections of this post suggest what some of those iterations would look like. For example, after tweaking the software and adjusting the settings, I would want to install software. At multiple points during and after each of those stages, I would probably want to make a clone or a copy as backup. So I would collect several clones or copies along the way, each representing further progress toward the goal of a final, working VM.

This plan did not seem to raise any problems with the legal or licensing aspects of Windows 7. According to ZDNet (Bott, 2010), different types of retail (e.g., full vs. upgrade) and OEM Windows licenses tended to differ on such matters as transferability to a different machine, activation requirements, allowable hardware upgrades, and upgradeability to newer Windows versions. My brief look at some aspects of Windows 7 licensing in another post suggested that, if anything, Microsoft might be overreaching when it essentially deterred users from buying and using physical or virtual system components.

That other post acknowledged that the courts perpetuated gross injustice, insofar as they supported a legal system in which corporate power insured that Windows users’ rights would rarely be properly researched and argued against Microsoft. But for purposes of responding to the moralistic browbeating that I had occasionally witnessed in discussions of Windows 7 VMs, the License Terms — at least the ones I examined — appeared to give users the right to install Windows 7 in multiple VMs, and to make backups of those VMs along the way, as long as they only used one VM per license at any one time.

One problem, then, was primarily that Microsoft’s marketing had become very aggressive in general, and visibly hostile to Windows 7 in particular. I was concerned, that is, that the process of activating a new Windows installation might become a barrier, if Microsoft saw it as another way to make Windows 7 harder to use. The forums were full of people who, for one reason or another, found themselves unable to activate their copies of Windows. I didn’t want to be among them.

Activation was ordinarily necessary within a short time after Windows was installed. Reactivation would then be necessary whenever the Windows installation detected enough of a hardware change to suspect that the user had copied it over to a different computer. Activation and reactivation would be required for VMs just as for physical machines. That said, excessive vigilance would probably be unjustified. As a practical matter, it was unlikely that most Windows desktop or laptop users would attempt to run more than one VM simultaneously: there did not seem to be much need for that sort of thing; multiple (1 2 3) sources said that doing so would tend to entail a significant performance penalty; and in any case Microsoft wasn’t losing anything, as nobody was going to buy another new copy of Windows XP or 7 (which Microsoft was no longer selling anyway) in order to run an additional VM.

Within the virtual world, it appeared that reactivation could be triggered by various changes in the VM’s virtual hardware that VirtualBox or I might make for reasons unrelated to Windows licensing, and also by VirtualBox upgrades. Beyond that, according to mpack, Windows 7 VMs “seem prone to suddenly deciding that your Win7 VM is not running genuine Windows, despite it being a completely genuine install.” As noted in the other post, that too appeared to violate the License Terms, at least in my brief review of relevant portions of those Terms.

I was inclined to avoid reactivation to the extent possible. To preserve the VM’s security, as noted above, I didn’t want to have to take this VM online to activate, so I would have to do phone activations. I didn’t want to have to make an activation phone call in the first place, and spend five or ten minutes hearing and responding to a digital voice rattling off strings of numbers; I didn’t want to find that the activation phone line was unresponsive; I didn’t want to be confronted by a live representative who would deny reactivation on the grounds that I had done too much tinkering, or had reactivated or changed system components too often. In short, I simply didn’t want additional snags when trying to work out the best way to create and use my copy of Windows 7 in my VirtualBox VM.

Appropriate Responses to Microsoft’s Overreaching

There was no doubt that, if users failed to do what Microsoft was able to demand of them, they would pay a price. There was also little doubt that, among those labeled as software pirates, some were probably good people who were simply trying to do what they could, to express justifiable outrage or otherwise make a difference, in a sea of indifference to gross (and sometimes grossly hypocritical) crony capitalism.

Principle aside, some technical responses to reactivation concerns seemed to offer relatively complete solutions. For instance, there was the suggestion to run the Windows 7 VM on a Linux host. I had seen reports that changes in the host machine’s hardware could trigger reactivation in the VM, but had also seen claims that that shouldn’t happen. I wasn’t sure whether a Linux host, with or without a switch to KVM or Xen, would reduce that worry. On the OS level, there was also the possibility that a Windows XP VM would work better. That possibility came to mind as I reviewed a SevenForums discussion and various VirtualBox.org discussions, some of which said that WinXP was less eager than Windows 7 to trip a reactivation. (I had found WinXP unstable when installed natively, but for me it had been pretty stable when running in a VMware VM circa 2009 — but I still had to reactivate sometimes.)

Another relatively comprehensive response would be to use a Windows 7 activator — which, if successful, would take care of activation at the start, and might even continue to do so. Examples mentioned by ZDNet (Bott, 2010) and Computerworld (Keizer, 2009) included Chew-WGA (short for Windows Genuine Advantage), RemoveWAT (short for Windows Activation Technologies) and Windows 7 Loader by Daz. Softpedia did not seem to carry any of those tools. Among additional possibilities, I saw specific references to Infinite Rearm (recommended by WikiHow, 2012) and Windows 7 AIO activator (recommended on Quora). It appeared that multiple sites claimed to offer such tools, but may not all have been offering the real thing; some may have been virus-ridden.

Like the ZDnet and Computerworld articles, most of those tools seemed to date from 2010 and thereabouts. There seemed to be considerable debate (e.g., 1 2 3) on whether various activators still worked or might cause system problems. Bott (2010 A and B) spoke of “a cat-and-mouse game” where Microsoft would apparently ship an update that would defeat one hacktivation technique, and the hackers would figure out a new way around it. Along those lines, Bott discussed the Windows 7 KB971033 update that would keep checking activation status every 90 days. It appeared that that update was included in service packs but could be removed. I wasn’t sure whether other unwanted updates had the same effect. (See e.g., the list provided by AddictiveTips (2016).) If so, presumably they could be removed too. Alternately, the user might be able to install, in the VM, a version of Windows 7 that predated such updates, and thereafter avoid adding that update.

As noted in my previous post, there were numerous other alleged possibilities for avoiding or defeating activation. At present, these appeared to include what that post described as “more radical and in some cases probably illegal use of pirated license keys . . . or other tricks,” as well as specific techniques described on Quora and GeeksForFun, the latter offering a companion video which explained that it was helping users to “activate it pirately.” The GeeksForFun method required download of a file that it called “Microsoft Toolkit” — which, of course, I was not about to download and run. The pirated license keys would presumably be useful if the user went through too many reactivations with his/her original license key. I did not test these methods, and thus could not say whether they were useful, useless, or harmful.

If such methods worked, as I say, they could provide a comprehensive or final response to the problem of rogue Windows activation demands. As a less complete but probably safer solution, various sources (e.g., WikiHow) described an apparently legitimate way to use Windows 7 without activation for several months. If you didn’t mind the hassle, some said this could be used with VM snapshots, using up those months and then rolling back to a clean machine and starting the same thing over again.

On such matters, my intended approach, at least for the time being and probably for the foreseeable future, was to follow the officially approved path: do what I needed to do and, when necessary, get my VM reactivated as usual and hope things went well. I had never run out of Windows activations in the past, and hoped that wouldn’t be an issue now. But I could see where, especially in Microsoft’s current mood, this VM thing might involve a lot more reactivations than when I was last seriously using VMs, years earlier.

Cloning

To summarize the preceding sections, my experimentation indicated that I would have better luck by developing the minimal VM in which I had installed Windows 7 and made a few basic adjustments, than by trying to convert an Acronis drive image backup into a VHD file that could then be the basis for a VM. On that basis, as described in a previous post, I created and activated a minimal Windows 7 VM in 2016; I put it on the shelf; and now I intended to develop it.

My way of developing that minimal VM would be to make some improvements in it; save a backup copy or clone; make more changes; make another backup; and so forth, until I had a final version of the VM, from which I would create copies or clones that I could use until they became corrupt, and then replace with another copy of the final VM. The Windows 7 license did not appear to prohibit any of this, but the reactivation process was something to avoid if possible. I hoped, now, to identify the best copying or cloning process for purposes of making these backups and working copies of the final VM.

Clone vs. Copy vs. Appliance

The previous post said that I activated the minimal Windows 7 VM when I created it, back in 2016. After that, according to my notes, I proceeded to make a clone, in VirtualBox, by right-clicking on that minimal VM and choosing Clone > provide new name and check the “Reinitialize the MAC address” box > Full Clone. If the desired target VM name already existed, or if there were other irregularities, my cloning effort might generate error messages like those discussed in another post. But in this case, the clone had succeeded: I now had a VM that I had named Win7 x64 Enhanced.

I ran that VM and saw that this cloning effort had triggered a new activation notice. That is, in Control Panel > System, at the bottom, it said, “3 days to activate. Activate Windows now.” I’m not sure if I knew, in 2016, that there were alternatives to cloning; and by early 2018 either I had forgotten or I hadn’t yet figured out that I might not have to use up one of my reactivations on this clone. Instead, I just went ahead and reactivated it by the phone method. (Note the option of using the MGADiag.exe tool, in Windows 7, to obtain information about an installation’s current licensing status.)

This was probably the point at which I should have gone into VirtualBox Manager, with all VMs powered off, and chosen File > Preferences > General > set the default machine folder to the desired location. I didn’t do that. This would create problems that I would have to deal with later, when I discovered my mistake (see next section, below).

A SuperUser discussion said there were three basic ways to move and/or make a copy of a VirtualBox VM: create an appliance, a copy, or a clone. All three required the machine to be powered down. The steps for the appliance and clone options began from the VirtualBox Manager, with the clone selected. My experiences with these three options were as follows:

1. Appliance. File > Export Appliance > Expert Mode > Export. The default was Open Virtualization Format (OVF) 1.0 format. TechRepublic (Wallen, 2017) advised sticking with that. DMTF said the principal advantages of OVF 2.0 format had to do with networking and encryption. I did not need those advantages. I had other tools for file encryption if needed. A SuperUser comment indicated that, at least into 2016, OVF 2.0 was considered experimental. Finally, as its name suggested, the Oracle Public Cloud Format appeared unnecessary for my needs. Thus, I opted for OVF 1.0 format. I noticed that it was going to save in .ova format. Wikipedia said that an .ova package would be “a tar archive file with the OVF directory inside.” Linux Village said the Manifest would contain the VirtualBox settings of the VM being exported. Mousing over the Manifest option produced a tooltip that said, “Create a Manifest file for automatic data integrity checks on import.” Mivilisnet said this option was “highly recommended.” So I checked the “Write Manifest file” option. In Storage Settings, I browsed to the desired output file location. Finally, in Appliance Settings, I double-clicked to change the name to match the output filename rather than the input filename. Then I clicked Export. This gave me an .ova file. In Windows Explorer (a/k/a File Explorer in Windows 10), right-click > 7-Zip > Open Archive showed me that this OVA contained a .vmdk, an .ovf, and a .mf file, the last presumably being the manifest. Back in VirtualBox Manager, as advised by TechRepublic (Wallen, 2017), I went into File > Import Appliance > browse to the .ova > Next. This showed me the appliance settings, presumably from the manifest file. It was possible to uncheck some items, but I just went with the defaults and clicked Import. I should have looked more carefully at the name: somehow, now, I had a new VM with the wrong name, in the list in VirtualBox Manager. In Windows Explorer, I looked at the new folder of the same name. Instead of the .vdi file found in a normal VirtualBox VM folder, I saw a .vmdk file. SuperUser said the export would throw away all snapshots. I powered up this new VM. In Control Panel > System, it said I had 3 days to activate. So the Appliance method produced a reactivation demand. Aside from the production of an .ova that might be useful in VMware or other software, I saw no particular advantage in creating an appliance rather than a clone. I powered down and removed the new VM and its files.
2. Copy. In Windows Explorer, copy and paste the folder containing the VM. This option is discussed in more detail in the next section (below).
3. Clone. Machine > Clone > Expert Mode > Full Clone and (optionally) Everything > enter the output VM’s name > Clone. As with my other VMs, I had already created a folder with the same name as the clone, and now in Windows Explorer I saw that folder begin to fill with the output .vdi. This cloning process was much easier than the Appliance process (above). When it was done, I selected the new addition to the VirtualBox Manager list of VMs > Machine Tools at the upper right corner > Snapshots and saw that it contained the same snapshots as the source VM. I started the VM and went into Control Panel > System. It said, “3 days to activate.” I powered down and went into VirtualBox Manager > select this new clone > right-click > Remove > Delete all files.

Some comments in a long VirtualBox thread (running from 2009 to 2017) suggested that there were versions of Windows XP and 7 (corporate or OEM, apparently) that would allow users to make clones of their VMs without triggering any need to reactivate. That may have explained TechRepublic’s (2017) joy at the prospect of making clones whenever they felt like it, no problem.

Sources indicated that using VirtualBox to make a clone of a VM triggered activation because VirtualBox would give the clone a different Universally Unique Identifier (UUID), so that the clone and its parent could coexist in VirtualBox without conflict. One option, then, would be to remove the source VM from the list in VirtualBox Manager, and then edit the clone’s .vbox file, so as to remove the UUID conflict. A separate post explored that and other responses to activation problems in clones. Other sources (e.g., 1 2) offered information that might add to or clarify what I had assembled in that post.

CloneVDI

This was approximately the point at which I discovered CloneVDI. I downloaded it through a VirtualBox forum. It was not available at Softpedia or FileHippo.

In my brief testing, CloneVDI offered several capabilities that could be very useful under certain circumstances. It could merge a chain of snapshots into the output VM (as long as they were in the default folder named “Snapshots”) and then delete those snapshots. (See next section for further information on snapshots.) (I was not sure whether the preservation of snapshots would depend on which snapshot was selected as the VM’s Current State.) In addition, CloneVDI was reportedly able to detect and repair VDI file corruption automatically, and could also compact and enlarge the VM. CloneVDI debuted in 2009 but, regrettably, these useful and sensible capabilities still had not been incorporated into VirtualBox itself as of early 2018.

For present purposes, the key question was whether CloneVDI could produce a clone with the same UUID, so as to avoid an unnecessary reactivation. To test that capability in CloneVDI, I started by powering off all VMs in VirtualBox Manager. I made any backups that I needed. Then I ran the CloneVDI .bat (not .exe) file. As the source, I designated an activated Windows 7 VM. I checked “Keep old UUID.”

While I was at it, to test its other features, I accepted CloneVDI’s option to increase virtual disk size, and designated a larger output size. The release notes accompanying the CloneVDI download said that the option to Increase Partition Size was available only when the Increase Virtual Drive Size is checked. Although it wasn’t entirely clear, the notes seemed to suggest that it would ordinarily be advisable to check this option as well as the Compact Drive While Copying option, at least for Windows systems. The notes seemed to say the compaction option might work best after defragmenting the guest operating system first. The notes also advised making a backup of the VM before proceeding.

With those settings and caveats, I clicked CloneVDI’s Proceed button. It responded with a dialog labeled Cloning Virtual Hard Disk. Cloning a 10GB (actual filesize) VM took about two minutes. When it was done, CloneVDI returned me to its main dialog. The dialog still contained my settings, with no indication that anything had happened.

I exited CloneVDI. In VirtualBox Manager, I right-clicked on the source VM (which, itself, was a disposable clone) > Remove > Delete all files. Then I clicked New > Expert Mode > Use an existing virtual hard disk file > navigate to the new clone’s .vdi file > set desired Memory Size etc. > Create. At this point, in a later test, I got some error messages. (Specifically, they were “Cannot create the machine folder . . . . This folder already exists and possibly belongs to another machine” and “Failed to open the disk image file . . . . Cannot register the hard disk.”) I cleared these up through a combination of rebooting VirtualBox and relocating some files.

Then I took a look at the snapshots for the new VM. I saw that the snapshots were gone, as desired. According to Windows Explorer > Properties, the new clone’s .vdi file was 8.7GB, while the source .vdi had been 10.9GB, so apparently the compaction process worked too. VirtualBox details showed, nonetheless, that the VM had been expanded to the requested 50GB capacity, which it would presumably fill as needed. I started the clone with no problems. (I think, but my notes did not specifically record, that the changes captured in the snapshots were now preserved in the new VM.) The one big disappointment was that, when I took a look at its Control Panel > System, it said, “3 days to activate.” Possibly I had misunderstood the “Keep old UUID” option; possibly there was some other way to avoid activation when creating a clone using CloneVDI. At present, those were unknowns pending further investigation.

To summarize this section, I found that, at least for my purposes, cloning achieved the same thing as making an appliance, with less work. I also found that cloning triggered a Windows 7 reactivation. CloneVDI offered some very useful features, but did not presently seem to prevent that reactivation, though possibly there was a technique I had missed; after all, its reputable creator claimed otherwise. At present, if I wanted to make clones without triggering reactivations, it seemed I would have to try those .vbox edits discussed in a separate post.

Moving, Renaming, Copying, and Taking Snapshots

This section discusses problems and solutions relating to the locations of VirtualBox VM files. My efforts to understand VirtualBox snapshots, at this point, produced a set of guidelines listed in another post. Those guidelines weren’t too complicated, but they weren’t all obvious, and in the sources I had seen, nobody else had figured out some of them. Among other things, they suggested a way to merge screenshots within VirtualBox.

At this point, I was finally moving somewhat past the testing phase, and was starting to get to a place where I could make something of my Enhanced (i.e., no longer Minimal) VM. Note that, especially for processes discussed in this section, VirtualBox could be very picky, very sensitive to slight variations from the correct procedures — very prepared, in other words, to give error messages.

Moving .vbox and .vdi Files

(This subsection contains notes that, on later review, seem somewhat tangled. I am leaving them as-is, in case others find them helpful. If nothing else, they may convey a sense of how difficult and confusing it could be to perform seemingly basic file functions in VirtualBox.)

This was when I discovered that I had not changed the Default Machine Folder, as described above. So somehow my Enhanced VM’s .vdi file was in one folder and its .vbox file was in another. I wanted them together. But how? (In solving this problem, I was aided by the Everything file finder, which showed a constantly updated list of all of the files pertaining to the Enhanced VM and the times when they were last modified.)

My search didn’t lead to a solution, so (after making a backup) I tried what seemed like the logical response, based on the advice I had seen so far. First, I made sure all VMs were powered off. Then I went into VirtualBox Manager > File > Preferences > General > Default Machine Folder > change to the desired folder. For example, I had a folder named VMs, and I wanted my VMs to be created in subfolders within that folder. So, to wind up with a D:\VMs\Enhanced subfolder, I would designate D:\VMs as the desired folder, and then the Enhanced subfolder would be created. Next, I went into VirtualBox Manager > select the Enhanced VM > modify Machine > Settings > General > Advanced > Snapshot Folder. In the example just given, the location would be D:\VMs\Enhanced\Snapshots. Those steps changed the (right) .vbox file in the (wrong) folder. Now, I guessed, would be a good time to close VirtualBox altogether, and then move the (right) files (including especially .vbox and .vbox-prev) from the wrong folder to the desired Default Machine Folder. So I did that, and then verified (in Everything and Windows Explorer) that I no longer had any stray files in the wrong folder or any other unwanted locations. Then I restarted VirtualBox.

Sadly, that didn’t pan out. VirtualBox showed the Enhanced VM as Inaccessible. The details in the right pane included the words “Path not found.” The error message referred to “F:\tinderbox\win-5.2\src\VBox\Main\src-server\MachineImpl.cpp[739].” The error message was confusing: neither that path nor that particular file existed on my machine.

At this point, I digress for a commentary on what happened when I looked for help with that situation on VirtualBox.org. Along with the opportunities to vent a bit of frustration and to provide advance notice to others who might post questions on VirtualBox.org, this digression let me think a bit more about problematic interactions in online help forums:

Seeking a solution, a search led to a ridiculously small number of hits, implying that I was one of the few people in the world who had ever had this problem. (Sigh.) Welcome to my life. Among those few hits, I found one VirtualBox forum discussion where someone else asked a question that seemed similar to mine. For some reason, unfortunately, the VirtualBox.org site moderator did not answer that guy’s question. Instead, the moderator (“mpack,” the creator of CloneVDI) just said, “Make the path exist, or correct it.” But he didn’t say how to correct it; and when I asked what that meant, another moderator (“socratis”) falsely accused me of hijacking the thread.

Overall, I’m sure those moderators were very helpful. But in the arguments mentioned in my other post, sometimes they had also been part of the problem. I had seen them give nonsensical and sometimes harsh responses to users who were expressing and trying to work through the frustrations of VirtualBox’s handling of snapshots. Ultimately, these moderators did not help at all to make that particular aspect of VirtualBox more understandable. If they had, I wouldn’t have had to go to the trouble of writing that other post, to work up a better explanation of snapshots.

Sometimes, these guys seemed deliberately unhelpful. For example, I had seen a thread where an ordinary user ventured the obvious suggestion that VirtualBox should offer a basic option to rename a VM, in place of the convoluted process described below. Two other users agreed (as do I). But the moderator (mpack) quibbled about terminology, went off on a tangent, and essentially disregarded the suggestion. That was in 2014. VirtualBox still doesn’t have the simple ability to rename a VM.

I assumed these moderators were volunteers, but possibly they were Oracle employees. Regardless, for some years, they had been helping people who definitely needed their assistance; they might have been a little frustrated with Oracle; and they were showing signs of caregiver burnout or compassion fatigue (see Wikipedia; Vitas; AARP) (e.g., always being “the go-to caregiver”; “becoming unusually impatient, irritable, or argumentative”). I suspected that a fair number of readers responded as I did in this case: upon seeing this kind of behavior, either they took their questions elsewhere or they just tried to solve them on their own.

In this case, I was able to resolve the error message by myself. To do so, I re-created the path that VirtualBox was no longer finding, closed VirtualBox, returned the moved .vbox files to that path, and then restarted VirtualBox, to see if the VM was still inaccessible. I did that, and it wasn’t. Whew! The VM still ran OK. So the rule seemed to be, don’t move the .vbox file; move the whole VM (somehow).

I say the VM ran OK. It did, but only after it gave me an error — which, with details, was as follows:

An error has occurred during virtual machine execution! The error details are shown below. You may try to correct the error and resume the virtual machine execution.

Details

Unable to allocate and lock memory. The virtual machine will be paused. Please close applications to free up memory or close the VM.

I clicked OK. The VM did nothing further. To see what was taking RAM, in the host (Win10) machine I went to Win-R > taskmgr. Remarkably, the Chrome browser was using almost 10GB. I closed that. This didn’t change anything with the VM. I went to VirtualBox menu > File > Close > Power off the machine. Then I tried starting it again. It said there had been a startup problem, but I hoped there was nothing to fix; I chose Start Windows Normally. That worked: the VM ran.

I powered it down and considered the situation. I had my .vbox file in one folder and my .vdi file in another folder. A search led to a Dolce Music post (ftrobaugh, 2015) suggesting that the .vbox was the “virtual machine” and the .vdi was the “virtual disk.” To move the .vbox to the right folder, ftrobaugh told me to right-click on the Enhanced VM > Show in Finder. Ftrobaugh was using a Mac; apparently the Windows equivalent was Show in Explorer. I did that. It opened Windows Explorer in the folder where the .vbox was located. Now ftrobaugh said that I should use VirtualBox Manager > right-click on the Enhanced VM > Remove > Remove only. That just removed the Enhanced VM from the list of VMs in VirtualBox Manager; I could see that the .vbox and .vdi files were still safe in their respective folders in Windows Explorer. Now, ftrobaugh said (in effect), I could use Windows Explorer to move the .vbox to the desired folder. I did that. The final step was to go into VirtualBox Manager > Machine > Add > navigate to the .vbox file in its new, desired location. I started the VM. It ran OK. All was good.

If I had wanted to move the .vdi, ftrobaugh said I would do more or less the same thing. (See also 1 2 instructions from mpack.) In that case, after powering down the VM, the advice was to go to VirtualBox Manager > select the VM in question > Details > click on Storage > look at Storage Devices > mouse over the .vdi > observe the path in the tooltip that comes up > select the .vdi > drop down to the icon with the red minus symbol on it. That would tell the VM to forget about the .vdi. Then I would have to tell VirtualBox to forget the .vdi too. For that, the instructions were VirtualBox Manager > File > Virtual Media Manager > select the .vdi > right-click > Remove > confirm Remove > Keep the .vdi (i.e., only remove it from the list of known hard disks) > Close. Now I could move the .vdi. Once that was done, ftrobaugh told me essentially to repeat those same two changes in reverse order. His/her advice didn’t quite work for me. S/he said, first, I had to open VirtualBox Manager > File > Virtual Media Manager. There didn’t seem to be an “Add” option in Virtual Media Manager, so I would have to find the desired .vdi using Windows Explorer > drag the .vdi into Virtual Media Manager. But when I tried that, Virtual Media Manager didn’t want to take it. Instead, as it turned out when I actually needed this advice, all I had to do was to go into VirtualBox Manager > select the desired VM > Settings > Storage > Storage Devices > right-click on Controller: SATA > Add Hard Disk > Choose existing disk > navigate to the desired .vdi > select it > Open > OK. As I would soon see, those steps worked.

Renaming the VM

After my first draft of this subsection, I proceeded to make a number of changes to the Enhanced VM (below). Then I came back and rewrote this part of this post. At that point, I decided to rename the Enhanced VM to be the Configured VM.

Renaming the Enhanced VM was surprisingly complicated. First, with the VM powered off and the Enhanced VM selected, I went into VirtualBox Manager > Machine > Settings > General > Basic tab > change name > OK. This changed the name of the folder containing the .vbox file, as well as the name of the .vbox file. It did not change the name of the .vdi file.

To change the name of the .vdi file, mpack emphasized that the VM should not use snapshots or encryption. Assuming no problem there, with the VM powered off, he seemed to intend that I should go into VirtualBox Manager > right-click on the VM > Remove > Remove only (not Delete All Files). Then, in Windows Explorer, rename the .vdi file. Back in VirtualBox Manager, he said, “[M]ount it again inside the VM that needs it.” I was not sure what that meant. Socratis rephrased: “Re-attach the renamed HD.” To do that, I went into VirtualBox Manager > Machine > Add > select the .vbox file. That added the VM back to the list of VMs in VirtualBox Manager. Then I went into File > Virtual Media Manager > select the old name of the .vdi file > right-click > Release > right-click > Remove > Close. (Maybe I should have released and removed the .vdi before renaming it.) It took me a while to figure out how to reattach the .vdi. The solution seemed to be to select the VM > Settings > Storage > Storage Devices > use the icon or right-click on Controller: SATA > Add Hard Disk > Choose existing disk > navigate to the .vdi > OK. That seemed to work: the file and folder were now renamed as desired; the VM worked; and in Windows > Control Panel > System, the operating system was still activated.

Note that, although this approach worked here, and seemed to be the one recommended by those VirtualBox.org moderators, it may not have been the fastest or best approach. I say that because I successfully used a somewhat different approach later, as described in the following subsection.

Altogether, with Google searches and reading various posts and making mistakes and starting over, the struggle to rename this VM took about two hours. I had also lost hours in similar previous efforts, before giving up or stumbling upon the solution. I had previously documented multiple other VirtualBox problems for which, as far as I could tell, there were no solutions. These personal experiences — combined with repeated indications (by moderators as well as users) that VirtualBox was “quirky” (to use just one example of an admission I had encountered) — did suggest to me, at this point, that eventually I might want to revisit the decision to use VirtualBox.

Copying the VM

I had now renamed the Enhanced VM to be the Configured VM. From here, I proceeded to add the tweaks described in the following section. When those were done, I would start installing programs, as described in the section after that.

When I reached that point of being prepared to start installing programs, I came back here and rewrote what I had originally written about copying the VM. In other words, the task described here was to make a copy of the Configured VM and save it as Programs VM.

To make a copy of the Configured VM, I made sure all VMs were powered down in VirtualBox Manager. Then I went into Windows Explorer and simply copied and pasted the Configured folder. That gave me a folder called Configured – Copy. I renamed that folder and its constituent files to be Programs rather than Configured.

Since Programs was identical to Configured in all regards except name, its UUID would conflict with Programs, if I tried now to add Programs to the VirtualBox list of VMs. VirtualBox would not know which folder to associate with that UUID. As I learned the hard way, it would give me a “Failed to open virtual machine” error:

Trying to open a VM config ‘[pathname].vbox’ which has the same UUID as an existing virtual machine.

The solution to that problem was to remove Configured from the VirtualBox list. That would not be a solution if I wanted to run both VMs, but I didn’t. Configured was the past; Programs was the future. To remove Configured, I made sure the VMs were powered down in VirtualBox Manager. Then I selected Configured and used right-click > Remove > Remove only (i.e., not Delete all files). I verified that the Configured VM files were still in their folder in Windows Explorer.

Then, to add the new Programs VM to the list of VMs in VirtualBox Manager, I used Machine > Add > navigate to the Programs .vbox > Open. It was added with the name of Configured, not Programs. To rename it as Programs, I used VirtualBox Manager > Machine > Settings > General > Basic tab > change name > OK, as in the preceding section.

At this point, I realized that I was taking a different route than that described in the preceding section. Just now, I had simply renamed the .vdi file, and that hadn’t worked when I had tried it in the preceding section. I saw, now, that it wasn’t going to work here either. In VirtualBox Manager, with the Programs VM selected, I looked at the right pane. There, I had selected Machine Tools (i.e., the drop-down button at the top-right corner of the VirtualBox Manager window) > Details. In that Details pane, under Storage, I saw that the Programs VM was still linked with the Configured .vdi file. And that made sense. I had renamed the files, but that wouldn’t change their internal references to one another. I saw, too, that the Configured .vdi file was labeled, there, as Inaccessible.

To resolve that, as in the previous subsection, I selected the Programs VM > Settings > Storage > right-click the Configured .vdi > Remove Attachment > OK. Then VirtualBox Manager > File > Virtual Media Manager > select the Configured .vdi > right-click > Remove > confirm Remove > Close. Then VirtualBox Manager > select the Programs VM > Settings > Storage > Storage Devices > right-click on Controller: SATA > Add Hard Disk > Choose existing disk > navigate to the Programs .vdi > select it > Open > OK. Now the Details pane showed the Programs .vdi, and there was no Inaccessible remark beside it. I clicked Start, and saw that the VM started correctly. In Control Panel > System, it said that Windows was still activated. I powered down the VM and looked at Windows Explorer. It confirmed that the Programs .vdi, not the Configured .vdi, was the one that had been most recently updated.

Would that slightly different approach have worked in the Renaming subsection (above)? I wasn’t sure. I would have to try it again sometime.

These steps still felt pretty complicated. Ideally, VirtualBox would give users an option of creating an identical copy, and of choosing whether the source VM or the copy would then be removed from VirtualBox Manager’s list of VMs, so as to prevent UUID conflict. Unfortunately, that option did not yet exist.

Configuring the VM

We were moving closer to the time when I would be able to install programs on the Programs VM, so that it could serve as the parent for the Working VM where I hoped to run programs that weren’t running in Windows 10. We weren’t quite there. First, I had to deal with a number of tweaks, to get the VM ready. I began by starting up the Programs VM and verifying that the copying process hadn’t changed its activation. Control Panel > System confirmed that the VM was still activated. Then I proceeded with other steps.

Windows Updates

As mentioned above, the Windows 7 KB971033 update would keep checking the VM’s activation status. I didn’t know if it would make the system more likely to demand reactivation, but I also didn’t see a downside to removing it. To see if I already had that update, I went into Control Panel > Windows Update > View update history. It said, “You have not tried to install any updates for your computer.” Just to be sure, I clicked on the link I saw there, “To remove an update, see Installed Updates.” That, too, said, “No updates are installed on this computer.” So if I did have KB971033 or other unwanted updates, apparently they were baked into the basic Windows 7 installation from the CD or DVD I had used, and could not be removed.

If reactivation came to be a hassle in the future, it seemed I might want to review the part of my earlier post where a manual edit seemed to eliminate the demand for reactivation, at least in the situation described there. The prospect that (knowing Microsoft) reactivation could well become a problem was one more incentive to keep alive the dormant project of becoming less reliant on Microsoft, though there did not seem to be major progress in resolving the problems of Linux as an alternative. My suggestion that the Linux world focus itself on the needs of Windows power users, rather than try to compete for ordinary users, did not seem to have been noticed. Still, in a pinch, I hoped the VM I was developing here would be portable into a Linux system, in which case I might have some OS independence after all.

Miscellaneous Tweaks

The steps listed in this subsection came to my attention along the way. These were in addition to the tweaks already performed when first creating the VM, as indicated in a previous post.

Note: the Host key was Right-Ctrl, by default. As a reminder, that fact was stated in the status bar, at the bottom right corner of the window containing a running VM. (The Host key was sometimes essential for clarifying whether you were sending a command to the VM or to the underlying host OS.)

• Control Panel > System > Computer name > Change settings > rename computer as Configured VM.
• Control Panel > Programs and Features > uninstall any software that I might have installed earlier in the process, back in 2016. The only unwanted things I saw there were Avira and Malwarebytes antivirus. As noted above, I had decided to run the VM without Internet connections and thus, to improve performance, without antivirus software. I hoped the Avira and Malwarebytes running on the host computer would catch any problems that might come along.
• Control Panel > Windows Firewall > Turn Windows Firewall on or off > turn on for both Home and Public settings. It was already set that way; now I decided to turn on its “Block all incoming connections” options for both Home and Public settings.
• VirtualBox top menu (with VM running) > Devices > Shared Clipboard > Bidirectional. This made it possible to copy and paste between the VM and the host system.
• I couldn’t figure out how to get the calendar from the system tray to persist onscreen, so until I found a solution to that little unknown, I opted for Ultimate Calendar Portable.
• I thought that, at one point, VirtualBox was giving me full-screen windows with appropriate resolution. If so, for some reason that died: now, in VirtualBox > Windows > Control Panel > Display > Screen Resolution, the maximum was 1280 x 960, whereas the host went up to 1920 x 1080. To fix that, as detailed in another post, with the VM running, I found the folder where VBoxManage.exe was located, and entered this command:

  vboxmanage controlvm "Name of VM" setvideomodehint 1920 989 32

  where “Name of VM” was the name shown in VirtualBox Manager; the ending 32 was the maximum color mode (i.e., 32-bit) allowed (where 24 might be a workable alternative if needed); and the resolution (i.e., 1920 x 989) was the result of trial and error, where going any larger would produce scrollbars and thus conceal part of the screen.

There were several tweaks and features I decided against, for now:

• VirtualBox top menu > View > Scaled Mode (or just toggle with Host-C; use Host-Home to unhide menu bar). To understand Scaled Mode, it was helpful to open a few small windows in VirtualBox in fullscreen mode. These windows would take only a fraction of the screen. Thus it would be possible to have several windows visible at once. Scaled Mode would preserve those relative sizes when shrinking the fullscreen window back to normal size. Without Scaled Mode, each of those windows might fill the normal-sized window; it would not be possible to see all of them at once. Keeping the VM in a normal rather than fullscreen window would make it easier to keep it in sight without blocking access to other programs on the host. On the downside, visual quality was reduced in Scaled Mode.
• VirtualBox top menu > View > Seamless Mode. The User Manual (4.6) seemed to say this would allow windows from within the VM to appear on the host desktop, as if they were running on the host. Presumably this would save one or two steps in gaining access to programs running in the VM. At this starting point, I felt this could be somewhat disorienting.
• VirtualBox top menu > Devices > Drag and Drop > Bidirectional. I usually used cut and paste rather than drag and drop, so for me this was optional.
• VirtualBox Manager > Settings > Display > Screen tab > Enable 3D Acceleration. I believe this was what the User Manual (4.5.1) was referring to, when it said this was experimental. The description did not inspire confidence. In addition, previous exploration suggested acceleration could be problematic for purposes of running Adobe Premiere Elements. I decided to postpone until it became essential.
• I did not get to the question of whether there were Windows 7 programs that I might still want or need, but that did not run well, or at all, in Windows 10. One example that came to mind: Unlocker. I had found it very useful for moving and deleting files that, for some reason, Windows did not want to relinquish. I had the most recent version, but it still didn’t seem to be working in Windows 10. I doubted it would overrule the Win10 host, running from a Win7 VM, but that would be something to explore. If that didn’t work, Windows Central (Huculak, 2017) said there were other approaches.
• I did not set up batch files — to start the VM at a certain time of day, for instance, or to automate specified processes in the VM. That would tend to be a development of a more settled system.

Access to Host Drives: Shared Folders

By default, the VM only saw files located on its own drive C and in its Guest Additions virtual CD, once that was mounted. I didn’t think I would want or need for it to have access to drive C on the host machine; if anything, I thought that might get confusing. But I did want it to have access to files on at least some data partitions (D, E, F, . . .) in the host machine.

The VirtualBox User Manual contained a section (Chapter 5) on Virtual Storage. It said a VirtualBox VM would most commonly use a large image file, such as the .vdi files I had been working with. It also said that I could attach an iSCSI storage server or allow the VM to access a host HDD directly. It described that last option as “an advanced feature.” The section (9.9.1) describing that approach said it was “for expert users only” and that improper use “can lead to total loss of data.” That sounded unpleasant.

These options didn’t seem to describe what I dimly recalled using previously in VirtualBox. I backed up to the User Manual’s main page and, with the help of a search, tried again, this time winding up in the Shared Folders section (4.3). That was what I was looking for. It said the Shared Folders feature would work as long as I had the Guest Additions installed. I would have to define my Shared Folders for each VM separately, though I assumed shares already set up would be passed along if I cloned or copied the VM. (Although they called it shared “folders,” it would also work for entire partitions or drives.)

To define Shared Folders, the User Manual said that, in the VM, I could use Windows Explorer > My Networking Places > Entire Network > VirtualBox Shared Folders. That didn’t work. In my case, there was nothing under Network in Windows Explorer. I wasn’t sure whether that was because I had just shut down all network connections in Windows Firewall. Regardless, I was able to use VirtualBox Manager > Settings > Shared Folders > right-click or use the folder-plus icon > click the down arrow > Other > navigate to the partition that I wanted to access on the host machine > Select Folder > give it a name containing no spaces > OK > repeat as desired > OK. It appeared that the Auto-mount option would be useful after using the Map Network Drive option in the Windows VM to assign desired drive letters to the Shared Folders. Evidently encrypted partitions would be visible in the VM as soon as they were decrypted (using e.g., the VeraCrypt password) in the host.

Customized Start Menu: Using Programs without Installation

(This subsection describes a procedure that, once developed, would allow me to add many portable programs, from the host’s customized Start Menu, to any Windows VM’s start menu. In my case, the customized Start Menu contained more than 10GB of portables. While I did work through this procedure once, I decided that I would not ultimately use this approach on the relatively minimal VM that I wanted to use to run a few specific programs. I decided instead to bring over selected portables from the host on an as-needed basis. That way, I could keep backups and copies of this VM to a relatively small size.)

In 2010, I began using a customized Start Menu. These days, my typical Windows 7 installation used Classic Shell to provide a Start Menu more like that found in older versions of Windows, along with a registry tweak to tell Windows to look at drive X rather than the default folder on drive C for its Start Menu contents.

Drive X, containing the customized Start Menu, was not encrypted, so it would be available as soon as the system started. It was not on drive C, so it would not be wiped out every time I reinstalled Windows. So I could arrange its contents as I pleased, and the arrangement would remain. This resulted in an organized and hierarchical menu in which, over time, I tended to know where things could be found. When I did reinstall Windows, I almost always used the default program folder locations. That way, as soon as a program was installed, its icon in the customized Start Menu would change from a blank rectangle to the colored icon normally associated with that program: that is, I wouldn’t have to sort the icons again, and I could tell immediately if I had neglected to reinstall a desired program; old favorites would not be forgotten.

Those aspects of the host’s Start Menu would not be of interest in the VM because, as I was about to see, programs installed on the host would not run on the guest. That is, in the VM, I could navigate to drive X on the host; I could see the icons, there, for the programs installed on the host; but clicking on those icons would not cause those programs to run in the guest. They would have to be installed on the guest before the guest could run them.

But the situation was different for portable programs. Years earlier, when I had created the customized Start Menu, I had discovered that I could put an entire folder, containing all program files for a portable program, into the appropriate place in the customized Start Menu on the host’s drive X. So, for instance, the folder containing Ultimate Calendar Portable (above) could reside in the Start Menu on drive X, at the same location as any other calendaring programs I might use. Similarly, the Start Menu could also contain links to cloud-based programs (including storage options). The portable programs, and the links to tools online, would be functional even if I copied the Start Menu to another computer, though of course the online links would not work without an Internet connection.

That portable functionality interested me now. I wanted to know if the VM could run a portable program stored in the Start Menu on drive X of the host machine. I proposed to achieve that by making drive X a shared folder, navigating to that portable program’s executable file in the VM, and double-clicking on it. I could have just tried it, but I was afraid of breaking something, so I ran some searches, to see what people said. But the searches I tried weren’t leading anywhere, so I just said to hell with it and tried it. That was successful with almost all programs tried:

• Notepad was not a portable, but I saw that its icon was working in the host’s X drive, viewed through the VM, so I tried it. It ran. It seemed to get confused, though, when I tried to save my work. It paused and then said, “Notepad has stopped working.”
• Audacity Portable ran, recorded audio (though it was just empty space, as I didn’t believe the VM had a microphone connected), and saved it as a playable MP3 (after I pointed Audacity to a copy of lame_enc.dll) on the host’s D drive.
• IrfanView Portable ran, played a .wav on the host’s D drive, captured (via Ctrl-V) a screenshot of the VM’s screen, and saved it as a PNG on the host’s D drive. The audio quality was poor, probably due to driver issues.
• Cool Edit 2000 (virtualized). This was an old audio editor. I had virtualized it using Cameyo. That is, Cool Edit wasn’t a portable program, but the virtualized copy ran as a portable. It didn’t run perfectly — I probably needed to do more tweaking to refine the virtualization — but I knew it would run in the Windows 10 host. It ran in the VM too, from its location on host drive E: it opened and played a .wav file, though again not well.
• Microsoft Office 2003 (virtualized). It opened, calculated, and saved with apparently the same functionality as in the Windows 10 host.
• LibreOffice. I tried the Calc program, an Excel alternative. It worked.
• Everything. The portable version of the Everything file finder did seem to work properly, when run, in the VM, from its location on the host machine. But it was able to search only drive C in the VM, and I was concerned that its use in the VM would confuse its index on the host, though it did not actually seem to be doing so. I copied the portable Everything folder from the host’s customized Start Menu to a new Portables folder on drive C in the VM. There, in Everything > Tools > Options, I pruned the list of NTFS drives; and in Indexes > Folders, I added the Shared Folders, so that Everything on the VM could return results from data partitions on the host. Unfortunately, Everything was confused on the drive letters, for these shared folders, and on at least one occasion it also removed them from its Folders list on reboot.

As discussed in those links, some programs virtualized better than others. I had only virtualized Windows programs; I didn’t know if it was possible to virtualize Linux or Mac programs for use in a Windows VM. As illustrated here, virtualization could make old programs run on new computers and new versions of Windows.

So that was pretty cool. It seemed that, if I set up a portable program (or created a portable by virtualizing an installation) on my host’s Start Menu, I was in effect setting it up for the guest as well. By contrast, I did see, at this point, that the VM wasn’t going to be able to play programs that were installed on the host but not on the VM: their icons were blanks. I tried one and got an error, “The specified path does not exist.”

I didn’t want to rewire the VM’s registry to seek its Start Menu on drive X of the host machine. I could have — as I say, drive X was always available — but doing so would have forced me to move the Start Menu icons created in the VM’s drive C to the host’s drive X, if I wanted to use them, and then they would have cluttered up the host’s Start Menu.

Instead, one approach would be to go into the host’s drive X, create shortcuts to commonly used portables, and move those shortcuts to the VM’s Start Menu, saving copies on host drive X for copying to future VMs. Another approach would be to put a shortcut to the host’s drive X into the VM’s Start Menu, so that I could use Start > X Menu > find the desired portable. A third option was to copy over the portables from the host’s Start Menu to the guest’s Start Menu. That was the option I chose.

To prune those portions of the Start Menu that contained no potentially useful cloud links or portable programs, I put a copy of the host’s Start Menu into an empty partition on the host, went into the guest, and proceeded to delete (from that copy) all links that were not recognized on the guest. To do that, I searched for a program that would delete dead links. That search led to a SuperUser discussion in which participants recommended CCleaner, Fix Shortcuts, and Broken Shortcut Fixer. I also saw a reference to Shortcuts Search and Replace. The older ChkLnks.exe appeared to have dropped out of use, though possibly it could still be obtained and used through Windows Server 2003 Resource Kit. I had used NirSoft’s ShortcutsMan successfully in Windows 7, and I liked NirSoft’s stuff, so I started with that. Unfortunately, its GUI (as distinct from its command-line options) appeared able to detect shortcuts only on the default Start Menu. A glance at CCleaner suggested that it, too, would search only the standard Start Menu plus the desktop. (It later occurred to me that I could have moved the copy of the host’s Start Menu into a folder in the guest’s Start Menu at this point, rather than later, thereby making its contents available for scrutiny by NirSoft and CCleaner.)

As other alternatives, Puran’s Fix Shortcuts was shareware with a higher rating but fewer raters on Softpedia, so I tried Broken Shortcut Fixer (3.6 stars, 20 raters on Softpedia). Broken Shortcut Fixer was not a portable, but it did have the advantage of allowing me to focus on a specific drive (though not on a specific folder). So I installed and ran it in the guest VM, pointed it toward the host partition where I had placed the copy of the Start Menu, and clicked Scan Shortcuts. It soon returned a dialog: “8 broken shortcuts found and resolved, 313 other broken shortcuts could not be repaired.” I clicked OK; took a look at the list, to verify that I wanted to delete the listed files; and then clicked Delete Broken Shortcuts. I put a copy of Everything (portable) into the VM, configured to show .lnk files and to search the host folder where I had stored the copy of the Start Menu, and used it to search for certain filetypes. (I had to use Everything > Tools > Options > Indexes > Force Rebuild to make Everything see this copy of the Start Menu.) I decided I could delete .pdf files on this copy of the Start Menu, since they already existed in the host’s Start Menu. I also searched for uninstall*.lnk and deleted those uninstall links.

Then, back in the host, I scanned the copy of the Start Menu with Remove Empty Directories (one of several programs designed for the purpose), and deleted the empty folders it found. I started to use TreeSize Free > right-click > Open to view the contents of folders that I felt should not still be on the VM’s Start Menu, but after the first few folders I realized that manual pruning of this Start Menu copy could be time-consuming. Besides, it mostly looked OK. I would prune it further as needed. I made a zipped backup of the pruned Start Menu copy, and then moved the pruned copy itself into the VM. Right-clicking on the VM’s Start button reminded me that Windows 7 Start Menu entries were stored in two different folders. I moved this pruned copy of the host’s Start Menu to the folder that opened up when I went to VM > Start button > right-click > Open All Users. From there, I did a little more folder moving and consolidating. And that gave me a greatly expanded set of program options in the VM, without having to install and reinstall them on various VMs. Finally, I put the zipped backup into a folder on the host where I was storing copies of software used in the VM.

Audio Playback Quality

In tests of IrfanView Portable (above) and Adobe Premiere Elements (below), I noticed that the VM’s audio quality was poor. A search suggested that many people had encountered this. Participants in one discussion said that (at least in its latest form) this was a new problem, emerging in VirtualBox 5.2. It appeared that it might be related to changes in Windows 10.

I powered down the VM and tried VirtualBox Manager > Settings > Audio > Audio Controller > ICH AC97 (instead of the default Intel HD Audio), keeping the default Host Audio Driver = Windows DirectSound. On restart, that produced an error (“Device driver software was not successfully installed”) and Windows Media Player was not able to play audio files. I powered down and tried again with the SoundBlaster 16 audio controller. That didn’t work either. So it seemed I was limited to the Intel HD Audio option. Following suggestions by ATKDinosaurus, I went into Settings > System > Processor tab > Processor: 1 CPU. Also System > Acceleration tab > Paravirtualization Interface: Minimal. The suggestions may have been old: there was no longer a PulseAudio option for Host Audio Driver. Those suggestions did not help.

At this writing, some reports suggested that VirtualBox programmers had been working on the problem for at least two months. It appeared that reverting to an older version of VirtualBox might solve the problem, as might a switch to running the VM on Linux. I found it mildly disturbing that a final release of software would have overlooked such a readily noticeable and apparently widespread problem. But that may have just been my perspective. No doubt many other VirtualBox users were having no problems.

As I viewed the Changelog, I surmised that attempting to go back to VirtualBox 5.1 or earlier would entail other complications. The alternatives would apparently be either to wait for VirtualBox to fix the problem, reinstall Windows 10 and hope it fixed the problem, or switch to VMware.

Adding Programs

At last, the moment had arrived. I had a Windows 7 VM that was ready to let me install and use programs that were not presently running on Windows 10. I made a copy of the Configured VM, using the steps described above, and named the copy Programs Installed. Now it was time to identify the programs that I wanted to install, and install them.

(Later, it would develop that most of the changes described in this section were lost. The reason: I failed to go into VirtualBox Manager > Settings > General > Advanced tab > Snapshot Folder > change to the folder for the Programs VM. Instead, my snapshots were continuing to be saved in the folder for the previous VM, from which I had copied the Programs VM. I zipped up that previous VM and then, later, seeing only a Snapshots subfolder in that older VM’s folder, assumed it was just leftover junk, and deleted it. Its latest state, with the desired snapshots, was overwritten in backup and not found in the Recycle Bin. But let us continue the story.)

It was possible that, at some point, I would want to use this Windows 7 VM as my last Windows outpost on a Linux system. In a previous post, I examined a short list of 95 programs that I absolutely could not live without . . . or, well, that at least I would really prefer to have, if possible — drawn from an original list of maybe 1,000 programs that were installed on my Windows computer. That examination, informed by practical experience with some Linux alternatives, yielded the conclusion that, while there were good Linux replacements for many Windows programs, and while some inimitable Windows programs would run on Linux via Wine, I would still probably want to install quite a few programs in a Windows VM running on Linux.

But that was not the present situation. In the present situation, I was planning to run the VM on Windows 10, where most of my Windows programs would hopefully continue to run without problems. I was developing the VM primarily to handle a few programs that (for unknown reasons evidently related to Windows updates, as indicated at the start of this post) were no longer working in Windows 10. Of course, unless there was some problem with activation or licensing, the VM could also be useful for allowing me to run completely distinct sessions of Windows programs, one in the Win7 VM and one in the host Win10, if the need arose. In addition, the VM would refamiliarize me with the experience of working in a VM, as a transitional step toward a possible return to doing most of my work on a Linux host. The VM might also help me resurrect some useful Windows 7 tools that were simply incapable of running in Windows 10.

That said, there were reasons not to overdo the number of programs installed in the Windows 7 VM:

• My attempts to build working VMs by converting Acronis True Image drive C backups had not fared well. Perhaps most of the problems stemmed from the conversion process. But it did seem that a huge and bulky Windows installation could bog down a VM even under the best conditions.
• I had shortsightedly created this particular VM with a maximum size of 25GB. It was presently at 11GB. I might be able to install the essential programs on it without hitting that 25GB ceiling. If necessary, I could use CloneVDI or other methods to resize it, probably triggering a reactivation. I hoped to postpone that until some other development required a reactivation, so as to avoid the risk that Microsoft would say I had reactivated too many times.
• My previous tinkering had found that different programs could require different VM settings. In particular, Adobe Premiere Elements 12 had required me to disable video acceleration, but that could be undesirable for purposes of running other programs optimally. In a Linux host, especially, where I might want to run many Windows programs, it might develop that the best approach would be to run different VMs (using other Windows XP, 7, or 10 licenses as needed), with divergent settings as needed, as essentially distinct desktops. For example, my video editing would probably not have much to do with my word processing; I might choose to suspend one VM to work in another. As another example, I might design one VM to go online, complete with the latest Windows 7 updates and antivirus software, where I would not want that performance penalty and risk in other VMs.
• In some eventual Linux host, it would be to my advantage to learn how to use worthy Linux alternatives to Windows programs. Doing so would reduce my dependence on Microsoft and Adobe, in particular, and might thus eventually save money. If a Linux program running natively on a Linux host could do the same things as a Windows program, and if I could learn it without too much time investment, it would probably not make sense to remain tied to its Windows alternative in a VM.
• In some cases, as explored in a separate post and in the remarks about the customized Start Menu (above), it might not be necessary to use a program installed in either Linux or Windows, because a virtualized, portable, or cloud solution might suffice.

Thus, I approached this VM as a focused rather than general solution, existing (for now) only to run essential programs that were not running in Windows 10. At present, those programs, and notes regarding their installation in this VM, were as follows:

Microsoft Office 2016

Since Office 2016 was no longer working on the Windows 10 host, I went into that host’s Control Panel > Programs and Features > Microsoft Office 2016. I had repeatedly tried the Change > repair options available there, but it had been a week or two since my last try, at this point, so I tried the more thorough Online Repair option again. As anticipated, the result was a failure; Office was unable to run. Therefore, in Programs and Features, I uninstalled Office 2016.

Now, it seemed, I should be able to install and activate Office 2016 in the VM. I had already set up the host computer’s drives as shared folders in VirtualBox (above). Now, using Windows Explorer in the VM, I was able to access the Office 2016 setup folder that I had saved on the host when I bought Office 2016. In that folder, working in the VM, I ran Setup.exe. It installed Office.

Now, the question was whether I could activate Office 2016 by phone, or in some other offline manner. Going online for any purpose, in a VM with no antivirus installed, was a risky proposition. Going online to a Microsoft update source — when I had created the VM as a purely offsite project partly to avoid the risk that Microsoft might supply updates that would corrupt Windows 7 — would simply make no sense.

So I ran Excel 2016. It said, “We are unable to connect right now. Please check your network and try again later. [Or] Enter a product key instead.” I clicked on that product key link. The dialog offered, “See product key examples.” That opened Internet Explorer (IE) and, since it was the first time, that in turn opened the Set Up Windows Internet Explorer 8 dialog. I clicked “Ask me later.” IE then said, “Internet Explorer cannot display the webpage.” So evidently the product key examples were on a webpage. I copied the link out to the host VM and tried there. It showed an example of the usual five-sets-of-five-characters product key: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX. Back in the VM, I closed IE. The dialog was still waiting for my product key, or for me to click the alternative link, “Sign in with an active account instead.” I pasted my product key into the dialog. It showed a green check mark. I clicked Continue. It didn’t say, “Good, great, happy computing!” It just took me back to the “We are unable to connect right now” dialog. I tried again. Same thing. I closed the dialog. Apparently it should have closed itself: now I had a dialog that said,

First things first.

This product also comes with Office Automatic Updates.
Learn more.

By clicking “Accept” you agree to the Microsoft Office License Agreement.
View agreement.

I clicked the “Learn more” link and got this:

Updates to this Office product are enabled by default and are downloaded through your Internet connection and installed automatically. To check your update status and turn on or off updates, select the File tab, and then click Account. Under Office Updates, you can view your current update status and turn automatic updates on or off.

Then I clicked the “View Agreement” link. That gave me the text of the agreement, without a link. I closed that and clicked Accept. Excel ran. Across the top, it had a yellow banner saying, “PRODUCT NOTICE Excel hasn’t been activated. To keep using Excel without interruption, activate before Tuesday, February 27, 2018.” It was now February 22, so I had about 4.5 days. I clicked the Activate button. It gave me that same “We are unable to connect right now” dialog. I tried once more to enter the product key instead. Nothing changed.

A search led to a Microsoft Office Support webpage offering multiple options, none of which exactly fit the present situation. The one that seemed most relevant was, “If you see the Activation wizard.” I clicked its “Get help with activating Office after you install it” link. That led to a webpage with an “Activate by telephone” section. Unfortunately, it assumed I was seeing that kind of option onscreen, and I wasn’t. There was a link to Microsoft Support, but I wasn’t quite ready to go there, as I had found it could be very time-consuming and of poor quality. In Excel, I tried File > Account > Activate Product, but that just opened the same “We are unable to connect” dialog. Another Office Support webpage offered a response to “‘Telephone activation is no longer supported for your product’ error when activating Office.” That page offered a drop-down selection for various countries. For the U.S., the number was 866-421-7141. I dialed that and indicated that I was calling to activate Office. It asked for the installation ID, which it described as “a long number broken into several groups.” I was familiar with this. It was not the same as the product key. I didn’t have a screen displaying an installation ID, and I didn’t know how to find one. A Microsoft Answers page on this issue pointed me back to the “Activate by telephone” section I had just tried. (And yes, in case you were wondering, as with Windows, there did appear to be pirated product keys floating around out there.)

Another Microsoft Answers page presented replies from several users. One said that Office 2016 versions “require net access to verify the license, not only on initial install but every 30 days or so.” Another said the solution was to right-click on the Excel (or other Office) icon and choose “Run as administrator.” That option didn’t appear on the icons that the Office installation had added to the taskbar, but it did appear in the new Start Menu icons. Unfortunately, that approach just opened the same “We are unable to connect” dialog. Another contributor to that webpage said, in effect, that I should go to “my account in microsoft webpage.” I didn’t know what that meant. I tried my Outlook Live account, but didn’t see anything obviously relevant. The advice, assuming I found that webpage, was to select the “I want to burn a disc” option. A search led to a Techspeeder page that seemed to say I was supposed to sign in at Office Setup. I did that on the host computer and clicked Next. Techspeeder told me to enter my product key. I did that. Then, Techspeeder said, instead of clicking on Install, I should choose Install from a disc > I want to burn a disc > View your product key (and, if needed, Download the installation file). The page said, “Once you have created your disc, you’ll need the product key shown on this page to complete installing offline.” I saved that product key and tried using it to activate Excel in the VM. This time, instead of Continue, it said Install. Now, at last, I got the Activation Wizard dialog:

I chose, “I want to activate the software by telephone.” That gave me the long Installation ID; but instead of giving me a phone number, it said, “Telephone Activation is no longer supported for your product.” That turned out to be incorrect. I tried the number I had found earlier (866-421-7141). I entered various information as instructed there; it gave me a confirmation ID; and the product was registered, as I confirmed in Excel > File > Account, where it said, “Product Activated.” I also verified that PowerPoint and Word were working, and that Windows itself was shown as still being activated in Control Panel > System.

I would have to revisit this installation, a month or two down the line, to see whether it was true that Microsoft would expect it to be periodically rechecked online. But for now, I had a working, activated installation of Office 2016 in the VM, without going online. For Office 2016, and for other programs discussed below, there would still be a matter of configuring various settings, but I was going to revisit that after looking at CloneApp (below).

Adobe Premiere Elements 12

As with Microsoft Office 2016, in the VM I browsed to the host drive partition where I had saved the Adobe Premiere Elements (APE) installer, and I ran it. At one point, it paused to say, “Adobe Premiere Elements 12 may attempt to contact the Adobe servers over the Internet in order to complete the license activation process and validate the right to use this software on this machine.” I ran a search, to see whether there was anything I should do at this point for an offline activation alternative. There didn’t seem to be.

When installation was finished, a dialog said that APE would require QuickTime for some purposes, and would also require activation for some components. Wikipedia said, “[T]he latest Mac version, QuickTime X, is currently available on Mac OS X Snow Leopard and newer. Apple ceased support for the Windows version of QuickTime in 2016.” An Apple webpage said, “QuickTime 7 for Windows is no longer supported by Apple. New versions of Windows since 2009 have included support for the key media formats, such as H.264 and AAC, that QuickTime 7 enabled.” That webpage offered QuickTime 7.7.9 as, apparently, the last version. I decided to wait and see if the VM’s version of Windows 7 did contain the necessary support.

The installer required a reboot. After the VM rebooted, I tried running APE. I got an “Entry Point Not Found” error message:

Adobe Premiere Elements 12: Adobe Premiere Elements 12.exe – Entry Point Not Found

The procedure entry point ucrtbase.terminate could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll.

(To clarify, the ambiguous character in that file’s name was runtime-L1.) I clicked OK. The error message came up again. I clicked OK again. APE started. It gave me a choice between Organizer or Video Editor. I chose Video Editor. But then I killed APE and focused on the error.

A search suggested that this error was not uncommon. Appuals said this error was probably due to a “corrupt or outdated Visual C++ Redist,” outdated Windows updates, or a failure of Windows Update KB2999226. Aside from a check of Windows Updates, Appuals recommended running Reimage Plus (which, from its link, attempted to download as ReimageRepair.exe) “to scan and restore corrupt and missing files.” Malwarebytes described Reimage Repair as a “so-called ‘system optimizer'” that would sometimes generate pseudo-problems to promote software sales. A participant in an Avira discussion advised uninstalling Reimage Repair. This was also the gist of a Norton discussion.

Raising some of the same issues, an Adobe page linked to Microsoft Download Center, with an indication that I could resolve the error by downloading and installing Microsoft Visual C++ x64 Runtime. At the Download Center, it appeared this software was now known as Visual C++ Redistributable for Visual Studio 2015. The download link offered 32-bit (vc_redist.x86.exe) and 64-bit (vc_redist.x64.exe) versions. I chose both. (They were only 13-14MB each.) My Windows 10 host system already contained files with those names (i.e., vc_redist.x86 and .x64), in subfolders under C:\ProgramData\Package Cache, but those files (~500-800KB each) were much smaller than the downloads. Probably what was installed was only a small part of the installer.

I attempted to use the Everything file finder, in the VM (via shortcut to its portable installation in the host’s customized Start Menu (see above)), to see whether the VM’s drive C contained any vc_redist files already. Running Everything triggered several more instances of the same error message (i.e., “Entry point not found”). Evidently multiple programs depended upon resolution of this problem. I was tempted to just insert a copy of api-ms-win-crt-runtime-l1-1-0.dll somewhere, but I saw that it came in at least three sizes, on my Win10 host, with multiple last-modified dates. So that wasn’t the most promising solution. When I did click through all those additional error messages, Everything reported no instances of any vc_redist files in the VM. So it did appear that running something to add some would be helpful.

Presumably I had avoided the error message, in previous installations of APE, either by being online or by installing other software that contained the needed file(s). At any rate, I went ahead and stuck a copy of vc_redist.x64.exe onto the VM’s desktop and ran it. It said I was installing Microsoft Visual C++ Redistributable (x64) – 14.0.23026. And then it said Setup Failed, with error 0x80240017, “Unspecified error.” (Why did I always get “Unspecified error” or “Never heard of this problem before”?) The error message provided a link to the log file. The log file was not long. It seemed to say the error was actually not “unspecified”; it was “Failed to execute MSU package.” I tried running the installer again. It gave me choices: Repair, Uninstall, or Close. It seemed to be confused as to what exactly had happened. I tried Repair. Same outcome. But, hey, maybe the system was OK with that.

I tried running APE again. It ran. I also tried running Everything. It ran. No more of those error messages. Maybe setup did fail, in that Visual C++ Redistributable, but it seemed to have given the VM what it needed. Everything reported that the VM did now have VC_redist.x64.exe, 519KB, in a folder under C:\ProgramData\Package Cache.

APE’s startup was a little confusing at this point. It gave me the opening screen, with the choice of Organizer or Video Editor. I chose Video Editor. It just seemed to hang there. Eventually I noticed that a Sign In Required dialog had come up behind it. That dialog said,

Signing in with an Adobe ID and registering Adobe Premiere Elements is required within 7 days otherwise it will stop working.

Enter Adobe ID to register your product.

I clicked the Sign In Now button. A new dialog: “Please connect to the Internet and retry.” It went on to say, “An internet connection is required.” But it also said, “If this computer cannot access the Internet, get more details at at http://www.adobe.com/go/getactivated using an Internet enabled device.” I tried that, using the Windows 10 host machine. That led to a webpage that gave me another link to generate a Response Code. That link required me to log into my Adobe account. Then I was looking at an Office Activation page, asking for “your product’s Request Code and Serial Number.” I had a serial number, but no idea what the Request Code was. Results of a search suggested that multiple people had run into the same problem. One Adobe discussion advised me to contact Adobe Customer Care. The automated solutions there were all focused on Creative Cloud, which was much newer than my old APE 12. Fortunately, their link to more contact options did put me through to phone and chat options.

Chat was pretty slow. It only took a few minutes of waiting to get a representative. Unfortunately, after 20 minutes of waiting for him, apparently, to handle a dozen other users, we still had not gotten to the point where he even understood my question. He did send me an unneeded but possibly someday useful link to a page where I could download another copy of a Premiere Elements 9-13 installer. At the 20-minute mark, he sent me a link to the “Get Activated” webpage. So then I knew he was starting to get warmed up. By the 30-minute point, he had repeated the same advice several times, and was showing signs, I believed, of beginning to grasp my question. But then, no, he said I would have to call 800-833-6687 for “other information.” After pleading and being denied for a chance to get him to look at what would happen if he clicked on the link in question, I asked to speak to a supervisor. That took another 20 minutes, believe it or not. But then, at long last, I did finally get to speak with someone who could understand the question.

And that’s all it took. I got busy with other things, during that hour online, keeping one eye on the chat and taking care of other tasks; but when that supervisor asked a few basic questions, I went back to the VM to try some other possibilities. It seems that I should not have clicked the “Sign In Now” button — or, if you prefer, Adobe should have provided offline activation information to those who did, and who then got the false message (above) that “An internet connection is required.” Instead, I should have clicked the “Having trouble connecting to the internet?” link. I assumed that would lead to guidance on connection issues. But it didn’t. It automatically generated the Request Code. I pasted that into the webpage, along with my serial number, and got a Response Code. I pasted that into the Response Code box, in APE, and clicked Activate. It said, “Adobe Premiere Elements 12 has successfully been activated and is ready to use.”

I clicked Launch, and APE started up — and gave me the “Entry Point Not Found” error again. I clicked through two or three of those and got another notice: “We have detected generic Microsoft’s display driver on this machine. To get a better and faster playback performance, please update your display driver.” A search led primarily to my own previous post, raising the thought that the error might not occur (but then, APE might not run at all) if I enabled 2D and 3D acceleration. To test that, I powered down the VM and went into VirtualBox Manager > select the VM > Settings > Display > Screen tab > check the boxes to enable 2D and 3D acceleration. Doing so opened the option of allocating a maximum of 256MB of video memory, rather than the 128MB maximum VirtualBox had offered previously. Speccy said my host system had 4GB of graphics RAM, so I felt I could spare it. I restarted the VM and tried APE again. The Entry Point error was still there, but the driver warning did not recur. APE was able to import and play video. I noticed that its audio quality was poor, as with IrfanView (above). This prompted the effort (above) to tweak the VM’s audio and the decision (below) to try VMware.

I wondered whether perhaps the Entry Point error would have been fixed if I had installed, not only the vc_redist.x64.exe download, but also its vc_redist.x86.exe companion. I tried that. It, too, concluded with an indication that it had failed, and with the same error. I restarted APE and saw that, no, vc_redist.x86 wasn’t the solution; the Entry Point error was still there.

Cool Edit 2000

I had developed a virtualized copy of Cool Edit 2000. I ran that now, in the VM, just to confirm that it, too, had audio problems — more specifically, the same problem that it had in Windows 10: rather than crackling audio, it played no audio at all. I was inclined to postpone a full installation, test, and configuration, awaiting a VirtualBox update that would resolve those problems. But it was possible that, ultimately, Cool Edit needed a Windows 10 fix, or perhaps that something on my Win10 installation had gone wrong, and only a reinstallation of Windows 10 would solve the problem.

Wrap-Up

There were things to like about VirtualBox. But I didn’t like its complexity for what should have been simple file operations (e.g., moving, copying, or renaming VMs), and I definitely didn’t like that it wasn’t running key programs that I needed it to run, if it was going to serve as a substitute for running those programs natively on the Windows 10 host. Therefore, as described in another post, I turned to an exploration of VMware’s Workstation Player.