Mark Minasi's  Tech Page
Issue #114 May 2016

Document copyright 2016 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text. (Thank you for respecting my intellectual property rights!)

What's Inside

  • News
    • The Newsletter Is Back
    • Learn with My Seminars, Audio Recordings and More!
  • Tech Section
    • Shiny New Boots: What You Need to Know About UEFI and Secure Boot
  • Conferences
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

Welcome back!  You are probably wondering where The Newsletter's been for the past two years.  Well, the little rascal hopped a plane back in May 2014 and spent two years in the rain forests of western Washington state searching for Windows 9.  It was unsuccessful so I'm not sure why it was gone so long, but it came back with a lot of tie-dyed t-shirts, so I suspect it was experimenting with the state's newly-legal crop.  Anyway, it's back, and this month I'm going to do the first of a couple of "catch-up" articles, this time about "UEFI firmware," which is interesting partially because most of the PCs you've purchased since around 2011 do not have BIOSes, they as UEFI firmware has replaced those BIOSes, and partially because UEFI enables a Windows 10 feature called "Secure Boot" which is Microsoft's latest works-without-you-thinking-about-it anti-malware armor.

As you will see, understanding and working with UEFI and Secure Boot isn't too bad, but they do bring new concepts, new ways of getting things done, and the occasional pitfall if you're not wary  . I've found following it interesting and I hope that you will also but first, a word from our sponsor...

Shiny New Boots:  What You Need to Know About UEFI and Secure Boot, Part One

Ever since malware appeared ages ago, many anti-malware tools have worked by using some mechanism to detect any changes to files or data areas important to the operating system, assuming that "changed" meant "infected."  One of the most reasonable approaches was to digitally sign all of the programs, DLLs, manifests and the like in the operating system.  Malware modifying some OS file would thus "break" the signature on that file, and Windows would then take some action to un-do the problem.  Signed operating system files aren't new -- the first version of Windows employing widespread code signing was XP Service Pack 2, released in the spring of 2004.  Signed code is, however, only as good as what is called the "chain of trust" in those signatures.  Secure Boot is nothing more than a better, more bulletproof system of code signing that covers not only the operating system code on the hard disk, but also what most of us would call the "BIOS."  That sounds good, but Secure Boot systems can only be installed on systems with a far-improved replacement of BIOSes called "UEFI firmware," so we'll start from there in this article.

Before UEFI:  BIOSes, and Why They Have Overstayed Their Welcome

Way back in 1981, you could buy an IBM PC with a floppy drive, a keyboard, and a monitor.  You loaded the DOS operating operating system from a few files on a floppy disk formatted with the /S option.  That was useless, however, if the computer didn't know to go look for and load those few on-floppy files.  Computer manufacturers like IBM solved the problem by installing a small amount of nonvolatile memory (that is, memory that retains its contents even when the computer it's in is turned off) preloaded with just enough code to go look on that floppy disk.  At the time, the industry called that nonvolatile memory Read Only Memory or ROM, and nowadays it does more than its 1981 cousins and is called NVRAM, (among other things -- you might know the related phrase "flash memory") which is short for NonVolatile RAM.  On the original PC, IBM called the software stored in the PC's ROM the Basic Input-Output System or BIOS.  The software in the BIOS was so simple and, well, basic that IBM included a printout of it as an appendix of its IBM PC Technical Manual -- just a bunch of short assembly language chunks.  Despite the fact that as time went on and computers got more complicated, BIOSes didn't really change all that much.  Eventually, BIOSes got a bit smarter in that they understand not just floppies but hard disks, but even then they don't understand the C:, D:, F: or whatever volumes you put on those disks.  BIOSes understand network cards a tiny bit, but really only enough to do a "PXE boot," a fairly simple operation -- they're not going to connect to your file server, grab something from your SharePoint site, or download the Picture of the Day from some web server.  Worst of all, though, is the way data is laid out on hard disks that BIOSes support.  Those disks lay out their data in a familiar (to us techies) format called Master Boot Record or MBR disks.  What's wrong with MBR disks, you ask?  Well, the startup code for your boot disk -- the code that runs right after the BIOS code gets things going -- is more assembly language, and there's only room for around 430 bytes.  (Yes, bytes.  As in "almost no space at all.")  But wait, there's more, or, actually less:  partitions on MBR drives can't exceed two terabytes, which probably seemed like a pretty reasonable limit in the 80's, but doesn't really feel that way now.  In short, the whole BIOS structure just cries out for an upgrade, or to be more truthful, a complete rewrite.

Terminology Sidebar:  "Firmware" Versus "BIOS," and Why You Don't Have a "UEFI BIOS"

I'm about to start using the phrase "firmware."  It is often confused by many with a phrase I've already used, "BIOS," which is why I'm taking the time here to explain the two and how they're different.  In short, "firmware" is a type of software, and "BIOS" is just one very widespread example of that kind of software.  If firmware were trucks, BIOS would be the Ford F-150. 

Firmware is the generic term for software stored on on-board chips (NVRAM or ROMs, remember) shipped with computers and other devices, as opposed to software installed from CDs, DVDs, downloads and the like.  But firmware isn't just in computers.  Think of all of the devices that you've got to "update" now and then.  In my case, I've got Roku streaming boxes that update themselves periodically, a couple of TVs and Blu-Ray players that need to download updates now and then.  I've also got a smartphone, my iPad, my digital SLR, the tripod that knows how to point my telescope at a given star -- every one of them "updates" at some point.  There's even a computer and some software on my diesel Volkswagen Beetle that lies about its emissions (yup, I bought one of those... thanks, Volks!) and it's going to have to get updated sometime soon.  What got "updated" on all of those devices is software stored on a NVRAM chip on the device, and all of those bits of software are properly called "firmware" because they reside on NVRAM.

In this article, I'm talking in particular about firmware in PCs.  As you've already read, the firmware shipped in microcomputers between 1981 and 2011-ish was called "BIOS."  After 2011-ish, computer firmware was almost certainly not called "BIOS," it was called "Unified Extensible Firmware Interface" or UEFI.  (Some people pronounce UEFI by speaking the four letters separately.  Others pronounce it like "yoo-fee," rhyming with "goofy.")  Almost no one says "my new PC has UEFI firmware" or "my new PC is UEFI," they tend to say, "my new PC has a UEFI BIOS," which is way wrong.  It's entirely understandable, as we techies are used to saying that a system has a such-and-such BIOS, that our BIOS needs flashing, that we've got to press F1/F2/Del/Return at boot time to get to our "BIOS settings," and so the phrase "UEFI BIOS" sounds right, even though it isn't.  It's sort of like those towns in the southern US that call all carbonated beverages "Cokes," as in this conversation I once overheard in a suburb of Atlanta:

Restaurant server:  "What would you like to drink?"

Customer:  "I'll just have a Coke."

Server: "What kind?"

Customer:  "A Diet Pepsi, please."

Server:  "Coming right up."

And no one at that table appeared to think that there was anything strange about that interchange at all.

So, the bottom line here is that pretty much every computer that you've purchased since around 2011 does not have a BIOS in its firmware.  It does have firmware, but it's UEFI, not BIOS.  If you're scratching your head thinking, "hey, I just bought a computer, installed Windows on it and nothing looked any different," then that's because UEFI firmware contains software that can mimic a BIOS, for compatibility reasons.  That BIOS-mimicking software is officially called a Compatibility Support Module or CSMPretty much all UEFI systems have a CSM, but at some point the world won't care about backward BIOS capability.

So, in other words, most of us already have an improved replacement for BIOS!  So let's return to the story and see how we got it, what it does, and what you need to know as someone who's got to keep Windows computers running.

UEFI Beginnings:  Itanium, EFI and UEFI

The work on building a better "BIOS" began a couple of decades back in 1997.  Intel was making a pile of money selling zillions of Pentium chips, but wanted to create more demand for their processors, and made a big bet on a completely new processor aimed at creating microcomputer-based servers with the power of mainframes.  Called the Itanium, the new processor sadly never really succeeded in the market, and is essentially dead now.  But thinking about an all-new platform for computers, however, led Intel (and HP, to an extent) to develop a new approach to firmware.  Intel originally called the putative BIOS replacement the "Intel Boot Initiative," but soon renamed the new firmware to the Extensible Firmware Interface or EFI.  The "U," for "Unified," would come eight years later in 2005, when Intel handed the EFI's specifications over to an industry group called the UEFI Forum, which writes the specifications for the standard to this day.

