About Steve Schardein

The owner of the website!

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!

SOLUTION: IAStorDataSvc consumes 20-40% CPU following Windows 10 build upgrade

Intel’s Rapid Storage Technology drivers haven’t been getting a lot of love from me recently, and unfortunately, that isn’t about to change today.  A recent Windows 10 upgrade (the Anniversary Update, build 1607) also includes a new Intel RST driver, and on some systems, it’s a source of significant headaches.  These systems are stricken by suddenly noisier than usual operation and higher temperatures, both of which stem from higher-than-normal CPU consumption from the Intel RST system service.

How do you know if your system is affected?  In Task Manager, you should see IAStorDataSvc consuming CPU cycles in excess of 20%, and sometimes as much as 40%.  You can kill the process, but the permanent fix is to uninstall Intel Rapid Storage Technology entirely.  The program is unnecessary for the drivers to continue functioning normally, so it won’t hurt to simply leave it out in most cases.  Before you do so, however, for safety’s sake, you’ll want to create a System Restore point.

You can also upgrade the package to its latest available version in hopes that this will correct it.  If you wish to do so, Intel lists it in the Download section on their site, or you can obtain them directly from your PC manufacturer.

SOLUTION: “No bootable devices found” on Dell Laptops – SSD not detected

A relatively new form of problem which has been introduced by the wider adoption of solid-state drives (and other drives with more particular power requirements than standard mechanical hard drives) is that of drive detection and compatibility.  This applies most notably to sleep/resume and cold boot detection of these devices, which sometimes are not detected at all on specific systems.  Occasionally a BIOS update on the computer or a firmware update to the drive can resolve the issue, but other times, the drive may simply be incompatible.

I have seen this most recently with Crucial brand SSDs, which by and large have proven to be a good value — when they work.  Reliability hasn’t been a concern with regard to the drives I’ve purchased for my clients, but on occasion, drive detection is a problem.  Specifically, some of the newer Dell Latitude laptops (of which I purchase and service quite a large number) seem to struggle with Crucial SSDs.

The message you will see on a Dell Latitude if this happens to you is:

No bootable devices found.
Press F1 key to retry boot.
Press F2 key for setup utility.
Press F5 key to run onboard diagnostics.

Interestingly, if the user presses F1 to retry, the machine then boots normally.  This indicates that the problem has to do with the machine not detecting the drive quickly enough during POST to continue with the boot process.

With other machines, the problem can be resolved by switching ON “Hot plug support” (or similar) in the BIOS Setup.  However, this option does not exist within Dell’s BIOS Setup.

So, then, what’s the solution?  Actually, it’s precisely the same thing I posted in my previous update as a response to a completely different problem: bypass the RAID controller and use AHCI interface instead.  The problem apparently seems to be related, at least in part, to how the system processes the communication between the drive and the chipset via the Intel RAID controller.  Disabling RAID does require jumping through a couple of hoops, but it’s relatively quick and easy.  See my post here for full instructions!

Once this is complete, the machine boots normally each and every time!

SOLUTION: Switch Windows 10 from RAID/IDE to AHCI operation

PSA: You should not be attempting these fixes unless you’re a professional!  And it goes without saying, you will ALWAYS need your local admin password, recovery media, and backups of your data before fooling around with low-level storage driver configuration — or really anything else for that matter.  See the comments section below for examples of a couple of people who ran into mishaps after encountering other underlying issues or forgetting their admin password before starting the process.  PROCEED AT YOUR OWN RISK!

It’s not uncommon to find a system on which RAID drivers have been installed and something like the Intel Rapid Storage Technology package is handling storage devices, but where an SSD might require AHCI operation for more optimal performance or configurability. In these cases, there is in fact a way to switch operation from either IDE or RAID to AHCI within Windows 10 without having to reinstall.  Here’s how.

  1. Right-click the Windows Start Menu. Choose Command Prompt (Admin).
    1. If you don’t see Command Prompt listed, it’s because you have already been updated to a later version of Windows.  If so, use this method instead to get to the Command Prompt:
      1. Click the Start Button and type cmd
      2. Right-click the result and select Run as administrator
  2. Type this command and press ENTER: bcdedit /set {current} safeboot minimal
    1. If this command does not work for you, try bcdedit /set safeboot minimal
  3. Restart the computer and enter BIOS Setup (the key to press varies between systems).
  4. Change the SATA Operation mode to AHCI from either IDE or RAID (again, the language varies).
  5. Save changes and exit Setup and Windows will automatically boot to Safe Mode.
  6. Right-click the Windows Start Menu once more. Choose Command Prompt (Admin).
  7. Type this command and press ENTER: bcdedit /deletevalue {current} safeboot
    1. If you had to try the alternate command above, you will likely need to do so here also: bcdedit /deletevalue safeboot
  8. Reboot once more and Windows will automatically start with AHCI drivers enabled.

