msphpsql: Faulting module name: ODBC32.dll

Hi all,

We are currently actively working on a fix for this issue. For now, we seem to have found the cause of this problem and we are hoping to have the fix ready in a preview release near the end of the month. Please stay tune.

A new release which should fix this issue is now available. You can download it from here, windows downloads available from here or here. Please let us know if the problem occurs again. Thanks!

@ezison The error you describe occurs because a transaction is started in Management Studio, and then a PHP script is run on the same table before the first transaction has been committed. When you commit this transaction:

begin tran;
update table_timestamp_t set last_updated_at = GETDATE()
where table_name = '0000000000679'
;

The PHP script will work as intended. I do not think this is related to the ‘Faulting module name’ error, which we are continuing to investigate.

Hi @yitam ,

Seems to be good for us after few install. Thanks a lot for your job @david-puglielli @yitam and others like me. Do you planned any release for that because front of customer, tag preview is not symbol to quality 😦

Regards

Thanks @yitam , we had the same problems (with php 7.2.9 and sqlsrv 5,3,0). With 5.4.0-preview our tests are all passing.

Thanks @bstoney and @yitam

We’ll try to launch our test suite and manual check asap.

Regards

Thanks @yitam , my tests are all passing with 5.4.0-preview. 👍

Thanks @dga26 for getting back to us. We suspect it’s a similar issue with the one reported by @bstoney above (also only happened with php 7.2*). We are planning to release a preview with the fix for that, so please stay tuned.

In the meantime, you might want to send us some typical queries that you run on a regular basis. That would help us investigate.

Thanks heaps @yitam, I will verify the fix as soon as the next preview is available. I really appreciate your efforts.

Hi @bstoney I could finally track exactly why it crashed – freeing a SQLHANDLE when it had already been freed earlier. However, the cause(s) remain unclear to me, and my suspicions are similar to what you said. Thanks for your input. Please stay tuned.

Hi @dga26 , I thought the original issue (executing an invalid query in a transaction) was fixed in 5.1.2-preview. Did you mean this version worked for several week and suddenly it didn’t work anymore? or this problem only occurs in 5.2-rc? If this problem is happening on 5.1.2-preview, I think this is a different problem than the original one. Would you mind providing us a repro script of what your customer tried to do? If this is only happening on 5.2-rc, then I will investigate what code was introduced in between that may cause this regression.

Thanks.

hi @dga26 according to your comment I believe this issue has been resolved?

Hi,

I upgraded PHP from 5.6 to 7.0.24 on my development machine today and have similar problem - PHP crashes randomly with following errors in Application log:

Faulting application name: php-cgi.exe, version: 7.0.24.0, time stamp: 0x59ca4206
Faulting module name: ODBC32.dll, version: 10.0.16299.15, time stamp: 0xb292589c
Exception code: 0xc0000005
Fault offset: 0x000364dc
Faulting process id: 0x9e8
Faulting application start time: 0x01d34b044d4fc72d
Faulting application path: D:\PHP7\php-cgi.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ODBC32.dll
Report Id: eb9c37e6-74a1-4484-87df-255e1525dd54
Faulting package full name: 
Faulting package-relative application ID: 

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: php-cgi.exe
P2: 7.0.24.0
P3: 59ca4206
P4: ODBC32.dll
P5: 10.0.16299.15
P6: b292589c
P7: c0000005
P8: 000364dc
P9: 
P10: 

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_php-cgi.exe_dffb76e7f6b9ba256ee96f3d2b66948b6d4d056_ef93abaf_199137a3

Analysis symbol: 
Rechecking for solution: 0
Report Id: eb9c37e6-74a1-4484-87df-255e1525dd54
Report Status: 4
Hashed bucket: 

There are only few SELECT statements on the page.

Apache/2.4.28 (Win32) OpenSSL/1.0.2l mod_fcgid/2.3.9 Windows 10 pro 64 bit PHP: 7.0.24 NTS Extension: php_pdo_sqlsrv_7_nts_x86.dll MS SQL Server Express 2014

