Change in COMMON_APPDATA-path returned to newer apps

[Mads]

If I install an application built in LabVIEW 2012 back in 2013 on a Windows 7 machine as a service (using srvany, with the RunAsService key set in the INI file of the application), on a 64 bit Windows 8.1 or 7 machine  - and that application tries to store data in CSIDL_COMMON_APPDATA, the data ends up in c:\ProgramData.

This is what we have always expected.

However, if I build the same application *now* (not just in LV2014 but 2012 as well), and install it using the exact same batch script and srvany, the returned path when the application runs as a service and requests CSIDL_COMMON_APPDATA has changed to: C:\Windows\SysWOW64\config\systemprofile\AppData\

(This also happens if we use the native system folder VI instead of a Win32 call).

Does anyone know why? Has the effect of the RunAsService key on the application itself changed perhaps (only makes sense here if 2012 has gotten an update as well), or is it a change in the installer/ - or Windows (that for some reason does not affect the old application/installer)?

[FouadR]

Hi Mads,

Have you changed either LabVIEW or Windows in this time e.g. updates?

[Sam_Sharp]

I was interested in this as I do something similar (have a LabVIEW app running as a service with system-wide configuration data) and found this:

http://superuser.com/questions/598601/what-is-system32-config-systemprofile

For some reason it is using the User App Data of the 'System' account (as it's running as a service). Why it's doing that I don't know, my App works fine reading/writing a subfolder in from C:\ProgramData. You are writing to a file in a sub-folder rather than a file just in C:\ProgramData because I had permissions issues trying to do that.

I had to have my installer create a subfolder in the system app dir, unlock it from the installer and also place a (dummy) file inside it to allow it to be read/written from my App. Maybe you need to do something similar?

[Mads]

We run Windows with auto-updates on all machines, so there has definitely been updates...but if that is where is has changed it has affected both Windows 7, 8 and 8.1. 

[Mads]

Sam,

We use whatever  path the Get System Directory VI returns (or similar VIs that make system32 API calls), so the write access is handled automatically (as the path it returns will be accessible), but I was curious as to why that path suddenly has changed from poitning to a subfolder of ProgramData to pointing to the more obscure SYSWOW directory. It makes sense if the change has happened in Windows itself, but in that case it must have been included in an update of all versions from 7 to 8.1....

[Sam_Sharp]

Yes Mads, I completely agree that it is very strange as I do exactly the same thing - writing to a file in a subfolder of all users' ProgramData. I don't think a windows update would change something like that as it would cause all applications that have system preferences to suddenly lose their configuration files by pointing to a new folder.

Have you tried writing a simple VI that you can run that returns/logs the paths when you run the application under different operating modes (e.g. run as a service, run as administrator, run as a user)? I'd be interested to see if the paths change between different execution modes and whether it's LabVIEW returning the wrong path or if the filesystem/OS is doing some redirection under the hood (as it does with registry keys).

[Mads · Accepted solution]

The reason for the change in the returned APPDATA path was simply that the executable did not find the RunAsService-key in its ini file. We had overlooked an error in the section name in the INI-file. So if your application rusn as a service and starts to store data in a subfolder of Windows\SysWow64 or \system32 when you were really aiming for c:\ProgramData, the problem is probably caused by a missing or incorrectly stored RunAsService-key.