Devart Forums

At the moment we could not reproduce the issue. If you create and send us a small test project with corresponding DDL/DML scripts which reproduces the issue, it would great help in the issue research.

If your project has a size of several megabytes or more, you can archive your project and upload it to our ftp server ( ftp://ftp.devart.com/ , credentials: anonymous/anonymous ) or to any file exchange server so that we could download it from there. You can send us the password to the archive via our contact form.

We are also having this issue at one of our client sites. We have not been able to successfully reproduce the issue in-house.

Is there any update on the status of this issue or its causes?

Unfortunately, the situation is not changed. Without an example that consistently reproduces the issue we cannot move forward and find out the reason of the issue.

Please check your IIS settings:
https://forums.iis.net/t/1216179.aspx
https://weblogs.asp.net/owscott/windows ... ests-limit

We have already reviewed the IIS settings related to concurrent connections. Doubling those settings only delays the time before the deadlock (i.e. freezing of the web server) occurs.

We have traced the root of the issue down to the DevArt driver and need assistance from your engineering team to troubleshoot the issue at our client site.

We believe that connections in the pool are somehow becoming corrupted or invalid. Is there a way we can monitor or look into the connection pool and inspect the transactions?

We do not currently have the option of validating the connection before use because that causes a significant degradation in performance.

As mentioned in this topic previously, the issue is reproduced only when IIS is used. It means that the freeze occurs not because of some error in pooling implementation, but because IIS has such behavior with threads. https://forums.iis.net/t/1216179.aspx - IIS has an issue with .NET Lock. We are using .NET Lock in our pooling, and IIS has an issue with .NET Lock.

Thank you for the information.

We recently upgraded the Devart dotConnect driver in our software from version 6.80.350.0 to 9.3.230.0. Once we deployed the latest version of our software to our client, they started to see the server freezes with regular frequency, with some web servers freezing multiple times in a day.

Were there significant changes related to how pooling is done between these 2 versions of the software? Could there be some configuration that, while working against 6.8 would cause issues against 9.2?

We will look further into this ourselves while we await your next response.

About 5 years passed between the releases of dotConnect for Oracle 6.80.350 and 9.3.230. It's hard to find out which of the changes can be the reason of it. If you find the latest dotConnect for Oracle version, with which your app works, so that it fails with the next public version, we will study all the changes made between these versions that may cause the dead lock in a pool.

Thank you for your response. Unfortunately, this is not an option at this time, due to the fact that our client has upgraded to Oracle 12. Our understanding is that many older versions of the dotConnect driver do not support Oracle 12.

We are planning to gather hang dumps of the hung w3wp process. Would your team be in a position to assist us in reviewing those dumps?

You can send the hang dumps to us and we will study them. But we warn you in advance that dump may contain sensitive information (like passwords, etc.), so we don't recommend you to do it. Besides, dumps are not always helpful for finding out the reason of the issue.

Today we were troubleshooting one of the client's web servers that had become non-responsive. When we launched DBMonitor, it failed to attach to the w3wp.exe process and displayed no data at all. Once we recycled the app pool, DBMonitor was able to attach to w3wp.exe and started displaying diagnostic data.

Can you help me understand how DBMonitor attempts to communicate with w3wp.exe? This may aid in our troubleshooting. Thank you.

We captured a hang dump of the w3wp.exe process today. Analysis of the dump led us to find this deadlock:

0:000> !sosex.load
0:000> !dlk
Examining SyncBlocks...
Scanning for ReaderWriterLock(Slim) instances...
Scanning for holders of ReaderWriterLock locks...
Scanning for holders of ReaderWriterLockSlim locks...
Examining CriticalSections...
Scanning for threads waiting on SyncBlocks...
*** ERROR: Module load completed but symbols could not be loaded for Devart.Data.Oracle.dll
*** WARNING: Unable to verify checksum for Strm.Appender.dll
*** ERROR: Module load completed but symbols could not be loaded for Strm.Appender.dll
Scanning for threads waiting on ReaderWriterLock locks...
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
Scanning for threads waiting on ReaderWriterLocksSlim locks...
*** WARNING: Unable to verify checksum for System.Data.Entity.ni.dll
*** WARNING: Unable to verify checksum for System.ni.dll
*** WARNING: Unable to verify checksum for System.Transactions.ni.dll
Scanning for threads waiting on CriticalSections...
*** WARNING: Unable to verify checksum for System.ServiceModel.ni.dll
*** WARNING: Unable to verify checksum for System.Runtime.DurableInstancing.ni.dll
*** WARNING: Unable to verify checksum for System.ServiceModel.Activation.ni.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for HipIISEngineStub.dll -
*** WARNING: Unable to verify checksum for System.Core.ni.dll
*DEADLOCK DETECTED*
CLR thread 0x49 holds the lock on SyncBlock 0000000006f13248 OBJ:00000001c160ac38[Devart.Data.Oracle.OracleInternalConnection]
...and is waiting for the lock on SyncBlock 0000000015859ec8 OBJ:00000001a0802e88[System.Collections.ArrayList]
CLR thread 0x10 holds the lock on SyncBlock 0000000015859ec8 OBJ:00000001a0802e88[System.Collections.ArrayList]
...and is waiting for the lock on SyncBlock 0000000006f13248 OBJ:00000001c160ac38[Devart.Data.Oracle.OracleInternalConnection]
CLR Thread 0x49 is waiting at Devart.Common.DbConnectionPool.RemoveObject(System.Object)(+0x0 IL,+0x31 Native)
CLR Thread 0x10 is waiting at Devart.Common.DbConnectionPoolGroup.a(Devart.Common.DbConnectionPool)(+0x21 IL,+0xa2 Native)


1 deadlock detected.

Please advise as our client is quickly growing impatient.

Thank you for the provided information. We will create and send you a special build, in which we will try to solve this issue. We will post here when this build is ready.

Can you provide some guidance as to when we can expect the build? We need to respond to our client.