[C/C++] 0x80004003 ADO application does not run on Windows Server 2008R2

Symptoms

Consider the following scenario. on a computer that is running Windows 7 Service Pack 1 (SP1) or Windows Server 2008 R2 SP 1 or that has KB9823246 installed, you recompile a Microsoft ActiveX Data Objects (ADO) application by using one of the following applications:

• Microsoft Visual C++
• Microsoft Visual Basic for Applications (VBA)
• Microsoft Visual Basic 6
• Microsoft .NET applications

In this scenario, you find that the application does not run on down-level operating systems. For example, it does not run on the release version of Windows 7, on Windows Vista, and on other earlier versions of Windows. Depending on your implementation, you also receive an error message that resembles one of the following. (You may receive other error messages.)

Error message 1

REGDB_E_CLASSNOTREG (0x80040154)

Error message 2

E_POINTER (0x80004003)

Error message 3

E_NOINTERFACE (0x80004002)

Error message 4

Unable to cast COM object of type 'System.__ComObject' to interface type 'ADODB.Connection'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00001550-0000-0010-8000-00AA006D2EA4}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).”

The following Visual C++ code segment replicates this issue.

#import " msado15.dll" no_namespace rename("EOF","EndOfFile")
 
int main()
{
  CoInitialize(NULL);
  _ConnectionPtr pConnection = NULL;
     HRESULT hr = pConnection.CreateInstance(__uuidof(Connection)); //hr gets E_NOINTERFACE here
}

The following Visual Basic for Applications code segment replicates this issue.

Private Sub Form_Load()
 Dim Conn As New ADODB.Connection ‘Runtime error here: Class does not support Automation or does not support expected interface
End Sub

VBA Error:Run-time error '430': Class does not support Automation or does not support expected interface

Note Microsoft no longer supports the primary interop assembly for ADO and no longer supports Visual Basic 6. For more information about Visual Basic 6 supportability, visit the following MSDN webpage:

Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7

For more information about the primary interop assembly for ADO supportability, click the following article number to view the article in the Microsoft Knowledge Base:

318559 Using the primary interop assembly for ADO (ADODB) in Visual Studio .NET

Cause

This issue occurs because some ADO interfaces were changed in Windows 7 SP1 to be associated with new instance identifiers (IIDs). The older IID interfaces were assigned the following suffix:

_Deprecated

For example, the interface _Connection was updated as follows:

• In Windows 7 and in earlier versions of Windows, the _Connection IID is 00000550-0000-0010-8000-00AA006D2EA4.
• In Windows 7 SP1, the _Connection IID is 00001550-0000-0010-8000-00AA006D2EA4, and the IID for _Connection_Deprecated is 00000550-0000-0010-8000-00AA006D2EA4.

If your application uses early binding to _Connection, the new IID is stored in the application binary during compilation. This causes an error when the application runs on a down-level operating system because the IID does not exist.

Some ADO APIs are platform-dependent in ADO 2.7 and in later versions. on 64-bit versions of Windows, these ADO APIs process arguments by using a 64-bit data type (such as the LONGLONG data type). However, applications that use these APIs still use the LONG data type. Therefore, you receive a "Type Mismatch" error message when you try to run the macro.

Resolution

To resolve this issue, install one of the updates that are described in the following article in the Microsoft Knowledge Base:

2640696 An ADO-based application that is compiled in Windows 7 SP1 or in Windows Server 2008 R2 SP1 does not run in earlier versions of Windows

More Information

A better solution for the Windows 7 SP1 ADO GUID changes

http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx