FTDI FT232H Windows access permission problem

[Perreijn]

Hi guys,

Not sure if this is the right place to ask, since it might be a 3rd party driver issue, but given the popularity of FTDI's chips I'll try anyway.
I wrote a simple LabVIEW program to toggle some GPIO pins and read data over I2C using a FTDI FT232H IC. Everything seemed OK, so I made a build specification and built an executable.
When I run it without permission elevation (compatibility > run as administrator), FTDI communication fails. If I switch 'run as administrator' on, everything works fine.

Of course you need administrator rights to install the driver, but it seems strange I would need these rights to simply call the ftd2xx.dll.
The application was built with LabVIEW 8.6 and it runs on Windows Embedded 8.1 Industry Pro (64-bit). I used FTDI's LabVIEW examples (link) as a basis for my program and therefore call the ftd2xx.dll library, not the mpsse library (which is like a wrapper for the ftd2xx API).

Is this a LabVIEW issue or is it a Windows setting I need to alter? Thanks in advance for your help.

Paul

[rolfk]

Are you sure the driver is both installed and fully enabled? It could be that the FTDI library goes to some extra lengths and does recognize when the driver is not enabled and is using the Service Control manager to enable it anyhow. But that is a privileged operation that can only be done with elevated rights. It could be that there is a difference when installing the driver on an embedded system in such a way that the driver isn't automatically fully enabled.

What does the Device Manager tell you about that device?

[Perreijn]

I have looked further into the matter. 

The driver seems to be installed OK: the FT232H is listed as an 'USB Serial Converter' in the Windows device manager. No exclamation marks or anything.

With remote debugging I probed the results of the API calls. In the init subVI I first call FT_CreateDeviceInfoList to let the driver create a list of all connected FTDI devices.
The result of this function is status 0 (FT_OK) and 'Number of Devices' is 1. Next I call FT_GetDeviceInfoDetail to get detailed information of the device with index 0.

The result is different when I run the program as a normal user...

...compared to when I run it as an administrator:

I did notice something else. My LabVIEW development computer doesn't have a FTDI device, but the drivers are in the LabVIEW project folder (not in c:\windows\system32). Because of this, all the FTDI  'call library nodes' are configured with an absolute path to the ftd2xx.dll file, instead of simply ftd2xx.dll without a path. That's why LabVIEW copies ftd2xx.dll to the build destination folder when I build my test program and I have to manually remove it before deploying it to the target PC.

I ordered a generic FT232H development board, so hopefully tomorrow I can test it with real hardware on my development computer. I'll keep you posted.

[Perreijn]

Another follow up on the FT232H problem.

I connected the FT232H hardware to my development machine and updated the FTDI driver to the latest version (2.12.12.0). Controlling the hardware in the development environment as well as a built executable works well on my (Windows 10) computer, even as a normal user. 

Alas, this still doesn't work on Windows Embedded: you still need to run the program as an administrator. So I think it's safe to conclude that it is a Windows Embedded-specific problem.

I will contact FTDI support to ask if there any special ' features' in this Windows version I should know about. If there any Microsoft MVPs here, please chime in 

[Sam_Sharp]

Using those FTDI converters / D2XX drivers, I have seen a weird issue before where my LabVIEW application would have some serious issues running until I had plugged in the hardware for the first time. I had installed the drivers from FTDI (which would install the driver dlls) but my application would not run/had some weird issues (beyond the expected 'the hardware isn't plugged in') until I had actually connected the device and it had installed the drivers for that device. Once it had done that once, it would then run fine in subsequent executions, even if the hardware wasn't plugged in.

I wonder if the FTDI driver doesn't register/install the hardware libraries (e.g. d2xx.dll) until you actually connect a device.

While we haven't suffered the same symptoms, I do wonder if the underlying cause is the same.

[Perreijn]

Another update on the FT232H situation.

I got a reply from FTDI tech support, but they're unaware of any problems related to Windows Embedded.

So, I decided to ask on the MSDN forum for Windows Embedded and somebody suggested turning off UAC. At first I thought that this doesn't make any difference, because I already tried different slider settings, including turning the slider all the way down (never notify). Then I tried disabling UAC completely:

I set the the 'EnableLUA' key to a value of 0 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Restarted the machine and lo and behold: now the software also works for normal, unprivileged users! 

I kind of solved my own problem, but I'm a bit wary of disabling security features. I'll ask FTDI again if they can comment on this.