A step-by-step procedure for fixing Error accessing the System Registry in MS Office VBA, Tools, References [Office 97 - 2016, Windows 7-10]

Introduction

• Repairing the fault took less than 10 minutes. 
• The solution was to alter access to a Registry key. 
• The fix itself is in section 4.3 step 16 and it takes less than a second. 

The fault & its repair procedure apply to Office 97, 2007, 2010, 2013 & 2016 running in Windows 7 32-bit & 64-bit, Windows 10 32-bit and in Windows 2008 Terminal Server. 

• The fault & its repair procedure might also apply to Windows XP, Vista & Windows 10 64-bit but no relevant user reports have been received for those OSs. 

I have tried to make this procedure suitable for those without any specialist skills. 

• Whilst it all looks pretty daunting, I believe that this repair can be carried out by any user who is prepared to work carefully through each part step by step.
• I have broken the procedure down into small individual steps in the hope of minimising confusion & avoiding mistakes.
• In several stages of the procedure, you will see instructions to jump forward or backwards depending on the results of a question or system check.  This probably makes the whole thing look even more complicated.
• All I can say to excuse this structure is that I designed it to be able to cope with the myriad initial conditions & interim test results that might apply and to help you avoid the confusion & the dead-ends that I encountered when I first tried to work my way through this.
• Every jump forward or back has been doubled-checked several times.
• A couple of dozen users have already completed this procedure.
• I have personally worked my way through this procedure three times -
  • Once when I had the additional tension of a fault condition that I had to correct,
  • Once again after I had finished recording the procedure for future reference to make sure I had made no mistakes in documenting it, and
  • Yet again after I had published it in a forum thread for others to use so that I could be confident I was not misleading anybody or wasting their time. 

I originally published this procedure in this forum thread.  All user feedback up to December 2016 has already been incorporated into this forum article.

1              First appearance of the fault symptoms

In an MS Office 2007, Excel, VBA window attempts to open the Tools, References entry were rejected with an error message stating that there had been an Error accessing the System Registry. 

The same fault was evident in all the VBA-capable MS Office 2007 applications that had been installed & had previously operated correctly - Excel, Access, Outlook, Word & PowerPoint.

I found a note that indicated that I had last opened the Tools, References entry a month ago.  There had been no Registry access error then or at any other time before today.

No changes of any known significance had been made to the system during the period.

The computer was a Dell Inspiron 1545 running Windows 7 Home Premium x64 & Office 2007. 

2              Aim

My aim was to fix the fault without running the risk of causing other faults.

3              My own fault investigation

3.1           Initial tests

The fault was also apparent in Safe Mode and was therefore either a Windows or an Office fault.

The error message had suggested re-installing the host application.  Office Diagnostics found nothing wrong.  Users in other threads [see section 3.3 below] reported that re-installing Office had had no effect i.e. the fault survived after re-installation.  It therefore seemed more likely to be a system fault and not an Office fault at all.

The fault happened in a Standard user account.  An existing Admin user account had no error.  A new Standard user account & a new Admin account both had the error.  I therefore dismissed any notion that the fault was a symptom of user profile corruption.

SFC reported no errors so non-configurable protected system files were not corrupted.

This all pointed to a Registry access fault as being a probable cause of the error i.e. the fault was exactly what the error message had said it was. 

3.2           A Microsoft Knowledge Base article

Microsoft published a KB article PRB: 'Error Accessing the System Registry' Message When Displaying VB/VBA References KB269383 in 2004.

The fault was the same as that described in the article.  It explained the fault as a symptom of a lack of user access to the Registry key[s] concerned.  The article ascribed the cause of the fault to a specific application installation, an application that I did not have, but I decided that the article was nevertheless relevant because it identified the fault symptom precisely.

The MSKB article suggested checking for any dimmed Registry keys within HKEY_CLASSES_ROOT\TypeLib\{...} & HKEY_CLASSES_ROOT\CLSID.

I looked at the Registry but found no such dimmed entries.  However, I now think that I failed to appreciate the significance of my personal habits in regard to this step.  I always run RegEdit as Admin but I had already established that the Admin account did not exhibit any fault.  Had I opened RegEdit with only the permissions of one of the accounts inflicted by the fault then I might have been able to identify the faulty key straightaway & could then have skipped straight to the recovery procedures at sections 4.1 (9), 4.2 & 4.3 step 9 below.  I have incorporated appropriate checks in this procedure.

The article suggested using SysInternals RegMon as an alternative means of identifying the faulty Registry key[s].  Note that RegMon has since been replaced by ProcMon.  Additionally, I subsequently discovered when using ProcMon that other details of the article’s recommended procedure are also out-of-date [the MSKB was nine years old when I found it so that’s fair enough].  I took account of the necessary changes when developing this procedure.

I took note of the MSKB article’s suggested permissions for different types of user:-

•     System - Full control
•     Administrators - Full Control
•     Users - Read
•     Everyone - Read

I made no further direct use of the MSKB article. 

3.3           Reports from other users

I searched the MS Community forums for useful reports.  In for none administrative user cannot open references dialog from tools menu visual basic window, a user reported the same fault.  Re-installing Office had not cured the problem.  No solution was offered but a workaround of always using an Admin account was. 

• The workaround of always using an Admin account could be an effective one in the short term as any required changes to Tools, References could be done in an Admin account & then the files themselves could be copied to each user. 
• Whilst Tools, References settings are file-specific, they could be extended to all users by setting them in a common template file [for Excel 2007 on a Windows 7 x64 computer, for example, this would be C:\Program Files (x86)\Microsoft Office\Office12\XLSTART\Book.xltm]. 
• However, any new Admin accounts in the future would be afflicted by the fault - all accounts [including Admin accounts] can suffer from user profile corruption and can therefore need to be replaced. 
• Avoiding permanent fault rectification would therefore be a risk.

I googled the fault symptom Error accessing the System Registry and found several other reports that re-installing Office had not cured the problem.

I found a relevant thread in VBForums [RESOLVED] Sudden "Error accessing the system registry". 

• At least one user described fixing the fault by adjusting some display settings [in Windows XP] but these posts were not particularly persuasive.  For example, display settings should not affect Registry permissions and disabling desktop composition is a setting for each application [Properties, Compatibility tab, Disable desktop composition] rather than for the system as a whole.
• However, one 2009 post identified an application [iTunes] as having caused the same Registry key access fault as had been identified in the MSKB reviewed in section 3.2 above.  The post also contained useful guidance for the recovery procedure itself [see section 4 below].

I found another relevant thread Error accessing the system registry in Office VBA Editor. 

• I discounted all suggestions about running Registry “cleaners” as my aim was to fix the fault without running the risk of causing other faults.
• The user KJW reported the same fault symptoms [with Office 2010] including the same mix of correct & faulty behaviour in existing & newly-created user accounts.
• KJW successfully fixed the fault. 
• KJW’s posts displayed competence, diligence & a logical approach to problem-solving so I had confidence in the solution KJW proposed. 
• KJW’s proposed solution was consistent with the MSKB article already reviewed in section 3.2 and it contained useful additional guidance for the recovery procedure. 

4              The recovery procedure

4.1           Preparations

You are about to edit the System Registry.  Mistakes in doing so can cause a system to become unstable, unpredictable or even unusable.  Appropriate Registry back up instructions have been provided within the relevant stages of the procedure.

Where I have used “recent” in this section, I chose to include the whole 5-week period since I had made the system image that preceded my last recorded successful use of the Tools, References entry.  As it turned out, I did not have to revert the system back in time at all - fixing the fault did not require restoring from any system images but my preparations ensured that I was ready to do so if necessary.

(1)  Back up your own files & any recently downloaded installation files. 

(2)  Make screenshots of recent installations & updates in Control panel, Programs & features. 

(3)  Make screenshots of recent Windows Updates in Control panel, Programs & features, View installed updates. 

(4)  If you use WMP, consider making screenshots of WMP’s recent Date last played entries.  These settings would be reset to the values that they had had on the day that any restored system image had originally been made. 

(5)  Have a look around the computer and make notes about recent system & application changes. 

(6)  Make a new system image so that you can at least get back to square one if your attempts to fix the fault make things worse. 

