前言
在调试一个Winform程序,使用File.Exists 判断一个已经存在的驱动文件,程序一直返回false。
因为驱动文件属于系统目录,心想难道是权限不够导致的?然后用管理员身份运行软件,依然返回false。
吓的我赶紧去系统目录C:\Windows\system32\drives 搜索该文件,一看在这里啊,怎么还是返回false。
开始还以为VS出问题了,然后尝试判断一个D盘下的文件,发现可以判断成功。
判断代码如下
// 获取系统目录
var system = Environment.GetFolderPath(Environment.SpecialFolder.System);
var filePath = system + @"\drivers\evserial7.sys";
var flag = File.Exists(filePath);
MessageBox.Show("系统路径:" + filePath + "\r\n" + "checkDrives:" + flag);
运行结果
在系统中找文件确实存在,如下图
奇怪在于当我把程序设置成Release运行的时候判断又成功了,第一张图Debug运行的,下图是Release
当时心想为什么Release和Debug不一样呢,一时有点诧异,然后就想着,看看反编译后的IL代码,看两者是不是有什么差别?
Debug反编译
Release反编译
这样看两者并没有任何差异,因为我们判断是路径,所以我们只看IL中路径是否有不同编译, 两者中IL_0002: call string [mscorlib]System.Environment::GetFolderPath(valuetype [mscorlib]System.Environment/SpecialFolder)都是一样的,说明系统路径一样,后面拼接字符串更加不会有任何差别。
最终通过stackoverflow找到原因,因为我当前程序编译的是32位即X86,32位应用程序在64位系统中是无法访问system32目录的。为什么我程序要选择编译32位呢,因为我程序当中需要调用一个C++写的dll,该dll是32位的,我无法改变。如果我程序编译时选择AnyCPU或者X64,那么该dll是无法调用的。所以我只能改成X86。
为什么当我用Release又能判断正确,原因在于上图的这个生成配置页面在Release的时候目标平台任然是:Any CPU。(不是X86),所以能判断成功。当把Release模式的目标平台改为X86后结果就是false了。
那么编译的32位程序到底该怎么判断64位系统中的系统文件呢?其实当我们32位应用程序访问system32文件夹的时候,64位系统会自动帮我们自动重定向到SysWoW64文件夹。
通过专业解释该文件夹主要是被设计用来处理许多在32-bit Windows和64-bit Windows之间的不同的问题,使得可以在64-bit Windows中运行32-bit程序。
所以我们在32位程序的时候判断系统路径其实已经重定向到了: C:\Windows\SysWoW64\drivers\evserial7.sys,这是系统自动重定向,所以IL代码中我们也看不到差异。这个目录肯定不存我们的文件,所以导致返回判断false。
那我们如何在32位下真正的访问system32目录呢?不要系统重定向。
使用 C:\Windows\SysNative路径,这是个虚拟路径,我们在Windows资源管理器中是无法找到的。但是他最终还是会指向到system32中。SysNative文件夹目的就是让32位应用程序访问64位系统文件的方法。
现在我将代码改下,前面的 Environment.GetFolderPath(Environment.SpecialFolder.System)是获取system32这里要改为Environment.SpecialFolder.Windows,获取windows目录,并在下面拼接上Sysnative目录。
这只是在判断系统文件的时候会存在32位和64位的差异,普通文件就不存在任何影响了。
最后修改代码如下
// 获取windows目录
var system = Environment.GetFolderPath(Environment.SpecialFolder.Windows);
var filePath = system + @"\Sysnative\drivers\evserial7.sys";
var flag = File.Exists(filePath);
MessageBox.Show("系统路径:" + filePath + "\r\n" + "checkDrives:" + flag);
运行结果