Details
- 
    Bug 
- 
    Status: Stalled (View Workflow)
- 
    Minor 
- 
    Resolution: Unresolved
- 
    3.1.0
- 
    None
- 
    None
- 
    Windows Server 2012R2 X64
 ODBC 64-BIT 3.1 RC
Description
I still need to develop a test case, but when switching from the 32-bit to 64-bit driver I'm getting access violation exceptions in ntdll.dll.
| Unhandled exception at 0x00007FFE33F07A3D (ntdll.dll) in SQLDmpr0005.mdmp: 0xC0000005: Access violation reading location 0x000000914B66E004. | 
| The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
 | 
Stack trace from Visual Studio debugger:
| >	ntdll.dll!CountUnicodeToUTF8()	Unknown | 
|  	KERNELBASE.dll!WideCharToMultiByte()	Unknown | 
|  	maodbc.dll!MADB_ConvertFromWChar(const wchar_t * Wstr, long WstrCharLen, unsigned __int64 * Length, st_client_charset * cc, int * Error) Line 145	C | 
|  	maodbc.dll!MADB_Wchar2Sql(st_ma_odbc_stmt * Stmt, MADB_DescRecord * CRec, void * DataPtr, __int64 Length, MADB_DescRecord * SqlRec, st_mysql_bind * MaBind, void * * Buffer, unsigned long * LengthPtr) Line 342	C | 
|  	maodbc.dll!MADB_ConvertC2Sql(st_ma_odbc_stmt * Stmt, MADB_DescRecord * CRec, void * DataPtr, __int64 Length, MADB_DescRecord * SqlRec, st_mysql_bind * MaBind, void * * Buffer, unsigned long * LengthPtr) Line 691	C | 
|  	maodbc.dll!MADB_ExecuteBulk(st_ma_odbc_stmt * Stmt, unsigned int ParamOffset) Line 373	C | 
|  	maodbc.dll!MADB_StmtExecute(st_ma_odbc_stmt * Stmt, int ExecDirect) Line 1112	C | 
|  	maodbc.dll!SQLExecute(void * StatementHandle) Line 1347	C | 
|  	[External Code]	
 | 
I can cause the issue reliably from the integration package I have, but am still trying to build a test case.
Attached is the windbg ! analyze output from the minidump if it'll help.
Edit: still no luck developing a test case for this one. Works fine with the 32-bit driver, but crashes with the above in 64-Bit, which suggests maybe type related difference between the builds? Only other thing to mention is that there is 20 threads running when this crash occurs.
Edit2: Nothing to do with the threads. Seems to the mediumtext field. See first comment below. Added updated WinDBG analyze results and the ODBC Trace.