Bypass Microsoft Account Creation during Windows 10 Build 1909 OOBE Setup

This is a quick and easy one. In previous versions of Windows 10 setup, selecting an offline (so-called “limited”) account was relatively easy. However, with the latest build of Windows 10 Home, if the machine is connected to the internet during setup, the option disappears.

It’s true that you can simply disconnect from the network (or open cmd and delete the wlan profile), then click back and try again, to avoid this. But there’s a much easier way.

Instead, in the sign-in field, type a bunch of random numbers, then click Next. At this point, you can choose to create a local/limited account instead—even if you’re connected to the internet. It’s really that easy!

SOLUTION: Windows 10 upgrade failure 0x8007001F – 0x20006

This week, a client brought me a Windows 7 PC which refused to upgrade to Windows 10, despite their having reserved a license long ago for the OS and attempting to install it repeatedly. The error message they were receiving was:

0x8007001F – 0x20006
The installation failed in the SAFE_OS phase with an error during REPLICATE_OC operation

A screenshot of the setup error message which repeatedly plagued this machine

My usual remedial measures, after poring through setup error logs and all that fun stuff, were completely unsuccessful in this instance. Myriad internet searches also turned up lots of other people with the same problem, but no actual solution. Everyone simply wiped/reinstalled Windows.

Some of these attempts included:

  • sfc /scannow
  • BCD rebuild
  • Boot parameters rebuild
  • System (boot) partition rebuild
  • Filesystem checks, etc
  • Permissions repairs

Nothing at all worked. Eventually, however, I stumbled across a solution almost too simple to seem likely to work: an in-place upgrade of Windows 7. In other words, in colloquial terms, a conventional “repair install”.

All this involves is to grab Windows 7 install media matching the version installed and perform an “upgrade” process right from within Windows. Once complete, I had to reenter the Product Key and reactivate – so make sure the sticker is legible on the particular machine you’re working with. If it isn’t, specialized activation backup/restore methods will be required to continue with the process and eventually the Windows 10 upgrade.

After this, everything worked perfectly. The W10 upgrade process was smooth, and the client is now happy as a clam!

SOLUTION: “There is a problem with the selected printer” when printing email in Outlook

Today, I encountered an issue that was new to me. A client’s PC refused to print any email within Outlook (in her case, Office 2013 version, but the same problem persisted in Outlook 365 prior to my correcting it). The error message she received was:

There is a problem with the selected printer. You might need to reinstall this printer. Try again, or use a different printer.

The problem persists regardless of which printer is selected—even if it’s a default built-in virtual printer such as Microsoft Print to PDF or the XLS printer. However, it won’t necessarily affect all email messages.

So, what’s the deal? As it turns out, this problem is caused by a corrupted font. Knowing this is half the battle—but unfortunately, it’s only the start of the process you’ll need to follow in order to fix it.

As the folks over at Kinetic Computer Services explain, copying and pasting the entire contents of an affected message into Word (Close Word if open, CTRL+A + CTRL+C to copy, then reopen Word and paste using CTRL+V) will generate a related (but different) error if you wish to confirm that this is actually the case. Word will complain that “There is insufficient memory or disk space. Word cannot display the requested font.”

You might think that simply reinstalling all system fonts would correct this problem, but as I discovered, it sadly does not. The System File Checker also doesn’t fix anything. So, instead, you’re left to identify the affected font on your own and then take action.

What I did was to highlight small sections of an affected email message and copy and paste them individually into a new Word document until the error message appeared. This was much easier than attempting to step through an affected document and identify manually which font might be to blame based on differences in appearance. In my client’s case, it was the Papyrus font that was bad.

!


Keep in mind that after the error appears once, you’ll need to close Word to provoke it to appear again. So after the copy/paste of the entire message the first time, close Word, then reopen it before beginning your sectional diagnosis of the email content.

Once you identify the affected font, open a Windows Explorer window and navigate to C:\Windows\Fonts. Search for the font that’s affected, highlight it, and copy it someplace else for backup purposes just in case. Then, simply delete the font from the C:\Windows\Fonts folder. If it’s a critical system font, Windows should automatically replace the file for you. If it doesn’t, try right-clicking the copied file (located outside of the Windows Fonts folder) and choosing Install for all users. It should complain about the font being corrupted, and then install a good version for you automatically.

If all else fails and Windows can’t work this out on its own, find yourself another Windows machine and manually copy the font from there, then install it on the affected machine. Once this is all done, close and reopen Outlook—and the problem is solved!

SOLUTION: bootrec /fixboot Access is Denied

So here’s a new one. Warning: this one’s rough. It’s an advanced one, and there are possibly more causes than simply this… so as always, I take zero responsibility for anyone messing with their own machines without professional help.

This particular story is just that: a case study, basically, referencing the circumstances of the individual machine I was working on. This post is more for my reference than for anyone else’s from that standpoint. 😉

A client’s machine came to me, stuck in a boot loop to WinRE. Nothing corrected it, but the machine seemingly wasn’t even trying to boot to the Windows partition. As is often the case with Windows 10, System Restore was of no help. As always, the first step, then, was to repair the BCD and boot parameters (this was a GPT/UEFI drive), so I went through the usual steps first.

However, once reaching the bootrec /fixboot step, the result was Access is Denied. This is the first time I’ve seen this message to my knowledge, so I did some digging.

What I discovered is that apparently the latest build of WinRE doesn’t properly handle this command in some situations. I booted to an older build of a Windows ERD (based on 1703), ran the same commands, and this time, it worked.

After this (and after disabling automatic restart on system failure), I was finally reaching an intelligible boot error screen, thus confirming that the system was at least attempting a boot from the Windows partition. The error referenced the file WdFilter.sys, which is located at c:\Windows\system32\drivers\wd\WdFilter.sys. It’s the Windows Defender Real-Time scanning filesystem filter driver, specifically.

I navigated to this directory next and noted the file creation/modification dates on the two files, which was 10/23/2018 (in case this is of any use to anyone else with this problem). The same dates were shared by WdNisDrv.sys (the Windows Defender network stack filter driver). WdBoot.sys, meanwhile, was dated sometime in April 2018.

Copies of these files are stored in c:\Windows\system32\drivers. Suspecting that one of the October-dated versions was corrupt, I replaced both WdFilter.sys and WdNisDrv.sys, then booted the system.

This time, the machine finally reached Windows. The work wasn’t finished yet: to bring everything up to consistency, I next performed a Component Store Cleanup and DISM RestoreHealth command followed by a system file check and repair. After all of these steps, the problems were completely resolved, and everything was back to working normally.

SOLUTION: Word/Excel hangs when opening files/scrolling is greyed out

Recently, a number of machines I’ve serviced have experienced a problem where particular Office files hang when scrolling through them. At first, this seemed likely to be an issue with Hardware Accelerated graphics rendering, but that wasn’t the case.

The actual issue lies with what’s called Protected View. It’s designed to bolster security by limiting the permissions of files opened from risky locations, but at least currently, it’s leading to some broken functionality on a lot of machines.

The best solution that I’ve found (as a workaround) is to simply disable Protected View entirely until Microsoft sorts this out and releases a patch. Here’s how to do that:

  1. Open the affected Office application (you have to do this separately with all affected applications)!
  2. Navigate to: File > Options > Trust Center > Trust Center Settings > Protected View
  3. Uncheck all of the items within this dialog, as seen below.

Problem solved!

SOLUTION: Black screen on boot with mouse cursor, Windows 10 Fall Creators Update [Build 1709]

Recently, I’ve seen more and more machines (still a small amount, but an increasing number seemingly) with a problem upon boot following some recent updates to the Windows 10 Build 1709 subsystem.  Specifically, these machines hang on boot at a black screen following the Welcome/login screen with only the mouse cursor present for anywhere from a few to several minutes.  Task Manager can be invoked and CTRL+ALT+DEL still works, but the machine will not operate normally with the usual Windows shell interface (explorer.exe GUI etc.) until the process sees itself through to fruition.  This happens at each and every boot.

Microsoft has indeed acknowledged this issue, blaming it on some rogue registry keys supposedly put in place by some OEMs which are incompatible with the latest builds of Windows 10.  However, I’ve come to doubt that explanation, as the fix they provide in the relevant KB article has not yet once worked on any of my clients’ machines, and another, more foolproof fix has instead corrected the problem.

This is the service which causes all of these headaches.

This is the service which causes all of these headaches.

A while back, people discovered that the singular service responsible for this behavior is the App Readiness service, which prepares user data the first time a user logs on following the installation or update of a Windows Store app.  Disabling this service does correct the problem.  If you experience this exact behavior, I have what is likely a permanent fix for you however, and best of all, it’s easy.


First, determine if this particular problem applies to your machine. Lots of things can lead to hangs during the boot process, so before you proceed further, it’s a good idea to ensure that the App Readiness hang is actually what is afflicting you:

  1. Boot the machine normally.
  2. During the hang at the black screen, press CTRL+SHIFT+ESC to bring up Task Manager.
  3. Choose File > Run New Task.
  4. Type msconfig and press ENTER.
  5. Click the Services tab, uncheck App Readiness, and click OK.
  6. Either wait out the rest of the boot procedure and then reboot your PC, or force a reboot by returning to Task Manger and running this task: shutdown -r -t 0
  7. Upon reboot, if the problem disappears, this is indeed your issue.
  8. If the problem is solved, next reverse the procedure by rerunning msconfig and rechecking the box next to App Readiness.  Reboot again and allow the slow boot procedure to complete.

The reason you need to reenable App Readiness is that without it, the next steps will fail.

You can also disable the service via the standard services.msc snap-in interface if you prefer that.

You can also disable the service via the standard services.msc snap-in interface if you prefer that.

Once the diagnosis is complete, the next step is easy.

  1. Obtain Windows 10 Fall Creators Update (Build 1709) or later installation media directly from Microsoft’s software download website (update May 2018: the latest build is now 1803, the April Update). Try using the “Download Tool Now” button method and creating an installation DVD first, as this procedure is more likely to succeed.
  2. Once you have created the DVD, run the setup process from the DVD and choose to upgrade Windows while retaining all apps and user data.  This process is called an in-place upgrade as has been available for many years now within Windows (barring a short hiatus).
    1. If a DVD drive is not available, you can simply mount the resulting ISO file and install it from the virtually mounted ISO.
    2. If both of these methods fail, you can try using the Windows 10 Update Assistant tool from that same webpage instead.
  3. See the installation through to completion.
  4. Once finished, reboot and see if the problem is fixed.  It should be!

I hope this helps restore sanity to someone’s computing life.

SOLUTION: Outlook 2016 will not start (stuck on “Loading Profile”)

This morning, I received a call from a client who was unable to open Outlook 2016 suddenly following an upgrade to the Windows 10 Creators Update.  This problem may or may not have been directly related to that update, but the timing was at the very least coordinated with it.

Each time the client clicked the shortcut to open Outlook, the splash screen opened and Outlook would hang on the “Loading Profile” screen.  These sorts of symptoms are actually not all that uncommon, and a range of different solutions exist to rectify them.

The solution this time, however, was not at all obvious.  After trying all of the usual fixes:

  • Disabling Hardware Acceleration via the registry
  • Starting Outlook in Safe Mode (outlook.exe /safe)
  • Checking/disabling compatibility troubleshooter flags on the Outlook shortcut
  • Resetting the nav pane (outlook.exe /resetnavpane)
  • Creating a new Outlook profile
  • Repairing Outlook via an Office 2016 Online Repair
  • Completely reinstalling Office 2016
  • sfc /scannow
  • DISM /Online /Cleanup-Image /RestoreHealth
  • netsh winsock reset
  • netsh int ip reset
  • ipconfig /flushdns
  • A complete Windows 10 “network reset”

Nothing corrected the problem.  Only one bizarre workaround provoked it to open with the Exchange account attached, and that was to disable all network connectivity (in other words, by invoking, for instance, Airplane Mode).  While disconnected, Outlook opened right up.

Some troubleshooting using Process Explorer revealed that Outlook TCP connections were opening but apparently failing during the launch.  This, along with a run of the Microsoft Support and Recovery Assistant for Office 365, eventually led to the solution:

Disabling IPV6 in the network adapter!

Here’s how:

  1. Right-click the Start Menu and choose Network Connections.
    1. (If on the latest Windows 10 build, you’ll need to perform this step next:) Scroll down to the bottom and click Change adapter options
  2. Double-click your primary network adapter.
  3. Click Properties.
  4. UNcheck Internet Protocol Version 6 (TCP/IPv6)
  5. Click OK.

Voila!  Outlook now opens normally.

After this one, I had a beer.

Ransomware: Identification and Response

By now, ransomware is an unfortunate fact of life.  Anyone who’s been working in IT for some time has very likely brushed up against it at some point during their career–and while it’s a stunning encounter in the outset, it’s the response to that encounter that makes all the difference.

