I've been having some frustration with this over the last few weeks, I hope someone with better knowledge of what is happening can help shine a light on this.
We have been receiving
40W06 "All threads are blocked" errors for most of our queries that are being passed through an external environment. So far CLR, C_ODBC64, and C_ESQL64 have been tested and found to exhibit this issue. I am running 184.108.40.20642 on both the production and my local system. My local system does not exhibit these issues (although I found a bug with long binary). This error is not received when calling C functions without an external environment (which isn't an option with CLR).
For additional clarification, I launched a dbsrv12 instance from a shortcut on the production desktop and received an "All threads are blocked" error on the first attempt to call the external function:
select property('AutoMultiprogrammingLevel') => 1
select property('CurrentMultiprogrammingLevel') => 7
select property('MaxMultiprogrammingLevel') => 400
select property('ThreadDeadlocksAvoided') => 0
select property('ThreadDeadlocksReported') => 0
call sa_report_deadlocks() => no rows
Additional information collected from examining the server itself:
- Process Monitor shows no attempt by either dbextclr12 or dbexternc12 to read the requested .DLL file
- After an error message the server will restart dbexternc12, while dbextclr12 is not restarted.
- ProcDump does not indicate any exceptions (1st chance or otherwise) generated from within dbexternc12
- DbgView does not show any diagnostic information generated from within dbexternc12
I'm starting to run out of ideas on trying to figure out what's going on. I half expect the answer to be "upgrade to 16" or "wait for another EBF". If I had some idea of tracking down the underlying cause or getting some indicator of what is happening (other than an error message that is misguided at best) then I might be able to resolve at least a workaround to get this up and running again.
28 May '15, 21:53