That’s all there is to it!  Special thanks to Toobad here for outlining this procedure.

Update 8/2/17:  Thanks also to Aalaap Ghag for clarification of instructions for those who have already updated to the Creators Update.  Thanks also to those who wrote in about removing {current} to make this work for some users.

SOLUTION? “Class not registered” when trying to open Chrome in Windows 8.1/10

Recently I have been seeing an increased incidence of this particular issue on newer Windows 8/8.1/10 machines.  It occurs when the user attempts to launch Chrome via any shortcut on the Desktop, taskbar, or elsewhere, or when opening any file or protocol (URL, etc.) associated with Chrome.  The only permanent “solution” is to create a direct shortcut to the Chrome.exe executable in the %PROGRAMFILES(x86)%\Google\Chrome\Application directory and then launch it from there.  However, this doesn’t fix the problems with trying to open .HTML files and URL links from other applications, which still trigger the error.

Lots of suggestions abound across the internet regarding ways to temporarily correct this problem.  Most of them center on the deletion of the Chrome Classes registry keys affiliated with the file/protocol associations, but these are only temporary; the problem resurfaces each and every time Chrome updates itself, which happens a lot.

Instead, there seems to be a much easier solution.  Bear in mind that I have only thus far tried this on one machine, but it worked immediately, and it jives with other research I’ve done on related subjects.  Please let me know in the comments if this solution also works for you.

The fix?

  1. Uninstall Java (all versions).
  2. Uninstall Chrome.
  3. Reboot.
  4. Reinstall Chrome.

This corrected the problem completely on my user’s machine.  It may or may not work for you; if it doesn’t, try one of these other solutions:

  1. Open regedit.
  2. Delete (if present) the following registry keys:
    1. HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{5C65F4B0-3651-4514-B207-D10CB699B14B}
    2. HKLM\Software\Classes\Chrome
    3. HKLM\Software\Classes\ChromeHTML\open\command\DelegateExecute
  3. Reboot.

Then:

  1. Open Default Programs and set a different browser temporarily to default (for example, IE).
  2. Open Chrome and choose to set it as default when automatically prompted.

Hopefully this helps someone else struggling with this problem.

ASUS Q502LA Official Driver Downloads

Looking for drivers for your ASUS Q502LA notebook? Good luck, because entering the model number at the ASUS website won’t get you to the right page.  Wondering why that is?  So was I, so I eventually located the correct page and have made the link available for you here:

https://www.asus.com/us/support/Download/3/686/0/1/CPUDRIVER_Ix-5xxxxU/45/

That’s it.  Because you need a support post to find drivers on ASUS’ fundamentally broken website.

By the way: if you’re having trouble with sleep/resume (you see a black screen) after upgrading to Windows 10 on this machine, you’ll want to ensure you have the latest ASUS system software installed (ATK, FlipLock, etc.) as well as the latest BIOS version.

SOLUTION: Cannot Uninstall Microsoft Security Essentials from Windows 10

Recently, I encountered two different workstations that had upgraded to Windows 10 from Windows 7 on which Microsoft Security Essentials inexplicably was not uninstalled during the upgrade process by Windows Setup.  This is baffling, because MSSE isn’t designed to work with Windows 10 (it doesn’t work), and plus, it precludes the use of Windows Defender, which is essentially the Windows 10 upgraded equivalent of MSSE.

If you’re in the same situation, you’ll also discover that it is impossible to remove Microsoft Security Essentials from Programs and Features; when attempting to do so, you simply receive a generic message which states “You don’t need to install Microsoft Security Essentials.”  That’s great, Microsoft, because we don’t want to install it, we want to uninstall it.

Anyway, the solution to this problem is actually quite simple:

  1. Press Windows Key + R to open the Run dialog.
  2. In the Open: field, type:
    • explorer “%PROGRAMFILES%\Microsoft Security Client\”
      and press ENTER.
  3. Highlight the file Setup.exe, right-click it, and choose Properties.
  4. Choose Compatibility.
  5. Click Change settings for all users.
  6. Check the box next to Run this program in compatibility mode for: and choose Windows 7 from the drop-down box.
  7. Click OK on all dialogue boxes to exit all windows.
  8. In the search box at the bottom of the screen, type cmd. At the top of the pop-up window, underneath the heading Best matchright-click Command Prompt and choose Run as administrator.
  9. In the Command Prompt window that opens, type the following command:
    • “%PROGRAMFILES%\Microsoft Security Client\setup.exe” /x /disableoslimit
  10. Follow the instructions to uninstall.

That’s it!

Special thanks to corrado_boy_g60 at the Microsoft Community for information leading to this solution.