Search code examples
c#powershelldlldsofile

Exception calling .ctor with 0 arguments: Retrieving the COM class factory for component with CLSID {ID} failed. HRESULT: 0x80070005 (E_ACCESSDENIED)

Receiving this error when using Interop.DSOFile.dll functions and classes in powershell 5.1 (x86) running as a different user. The account I am using is an AD functional account which has full privilege to the folder containing the dll. I need to use this account as it has more access than my own AD account for the work required.

I am able to run the following code on my own user account without issue, but when attempting to use the functional account I get the error in the title.

[System.Reflection.Assembly]::LoadFrom('C:\Path\To\Interop.DSOFile.dll')

New-Object DSOFile.OleDocumentPropertiesClass

Which results in the error:

New-Object : Exception calling ".ctor" with "0" argument(s): "Retrieving the COM class factory for component with CLSID {58968145-CF05-4341-995F-2EE093F6ABA3} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))." At line:1 char:1 + New-Object DSOFile.OleDocumentPropertiesClass + CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvoca tionException + FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.Power Shell.Commands.NewObjectCommand

I checked that the CLSID exists and that I can see it using the functional account, and it is there:

gci 'HKLM:\SOFTWARE\Classes\CLSID' | ?{$_.PSChildName -match '58968145-CF05-4341-995F-2EE093F6ABA3'}

Property      : {(default)}
PSPath        : 
Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE
            \Classes\CLSID\{58968145-CF05-4341-995F-2EE093F6ABA3}
PSParentPath  : 
Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE
            \Classes\CLSID
PSChildName   : {58968145-CF05-4341-995F-2EE093F6ABA3}
PSDrive       : HKLM
PSProvider    : Microsoft.PowerShell.Core\Registry
PSIsContainer : True
SubKeyCount   : 2
View          : Default
Handle        : Microsoft.Win32.SafeHandles.SafeRegistryHandle
ValueCount    : 1
Name          : HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{58968145-CF05-4341-9
            95F-2EE093F6ABA3}

I've tried to use solutions from similar Stackoverflow questions that reference using Dcomcnfg.exe\DCOM Config to give the account access. Com+ Configuration

  • Go to Control Panel - > Administrator -> Component Services -> DCOM Config
  • Open Microsoft Word 97 - 2003 Properties
  • General -> Authentication Level : None
  • Security -> Customize all 3 permissions to allow everyone

I've also added the AD function account to my local Administrator group, with no success.

Solution

  • Thanks to Lieven Keersmaeker's procmon debugging suggestion I was able to solve the issue.

    The registered dll that was being resolved was located in an encrypted folder under my old AD Account folder (My AD sAMAccount recently changed). I found the dll in the registry, changed the path to a more accessible copy of this dll, and it works perfectly!

    Before this I did not know how to properly debug this problem, nor did I know exactly how dlls were resolved by windows. I assumed if the dll, dsofile.dll in this case, was in the same directory as Interop.DSOFile.dll that it would resolve the file in the same directory rather than reach out to the registry. I now know better.