(7)  Check that you have a working & recently tested System repair disk, Windows 10 Recovery drive or Windows installation disk from which you could boot to initiate a restore from system image procedure if the system becomes completely unusable. 

• If you don’t have either of these disks then make a System repair disk using the link given on the left-hand side of the Windows Backup opening screen or by using a downloaded System repair disk ISO [if they are still available when you read this article].
• If you use Windows 10 then you can make a Recovery drive or you can make an installation disk [USB/DVD] using the Media creation tool

(8)  If you have not previously tested your System repair disk, Windows 10 Recovery drive or Windows installation disk by booting from it then do so now to make sure that it works.

(9)  Check which accounts are afflicted with the fault by opening each of them in turn and then trying to access the Office application’s VBA window, Tools, References entry.  Note especially which Admin account is clear of the fault as that account will be needed to give Admin permission to run the Registry Editor in section 4.3 step 3 below.

4.2           Additional preparatory steps required if all Admin accounts are afflicted with the fault

If a single Admin account exists that is not afflicted with the fault then that Admin account can be used to give permission for the relevant steps of the recovery procedure in section 4.3 below so, if that is the case, proceed straight to that section.

However, if all Admin accounts are afflicted with the fault then a higher authority will need to be used to run the Registry Editor.  That higher authority is the System and it can be invoked using the SysInternals PSExec utility which is part of the PSTools suite.

Please do note that in the following steps, I have made no reference to setting the system Path.  You will have seen such a step referred to in other recommended procedures for using PSExec.  My steps 2 - 5 [below] sidestep the need to alter the system Path.

Step 1  Download SysInternals PSTools & extract the PsExec.exe & Pstools.chm files from the downloaded zip file into any convenient folder such as the Desktop. 

Step 2  Open an Admin Command prompt window

[Windows 7] Type cmd in the Start menu search box, right-clicking on the cmd.exe shortcut that is offered, selecting Run as Admin. 

[Windows 10] Go to Start menu, Windows system, right-clicking on the entry Command prompt, More, Run as Admin.

Step 3  Enter cd followed by a space then the full path to the folder into which you have extracted the PsExec.exe file.  The command therefore takes the form

                    cd “C:\Users\YourUserName\Desktop”. 

Step 4  Check that you are in the correct folder by entering dir and checking that PsExec.exe is listed in the results.

Step 5  In the Command prompt, enter the following command to run the Registry Editor with System permissions.  If your Windows installation is in a different folder [i.e. not in C:\Windows] then you will need to substitute its folder path in the command.  You can, if you wish, check the significance of each part of the command by looking in the PSTools Help file Pstools.chm.

                    psexec -i -d -s c:\windows\regedit.exe

Step 6  After entering this command, you will need to accept the SysInternals Terms of use to allow the command to be processed & you should then close the Command prompt window as you will have no further need of it.

Step 7  With the System-controlled Registry Editor now open you can briefly review step 8 below and then proceed to the recovery procedure in section 4.3.  Bear in mind throughout the rest of the procedure that you are controlling the Registry with the highest permissions and that there is nothing to stop you completely messing up your computer.

Step 8  Note that you will have to manually find & select the Registry key identified in section 4.3’s Step 8 because the ProcMon utility used there is unable to Jump to… entries in a System-controlled Registry Editor.  You will be referred back to this step to do this when relevant.  To manually find & select a Registry key identified by ProcMon:-

• In ProcMon, with the appropriate entry still selected in the filtered results,

• right-click on that entry & select Properties… then look at the Path property.  Leave that dialog open as you will refer to it again in a moment.

• In the Registry Editor, select the key HKEY_CLASSES_ROOT & click on the dropdown arrow to its left.  Note that the list of entries is alphabetical but it can be a bit confusing as some entries begin with full stops [for example, .386] whilst others have full stops in the middle [for example, Excel.Sheet].

• Scroll down to & select TypeLib or CLSID [as shown at the start of the ProcMon entry’s Properties…, Path property],

• check that the Registry Editor Status bar at the bottom of its window or, for Windows 10 Ver 1703, its address bar at the top, confirms that you are in HKEY_CLASSES_ROOT\CLSID or HKEY_CLASSES_ROOT\TypeLib as intended [and have not been side-tracked into a sub-key such as HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{…..}\Typelib].

