Strange Error with 2: (works only once)

Community Support
1

Hi,

I’ve created a few different DLLs that gets hooked into my q-based environment using 2:. But I met a strange issue recently with one of our newer DLLs.

The symptom manifests itself in a way that 2: only works once – the very first call of 2: on this DLL is always successful, but another subsequent calls of 2: on this DLL (or even other DLLs) always fails with “The specified module could not be found.” error. I’m wondering if anyone else has seen such problem before?

==================DUMPBIN OUTPUT=========================

D:\DEV\arbitrage>dumpbin /exports Wind_API.dll

Microsoft (R) COFF/PE Dumper Version 12.00.31101.0

Copyright (C) Microsoft Corporation. All rights reserved.



Dump of file Wind_API.dll


File Type: DLL


Section contains the following exports for Wind_API.dll


00000000 characteristics

54DB396D time date stamp Wed Feb 11 19:13:49 2015

0.00 version

1 ordinal base

2 number of functions

2 number of names


ordinal hint RVA name


1 0 00017D6B Wind_login = @ILT+3430(_Wind_login)

2 1 00017032 Wind_logout = @ILT+45(_Wind_logout)


Summary


1000 .data

1000 .idata

8000 .rdata

2000 .reloc

1000 .rsrc

32000 .text

16000 .textbss


==================DUMPBIN OUTPUT=========================

==================KDB+ SESSION=========================

D:\DEV\arbitrage>q

KDB+ 3.2 2015.01.14 Copyright (C) 1993-2015 Kx Systems

w32/ 4()core 4095MB Think dev-thinkpad 192.168.10.104 NONEXPIRE


Welcome to kdb+ 32bit edition

For support please see http://groups.google.com/d/forum/personal-kdbplus

Tutorials can be found at http://code.kx.com/wiki/Tutorials

To exit, type \

To remove this startup msg, edit q.q

q)DLL:hsym`$“./Wind_API”

q)login:0N!DLL 2:(`Wind_login;2)

code

q)logout:0N!DLL 2:(`Wind_logout;1)

'The specified module could not be found.

q)login2:0N!DLL 2:(`Wind_login;2)

'The specified module could not be found.

q)/NOTE: Even the 2nd call to look up for `Wind_login failed…

==================KDB+ SESSION=========================

2

kdb+ won’t reload a shared library with the same name of a previously loaded shared library in that session.
So your choices are to either restart the kdb+ process or load the shared library from a different file file.

3

Thanks for your response, Charles. I don’t think that’s the problem, though. kdb+ seems to load up multiple functions from the same DLL (or even the same function multiple times) just fine. Please take a look at another q session below:

=======================KDB+ SESSION===================================

D:\DEV\arbitrage>q

KDB+ 3.2 2015.01.14 Copyright (C) 1993-2015 Kx Systems

w32/ 4()core 4095MB Think flying-thinkpad 192.168.10.104 NONEXPIRE


Welcome to kdb+ 32bit edition

For support please see http://groups.google.com/d/forum/personal-kdbplus

Tutorials can be found at http://code.kx.com/wiki/Tutorials

To exit, type \

To remove this startup msg, edit q.q

q)DLL:hsym`$“./iFinD_API”

q)login:DLL 2:(`iFinD_login;2)

q)logout:DLL 2:(`iFinD_logout;1)

q)login2:DLL 2:(`iFinD_login;2)

q)/NOTE: `iFinD_login is loaded twice.

=======================KDB+ SESSION===================================

4

ah, sorry, i read your email too quickly; thought you were reloading functions from the same dll, which may not throw an error, but also will not reload them from a newer dll of the same name.

I’ve not seen this particular error before. So some ideas -

Maybe related to the type of target you are building? e.g. release/debug

Or incremental linking?

If you place the dll in the $QHOME\w32 directory (usually c:\q\w32) and do not have it in your current dir, does that make a difference?

Are there any extra dependencies for this dll? i.e. a problem loading a dependent dll?

5

No problem. :^P

I’ve tested release/debug modes, no difference (i.e., same problem).

I’ve also verified DLL dependencies using Dependency Walker. With the fact that the 1st invocation to 2: went through smoothly, I don’t think that’s a problem.

While testing your 2nd suggestion below, though, I found that if I set DLL:hsym$"full/path/to/dll/Wind_API", things turned out fine. So it seems that the problem is my use of DLL:hsym$“./Wind_API”

Subsequently, I also verified the output of GetCurrentDirectory, but found no difference before and after the first invocation to 2:.

My gut sense now is that something fishy is going on with a 3rd-party DLL that my Wind_API.dll is dependent on – whenever this DLL is loaded the error regarding 2: occurs. I’m trying to reach out to th vendor now – though the support engineer doesn’t seem to have any clue at the moment…

Hope there is someone with better insight on Windows DLL loading, who can comment on this symptom.