labview 2017 (x64) hanged importing a shared library

[SZFan]

Hi, everyone.

A shared library (with a header file) was delivered along with an equipment.

Labview 2017 (64bit) terminated responding to windows 10 (64bit) when I tried to import the Dll file with the wizard. 

Labview hanged when parsing the header file. I waited for almost an hour but nothing happened.

I used to import the same dll file using Labview 8.6 and succeeded. 

The header file is in ANSI C format. I am sorry that the header file and dll can not be supplied.

But I can supply the error log or message if I know how to find it.

Any idea? Thanks very much.

[wiebe@CARYA]

---

@SZFan wrote:

But I can supply the error log or message if I know how to find it.

Any idea? Thanks very much.

---

There must be a bug... At least with the error log or message we would have something to go on.

[dkfire]

Is the DLL 64-bit complied? 

If you have used the same DLL with LabVIEW 8.6, I doubt that it is 64-bit. And there for your can't use it with your 64-bit LabVIEW. 

Why are you using LabVIEW 64-bit?

[wiebe@CARYA]

---

@dkfire wrote:

Is the DLL 64-bit complied? 

If you have used the same DLL with LabVIEW 8.6, I doubt that it is 64-bit. And there for your can't use it with your 64-bit LabVIEW. 

---

Good point, but LabVIEW still should not crash.

[rolfk]

LabVIEW 2009 was the first version to be available as a 64-bit version on Windows. So your DLL surely must be 32-bit if it worked in 8.6. Unless your supplier can deliver you a 64-bit version of the DLL, it will NOT work with LabVIEW 64-bit.

---

wiebe@CARYA

wrote:

---

@dkfire wrote:

Is the DLL 64-bit complied? 

If you have used the same DLL with LabVIEW 8.6, I doubt that it is 64-bit. And there for your can't use it with your 64-bit LabVIEW. 

---

Good point, but LabVIEW still should not crash.

---

It shouldn't, but handling DLLs is a pretty nasty part. The DLL import library wizard needs to know all the exported functions and there is no trivial API to do that. The DLL has to be loaded and then the executable image headers need to be walked manually to retrieve all the supported symbols. This could be done with LoadLibraryEx() to load the DLL as image only but then Windows will not check if the DLL is loadable by the current application, so your 64-bit LabVIEW would happily extract the exported functions and start creating import wrappers for it only to fail when trying to load the DLL for the actual wrapper VIs.

A DLL can do any of a few thousend nasty things to throw a wrench into this.Some even intentional.

[SZFan]

Thanks for reply.

Can you please tell me where to find the log ?

The windows event log just said that there was a error of application hang with unknown reason. And nothing more was given.

[SZFan]

Thanks for all replies above.

The dll file was complied in 32-bit system. And I also tried Labview 32bit, nothing positive happened.

[SZFan]

---

@dkfire 已写:

Is the DLL 64-bit complied? 

If you have used the same DLL with LabVIEW 8.6, I doubt that it is 64-bit. And there for your can't use it with your 64-bit LabVIEW. 

Why are you using LabVIEW 64-bit?

---

No, the DLL was 32-bit compiled. 

But I tried Labview 2017 32bit, the same thing happened.

And I also think that Labview 64bit should work fine with a 32bit dll.

[SZFan]

---

@rolfk 已写:

LabVIEW 2009 was the first version to be available as a 64-bit version on Windows. So your DLL surely must be 32-bit if it worked in 8.6. Unless your supplier can deliver you a 64-bit version of the DLL, it will NOT work with LabVIEW 64-bit.

---

wiebe@CARYA

wrote:

---

@dkfire wrote:

Is the DLL 64-bit complied? 

If you have used the same DLL with LabVIEW 8.6, I doubt that it is 64-bit. And there for your can't use it with your 64-bit LabVIEW. 

---

Good point, but LabVIEW still should not crash.

---

It shouldn't, but handling DLLs is a pretty nasty part. The DLL import library wizard needs to know all the exported functions and there is no trivial API to do that. The DLL has to be loaded and then the executable image headers need to be walked manually to retrieve all the supported symbols. This could be done with LoadLibraryEx() to load the DLL as image only but then Windows will not check if the DLL is loadable by the current application, so your 64-bit LabVIEW would happily extract the exported functions and start creating import wrappers for it only to fail when trying to load the DLL for the actual wrapper VIs.

A DLL can do any of a few thousend nasty things to throw a wrench into this.Some even intentional.

---

I also tried Labview 2017 32bit and the nothing changed. 

And, I used some of the VIs imported previously by labview 8.6 in a new VI created by labview 2017. The new VI worked fine with no error.

The Labview application hanged when parsing the head file. So I think maybe the error has nothing to do with the dll file at the time. It is all about the header file and the wizard.

One more message :  there are 85 functions in the dll totally. I don't think it is too much for the wizard. And the wizard hanged almost immediately after starting dealing the header file. 

[SZFan]

---

wiebe@CARYA 已写:

---

@SZFan wrote:

But I can supply the error log or message if I know how to find it.

Any idea? Thanks very much.

---

There must be a bug... At least with the error log or message we would have something to go on.

---

I checked the path "my documents\ Labview Data\LVinternalReports", and there is noly one file created last year in the 17.0f2(32-bit) folder. Nothing new was found in it. And no file in the 17.0f2(64-bit) folder. 

If somewhere else where I can find the error log, please tell me.