• Back in ProcMon’s Properties…, Path property select the whole of the key string in curly brackets [such as { 57A0E746-3863-4D20-A811-950C84F1DB9B}] and press Ctrl-c to copy it [it doesn’t really matter whether you include the curly brackets themselves or not].  You can now close that dialog since you will not need to refer to it again.

• Back in the Registry Editor, press Ctrl-F [or click the Edit menu’s Find entry], clear the checkboxes for Values & Data [leaving just that for Keys], click in the Find what entry box & press Ctrl-v to paste in the key string & then click Find next.

• Double-check in the Registry status bar / address bar that you are where you think you are.  Every letter, digit & full stop in the address is significant.

• You have now manually selected the Registry key identified in section 4.3’s step 8 so you can now return to that stage of the procedure.

4.3           Identify & fix Registry key permissions

I had not previously used the utility that was needed here, SysInternals ProcMon.  I went around in circles a bit at first before I got the hang of it.  The procedure I have described below avoids the pitfalls that I experienced.

Step 1  Download SysInternals ProcMon & extract the files from the downloaded zip file into any convenient folder.  Don’t open the files yet.  Note that ProcMon is a “portable” utility so it does not need to be installed, it is started simply by double-clicking on it & giving Admin permission for it to run - but don’t start it yet.

Step 2  Log in to one of the user accounts that is afflicted by the fault, open Excel, click on the Developer tab & open the VBA window. 

Step 3  If you had to follow the additional preparatory steps in section 4.2 above then your Registry Editor will already be open.  If not then open the Registry Editor with Admin permissions now -

[Windows 7] Enter regedit in the Start menu search box, right-click on the regedit.exe shortcut that is offered, select Run as Admin. 

[Windows 10] Click on the Start button, type regedit, right-click on the regedit.exe shortcut that is offered, select Run as Admin. 

Note that you will have to use an Admin account that is not afflicted with the fault to give this permission - see the results of your preparatory checks from section 4.1 (9) above.

Step 4  Start ProcMon & give it Admin permission to run.  Click on its Filter menu then select Filter… to display its Process Monitor Filter dialog.  Set up the following three filters:-

(1)  Click on the top-left button [which displays its Architecture entry when you first open it] to reveal its dropdown list & select Process Name.  In the entry box [the box with the clear white background], click on its dropdown list arrow & select excel.exe then click on the Add button to add this filter.

(3)  Click on the top-left button again & select Result.  In the main entry box [the box with the clear white background], type access denied then click on the Add button to add this filter. 

(2)  Click on the top-left button again & select Path.  Click on the button next to this [the button that currently displays is] & select begins with.  In the main entry box [the box with the clear white background], type HKCR then click on the Add button to add this filter.

Step 5  Click on OK to apply the filters & return to the main window.  Nothing will appear in the results’ list yet as Excel hasn’t done anything relevant since you started ProcMon.

Step 6  In Excel’s VBA window - click on Tools, References then click OK in the error message in order to accept it & close the dialog. 

Step 7  Return to the ProcMon window, select the final entry in the filtered results.  Another user has reported that ProcMon does not sort the entries reliably so you will need to read the times of all the entries to decide which is the final one.  I did not experience this sorting problem so I do not know if there is a better response to it - none of my original printouts or screenshots indicate any sorting issues. 

Step 8  Select the appropriate Registry key by one of these two methods then return to this procedure.

- If you were able to run the Registry Editor using a normal Admin account [in step 3 above], then right-click on the selected ProcMon entry & select Jump to…  The appropriate Registry key will be selected in the Registry Editor window. 

- If you have had to run the System-controlled Registry Editor using the procedures in section 4.2 then you need to find & select the appropriate Registry key manually using the procedure given in section 4.2 step 8.

Step 9  In the Registry Editor - create a permanent record of the contents of the key by right-clicking then selecting Export, browsing to a convenient folder, selecting save as type

- Reg, which you can read in Notepad by right-clicking on it and selecting Edit, and

- [optionally] Text, which you can read by double-clicking on it to open it in a Notepad window

then entering a suitable file name & clicking Save.  

