SOLUTION: Windows Update Error 0x80071A90 “Reverting Changes…” when installing KB2732500, KB2729094, KB2732487, & KB2647753

Wow, that one’s a mouthful.

This weekend I was working on a client’s PC that repeatedly failed to install these four updates.  Upon rebooting, the PC repeatedly entered the “Reverting Changes…” step of Windows Update that occurs when one or more updates fails to install properly.  The error code (0x80071A90) isn’t very helpful, either.

Fortunately, the solution to this one is easy.  All that’s required is for you to first download and install the standalone update package for KB2647753 separately.  You can find the standalone package here:

http://www.microsoft.com/en-us/download/details.aspx?id=29156

Once you’re finished with this, perform the remaining updates once more.  They should now properly install.

This is often the best solution anytime Windows Update chokes on one or more updates.  The standalone package is always the first thing I try, followed by the Windows Update System Readiness Tool, and finally more advanced/invasive measures, such as resetting the SoftwareDistribution store or running Microsoft Fixit 50202 in Aggressive mode.  I won’t cover those procedures in any more detail here as it isn’t really needed, but if you’re in need of help, leave me a comment and I’ll elaborate!

Never bother with Windows Update again.  If you’re a repair tech or sysadmin, check out WUInstall Pro today!

Repairing the .NET Framework in Windows Vista/7

These days I do a considerable amount of data recovery for my clients, and as you might expect, when dealing with failing drives, it isn’t always possible to recover all of the information.  Even the sophisticated hardware-based imaging tools I have can’t always extract every sector from a bad drive.

As such, I recently imaged a Windows 7 hard drive and retrieved something above 99% of the data.  This left very few files corrupt (and Windows was bootable following a chkdsk /f operation), but one item which was not working properly was the .NET Framework.  Problem is, unlike in previous versions of Windows, repairing the .NET Framework in Windows 7 isn’t as simple as removing/repairing all of the .NET Frameworks (either via Add/Remove Programs or using a cleanup tool and reinstalling them one-by-one).  Thanks to Aaron Stebner for his excellent reference material on this subject, by the way.

On Vista and 7, many .NET Framework versions are actually integrated into the OS.  As a result, when damaged files are responsible for its failure, you can often correct the problem using sfc /scannow.  However, when this fails, there’s actually a pretty straightforward way of making them work.

The catch is that the registry entries have to be intact.  There is, unfortunately, no easy way to restore these entries without a repair install (or “in-place upgrade” as it’s called in Vista/7).  In the event of disk failure and recovery, it’s very likely that if you’re able to boot, the registry is in working condition.  So if an sfc operation fails, it’s most likely that the file in the recovery store is also corrupt.  You can verify this by checking the CBS log for SFC entries (denoted by [SR]).  An easy way of doing this is to run this command once the sfc has finished its operations:

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

This command searches the CBS log for entries related to SFC operations and outputs all of the matching lines to another file called sfcdetails.txt.  If a corrupt file is found in the store and cannot be used to repair another damaged system file, you’ll see an entry like this one:

[SR] Could not reproject corrupted file {filename}; source file in store is also corrupted

My solution?  Pretty simple really; from a healthy Windows 7 64-bit system (the same OS as the patient PC), I backed up and then manually copied all files within these directories:

%windir%\Microsoft.NET\assembly
%windir%\Microsoft.NET\Framework
%windir%\Microsoft.NET\Framework64

As far as I know, the contents of these directories on identical, up-to-date Windows versions are standardized.  My suspicions were validated when, upon the next boot, the patient PC was suddenly working perfectly, with no adverse side effects!

By the way, while we’re on the subject of the SFC, one more solution to the problem is to simply replace every file it can’t repair as detailed here.  But you can also copy good versions of the files to the winsxs directory in the proper location and then perform a subsequent SFC operation to have it replace them for you.  Either approach works!

The dangers of registry cleaners

Update 2014: Microsoft has since finally posted their own take on the use of registry cleaners, and it’s quite clear:

Some products such as registry cleaning utilities suggest that the registry needs regular maintenance or cleaning.  However, serious issues can occur when you modify the registry incorrectly using these types of utilities. These issues might require users to reinstall the operating system due to instability. Microsoft cannot guarantee that these problems can be solved without a reinstallation of the Operating System as the extent of the changes made by registry cleaning utilities varies from application to application.