Update: Same issue with PHP 7.1 No issue with SQLSRV driver (7.0, 7.1) at all

Hi,

(I work with @dga26 on this problem.)

for some more details, here is the pull request containing our change to ADOdb: https://github.com/ADOdb/ADOdb/pull/379

If I understand correctly, it seems that if our app (or a library as was the case here) retains a reference to a PDO statement, it sometimes happens that that reference / statement is garbage-collected after the PDO disconnection / garbage collection, and then the dll crashes.

I have no idea, do you think it would be possible to modify the pdo_sqlsrv driver (i guess) to avoid a crash when this happens?

Thanks a lot, nico

same issue here:

Faulting application name: php-cgi.exe, version: 7.1.7.0, time stamp: 0x595e6ac5
Faulting module name: KERNELBASE.dll, version: 10.0.15063.608, time stamp: 0x943cbf8b
Exception code: 0xc0000005
Fault offset: 0x0000000000069e08
Faulting process id: 0x739c
Faulting application start time: 0x01d3413b346f49c0
Faulting application path: C:\Program Files\PHP\v7.1\php-cgi.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 2c8a1298-9a12-41ba-a11a-c2b7640c7aef
Faulting package full name: 
Faulting package-relative application ID: 

Hi

good news !

after many tries … we succeed to reproduce with very simple code (not good code sure but 100% efficient 😉 )

Fails

When

<?php
$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:server=xxx;database=xxx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
    $myDb->query('SELECT CURDATE');
}
?>

Then

Faulting application name: php-cgi.exe, version: 7.0.20.0, time stamp: 0x5937200f
Faulting module name: ODBC32.dll, version: 6.3.9600.17415, time stamp: 0x545046b6
Exception code: 0xc0000005
Fault offset: 0x000028ee
Faulting process id: 0x1e28
Faulting application start time: 0x01d33b5aea70a424
Faulting application path: C:\PHP\php-cgi.exe
Faulting module path: C:\Windows\SYSTEM32\ODBC32.dll
Report Id: 285666f7-a74e-11e7-80ca-0050568c6901
Faulting package full name: 
Faulting package-relative application ID: 

Succeed with normal exception:

When :

<?php
$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:server=xxx;database=xxx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
    $myDb->exec('SELECT CURDATE');
}
?>

Then

Uncaught PDOException: SQLSTATE[42S22]: [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Invalid column name 'CURDATE

Succeed too with

<?php

$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:server=xx;database=xx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
	$stmt = $myDb->prepare('SELECT CURDATE');
        $stmt->execute();
}
?>

Regards

Sure i’m not using transaction as normal case but the error doesn’t raise correctly

Same here.

Brand new Server2012R2 with php7.1

Faulting application name: php-cgi.exe, version: 7.1.1.0, time stamp: 0x587fb655
Faulting module name: ODBC32.dll, version: 6.3.9600.17415, time stamp: 0x5450504d
Exception code: 0xc0000005
Fault offset: 0x00000000000034e1
Faulting process id: 0x1848
Faulting application start time: 0x01d2f4e1fd5ddfe4
Faulting application path: C:\Program Files\PHP\v7.1\php-cgi.exe
Faulting module path: C:\Windows\SYSTEM32\ODBC32.dll
Report Id: 3b6b879a-60d5-11e7-80c8-005056b53611
Faulting package full name: 
Faulting package-relative application ID: 

Same as above I had to downgrade to v 5.6 to make the pages work.

hi @Hadis-Fard, @ulvii

We are in our application using adodb (lens) to interface app and database plugged with pdo_sqlsrv driver. I remove all __destruct job and register_shutdown_function without success.

I cannot send you the whole application but i’ll try to minimize the code to reproduce a very special case…only reproducible by the interface with the same scheme

Thanks for your answers