NI Advanced HTTP Client - Cant use DLL in Executable

[Kenny_K]

I am using the NI Advanced HTTP Client and have been for many months now.  Recently after updating LV, I am seeing an issue where when I use the code in an EXE or PPL, the code can no longer use the DLL.

I am currently working in LabVIEW 2025 Q3 64 bit. 

I found this article, and made the change to the Open Session.vi: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019XJwSAM&l=en-US

I then created an EXE that is JUST the Open Session.vi.

If I run the same Open Session.vi directly in the LabVIEW Development environment, I am able to execute the VI without issues.  NOTE: My development machine is different than the machine I was running the EXE on.

[billko]

I think it might be referring to the second error cause: file not found. Seems like the path to the DLL changed?

[Kenny_K]

If I make the path the same as what is on the DEV machine, the loading of the DLL gives the same error.

I also tried adding the viSearchPath to the application ini file:

I also tried leaving the DLL in the built EXE data folder.

[dkfire]

What is on the error cluster right after the DLL call ? 

What is the return code value from the DLL? 

[Kenny_K]

Error out 2 is the error wire right from the dll node, and the DLL return is the number returned.

[rolfk]

The ni_httpClient.dll library is only a relatively thin wrapper around the curlimpl.dll installed elsewhere on the system. "C:\<program files>\National Instruments\Shared\nicurl\curlimpl.dll". That in turn needs the correct Microsoft C Runtime library installation, although since about Windows 10 this should be all upwards compatible, so is seldom the problem.

In older versions it used to reference nicurl and niopenssl in similar locations but that was somewhere around LabVIEW 2012 or so.

I'm not quite sure what makes you believe that lvwebclient.dll is a valid DLL. Is that your own DLL? Who made it? With which C compiler version? Ahhhh I see that is Darrens Advanced HTTP library. Seems you need to tag him about this, his compilation is most likely using some features of curimpl.dll that may have changed in a recent security update to that library. NI is since some time pretty aggressive about addressing any CVE security advisory fairly quickly and that could for sure cause compatibility breakage.

[dkfire]

---

@Kenny_K wrote:

Error out 2 is the error wire right from the dll node, and the DLL return is the number returned.

---

So the return code is 2 from the dll. 

Dll can then be found, and can be called. The question is then why it returns 2 as a return code. 

Might be something else is missing.

[Darren]

A built EXE with the Advanced HTTP API works fine for me in both LabVIEW 2025 Q3 and 2026 Q1 64-bit.

What is your specific version of Windows? Mine is Windows 11 Enterprise 23H2 build 22631.6491.

[Kenny_K]

Both PCs (Development and EXE) are Windows 11 24H2, 26100.7634.

I attached NI Max reports for software from both PCs.

I also did an uninstall and reinstall of the NI Adv HTTP package to reset any DLL linkage and did a Mass compile.

[Kenny_K]