• Repair ADOCB

    • This topic has 8 replies, 3 voices, and was last updated 12 months ago.
    Author
    Topic
    #2540456

    Hard time to decide whether this belongs under Office or Windows, but I decided to post here because the problem appears in Access 2019. Access VBA program had been working properly, then spontaneously developed the problem described in this article:

    http://www.fmsinc.com/microsoftaccess/errors/class_not_registered/index.htm

    It results in an error when trying to create an ADODB object. I’ve tried all the recommended repair and reinstallation advice without success, then started some detective work. First thing I noticed is that the folder containing the DLL file referenced by the ActiveX Data Objects (VBE > Tools > References) was completely missing (c:\Program Files(x86)\Common Files\System). Running SFC / scannow restored the System folder, and the msado15.dll file that it contains. However that did not fix the error.

    Then I looked through the Windows Registry (looking only, did not change anything), and found a key for ADODB.Command, which contains a value for CLSID. On a computer that does NOT exhibit the problem, this CLSID can also be searched for and found in the registry, and it contains a path to msado15.dll. However, the failing computer does NOT have registry entries for the CLSID.

    In other words, the failing computer’s Registry has an entry for the ADODB class, but it lacks an entry to the actual DLL file. My wild guess is that the missing CLSID key is what’s causing the problem, but what tool will repair that corruption??? Re-installing Access 2019 did not repair it.

    I spoke with MS Support, but they were no help and directed me elsewhere. I’ve posted this same question on the Microsoft Community forum.

     

    Viewing 3 reply threads
    Author
    Replies
    • #2541005

      Hmm… 20 hours without a reply. OK, I don’t have any Office apps that new (latest was 2010) but AFAIK the Microsoft method to repair is here: Repair an Office application.

      As far as I can tell, with Access 2019 you need to follow the route for repairing Click2Run apps.

      Note that if the repair is unsuccessful then the article advises using a specialised Office uninstall support tool and includes a link to it.

      (If the Microsoft advice doesn’t work then post back. It’s not straightforward but I can advise how to use the registry to perhaps fix the issue.)

      Hope this helps…

      • #2541056

        I appreciate the response, but no joy. Turns out that the Office Uninstall tool was already in my downloads folder, but was not aware of it. Unfortunately, it was no more successful than the standard Uninstall process.

        Then it occurred to me that a Registry Cleaner might be the answer. Tried CCleaner and Restoro, both highly rated, but neither of them deleted the keys that look corrupted to me. Maybe I’m misinterpreting their state.

        Feeling like I could not do no more harm, I tried to manually delete the suspect Registry keys, but Windows responded with an error message that they cannot be deleted. Next step, install another program that purports to grant special permissions that allow stubborn keys to be deleted. Nope… still unable to delete them.

        At this point it looks like I either live with the inability to use ADODB at all (which is not that big a deal to me) or re-install Windows (an unpleasant task, to say the least).

      • #2541059

        Rick – I reread your part about posting back for advice about the registry just after responding to JoeP. I would welcome your advice.

         

    • #2541047

      You can use Regedit to create the key. Run Regedit on the PC which is OK. Find the key and export it to a file. Copy the file to the PC which is failing and import it using Regedit.

      --Joe

      1 user thanked author for this post.
      • #2541058

        Yes, that thought occurred to me as well, but it feels like going down a path that we are always warned about with mucking around in the Registry. I am not confident that I understand the Registry with enough detail to make the kind of changes that would be necessary. There are many individual keys, and many instances of each item, and probably lots of opportunity to get it wrong.

        I appreciate the input.

         

    • #2541060

      I tried to manually delete the suspect Registry keys, but Windows responded with an error message that they cannot be deleted. Next step, install another program that purports to grant special permissions that allow stubborn keys to be deleted. Nope… still unable to delete them.

      The CLSID sub-key of ADODB.Control is in HKEY_CLASSES_ROOT and has permissions set so *only* the TrustedInstaller account has Full Control. As the following screenshot shows, even members of the Administrators group don’t have ‘write’ or ‘delete’ permissions by default:

      hkcr_permissions

      It’s OK to export the CLSID key from the ‘good’ machine because that’s just a ‘read’ operation. However, to merge the exported .REG file into the ‘bad’ machine you’re going to have to resort to some jiggery-pokery.

      I *never* use any methods of taking ownership of registry keys. It’s doable but you cannot change ownership back to their defaults effectively because their security tokens are changed forever by changing ownership. IMO it’s a one-way street with no return.

      Instead, I’ve used Nir Sofer’s AdvancedRun to run regedit.exe under the context of TrustedInstaller to do similar (though, as per the screenshot, note that the ‘user’ will show as SYSTEM).

      regedit_ti

      You should then be able to use File > Import to merge the .REG file from the ‘good’ machine successfully.

      Hope this helps…

       

       

      1 user thanked author for this post.
      • #2541113

        Rick and Joe – you guys rock!!!! Success.

        To summarize my convoluted path. I was nervous about making wholesale changes to the Registry, so I made a System Backup. I was not confident that I would catch all the necessary keys from the “good” machine, so my first approach was to delete the top-level keys from the “bad” machine and go thru the Office installation. I hoped that it would repair the missing components, but it did not.

        So I did System Restore, and worked with the exported subkeys from the “good” machine. Happily, double-clicking the .reg files is sufficient to merge their contents, without the need of the NirSoft program. Total of 21 .reg files later, I opened Access and successfully opened the previously-broken form. Woo hoo!

        Thank you both for your help.

         

         

    • #2541063

      There are many individual keys, and many instances of each item, and probably lots of opportunity to get it wrong.

      If you only export the ADODB.Control’s CLSID sub-key from the ‘good’ machine and merge it into the ‘bad’ machine then, even if it doesn’t solve your issue, you will only have amended one sub-key and its contents.

      For a ‘belt and braces’ approach, export the same CLSID sub-key on the ‘bad’ machine first, before merging the .REG file from the ‘good’ machine. That way you can, if necessary, re-merge the export from the ‘bad’ machine and get back to *exactly* the same point as when you started.

      Hope this helps…

    Viewing 3 reply threads
    Reply To: Repair ADOCB

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: