64位系統下System32文件系統重定向

前言

      因為一次偶然的機會，需要訪問系統目錄“C:/Windows/System32“文件夾下的內容，使用的測試機器上預裝了win7 64系統。在程序運行中竟然發生了該文件路徑不存在的問題！！通過查看網上相關的資料，了解到64位系統下，System32(同時也包括Program Files)這兩個文件夾被動態地重定向了。為了可以直觀的反映這個問題，這里將編寫一個小的測試程序進行驗證。

 

實例驗證

      首先隨機選擇一個文件，並將其拷貝到系統目錄的System32文件夾下。本文選擇QQ啟動程序進行驗證（主要是QQ自帶企鵝圖標易於辨認，哈哈），如圖1所示

圖1 手動將QQ拷貝到系統System32文件夾下

    編寫實際測試程序，直接上代碼（調用了windows系統API PathFileExists來判斷文件是否存在）

/************************************************************************/
/* file   : 驗證在64位機器上system32以及Program Files的exe不能用API直接找到
 * author : Huagang Li
 * date   : 2014-8-23 01:22:55
 * tips   : 64位系統下system32 文件夾重定向機制
 *
 */
/************************************************************************/
#include <Windows.h>
#include <string>
#include <tchar.h>
#include <Shlwapi.h>

#pragma comment(lib,"Shlwapi.lib")  // PathFileExists鏈接時需要

int WINAPI WinMain( __in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in_opt LPSTR lpCmdLine, __in int nShowCmd )
{
    std::wstring strFile = L"C:\\Windows\\System32\\QQProtect.exe";

    if (::PathFileExists(strFile.c_str()))
    {
        ::MessageBox(NULL, _T("文件存在"), _T("Good"), MB_OK);
    }
    else
    {
        ::MessageBox(NULL, _T("文件不存在"), _T("Opps"), MB_OK);
    }

    return EXIT_SUCCESS;
}

      運行的結果如圖2所示：

圖2 文件不存在？？

      從上面的結果可以看出，在調用windows API檢測QQ文件是否存在時，系統給出了一個令人匪夷所思的結論：文件不存在！！但這個文件確實被拷貝進了該目錄下啊。要解釋這個奇怪的現象，就得從windows 64位系統中的文件系統重定向說起。當微軟開發了64位系統時，為了做到向前兼容，需要重新實現32為系統中需要的相關文件（system32文件夾下的dll以及exe）。然而，這些新的實現版本是基於64位系統開發的，因此如果繼續存放於System32文件夾下，顯得名不副實。可是為了做到向前兼容，又需要將這些依賴文件存放於這個目錄下，為了解決上述沖突，微軟采用了一種文件系統重定向機制：在64位系統下，System32文件夾下的文件實際重定向到SysNative這個文件夾（注意，這個文件夾不能直接找到）。這樣，就可以將64位系統下64位的庫和應用程序存放於System32文件夾下（因為已經重定向到SysNative了），而32位的庫和應用程序則被存放在另一個叫做SysWOW64的文件夾中。具體的對應關系為：

\Windows\SysWOW64  文件夾下存放32位的庫和應用程序 （WOW64 == Windows on Windows 64 bit ）

\Windows\System32  文件夾下存放64位的庫和應用程序

      為了驗證文件系統重定向，將前文中的測試路徑改為：

std::wstring strFile = L"C:\\Windows\\SysNative\\QQProtect.exe";

     測試結果如圖3所示：

圖3 改為Sysnative結果

      上述結果顯示了，64位系統下如果需要訪問System32目錄下的文件，一個可行的方法是將訪問路徑改為SysNative。但是由於sysnative文件夾不能通過windows資源管理器訪問到（如圖4所示），因此對於一般人來講，這樣的改名其實很困惑。

圖4 資源管理器訪問不到Sysnative文件夾

      既然微軟開發了文件系統重定向機制機制，那就可以通過一定的方式操作這種機制。通過查看msdn可以發現，http://msdn.microsoft.com/en-us/library/aa365743.aspx 提供的方式可以禁用文件系統重定向問題。因此，本文嘗試調用這個API接口進行驗證：

/************************************************************************/
/* file   : 驗證在64位機器上system32以及Program Files的exe不能用API直接找到
 * author : Huagang Li
 * date   : 2014-8-23 01:22:55
 * tips   : 64位系統下system32 文件夾重定向機制
 *
 */
/************************************************************************/
#include <Windows.h>
#include <string>
#include <tchar.h>
#include <Shlwapi.h>

#pragma comment(lib,"Shlwapi.lib")  // PathFileExists鏈接時需要

int WINAPI WinMain( __in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in_opt LPSTR lpCmdLine, __in int nShowCmd )
{
    std::wstring strFile = L"C:\\Windows\\System32\\QQProtect.exe";
    // 64位系統下 system32 文件系統重定向

    PVOID OldValue = NULL;
    Wow64DisableWow64FsRedirection(&OldValue);
    if (::PathFileExists(strFile.c_str()))
    {
        ::MessageBox(NULL, _T("文件存在"), _T("Good"), MB_OK);
    }
    else
    {
        ::MessageBox(NULL, _T("文件不存在"), _T("Opps"), MB_OK);
    }
    Wow64RevertWow64FsRedirection(OldValue);

    return EXIT_SUCCESS;
}

運行后得到的結果和上文中Sysnative一樣，如圖5所示：

圖5 禁用文件系統重定向機制后的結果

      注意，由於禁用文件系統重定向后可能引起其他一些問題（例如原本依賴於System32下的dll文件加載失敗），因此在禁用並完成需要的操作后，要回復原來的禁用狀態（如程序中Wow64RevertWow64FsRedirection(OldValue);）。這樣，在調用PathFileExists后，恢復了文件系統重定向機制，不會影響后續操作。

     另外，64位系統下Program Files與Program Files(x86)的關系就與上面的System32和S也是WOW64一致，也存在文件系統重定向。

 

結論

      1. 64位系統下存在文件系統重定向機制（File System Redirector）

      2. System32文件夾動態被定向到SysNative文件夾

      3. 可以通過windows API Wow64DisableWow64FsRedirection禁用這種定向機制

 

參考鏈接

[1] http://msdn.microsoft.com/en-us/library/aa384187.aspx

[2] http://msdn.microsoft.com/en-us/library/aa365743.aspx

[3] http://blog.sina.com.cn/s/blog_792da39c01013bzh.html