The subtle differences between 32-bit and 64-bit Windows present so many intricacies and pitfalls that even Microsoft employees seem to have trouble getting it right. I just stumbled upon a KB article that describes how to reset the hosts file to its original state. The topic alone is funny enough – it is not as if the default hosts file contained great amounts of data. An entry for localhost (IPv4 and IPv6) is all you need, and on Windows 7 / Server 2008 R2 not even that. But anyhow, there seem to be enough people asking MS support for this or they would not have troubled with creating a package (ResetHOSTSFileBackToDefaults.MSI) that basically empties the hosts file.
Is Hosts 64-bit or 32-bit?
As always, I am more interested in what the package does, and Microsoft is kind enough to explain that in most “Fix it for me” articles. As you probably know, the hosts file was, is and probably will always be located in %systemroot%\system32\drivers\etc. Simple enough. But wait: 64-bit systems have two system32 directories: one for 64-bit processes and the other for 32-bit processes. Now, where would the hosts file be located – or are there even two (potentially different) files?
The answer is: no, the hosts file exists only once on x64 Windows. And it is right where it belongs, in the 64-bit system32 directory. But where is that directory located on disk? Is it the one natively called system32, or is it SysWOW64?
Redirection Confusion
This is where confusion kicks in. Many people, including the person writing MS KB article 972034, see the number “64″ in the name of the folder SysWOW64 and think: yes, that must be the 64-bit version of system32. Nice thinking, but wrong. It is exactly the other way round. For compatibility reasons, the name of the system32 folder did not change in Windows x64, although on 64-bit platforms the folder does not contain 32-bit but 64-bit executables! That leaves the question of where to put the 32-bit files that 32-bit processes need – and also expect to find in system32? Obviously, the same DLL cannot be present twice in the same folder.
The requirement of two different system32 directories was solved by redirection. Actually there are two independent folders in any x64 installation: system32 and SysWOW64. The latter is shown to 32-bit processes under the name system32. 64-bit processes do not use SysWOW64.
How to Get to and Edit the Hosts File
If you want to edit the hosts file, you first need to locate and open it – on Vista and newer with UAC enabled from an elevated process (with admin rights). The procedure is a little tedious. Here is how to do it with 64-bit Notepad:
- Click on the Start button, type “notepad” and press CTRL+SHIFT+ENTER. Acknowledge the UAC dialog.
- Type CTRL+O. Navigate to C:\Windows\System32\drivers\etc. Select “All Files” in the bottom right corner.
- Now you see the hosts file. Select and open it. Make your changes and save it.
If you want to access hosts from a 32-bit process, use one of the following paths. Please note that in both cases the full path must be used. Navigating to “etc” from the root does not work (because System32 is redirected and Sysnative is not shown in directory listings).
- %Windir%\System32\drivers\etc. This works because file system redirection is disabled for the “etc” directory and thus accessing the 64-bit System32 works from a 32-bit process.
- %Windir%\Sysnative\drivers\etc. Sysnative is an alias that can only be used from 32-bit processes to access the 64-bit System32 directory.
So if a 32-bit app physically sees the SysWOW64 folder when accessing “%systemroot%\system32″ and a 64-bit app physically sees system32 when accessing “%systemroot%\system32″ then a 32-bit app looking to access the hosts. file will not get the real file?!? (or a “path not exist” error!)
32-bit and 64-bit Windows see one and the same hosts file in system32 and SysWOW64 respectively. This is because redirection is disabled for the folder system32\drivers\etc. More information can be found here: http://blogs.sepago.de/helge/2008/04/20/windows-x64-all-the-same-yet-very-different-part-7/
I just searched my 2008’s Windows folder + all subfolders – no hosts file at all…so this article didn’t bring me any closer…
Funny.
If you use MS Explorer (F3) you will find it in \\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\drivers\\\\\\\\etc\\\\\\\\hosts\\\\" !!!
Tested on Windows server x64 2008 SP2
;-)
hi, i’ve tried to put machine ip to the hosts file on Win64 in \\\\"C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\drivers\\\\\\\\etc\\\\\\\\hosts\\\\" !!! but i’m not receiveing desired result as i have when i update hosts file on Win32, seems like there is no difference whether i update host file on 64bit or no.
Do you know what the reason can be?
i need to update hosts file for connection to machine that is in different domain
Anna,
on Windows x64 the hosts file is stored in the (64-bit) System32 directory. In order to see that, either use a 64-bit program or, from a 32-bit program, use the following path:
%SystemRoot%\Sysnative\drivers\etc
Please note that the directory “System32″ which you see from a 32-bit application is not the “real” System32, but a redirection to SysWow64.
thanks for reply!
though it says that : \"Windows cannot find \’c:\\windows\\Sysnative\\drivers\\etc\’. Check the spelling and try again.\"
The SysNative virtual directory is available beginning with Server 2003 x64 SP2, I think.
Hello…..
Hope you still look at this thread.
I’m still confused.
I would like to add several 127.0.0.1 addresses to block sites.
Where do I add these under the default 127.0.0.1 local host.
Which Hosts file locaton is the “master”?
fmg
As I wrote in the article, there is only one hosts file on Windows x64. From 32-bit processes it can be reached via this path:
c:\Windows\Sysnative\drivers\etc\
From 64-bit processes use the traditional path:
C:\Windows\System32\drivers\etc
Thanks for this great information. I\’m trying to create virtual sites on my local machine and I was confused after updating to Windows 7.
It seems that having 127.0.0.1 with a website name in the correct HOSTS file does not do anything. In fact, in Windows 7 the host file says that HOSTS are resolved in DNS itself. Is there anyway to get around this?
You are referring to the following lines in the hosts file:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
The comment simply means that the resolution of the name “localhost” is done in the IP stack. In other words, Windows understands that “localhost” is the local system and does not need to be looked up in DNS.