Bottom line: don’t use registry cleaners, and view any product or company which recommends that you do in a rightfully suspicious light.

(My original post follows):

If you’re used to my work, you know how strongly against the use of any registry cleaners I am.  It’s no secret that many experts, including Windows guru Mark Russinovich, warn of their dangers.  The fundamental reason behind this position is that no program can know with certainty what is and is not desired or necessary to be stored in the registry.  And plus, even if plenty of unnecessary stuff is contained therein, it’s not really beneficial to remove it.  The registry as a whole is relatively small anyway compared with the amount of RAM available on modern PCs, and removing even a few thousand straggling values or keys provides very little, if any, performance improvement.

So in light of this, today I’m here with an update regarding one of the most popular posts I’ve had on this blog to date, and I felt like it deserved its own post thanks to the magnitude of the example.  In my Click2Run Configuration Failure Office 2010 post, I offer a solution to a fairly widespread and rather maddening issue with Office 2010 Click2Run installations suddenly failing.  Not even Microsoft has addressed the problem with an official solution to date, so this blog post has gotten plenty of traffic.

One thing my post didn’t include, however, was a known cause for the problem.  Well, as with most computer problems, this error doesn’t just spontaneously appear.  It’s now become apparent to me that the culprit behind this problem is actually registry cleaning applications.  The most commonly seen program responsible for this problem appears to be iolo’s System Mechanic, but it’s safe to assume that any registry cleaner could lead to the same results.  For a long time now, I have been recommending against the use of this program and have removed it from many of my clients’ PCs following consultation with them regarding its use.  If you have System Mechanic installed and have been using it, you can expect that you might run into the same problem in the future.

This is just an example, of course.  Although it’s now mostly certain that this is the predominant cause of this irritating Office 2010 problem, registry cleaners can just as easily lead to any number of other issues that are hard to diagnose and potentially impossible to troubleshoot.  Save yourself the headache and remove any registry cleaning program you may have installed from your PC today.

Netflix Error n8156-6013

Here’s an error a customer of mine received recently when trying to play videos on Netflix.  The problem persisted in all web browsers installed (Internet Explorer, Firefox, and Chrome).  A quick search across the internet reveals a solution which works for most people:

Browse to C:\ProgramData\Microsoft\PlayReady on Vista/7 machines and C:\Documents and Settings\All Users\Application Data\Microsoft\PlayReady on XP machines.  Rename the file mspr.hds to something else, such as mspr.hds.old (the file is recreated automatically).

Unfortunately, in this case, this solution didn’t work.  Probing further, I discovered that this problem only began occurring following the installation of a recent Windows Update (KB2636927).  To correct the issue, I was forced to uninstall Microsoft Silverlight and then reinstall an older version of the plugin until the problem is resolved on this machine.  I also had to hide this particular Windows Update to prevent it from reinstalling automatically!

Normally this is unadvisable as plugin updates most frequently provide security fixes and enhancements to the user’s machine, but in this case, there seemed to be no other solution.

If you’re experiencing this problem and you’re having trouble locating an older version of Silverlight to use, let me know and I can provide the installer!

Solution: AppleSyncNotifier.exe – “CoreFoundation.dll was not found”

AppleSyncNotifier.exe….This application has failed to start because CoreFoundation.dll was not found. Re-installing the application may fix this problem.

This is the frustrating startup message you may encounter if you have iTunes installed and you’re like many, many other unlucky people out there.  The suggested solution on Apple’s website is to reinstall some other related iTunes components (Apple Application Support and Apple Mobile Device Support).  Unfortunately, this hasn’t fixed the issue on any machines I’ve seen.

Instead, the foolproof solution is to uninstall MobileMe.  Odds are you don’t use it anyway, and getting rid of it fixes the years-old problem that Apple still hasn’t resolved.

By the way, while we’re on the subject of terrible Apple software, their Bonjour program/protocol is equally guilty of such problems.  Open up your Application Event Log (Start > Run > type eventvwr.msc and press ENTER) and look around.  See if you aren’t one of the very many afflicted by the errors that Bonjour inexplicably adds to the log. If you are, you’ll have a hard time missing them: there are generally many thousands of them, relentless, back-to-back.

