Jump to content

System directory hidden from LabVIEW (Not really a LabVIEW problem)

Recommended Posts

Happy new year everybody  :cool:


Now, onto this year's first conundrum. I am trying to get some customer code running on my PC, and am getting a bit unstuck with some strangeness that I cannot explain.


In particular this application reads and writes to files in a directory, lets call it ABCD that lives in  c:\Windows\System32\

(As an aside, I am well aware this is not exactly a Windows "best practice" to put stuff in System32, but that is how it has been done in the application (which is quite old now), and that is what I have to live with given that I have inherited ownership of the project)


The trouble is, on my Win 10 dev PC LabVIEW cannot even "see" that directory. If I try and open any files in it I get error 7 (File Not Found), and in fact when I browse to the System32 directory from within LabVIEW the ABCD directory is not even visible.


Clearly this some Windows permission problem, but I cannot figure out how to work around it. I have messed about with all the permissions of that directory, and according to Windows my user should have full access to that directory. I have even tried starting LabVIEW as an Administrator but still no joy. Strangely, even from within Windows I can create a new text file in that directory but cannot save it.


Any ideas what is going on?


Edit: perhaps this has something to do with 32-bit/64-bit compatibility? If I open LabVIEW 64-bit I can see the directory if I browse there and the same LabVIEW code then is able to open and read the file contents just fine. I really did not know directories and files could have a "bitness" assigned to them...

Edited by Neil Pate
Link to comment

Happy New Year to you too!


I did a quick check on my machine. Was able to reproduce the problem running LV2015 32-bit on Win10x64. I created a folder called ABCD in 'C:\WIndows\System32'. A Google search led to the following link in MSDN. Do read the embedded link within the first response about file system redirector. That throws more light.


I created another folder ABCD, this time within 'C:\Windows\SysWOW64'; and created an empty file there. Re-running my LV sample, which is still coded for 'C:\Windows\System32\ABCD' is now successful; and the empty file does get listed with the List Folder function call!


Bottomline: 32-bit apps on Win64 will be redirected to 'C:\Windows\SysWOW64'.


Hope this helps. Cheers!

  • Like 2
Link to comment
Bottomline: 32-bit apps on Win64 will be redirected to 'C:\Windows\SysWOW64'.


Absolutely right, however you can disable that behavior for a calling thread. To do so just call Wow64DisableWow64FSRedirection and Wow64RevertWow64FsRedirection when you are done. Make sure to call both methods in the same thread (I have used the UI thread in the past)! In between those calls you can access the System32 directory normally.


Very important: All calls to the System32 directory must be executed in the same thread as the DLL calls!


EDIT: You might be interested in reading this explanation to the File System Redirector: File System Redirector

Edited by LogMAN
  • Like 2
Link to comment

FYI something similar happens for Windows registry.  If you read Local Machine\Software\National Instruments from LabVIEW 32 bit, in a Windows 64 bit, you will actually be reading from Local Machine\Software\Wow6432Node\National Instruments.  A handy feature at time, but usually causes more issues than it solves.  I did not know a similar function was made for the file system in regards to System32.

  • Like 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.