Today I spent some time working through a few issues with SharePoint and DCOM permissions.  Hopefully this helps another developer on a quest to solve this issue.

If you’ve found 0×80004004 then you are already pretty far along to the solution.  While testing calls to the List service in SharePoint using WCF for the client I received the following error from the List service which I captured by enabling tracing on my WCF client.

<soap:Fault>
    <faultCode xmlns="">soap:Server</faultCode>
    <faultString xmlns="">Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.</faultString>
    <detail xmlns="">
      <errorstring xmlns="http://schemas.microsoft.com/sharepoint/soap">Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT))</errorstring>
      <errorcode xmlns="http://schemas.microsoft.com/sharepoint/soap">0x80004004</errorcode>
    </detail>
  </soap:Fault>

Repeated searches on Bing and Google yielded nothing with a direct solution.  But I did find a few pointers that helped my quest.

Digging through program files\common files\Microsoft Shared\Web Server Extensions\12\LOGS I found log files with rows looking similar to this:

w3wp.exe (0×1718) 0×1418 Windows SharePoint Services General 8e2s Medium Unknown SPRequest error occurred.  More Information: 0×80004004

This confirmed the error, but wasn’t helpful.  However, the line just above that was slightly more revealing:

w3wp (0×1718) 0×1418 Windows SharePoint Services Database 6f8g Unexpected Unexpected query execution failure, error code 11.  Additional error information from SQL Server is included below. “[DBNETLIB][ConnectionWrite (WrapperWrite()).]General network error.  Check your network documentation.” Query text (if available): “{?=call proc_GetTpWebMetaDataAndListMetaData( [some values here] ) }

My immediate thought was, “ok, database permissions”.  I was able to locate the stored procedure in question as belonging to the Administration database (SharePoint_AdminContent).  I tweaked a few permissions to no avail.

The project architect suggested I try the same code against a different SharePoint instance.  Sadly, when I tried that the only problem I had to fight was getting the NTLM credentials to work using WCF and SSL.  Things worked flawlessly after that.

With the assistance of our IT pro, he found this article which discusses DCOM permission issues with SP.  Unfortunately we found ourselves unable to change the IIS WAMREG permissions until we found this article which helped us slay that problem.  After taking ownership of the appropriate registry key, we were able to change permissions on the IIS WAMREG DCOM component to allow the SharePoint WPG groups to have Local Launch and Local Activate.

Apparently this issue stems from how the local SharePoint install was configured.  Seems that many people run into this issue when trying to consume SharePoint services on a local machine.

After a reboot and an IIS reset the problem went away.  Sadly, my WCF client received a new error which I will cover in a future post.