Before we go any further, I want to make this very clear: if your data is important to you, it is very wise not to attempt recovery/response on your own.  Bring your machine to a professional instead!  If you have nothing to lose, however, below are some guidelines to follow to attempt recovery in the aftermath of an attack.

It’s useful to comprehend the steps most ransomware specimens take to attacking/encrypting data on a machine to help facilitate a response to their attacks. This is absolutely not meant to be a comprehensive article on the subject (far more detailed analyses have been written by experts such as Lawrence Abrams at his excellent BleepingComputer.com), but here are a few common points that apply to most every ransomware in the wild today:

  • Most of them limit the types of files they encrypt to those which are most likely to contain critical user data–stuff like photos/pictures, documents, videos, databases, etc.
  • System/program/non-user data directories (X:\Windows, Program Files, Program Data, %APPDATA%, etc.) are explicitly excluded from encryption to prevent system stability issues post-infection and improve efficiency
  • Encryption normally begins silently in the early morning hours while the user is less likely to be in front of the machine.

The above items are done in the interest of efficiency to ensure the ransomware is able to complete its encryption job without the user noticing.  Typically, after the completion of the encryption, the ransomware will then remove itself from the system–leaving only a ransom note with payment instructions, as that’s all the attackers care about at this point after all.

Although most of them apply the same strategy (and many are, in fact, even blood-related), the first step to properly responding to a ransomware attack is to take a sample and attempt a positive ID of the malware.  This can be accomplished by using services such as ID Ransomware (by MalwareHunterTeam/Demonslay335), which is a free online resource that attempts to identify a ransomware infection based on either a ransom note or sample encrypted file.  However, it’s very important that you do not obtain the file while running on the infected OS.  Doing so provides the ransomware precious additional time to complete its destruction of the existing data if it has not already completed.  If you must collect the file in the host infected OS, only do so after you obtain a forensic image of the data.

Once an ID has (hopefully) been completed, the next step is to respond and attempt recovery (if necessary/desired)–assuming no backups are present and that does not exist as a (much simpler) option.  This involves several steps, but it roughly goes something like this:

  1. Obtain a forensic image of all affected storage devices/machines and store it safely away from the machine.
  2. Boot to a portable environment and manually inspect the parameters of the system, including:
    1. Boot processes, services, tasks, and other items frequently leveraged by malware as loading points
    2. The locations of any files which are infected, malware, or related to the ransomware infection
    3. The System Volume Information repository contents and the Volume Shadow Copy parameters/settings (to ensure that Shadow Copies and System Restore are turned on and that sufficient space is configured to allow for the storage of Shadow Copies)
    4. The health of any affected storage devices
  3. If necessary, suspend/disable any components which are related to the malware/ransomware infection next.
  4. Once this is completed, reboot into the host OS (Safe Mode if possible) and, if a decrypter has been identified for your particular ransomware infection, obtain it and attempt decryption of the data.
  5. If a decrypter has not been identified, the only remaining solution is usually to attempt to dig into the Volume Shadow Copy Storage in hopes of previous versions of the affected data still being present.
    • Ransomware specimens often attempt to purge shadow copies of files post-encryption to prevent recovery of the files using shadow copy storage.  However, the methods used to do this are often heavy and time-consuming (typically it’s a vssadmin command that’s used to accomplish this).  Many times the process will not have completely finished by the time the user notices the damage.  That’s why sometimes digging into the VSS storage can be a successful solution to recovering data following a ransomware attack.
    • There are multiple tools available which can accomplish Shadow Copy file restoration, but the best is probably ShadowExplorer.
  6. If shadow copies do not exist, the last-ditch effort to retrieve some remaining data is typically to perform a file carving operation on the entire hard drive.  Tools such as PhotoRec can be used to accomplish this.  File Carving identifies files based on their headers and not based on filesystem information/structural data (MFT/FAT/etc).  As a result, it can sometimes turn up lost files even following a ransomware attack.
    • Most ransomware specimens wipe both free space and the sectors on the disk affiliated with previous/clean versions of encrypted files once encryption is complete, so this process is usually fruitless.  But, as a last resort, it’s worth a shot.

If all else fails, backups are the final option.  If no backups exist, the user must consider paying the ransom in hopes of recovering their data–though authorities and experts will invariably tell you not to do this, as it encourages ransomware as a viable business venture and, therefore, the attackers win.  However, most ransomware gangs will in fact restore data following successful receipt of payment–and sometimes it is the only option.

Once recovery has (hopefully) been completed, any remaining ransom notes can be automatically removed using Demonslay335’s RansomNoteCleaner tool here.