EFI's big improvements include:

  • No more assembly language: EFI set aside more firmware space than did BIOS, allowing coders to use higher-level languages like C/C++ instead of assembler.  Even better, that meant that devs writing firmware for, say, an Intel-based EFI system could take the source code that they'd made work on the Intel system (for Itanium chips) and apply it to an ARM system by just recompiling the code on a compiler that spits out ARM code rather than Itanium code.  Why, it's reasonable to ask, hadn't the BIOS writers just made this simple change already?  Well, if the BIOS writers had expanded their firmware space, then they'd have ended up creating PCs that couldn't boot something like the old MS-DOS, so-called "real mode" code, which was limited to a mere one megabyte address space.  Sure, you and I aren't worried about compatibility with circa-1986 software, but in building Un-DOS-able systems in 1997  scared hardware vendors.  The real reason for finally embracing larger firmware probably came from the fact that, again, early EFI was aimed not at desktop home PCs, but instead at servers running a 64-bit operating system -- stuff that was expensive and unusual in 1997.  Nowadays, in contrast, the only 32-bit processors you carry around are on your phone... and as I write this in May 2016, even some phones now run 64-bit hardware and software.
  • A more complete software platform: as we've seen, the BIOS initiates the chain of events that get the operating system running, so in a very real sense it is a part of the operating system.  But BIOSes are far simpler and less flexible than modern operating systems, and that's a pain.  For one thing, consider how long it takes for BIOSes to include support for new-but-quickly-adopted hardware like USB sticks or, more recently USB 3.0 drives and sticks.  All Windows needs to support new storage hardware is a driver.  But a BIOS supporting that new storage at boot time?  Sorry... if you want that new hardware supported, you're probably going to have to buy a new PC with a newer BIOS.  EFI software is essentially a simple but basically complete small operating system, including drivers.  There is even a Linux-like "EFI command-line shell" that you can start up to examine and configure your system's UEFI.  (You've got to download it, stuff it on a Linux/BSD CD-ROM or USB stick.  Before you ask, no, I've not played with it much.  It looks interesting -- you can view your EFI drivers and the like, but unless you've ever done any Linux/Unix, it'll probably be mite cryptic.  Of course, it could also turn out to be a great way to brick your computer, so I'll be treading lightly there, and I recommend that you do also.)
  • A dedicated partition on the hard disk for supplemental "firmware-ish" space: EFI systems don't have to store all of their code in actual NVRAM chips.  EFI systems include a FAT32 partition on the primary hard disk, a partition called the EFI System Partition or ESP. Drivers can go there.  Thus, imagine that USB 4.0 has arrived with 8 gigabit/second speeds, and that it'd be great to boot from USB 4.0 sticks.  There would be no need to buy a new computer to boot from USB 4.0 -- some install program would just copy the USB 4.0 drivers to the ESP, and in a trice your firmware could support booting from USB 4.0.  (That's a heck of a lot easier than flashing a BIOS.)  Build a Windows system on a computer with UEFI hardware (and the CSM disabled) and you'll see a 99MB ESP partition.  It will lack a drive letter, but you if you're curious, you can easily give the ESP a drive letter with Disk Management, Diskpart or the PowerShell Set-Partition cmdlet.  On the ESP you'll see the BCD, EFI and other folders that you've seen on Windows boot volumes since Vista.
  • Supports much larger partitions: EFI systems could boot from a newer drive partition structure called GPT or GUID Partition Table.  It relaxes many constraints of MBR, including the maximum space supported on drives.  GPT drives can be a bit larger than nine zettabytes in size.  (Zettabytes are about one trillion terabytes.)
All of those EFI features were immediately enshrined in the early UEFI specs, so in some sense we can think of firmware with these features -- the non-security aspects of EFI/UEFI but no support for Secure Boot --  "UEFI 1.0."

Working With UEFI Firmware Settings

Time to move to the "what can I do with it?" part.  In order to get systems booting Windows atop UEFI firmware or install Secure Boot, we'll need a few basic skills:  to get into the firmware settings screens, and shifting your system between expecting a BIOS-boot on an MBR-equipped drive or a UEFI-boot an OS with a GPT/ESP-equipped drive.

Get to the UEFI Settings Screens

If you've been supporting computers for any time at all, then you're used to getting into BIOS setting screens.  For UEFI BIOSes, it's the same... almost.  For most UEFI systems that I've seen, it's the same old "press some key at boot time... but not too soon, nor too late, or you have to shut down the system and try it again," or, as I think of it, "the moment when computer support and video gaming meet."   Arrgh.  Anyway, as with the BIOS, the question of "which key to press?" is system-specific.  HPs want F10.  Lenovo wants Enter.  (Actually, Lenovos are a two-quick-button combo, Enter and then F1.)  Acer's opted for F2.  No difference from the old days.  They even look the same as the old BIOS settings screens, as in this Acer BIOS, where you'd never know it did UEFI without a bit of poking around:


I notice that the firmware's title is "insydeH20," which makes it sound like you're underwater when working with it and thus might make you wish for a Surface.  A Lenovo P50 settings screen also looks very traditional, as you can see:

One notices immediately that no one ever explained that whole UEFI-firmware-BIOS distinction to Lenovo's developers.  Ah well.

Getting to the UEFI Settings Screens When There's No Keystroke:  Meet "Boot to Settings"

Video-game startup keys are a pain, but it's even more of a pain when there is no key to press to get into the firmware settings screens.  Such is the case if you have a Microsoft Surface Pro 3 or 4.

 Instead, the Surface uses one of my favorite Windows 10 features, one I call "boot to UEFI."  I've often wished in print or on stage that Windows had a fifth shutdown option, so that rather than just offering "shut down," "restart," "hibernate" or "sleep," Shutdown also offered "reboot to firmware."  In this fantasy, I just choose that option, walk away for a minute, return to the computer, and I'm in the firmware settings, without the video game.  Well, we got that option in Windows 10, but it only works on systems booted from UEFI.  It's a great feature but unfortunately no one seems to know about it, so here's the step-by-steps that will work even if you're a Windows 7 expert who's just moving to Windows 10.  Again, this will only work if you're running a copy of Windows that booted from UEFI instead of BIOS.

  • Open up the Settings app.  (Just press the key with the Windows logo on it, and it'll be in the lower left-hand corner.)
  • In the Settings app, look for the last icon.  Labeled "Update and security," its icon looks like a counter-clockwise circular arrow.
  • On the left-hand column, click "Recovery."
  • On the right-hand side, you should get one or more sections with boldface titles, depending on your hardware, firmware type and configuration.  The first one, which you'll pretty much always see, is "Reset this PC."  Do not click that unless you want your apps wiped out.  If you have upgraded this system at least once, you will probably have an option "Go back to an earlier build."  If your configuration supports boot-to-BIOS, you'll see a title "Advanced Startup."  Under that you'll see a button, "Restart now."
  • That causes your system to boot to a miniaturized version of Windows that Windows 10 Setup installed, the "Windows Recovery Environment" or WinRE. 
  • You may be asked to choose a keyboard type, or not.  If so, choose your preferred keyboard type.
  • Then You'll find yourself at a screen entitled "Choose an Option."  One option will be (at least in my experience, on physical machines but not virtual ones) labeled "Troubleshoot."  Click that.
  • On the resulting Troubleshoot page -- hmm, maybe I'm understanding why so few people know about this, but trust me, it's worth it -- choose "Advanced Options," and again do not choose "Reset this PC..."  "Reset" here means "wipe and reboot," not "turn it off and turn it back on."
  • The resulting "Advanced Options" page offers six options, one of which is "UEFI Firmware Settings," and choose that.
  • The final page, "UEFI Firmware Settings," has a button "Restart" -- click it.  The system will reboot into the UEFI firmware settings screen.

Sidebar:  How Do I know if I've Booted BIOS or UEFI?

Once you start building systems to boot from UEFI instead of BIOS, you'll find yourself asking, "did this thing boot from UEFI or BIOS?"  I've got two answers that'll work for Windows 8 and later: MSINFO32, and a quick PowerShell one-liner.  Among the few dozen bits of info that MSINFO32 displays, there is "BIOS Mode," which it reports as "legacy" or "UEFI." (Another sad case of firmware ignorance.)  Using Sysinternals' Process Monitor tool, I snooped on how MSINIFO32 guessed the boot type.  This was interesting to me because as far as I can see, there are no WMI calls that will tell whether we've booted UEFI or BIOS.  I found that MSINFO32 looked for a Registry key, "HKLM:\System\CurrentControlSet\control\SecureBoot\State."  A little poking around showed that

  • BIOS-booting systems didn't have the "State" key at all.
  • UEFI-booting systems did have the "State" key, whether Secure Boot is enabled or not.
  • Inside the "State" key, there's a value entry UEFISecureBootEnabled of type REG_DWORD.  If it's 0, you're booting UEFI but Secure Boot isn't enabled.  If it's 1, you're booting UEFI and Secure Boot is enabled. The PowerShell one-liner that reports BIOS or UEFI looks like this -- you can cut and paste it into any PowerShell command prompt, whether elevated or not.

if ((Get-ItemProperty HKLM:\System\CurrentControlSet\control\SecureBoot\State -ErrorAction SilentlyContinue) -eq $null) {"BIOS"} else {"UEFI"}

Configure Your System for UEFI Boot

I can't cover everything in this article and will finish up in the next one, but for now I want to leave you knowing enough to try doing a UEFI install of Windows 8 or later on a test system.  On Windows 8 and later, one sure-fire way to do a Windows install that will boot UEFI is to

  • Make sure that your firmware settings expect to do a UEFI boot.  (Don't worry about Secure Boot -- we'll do that next time.  Just understand that you can boot UEFI without Secure Boot, but you can't boot Secure Boot without UEFI -- it never works atop a BIOS install.)
  • Get a Win 8 or later installation ISO and burn it to a DVD.
  • Wipe any partitions on your test PC.
  • Boot the test PC from the DVD and do a normal Windows installation.

Once that copy of Windows boots, it will have booted from UEFI, and you can use my PowerShell one-liner to verify it.  So how to make your system "expect UEFI?"  Via the firmware settings.  Let me clarify -- this isn't the only way to do a UEFI install, but it's the simplest to explain, and I'll explain more in the next article.

Once inside the UEFI firmware settings, you'll need to look around a bit to accomplish the first bullet point just above, the one about setting your system to expect to boot UEFI.  If you've never poked around your firmware settings searching for boot information, then expect to see one of three scenarios.

  • If the hardware is a desktop system pre-2011, there's a good chance that it may only support BIOS-type firmware.  In that case, you can't do a UEFI installation.
  • If the hardware is 2011 and later (and please remember that "2011" isn't a magic year, it's just the year that seemed to me to be the "tipping point" for UEFI firmware), then your firmware may be in CSM ("BIOS mimic" mode), with Windows doing BIOS boots.
  • The "super tipping point" for UEFI was Microsoft's introduction of Secure Boot with Windows 8, which shipped in October 2012, so after that date you'll find a lot of computers shipped from the manufacturer with UEFI and Secure Boot enabled. 

No matter what machine you're poking around in, you'll want to see up to four things, settings that let you control these options:

  • Should the computer boot BIOS or UEFI?
  • Enable/disable CSM -- in other words, it'd be nice to have a "kill BIOS entirely" switch.
  • Alternatively, a nice option is "boot either BIOS or UEFI, and given the choice, try UEFI first and if that fails, fall back to BIOS."  Don't expect this, it's not common.
  • Enable/disable Secure Boot?  Doing that should automatically (1) force a UEFI boot and (2) throw the "kill BIOS entirely" switch.

Some systems do a great job with this, and in particular I'm thinking of the Lenovo systems -- all four of my candidate options appear in the firmware settings.  In other systems, you'll see more Secure Boot-centric firmware options.  The HP was almost as good, offering Secure Boot off/on and option to choose to boot either CSM or UEFI. Acer's Aspire R3 doesn't even show UEFI settings until you disable Secure Boot... so expect that you may have to do a little experimentation to figure out what the firmware lets you do or not do on a system like that. The Surface was again the least flexible one in the pile, with apparently no CSM... there's only a switch to turn Secure Boot on or off.   If the system you're experimenting on is of value to you, please be sure to back your system up before monkeying with the firmware!

Next time, we'll finish doing a Secure Boot install, talk about configuring it and what limitations it imposes upon you.  You'll learn that there are actually two separate Secure Boots going on -- one in the firmware and one in your operating system.  You'll hear about trying to move between a BIOS and a UEFI install, and lots more.  If you have questions or comments, please feel free to drop me a line and I hope that some of you will join me in my Windows 10 support class, where we cover this and many other Win 10 topics.  As always, thanks for reading!

To Subscribe, Read Old Newsletters, Send Me a Comment or Change Your Email Address

To subscribe: (which just means I'll send you about a three-tweet-sized message in plain text via email including a link to my latest newsletter), please visit

To change e-mail or other info, drop me a line (haven't figured out a secure method yet).

To read old newsletters: visit and, if you like 'em, please consider subscribing.

To send me a comment:  I'm at

All contents copyright 2016 Mark Minasi.  I encourage you to quote this material, so long as you include this entire document. Thanks very much for reading, and see you next time.