All of this Event Log activity from Apple’s program, by the way, is nothing good for your PC’s performance or reliability.  The Event Log service is not meant to record so many duplicate errors so regularly.

Apple might make great Apple products, but I don’t think I’m alone in saying that their PC software (for one thing) is absolutely nothing special.

Change your router’s login information

As a bit of an extension from an earlier post, I’d just like to reiterate the importance of changing the default login information for your router (or your customers’ routers).  I’ve seen another uptick in DNS-Changer/DNS Hijack activity which includes the modification of router DNS settings to include malicious IP addresses, most of which hail from within the Russian Federation.

There is an easy way to correct this.  For starters, obviously, you need to ensure your router isn’t infected.  If the DNS settings have been changed, blank them out, then follow it up with a new username/password for your router.  It doesn’t need to be anything complex; even simply changing it to anything else will do the trick.  The malware responsible aren’t brute forcing the passwords or anything like that; they’re simply leveraging knowledge of the default login info for each router model to weasel their way into the settings and add their own DNS information.

It also goes without saying that all client PCs need to be clean before making the change, lest the settings will be reversed by any active malware on the network after you change them.  It is possible to change the login info first, and then blank out the DNS settings if you’re unsure which machine is causing problems and you just wish to prevent propagation of the malware/further information theft.  But this must be done from a clean machine.

Many ISPs will warn users if they’re affected by such DNSChanger infections.  By cleaning the malware off the PCs and checking the routers, you can ensure the problem is resolved.  However, there is one final setting to check:

HKLM\System\ControlSet001\Services\Tcpip\Parameters\\DhcpNameServer

This registry value will often be modified to include the same malicious DNS servers.  Be sure to check it on each machine, lest a clean machine can quickly become infected once again!

Solution: Can’t find script engine “VBScript” for script.

This is a problem I’ve run into probably 3 or 4 times, and each time, the solution is the same.  It’s a frustrating issue that can drive you nuts if you don’t know where to look to correct it.

Most solutions on the internet point to a bit of a dead end comprised of general-purpose advice for any sort of library-related problems in Windows.  They advise that you try the following commands at an elevated Command Prompt:

cd %windir%\system32
regsvr32 vbscript.dll
regsvr32 jscript.dll

Problem is, this never seems to work… at least, not on the machines I’ve worked on.

Fortunately, the real solution is comparably easy.  Open up regedit and check the following registry key:

HKCR\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32

Within it, there is a registry value called (Default) which should carry a Data value of:

C:\Windows\system32\vbscript.dll

If it says something else, you’ll need to change it to match the above.  This should fix your problem!

So what’s the reason for the bad value?  Nearly always, it’s thanks to a broken or partially uninstalled antivirus (the most common culprits are McAfee and avast!, both of which I’ve seen leave behind values in this key after an attempted uninstall).  AV programs use this value to redirect script processing through a driver of their own for filtering purposes so that they can check for suspect behavior.

“SafeBoot is corrupted (92h)” when McAfee Endpoint Encryption is installed

Here’s a rare example of a situation where I was actually very close to contemplating a reformat before finally stumbling across an idea which led to its resolution.

The client was an employee of a large company whose laptop hard drives (like many) are encrypted using McAfee Safeboot (Endpoint Encryption).  This is a great strategy for protecting against data theft in the event that the machine is stolen, but like all data encryption, any sort of problem whatsoever with regard to either data integrity or the encryption/decryption process can be potentially disastrous.

Since SafeBoot/EE is a boot sector encryption (“pre-boot authentication” it’s called) which applies to the entire storage volume, any problems relating to its boot partition information can completely break the entire system until either the information is repaired or the volume is manually decrypted.  Fortunately, McAfee provides a method for decrypting volumes offline using a special boot CD (called SafeTech/WinTech, depending on your version) and a rolling Authorization Code which changes daily.  Unfortunately, they only make these tools available directly to clients… meaning that us independent techs are completely out of luck, even if we have the decryption key (which the customer provided me).

While I was able to bypass the rolling Authentication Code by adjusting the system’s date to a specific day years back and using a code I found posted on an online forum, the built-in tools and even a SafeBoot Admin CD I located weren’t helpful in resolving the issue.  We had already tried contacting the IT department, who says they had no such tools at their disposal and that a reformat would be necessary.  Worse yet, my client was only in Louisville on a brief business trip, and there was data they needed on the encrypted volume.

