SOLUTION: “Windows cannot connect to the printer. Operation failed with error 0x0000011b”

Well, it’s not often I bother to write up a new blog post these days, but when I do, you know it’s something particularly irritating that I’ve decided to save you the trouble of solving on your own. This problem absolutely qualifies.

When attempting to share a printer over the network from one Windows 10/11 machine to other Windows 10/11 machines, the above error now often appears.

Myriad “solutions” across the internet exist, most of which involve uninstalling particular Windows hotfixes (KBxxxxxx) or manually adding the printer port. Problem is, none of these solutions actually work anymore. The problem was initially caused by Microsoft’s need to patch PrintNightmare and other related vulnerabilities in the Windows printer subsystem. These workarounds previously sufficed, but some situations require a more surgical approach now. Because if you attempt to simply roll back the patches, not only is that a temporary solution, it actually winds up forcing an install of the generic Microsoft Enhanced Point and Print driver instead of the correct one for the printer… which results in endless pages of gibberish being printed instead.

So here’s the actual solution: manually configuring group policies on affected machines (both client and “server”). The way to accomplish this is by using registry edits, because on any machine not running “Pro” editions of Windows, the Group Policy editor is MIA.

After lots of trial and error, here is the final version of the registry patch I used on all affected machines (again, client and server/sharing machine) to correct the problem. Simply reboot after applying the patch, reinstall the printer (by discovering over the network via Windows Explorer > Network on the client workstations), and you’re done.

Open Notepad, and save a new .reg file with the following contents:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"InForest"=dword:00000000
"NoWarningNoElevationOnInstall"=dword:00000001
"Restricted"=dword:00000001
"TrustedServers"=dword:00000001
"UpdatePromptSettings"=dword:00000002
"RestrictDriverInstallationToAdministrators"=dword:00000000

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print]
"RpcAuthnLevelPrivacyEnabled"=dword:00000000

Then merge the changes with the local registry by double-clicking the new .reg file and you’re done. Needless to say, to reverse the changes, simply delete the new keys this adds (though there is no reason to do so).

Enjoy, and you’re welcome! 😉

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? “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.

SOLUTION: Microsoft Outlook 2013 hangs at “Loading Profile…” after Office Update

Now here’s an interesting conundrum.  A recent update to Microsoft Office 2013 that’s being pushed out automatically to clients results in some of them being unable to open Outlook 2013.  Instead of running normally, the program will hang at the “Loading Profile” stage of launch, as though the profile is corrupt (if you haven’t already checked this, it could actually be the case instead of course).  A workaround is to open Outlook using the well-known /safe command line switch; but this is merely a workaround (which in turn disables all add-ons), not a permanent solution.

For a much more reasonable resolution, try this instead:

  1. Run regedit (Start > Run > type regedit and press ENTER)
    1. On Windows 8, Win + R; type regedit and press ENTER
  2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common
  3. Right-click, select New > Key and name it Graphics
  4. Select the Graphics key you just created, right-click in the right panel and choose New > DWORD (32-bit) Value and name it DisableHardwareAcceleration.
  5. Double-click the new value and assign it a value of 1.
  6. Close regedit and try opening Outlook again.

This should fix the problem.  I first stumbled upon the solution when I realized that opening my TeamViewer Remote Support program while Outlook was loading kicked it into launching, which suggested either a network- or graphics-related cause (as TV affects both of those when launching).  The original solution listed here came from the Microsoft Office 2013 Issues Blog, though the symptoms listed are different from these.

Hope this helps! 🙂

Solution: Windows could not connect to the Group Policy Client service

Under specific circumstances, I’ve encountered this message following a reboot on systems I am repairing/setting up:

Failed to connect to a Windows service

Windows could not connect to the Group Policy Client service. This problem prevents standard users from logging on to the system. As an administrative user, you can review the System Event Log for details about why the service didn’t respond.

The System Event Log also logs an event regarding the service timing out.  When attempting to stop/restart/configure the service, none of the options are available; they’re merely greyed out, though the service is present.