For specific help on a ransomware infection, check out BleepingComputer’s free support forum here.  Remember, though–if your data is important to you, let an expert handle it!  Don’t attempt a DIY recovery!

SOLUTION: “The requested system device cannot be found” on UEFI systems

With GPT disks and UEFI all the rage now, it’s not uncommon to encounter a scenario where boot parameters need to be repaired in order to reach the operating system.  Generally speaking, it’s often easy enough to accomplish this by executing the command bcdboot X:\windows (where X is the system drive letter) from a recovery environment.

However, other times, even in spite of this command properly completing, the system still will not boot.  In many cases the failure is evident when attempting to perform bcdedit /enum and receiving a message such as this one:

The boot configuration data store can not be opened.
The requested system device cannot be found.

Performing bootrec /fixboot also provokes the following error:

Element not found

This is bad news on a GPT disk using UEFI rather than BIOS.  Essentially, the system is looking for the EFI partition, which in this case is either missing or corrupt.

If it’s corrupt but still exists, you can simply enter diskpart, select the system partition (usually around 500 MB in size and with an ID of “EFI”) and assign it a letter, exit diskpart, and then perform a chkdsk command on the new partition assignment.  This sometimes will correct it.  Other times, forcibly removing the EFI and boot folders from the EFI partition and then executing the bcdboot command with a specific system partition parameter (e.g.: bcdboot X:\windows /s E:, where X: is the Windows partition and E: is the EFI paritition) works.

But let’s say the partition is missing altogether.  This is most often the case following a drive image using imaging tools to a new SSD for example.  Sometimes the tools (especially if executed externally on another system rather than live within the target OS) will remove the EFI partition and only image the Windows partition.

If this happens, most people will tell you that you will need to reinstall Windows from scratch.  However, all is not yet lost!  It’s fixable — but in order to accomplish it, you must recreate the EFI partition manually and then reload the boot parameters from there.

Here’s how it’s done at a command prompt from a recovery environment.  I’ve bolded the commands I typed to make it easier to read — hold on tight:

X:\windows\system32>diskpart

Microsoft DiskPart version 10.0.10240

Copyright (C) 1999-2013 Microsoft Corporation.
On computer: MININT-3A416N9

DISKPART> list disk

Disk ### Status Size Free Dyn Gpt
——– ————- ——- ——- — —
Disk 0 Online 489 GB 0 B *

DISKPART> sel disk 0

Disk 0 is now the selected disk.

DISKPART> list part

Partition ### Type Size Offset
————- —————- ——- ——-
Partition 1 Primary 489 GB 1024 KB

DISKPART> sel part 1

Partition 1 is now the selected partition.

DISKPART> shrink desired=1024

DiskPart successfully shrunk the volume by: 1024 MB

DISKPART> create partition efi size=260

DiskPart succeeded in creating the specified partition.

DISKPART> format quick fs=fat32

100 percent completed

DiskPart successfully formatted the volume.

DISKPART> exit

Leaving DiskPart…

X:\windows\system32>bcdboot c:\windows
Boot files successfully created.


Following these steps, the machine should now be bootable.  If it’s not, it’s probably time to call a professional!

Good luck!

 

SOLUTION: “Restart your computer to install important updates” won’t go away in Windows 7

In recent weeks, I’ve encountered multiple machines unable to install Windows Updates thanks to a perpetual message claiming:

No matter what the user does, these machines simply won’t install any updates.  If they’re rebooted as requested, nothing happens, and the message simply reappears upon reentering Windows, no matter how quickly the user attempts to invoke the process.  Resetting the SoftwareDistribution repository, by the way, does not solve this problem.  Neither does restoring the conventional Windows Update settings using a variety of troubleshooters, such as the Microsoft troubleshooter.

What does work, however, is removing a single registry key which is responsible for the problem:

osupgrade-key(apologies for high-res screenshots; I’m too lazy to correct this)

The particular key in question is:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\OSUpgradePendingReboot

All that’s necessary is to delete this key, and the problem evaporates, like it never even happened!  The key is related to the Windows 10 in-place upgrade process which (used to) take place through Windows Update.  The situation seems to suggest that these machines were nearing the final stages of the upgrade when something happened and they failed to install it.  Now, the upgrade windows has officially passed.

As always, of course, it’s wise to create a System Restore point before modifying your registry, etc., yada yada.

Hope this helps!