The next morning, I had planned to contact the customer and suggest that we do just that: reformat.  But on a last-minute whim, I stumbled across an idea which could perhaps explain the strange behavior we were experiencing.

If you Google the Safeboot 92h error, you’ll find a variety of reasons why it can occur, and plenty of situations where it was never properly resolved.  Reverse-engineering the situation in my mind, however, led me to an important point which I had almost disregarded in the midst of my desire to quickly resolve the situation and return a working PC to my busy traveling executive: the possibility that malware had triggered the problem to begin with.

You see, the very first step I performed was a drive image of the encrypted data for safety.  And I had noticed that, throughout the course of the imaging process, no read errors/bad sectors had been encountered.  For surety, I even performed a hardware diagnostic subsequently, and no memory or hard drive errors were found.  This means that the encryption probably had not failed due to a hardware issue, and that instead, some sort of software was likely to blame.  Malware is the perfect culprit here; most notably, boot sector rootkits, which specifically alter the MBR and/or partition information of a victim’s machine to provide a filtering mechanism for the malware where it is also entirely undetectable.

One such rootkit you’ve already seen me write about in the past: Rootkit.Boot.Pihar.B.  It creates a hidden, encrypted partition at the end of a drive and sets it as the main Active partition, after which it chainloads the operating system partition (which is set as Inactive by the rootkit).  This effectively allows the rootkit to leave the MBR “clean” by storing all code in its encrypted partition and then loading the OS normally afterwards.  While this rootkit wasn’t currently detected as active on my client’s system (using an offline TDSSKiller run), after booting to a partition management software, I found that the hidden/encrypted partition was present.  And the OS partition, predictably, was Inactive.

It was just that simple.  Setting the OS partition as Active and then booting normally did the trick.  Following that, I had plenty of malware cleanup on my hands, most of it related to a rogue which had piggybacked on the rootkit.  This was a lot of fun since the machine’s Administrator restrictions and policies stood in the way, but in the end, the machine was repaired, all data was recovered, and my client was happy.  That is, until he returns to his hometown, where he’ll then request an updated Windows 7 machine to replace this dinosaur. 🙂

Solution: Remove startsearcher.com Google Chrome search hijacker

Today I encountered an irritating Google Chrome search hijack which wasn’t removable via the usual methods.  Attempting to remove the rogue search engine via the Chrome options menu simply produced a yellow bar at the top of the screen which read:

Some options are managed by your administrator.

Even completely uninstalling Chrome and removing the existing User Data folder under Chrome’s AppData directory didn’t fix the problem.

Shortly thereafter, however, I discovered another location where Chrome settings can be preset/mandated: the registry.  Specifically, two locations:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome

and

HKEY_CURRENT_USER\Software\Policies\Google\Chrome

The specific keys which needed deletion in this case were:

  • DefaultSearchProviderName
  • DefaultSearchProviderSearchURL
  • HomepageLocation
  • HomepageIsNewTabPage

I had to remove them from both registry areas.  But after this, the problem was gone.

If this post has helped you, please take a moment to leave a comment!

Solution: “Only part of a ReadProcessMemory or WriteProcessMemory request was completed”

If you’re encountering this error, you should first know that it refers to a memory access problem of some type.  The vast majority of scenarios where it occurs are during program installs or executions from an optical drive, and that’s what most of the internet offers as a solution.   To fix those problems, the solution is well-known.

When I ran into this problem, I was unfortunately more interested in everything not related to CD/DVD media.  Instead, it was occurring each and every time I attempted to execute an application on my client’s PC.

I checked the usual suspects, including file associations, IFEO (Image File Execution Options), and plenty of other items.  But in the end, it was a likely culprit: the client had previously had Kaspersky Internet Security installed (not a bad program by any means), but in an attempt to remove it, the process apparently failed.  This left some of its drivers behind, including some filesystem filter drivers which were preventing the execution of applications until Kaspersky okayed them.  Of course, since it wasn’t installed, that never occurred, and instead this message appeared.

To fix the problem, I ran a cleanup utility from Kaspersky’s web site and checked for stray drivers using a deep system scanning utility.  Following that, everything was peachy.