The solution is pretty simple:

  1. Change the permissions on the relevant keys configuring the Group Policy Client service to allow Full Control to Administrators.
    1. Open regedit (Start > type regedit in the search box) and navigate to:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\gpsvc
    2. Right-click the registry key and choose Permissions.
    3. Click Advanced, then click Owner.
    4. Choose Administrators and check the Replace owner on subcontainers and objects box.
    5. Exit the permissions dialog and then open it again.
    6. Click Advanced, then choose Administrators and click Edit…
    7. Check Allow underneath Full Control, then click OK.
    8. Check Replace all child object permissions with inheritable permissions from this object.  Click OK and confirm; exit.
  2. Download the default gpsvc configuration information corresponding to your version of Windows:
  3. Back at the Registry Editor window, click File > Import… and choose the .reg file you downloaded above.
  4. Merge the changes with the registry.  Reboot.

Problem solved!

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.

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.

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!

STOP: c0000135 – The program can’t start because consrv is missing. Try resintalling the program.

Getting this error?  Wouldn’t you know, it’s actually the product of a nasty little rootkit called ZeroAccess MAX++ of which you might be familiar.  The particular variant that causes this error actually uses the consrv.dll file to ensure it is able to load at boot on 64-bit systems.  As such, among other items, this rootkit drops a file called consrv.dll into the %SYSTEMROOT%\system32 folder.  It’s the reference to this file in the registry which wreaks said havoc once the file is removed by any means (antivirus, offline deletion, etc.).

To rectify the problem, you will need to gain access to the %SYSTEMROOT%\system32\config\SYSTEM registry hive remotely (whether by Recovery Console’s regedit and the Load Hive… command or by booting to another operating system and loading the hive in similar manner) and change an entry modified by the rootkit back to its default value.

The infected machine will have a modified string (REG_EXPAND_SZ) data of the Windows registry value in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\SubSystems which looks like this:

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=consrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16
This value is wrong, and it’s the reference to consrv which is generating your c0000135 stop error.  Instead, change it to:
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

This will solve the problem and enable the machine to boot.  Please note that you should also modify the same value in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\… for completeness.

For a little more background/ancillary info, on the machine I was repairing which experienced this issue, the rootkit was accompanied by an additional MBR bootkit of the family Rootkit.boot.Pihar.a.  TDSSKiller actually took care of this one and restored the clean MBR.  In addition, plenty of other malware was along for the ride (all of it predictably hidden by the rootkit combo).  It was a nasty situation, but nothing I couldn’t handle. 😉
I hope you have found this case study useful.  Please let me know if it has helped you!

When Last Known Good Configuration fails

Sometimes when things go wrong, booting into Windows becomes difficult. As a tech, I often run into situations where the aftermath of an infection or a severe system file corruption prevents me from reaching the Windows desktop on a troubled PC.

My first step in such situations now is simple. I boot to a remote operating system of my creation, open up the system32\config directory, and copy the registry hive files to a backup folder inside of the config folder. The following files, of course, are the registry hives:

  • SAM
  • SECURITY
  • SOFTWARE
  • SYSTEM
  • DEFAULT

Once these files have been backed up, I navigate to any recent backup of the hives in the config folder (most often the one in the  RegBack subfolder will work) and simply copy those same files from that folder directly into the config folder. This essentially replaces the registry hives with older, working copies of those hives.

On XP machines, it’s a bit more complicated.  You’ll have to actually manually navigate into a restore point folder and copy the backup hives from there.  These are pretty easy to get to, however.  Look for the %SYSTEMDRIVE%\System Volume Information folder, and find a recently-dated _restore{GUID}RP#\snapshot folder inside it (the “RP” indicates it’s a restore point).  In this folder, simply copy the five hive files to the system32\config folder and rename them to match the hive files you removed above.

Generally, once this is complete, the PC is once again bootable. I highly recommend starting in Safe Mode next, however, as some of the drivers (whether filesystem or device) may not be accurately catalogued after this procedure. From there, repairs can be carried out to correct any remaining issues with startup applications or drivers.

It isn’t technically necessary to replace all of the hives to correct boot problems, but it’s good practice.

If you’re looking for computer help in the Louisville area, look no further.  Call me today and get it done right!