Home/ Questions/Q 6807287
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T19:48:49+00:00

I am developing an ADO application (32 bit) on Windows 7 64 bit SP1

  • 0

I am developing an ADO application (32 bit) on Windows 7 64 bit SP1 (all updates installed): The app must run on Win XP. According to http://support.microsoft.com/kb/2517589/en-us I am using msado60_backcompat. That worked well until lately, but now it crashes.

My code (snippets):

_CommandPtr cmd(__uuidof(Command));
cmd->ActiveConnection = dbconn;
cmd->CommandText = _T("SELECT [si] FROM [TTable] WHERE [TTable].[ti1]=?");
cmd->Parameters->Append(cmd->CreateParameter(L"@ti1", adTinyInt, adParamInput, 1, 7));

CreateParameter is implemented in msado60_backcompat:

inline _ParameterPtr Command15::CreateParameter ( _bstr_t Name, enum DataTypeEnum Type, enum ParameterDirectionEnum Direction, ADO_LONGPTR Size, const _variant_t & Value )
{
  struct _Parameter * _result = 0;
  HRESULT _hr = raw_CreateParameter(Name, Type, Direction, Size, Value, &_result);
  if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
  return _ParameterPtr(_result, false);
}

raw_CreateParameter() calls into msado15.dll into CCommand::CreateParameter. There a crash occurs at offset 0x34f (offset inside the function):

First-chance exception at 0x655ed5a6 (msado15.dll) in adosqlbugcheck.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Unhandled exception at 0x655ed5a6 (msado15.dll) in adosqlbugcheck.exe: 0xC0000005: Access violation writing location 0xcccccccc.

Msado60_Backcompat.tlb: 73728 bytes, 29.4.2011
msado15.dll: 6.1.7601.17514, 1019904 bytes, 21.11.2010

The error does not occur if I use msado15.dll.

Can someone reproduce the error? Is there a solution?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The issue is solved. I was #import-ing the msado60_backcompat.tlb from “C:\Program Files\Common Files”. If I import the version from “C:\Program Files (x86)\Common Files” it works. The compiler generates tlh files from both tlb files with exactly the same UUIDs and everything else, they only differ in that the one contains

    typedef __int64 ADO_LONGPTR; 
typedef ADO_LONGPTR PositionEnum_Param;

    While the other contains

    typedef long ADO_LONGPTR; 
typedef enum PositionEnum PositionEnum_Param;

    From my understanding of COM interfaces this should not happen. But since MS commits they really made a mistake it seems to just be the way it is.

    Just for information, MS has a new solution coming up: http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx.

    • 0