Does anyone have personal experience with this error on a SQL Anywhere 16 database trying to load and use DLL functions via CREATE PROCEDURE ... EXTERNAL? I'm trying to remotely debug the following error which prevents Foxhound 3 from responding to any user input in one single installation: SQLCODE = -620, SQLSTATE = WW006, ERRORMSG() = Could not load dynamic library 'C:\ProgramData\RisingRoad\Foxhound3\unknown' ALL the causes for that error (missing DLL, etc) that I know about have been eliminated. Attempts to locally reproduce the symptom have failed, INCLUDING testing a complete copy of all the installed files received from the remote site... it works fine on my computer. asked 21 Jan '15, 10:25 Breck Carter Volker Barth |
Bit of a head scratcher that!
In theory (and from a quick review of the relevant code)
'C:\ProgramData\RisingRoad\Foxhound3\unknown' should just be the dll name string passed into the gear that calls the Windows API function LoadLibrary() and it is thrown that right after the LoadLibrary( ) fails.
Since I doubt you have declared the SQL wrapper function for this that way . . . hmmmm
Does the customer's (now) broken database show anything in proc_defn from sys.sysprocedure that indicates the create failed on that system? And does that database throw the error on other systems ... if copied to them? (or "text" from dbo.syscomments show any odd history?)
Locally, the "broken" database works flawlessly. Here is what one of the CREATE PROCEDURE EXTERNAL objects looks like after being created locally (the first result set has been wrapped manually for clarity):
For what it's worth, the word "unknown" has been known to appear in this error message when the dll is missing from the folder. This makes me think that something mysterious is broken in the SQL Anywhere 16 installation... is there any mental equivalent of a dead chicken that might suggest to you what might cause this?... the failing foxhound3.db files works just fine when copied to my computer (I know it is the failing database because Foxhound has dutifully saved about a thousand of those error messages in its own diagnostic table).
Thanks very much for the suggestion... I hope to get the query results from the broken installation.
We parse that dll's FQN from that entry ... so something must be going wrong there. You might want to capture OS and C runtime library (version) information while you look into that at the site.
FWIW I've been looking through that code and it does not seem to be something that has changed much on this end.
The "unknown" substring is a red herring... it is coming from the application after it makes two successive failed calls to an external procedure, first using a 32-bit DLL and then using a 64-bit DLL. The purpose behind these two calls is merely to determine which DLL should be used. Sadly, the application does not capture ANYTHING about those two failures, but just uses "unknown" as the dll name for all further external procedure definitions... a huge design flaw that has gone undetected for many years. Until now, the two initial calls have both failed ONLY when the dll files are missing, which is not the case here.
A diagnostic patch has been delivered, with hope that it will be applied :)
Nick, while I wait for further diagnostics, can you think of anything one could DO to a Windows 2008 R2 and/or SQL Anywhere 16 2052 installation that would PREVENT an EXTERNAL procedure call from working?
Just a very wild guess: Missing permissions on the DLL? (Though that might raise a different error, I'd expect...)
Do we know if this is new behavior to just build 2052? Or even version 16? {I've been looking for all possible changes but knowing that may help narrow this down some}
As to V16 related changes, there could be a few differences to earlier versions such as: the sql security invoker clause default, a couple of new security features (-sf )around disk sandboxing, roles (of course ... and/but did the customer implement dbinit -pd? or use an older file format?), all in addition to the basics around execute permissions and credentials of the calling "chain".
None of which I believe interact in this way ... but do prove me wrong ... it could only help.
Volker and Nick: Thanks! The lack of diagnostics on the original error makes all your suggestions possible (except dbinit -pd since the physical database file was created by me). This is an environmental thing since a copy of the failing database file works OK on my computer.
I too have been tossing around possible ideas concerning permissions but I could not see how that could cause that 'unknown' to show up; the first time directory access or permissions come into it is immediately after the call to LoadLibrary() and that is not returning that (or any other) string.
That is what is leading me think there is some MSC library or shim or virus involved somehow.
The fact that the string 'u'-'n'-'k'-'n'-'o'-'w'-'n'-'e'-'d' harkens back to some old (V7-ish) behaviours also does not seem to come into it since it is part of a(n otherwise) whole string that has that substituted. Whole strings can be 'unknown' if some look up of text fails, but that's not the case in this scenario either.
Of course, infected software can always be doing something else . . .
sorry sorry sorry sorry sorry (that's five "sorrys", the maximum possible)... the "unknown" is a red herring, it comes from my application after it fails twice to call one of the EXTERNAL procedures... see my comment above for more information. I am currently waiting for more diagnostic information.