Error: Access violation (0xC0000005) calling 3rd party DLL on Windows Server 2019 but not in Windows 10

[VLg]

Hi guys,

I encountered an issue which I would like to seek advice on.

Currently, I am working on a project that uses a 3rd party motion controller. The vendor has made a 64-bit DLL available for use which I call from LabVIEW 2019 64-bit (usage of 64-bit LabVIEW is due to project requirements). The initial tests were done on a computer running Windows 10 Home, and ran well without any problems. These involve calling functions from the DLL using the Call Library Function nodes in LabVIEW.

Subsequently, we had to shift to use another computer that runs Windows Server 2019, with the same version of LabVIEW. After some initial hiccups (Call Library Function nodes were broken due to missing dependencies - installed VC redistributables and this seem to have sorted it out), we can run the test code again. The test code ran normally, but when closing the main VI for the test code, LabVIEW crashes with an access violation (0xC0000005) (screenshot and crash log+dmp file attached).

After a bit of searching on the NI website, I found this KB. I have checked the possible reasons for the issue, and ensured that everything is adhered to. At this point, I am unsure of what could be a possible cause.

Could this be an OS issue? LabVIEW 2019 officially supports up to Windows Server 2012, although this does not seem too likely. A more possible reason is that the DLL calls have corrupted the memory, but it just seems weird that the code could run on the Windows 10 computer without any problem.

If you have any thoughts or suggestions, please feel free to let me know.

Thanks a lot!

Best regards,

Victor

[Kyle97330]

Did you try running LabVIEW as an administrator on the Windows server machine?

Did you go into the file properties of the DLL and see if it needs to be "unblocked" since it came from another machine?  The article linked is for Windows 10, but I assume Server 2019 has the same security feature.

Do you know if the DLL crashes when any function at all is called, or only when certain ones are called?

[VLg]

Hi Kyle,

Thanks for the response!

Yes, I am running LabVIEW as an administrator on the Windows server 2019 machine.

I will also look at the file properties of the DLL to check out the "unblock" property. 🙂 I should have access to the machine again in a day or two, and will get back here on the outcome.

Regarding the DLL functions, we use a couple of them to initialize the motion controller, and that caused the crash when we close the Main VI for the test. I can try to start with the first function (e.g. open serial port function) and progressively check which function trigger the crash. None of these functions take in arrays or strings as inputs.

Will get back to you here again. Thanks!

[VLg]

Hi Kyle,

I had been busy for the past few days, and just managed to find a time to get back to you here.

The DLL file property does not have the "unblock" setting. From what I checked, this meant that the DLL was not blocked. Hence, it seems like that was not the issue.

I will investigate this again some time soon. Thanks again.

Victor

[rolfk]

---

@VLg wrote:

Could this be an OS issue? LabVIEW 2019 officially supports up to Windows Server 2012, although this does not seem too likely. A more possible reason is that the DLL calls have corrupted the memory, but it just seems weird that the code could run on the Windows 10 computer without any problem.

---

Unfortunately, the fact that it did not crash on that other computer is no guarantee that your code was fully correct even there. There are many ways memory can get corrupted, some might corrupt memory that is never really used and hence will never cause a problem, until you change something on the system. It can be something innocent like adding a little feature, or something more serious like installing new drivers or a new OS version, or as in your case an entire new computer. Suddenly the arrangement of data elements in memory is different than it used to be and the corruptoin that always slipped by before suddenly overwrites memory that is vital to something. Such errors can show up right away when the function is called, or sometimes later or only when you try to shutdown your software and LabVIEW dutyfully goes through all its memory allocations to clean them up before termination. Suddenly it tries to access and/or deallocate a memory pointer that was overwritten maybe hours or days before and Booooom!

Calling convention is extremely unlikely to be the cause here. Parameter datatypes can be an issue but by far the most common error made by LabVIEW programmers interfacing to a DLL is to not provide a (large enough) allocated memory buffer for an output parameter. Every array, string or other buffer that a DLL wants to have passed to it in order to write information into it needs to be properly preallocated before the DLL function is called. That either means using an InitializeArray node to allocate the necessary array size or using the Call Library Node configuration attribute "Minimum Size" for array and string parameters to make sure you pass a large enough buffer to the function. What is large enough should be documented in the Programmer Manual in the description of that function.

And don't tell me it can't be such an error. It usually is for me too, despite me knowing these things in and out!

[VLg]

Hi Rolf, 

Thanks for your reply!

---

@rolfk wrote:

---

@VLg wrote:

Could this be an OS issue? LabVIEW 2019 officially supports up to Windows Server 2012, although this does not seem too likely. A more possible reason is that the DLL calls have corrupted the memory, but it just seems weird that the code could run on the Windows 10 computer without any problem.

---

Unfortunately, the fact that it did not crash on that other computer is no guarantee that your code was fully correct even there. There are many ways memory can get corrupted, some might corrupt memory that is never really used and hence will never cause a problem, until you change something on the system. It can be something innocent like adding a little feature, or something more serious like installing new drivers or a new OS version, or as in your case an entire new computer. Suddenly the arrangement of data elements in memory is different than it used to be and the corruptoin that always slipped by before suddenly overwrites memory that is vital to something. Such errors can show up right away when the function is called, or sometimes later or only when you try to shutdown your software and LabVIEW dutyfully goes through all its memory allocations to clean them up before termination. Suddenly it tries to access and/or deallocate a memory pointer that was overwritten maybe hours or days before and Booooom!

I agree with your points, I think in reality too many variables have been changed as the code has been migrated to a new computer with a different OS. The crash occurs on closing the main VI, which as you mentioned could be happening when LabVIEW is clearing up its memory allocation. 

---

@rolfk wrote:

---

Calling convention is extremely unlikely to be the cause here. Parameter datatypes can be an issue but by far the most common error made by LabVIEW programmers interfacing to a DLL is to not provide a (large enough) allocated memory buffer for an output parameter. Every array, string or other buffer that a DLL wants to have passed to it in order to write information into it needs to be properly preallocated before the DLL function is called. That either means using an InitializeArray node to allocate the necessary array size or using the Call Library Node configuration attribute "Minimum Size" for array and string parameters to make sure you pass a large enough buffer to the function. What is large enough should be documented in the Programmer Manual in the description of that function.

And don't tell me it can't be such an error. It usually is for me too, despite me knowing these things in and out!

---

Thanks for this tip, I have looked at the programmer manual and went through each function call to ensure the buffers have been properly setup. The parameters are all scalar numerics so at least on this end, the buffer size shouldn't be too much of an issue. 

The other thing that we will be trying out is to run the code as an executable (the program is to be delivered to an end-user) and see how the crash will manifest itself. We will also try out the stability of the motion control code if run in 32-bit LabVIEW (with a 32-bit DLL), it might also be that the 64-bit DLL have some issues on Windows Server. The possibility is remote but we will give it a shot if time permits.

Best regards,

Victor