cost
cost

Reputation: 4480

Why does the prefer 32-bit flag cause a permissions issue reading system32

I have to read from a file that's stored in the Windows directory, either in System32 or SysWOW64. Why it's stored there and which one it ends up in is not up to me, but I check the registry to get a string that represents the valid path. It's commonly C:\Windows\System32\FileName.Sys

I long ago wrote a wrapper to handle reading this for me, which up until recently worked fine. But when I upgraded a project to use VS2013 and set the 'Prefer 32-bit' flag, the file check suddenly started returning false

if (!File.Exists(sysFilePath)) throw new FileNotFoundException(....

When I turn off the flag it starts working again. The file it's looking for is definitely there, which makes me think there's some kind of permissions issue. Running this as an admin had no effect, the file check still returned false.

Is anyone aware of changes to permissions to access System32 if an application is built AnyCPU with Prefer 32-bit checked, versus without it? Or perhaps is .NET or Windows doing something under the hood that is looking in a different directory than I specify?

Upvotes: 0

Views: 439

Answers (1)

Nipheris
Nipheris

Reputation: 507

Seems that you are trying to run the compiled binary on 64-bit machine. If you use Prefer 32-bit flag, CLR compiles your IL to x86 instructions, if possible (https://stackoverflow.com/a/12066861/3927447) instead of using native architecture.

When the program is running in 32-bit mode in 64-bit system, some of the system paths are virtualized. For example, the "real" system32 in the file system is redirected to SysWOW64 folder. So, when you are trying to open the file using original path to system32, you just can not find it there.

You should consider using another logic for determining location of the file to open. And, if possible, execute your code on native subsystem to skip the virtualization step.

Upvotes: 1

Related Questions