• Personally, I find the Reg format much easier to read & comprehend than the txt version. 
• If you accidentally double-click on a Reg file when you intended to just read it, you can bail out straightaway at the confirmation dialog that appears.
• If you need to stop the procedure and start again, you can double-click on the Reg file to restore that Registry key [that Registry section] to its original state.  
  • Doing this is called merging rather than running the Reg file because you are merging its contents with the contents of the other Registry keys. 
  • You cannot restore a Registry key using the exported text file, only the Reg file.

Step 10  Right-click on the selected key again, choose Permissions… then click on the Advanced… button.

Step 11  Note that if

(1)  the Registry key is greyed out & cannot be selected, or

(2)  the right-click Context menu does not appear, or

(3)  the Permissions… entry of the right-click Context menu is greyed out, or

(4)  the Registry Editor refuses to allow you to access & change permissions on the relevant Registry key during steps 12 - 18 below

then you will need to close the Registry Editor & re-open it with System permissions using the procedure given in section 4.2 above. 

Step 12  Select the Effective Permissions tab. 

Step 13  Click the Select… button.  Enter the user name of the account you used to run Excel i.e. the account for which Registry access is being denied.  Click the Check names button then click OK to list the account’s permissions.  Scroll down to the bottom of this list & you will see that there is no tick in the checkbox for Read control.  You can repeat this check for all the users who are afflicted with the current fault.

Step 14  You can also click the Select… button again & type authenticated users.  Click the Check names button then click OK to list this account group’s permissions.  Scroll down to the bottom of this list & you might see that there is no tick in the checkbox for Read control showing that no members of the group have Read control. 

• The term authenticated users refers to all users who have an account on the computer that they have to log in to and includes both Admin & Standard users i.e. all the people who might need to use MS Office & set up new VBA procedures.
• The term authenticated users excludes Guest users.  This type of account is normally disabled these days anyway.

Step 15  You can now decide whether to add Read control permission for each of the specific user accounts that are afflicted with the current fault or to add the permission for all authenticated users in one go [which is what I chose to do].  By applying the permission to authenticated users, any additional user accounts you might create in the future will automatically be included.

Step 16  Select the Permissions tab & click the Add… button.  Enter the chosen user name[s] or the group name authenticated users.  Click the Check names button then click OK to list account permissions.  Look at the bottom of this list, tick the checkbox for Read control then click OK. 

Step 17  You can now select the Effective Permissions tab again & repeat the checks in steps 13 & 14 to confirm that Read control has now been given to the user account[s] concerned. 

Step 18  Close the Advanced Security Setting dialog by clicking OK then close the Permissions dialog by clicking OK. 

Step 19  In Excel’s VBA window - click on Tools, References to confirm that you now have access to these selections.  If the fault remains then return to step 7 & start working through the procedure again but, instead of selecting the final entry in the filtered ProcMon results, select the entry above that one.  If you fail this step 19 again then step up another line in the filtered ProcMon results & continue looping through the procedure until step 19 is successful or you run out of filtered ProcMon results to select.  If it is any encouragement, my problem was solved on the first run through this procedure & many of the others who have used this procedure found the same i.e. the fault was rectified by fixing just that final filtered ProcMon results key.

Step 20  Close the VBA window & then Excel.  Close ProcMon & the Registry Editor.

Step 21  Using Notepad, read the Text or Reg file[s] you created at step 9 above and review the details of each Registry key for which you had to set up Read control permission. 

• For each Registry key [i.e. each file made], identify the responsible application using the information provided about its name & its file path [in my case, it was a Flash Player update about a week earlier]. 
• Make sure that you do not update any application identified as being responsible for the fault until you have made a new system image. 
• After any such updates, return to Excel & access the VBA, Tools, References list again just to make sure that the fault has not been re-created. 
• The update that caused my problem was updated again after the fault was fixed and it behaved itself this time.
• I continued using the same OS & Office 2007 installation on the problem computer for three years before upgrading to Windows 10 and the fault never re-occurred.

Step 22  To confirm that the fault has been fixed for each user account on the computer, you can open each account in turn then open Excel & access the VBA, Tools, References list. 

Step 23  Make a new system image.