Need Help with System32 File Access Permissions (I think)

I'm having trouble with the environment configuration on my new Win8 machine, I don't remember running into problems like this on 7, but I can't seem to find much useful online..

I have 4 dll files that need to go into the Windows\System32 folder in order for one of our applications to run. This is done through an Advanced Installer package I created, which will not allow the installation unless the user has administrative rights (it deals with Windows Services as well). One of the steps is to copy these 4 dll files, which it apparently does without any errors.

Herein lies the problem.. Technically, the files do indeed exist, as seen in the Bash shell screenshot below:


While they are quite simply not visible through either Explorer or command prompt, even when run as an elevated command prompt. The example screenshot below shows me trying to copy one of these files into the folder. Notice the overwrite file warning and the file listing behind it.


In the above shot, I had already figured out that copying the jacob-1.15-M4-x86.dll dll using the elevated command prompt seems to work, it shows in explorer and the applications that depend on it load fine.

Sorry my first post on EightForums is asking for help, but I'm very new to Windows 8 and I need to figure out why this is dying quite urgently.

In my searching online I found many many posts covering how to take ownership of the system32 folder to make modifications (and a more than decent number asking how to fix it afterwards), but this is something I need to cater for in a corporate installation package that gets sent out to international customers and I don't even know where to begin with Win8..

Anybody have an idea what's going on here? How could a file be copied into the folder that no Windows tool can see?

There are differences between bash and Windows. In linux, the hidden file started with a "." while in Windows you have to turn on "Show Hidden File" in the folder options. I happen to have UWIN (AT&T Unix) package installed in Windows and if I use ls -l in System32, almost all the files are owned by TrustInstallers. When I boot up linux Mint and do the same command, it listed all the files with owner and group owner as me (my username in linux).

First, try to set the folder options to show hidden files and hidden system files as shown below:



If you now can see the files, open the elevated command prompt and type: icacls filename where filename is one of your dll to see who actually own it.

Thanks for the tips topgundcp. The bash console I'm using here came with Git, but that part was a sort of "oh hey, bash shows the files" comment more than anything else. Unfortunately, the only way I can see them is through bash, which doesn't allow me to run takeown or icacls.

For the record, I run all my systems showing hidden files and not hiding protected operating system files by default (I don't much like nasty surprises, so I like to see everything). So mine is already set that way.

One interesting point, I uninstalled the app that originally placed the files there. It needed a restart, but afterwards they are now truly gone, even through bash where I saw them previously.


If this helps, the installation package in question (proprietary client-only app, can't share it) requires administrative access to install. I know at least in Advanced Installer this isn't the same as the actual Administrator, it merely requires a user in the administrators group, but I doubt that would make much difference here.

I'm going to try install this again, by simply running the installer straight and with "Run as administrator". If all else fails, I can leave them in an app folder and adjust the %path% variable on install, but I would prefer to not have to modify system variables if possible.

[edit] Nope, same behaviour. The files appear to be copied, I still get overwrite prompts and bash still shows them, but nothing through explorer or any Windows command prompt (normal, elevated, or VS2012) and the apps that require these files can't read them.

I actually use ksh instead of bash and in ksh I can run all the Windows programs with it except those built in with cmd.exe such as dir etc... Git for Windows is somewhat limited. icacls runs OK:



By any chance those dll's were removed by Windows Defender ?

Thanks, I'll look into ksh.. However I've had enough of this for today. I technically finished work an hour ago and it's a Friday, so I'll look at this on Monday again. I've used Win8 on friends computers, didn't like it. Been using it myself for just less than a week and already it's driving me insane.

So.. There's a distinct possibility that I was just being stupid on Friday afternoon, perhaps my brain shut down before work finished.

The system I was testing the installation on is a 64-bit machine, which means anything that the Advanced Installer package would copy to the OS's "system folder" would go to system32 on a 32-bit setup, and SysWOW64 on a 64-bit setup. The files I was fighting with do indeed get placed in the SysWOW64 folder as expected. I can assume Bash was seeing the files in system32 due to some internal symbolic linking, but that's just a best guess here.

Either way, the issue that prompted this file access investigation in the first place (not really mentioned here) must be due to something else. I'll just have to keep digging.

When a software program is installed that has not been updated to work properly with Windows Vista and above, it will try to write directly to a secure part of the OS or registry. When this happens, Virtualization will intercept these attempts and redirect the program to an isolated, non-system, user-specific location, such as the C:\Users\username\AppData\Local\Virtual Store folder. In the Registry, when a program tries to write to a system wide location such as, HKEY_LOCAL_MACHINE\Software, the write is redirected to the HKEY_CURRENT_USER\Software\Classes\VirtualStore key.


All of these redirects by the system are completely transparent to the application.


Check the Virtual store folder.

lastof said:

When a software program is installed that has not been updated to work properly with Windows Vista and above, it will try to write directly to a secure part of the OS or registry. When this happens, Virtualization will intercept these attempts and redirect the program to an isolated, non-system, user-specific location, such as the C:\Users\username\AppData\Local\Virtual Store folder. In the Registry, when a program tries to write to a system wide location such as, HKEY_LOCAL_MACHINE\Software, the write is redirected to the HKEY_CURRENT_USER\Software\Classes\VirtualStore key.


All of these redirects by the system are completely transparent to the application.


Check the Virtual store folder.

Click to expand...

Thanks for the info. Through a combination of your post and my general research over the last few days, I've found a number of things in my installation packages that need to be changed...

Unfortunately this also means our development team have to "fix" things in their code as well though, but I have been warning them for almost a year now about the hazards of hard-coding paths inside an app. Maybe this is just the kick they need to actually do it properly.

Hope you get everything worked out, I know virtualization and Microsoft's attempts at system security through such, can be a real bear to wrestle with.

Best of luck.