Call Library Function Node

[Cycler]

When using a call library function node and program is exited, I get a "has encountered a problem and needs to close" error having to do with ntdll.  It doesn't stop the program from running correctly, but it is annoying.  Any ideas?

[NIquist]

Sure, it's definitely one of about a billion posibilities.   You'll need to provide the dll and CLFN for anyone to help.

[Cycler]

Sorry.  The dll is user32 and the function is FindWindowA.

[NIquist]

Well, we can safely assume that a Windows DLL is OK so you must have set up your CLFN incorrectly.  I can only help with the basics here as I'm no C++ expert but if you post your VI that contains the CLFN where you're interfacing to user32.dll I'll take a look while we're waiting for a guru (like Rolf K.) to chime in. 

This is likely a simple problem to fix but don't be fooled by the fact that it just gives an error message instead of crashing.  You're probably corupting memory so although nothing horrible seems to be happening right now doesn't mean it won't later.  You must make sure to communicate between VI and DLL using the proper data structures and either LV or the DLL (but not both!) needs to be responsible for deallocating the memory used.  In other words, you need all your ducks in a row to avoid sneaky, niggling bugs that are very difficult to eradicate.

[Greg_S-Video]

Hello Cycler:

Just to get the ball rolling here.  The standard preliminary questions are what version of LabVIEW are you running and what operating system (version of Windows) are you running?

Are you given an error code when this problem occurs?  That would greatly assist me in assisting you if you could cite it.  As well, feel free to upload your VI in question.  Just for curiosity's sake, what are you trying to accomplish?

Thank you very much for your time, effort and consideration.

Greg S.

[rolfk]

Considering that there are quite a few versions of ready made VIs to access user32.FindWindowA(), why are you doing this yourself?

[smercurio_fc]

---

@rolfk wrote:

Considering that there are quite a few versions of ready made VIs to access user32.FindWindowA(), why are you doing this yourself?

---

Indeed. Like these: Windows API Function Utilities (32-bit) for LabVIEW

[Cycler]

Sorry about the missing information.  This is my first post.  I am using Labview 2010 on Windows XP SP3.  I am including a stripped down version of my application that will produce the same error along with the project file.  This only happens when the application is built into an executable.  It will also occur if the application is closed before FindWindowA is called.  I'm also including a file containing the error that comes up.  I appreciate all the help.

As to why I'm doing this myself?  Ignorance would be the best explanation.  A machine supplier gave me a VB program to communicate with his application.  I used the same functions in Labview to do the communication and it worked great.  I thought that was pretty cool. 

[rolfk · Accepted solution]

You should NOT specify the entire path to a system DLL in the Call Library Node confifuration. This messes up something in newer Windows versions. Instead just enter the DLL name only. It's sort of a bug in LabVIEW to not automatically detect the system paths and shorten the path accordingly on its own, but it's how things have been since a long time and you just need to be a little careful.

Also the return value should be really configured to be a pointer sized integer, since a HANDLE really is a pointer in Windows and the first parameter is also better configured as such. The way you have done it works fine for LabVIEW 32 Bit but will misbehave in LabVIEW 64 Bit.

[Cycler]

Thanks for the help!  There is no way I would have guessed that.  I also appreciate the heads up for the future.  I'll remember this as an excellent source for solving problems.