I do not know if you have encountered Hosts file invalidation. The Hosts file of my Windows 8.1 system can be used normally, but somehow it has suddenly failed. The failure of the Hosts file has caused me a lot of trouble in my work. In order to analyze the specific reasons, I will give you a demonstration test.
The visible hosts file path is correct, and there is only one row mapping to ensure that there are no other distracters.
Use ipconfig /flushdns to clean up the DNS cache, and in fact I stopped the DNS Client service. Then continue to ping, still returning the address of the real DNS resolution.
As shown in the figure, it can be seen that the permissions of the system are also allocated. The permissions of the account in my own account and the Admin group below are also completely controlled.
This is the case, I don’t know why it has suddenly failed recently. I might have encountered any hijacking?
Analytical processing
According to my guess in the reference, I used a message logger to track system messages related to the hosts file. For comparison, I also operate under Windows XP running on Windows 8.1 and virtual machines for comparison.
First of all, I found that all programs with network communication function will detect whether the UseHostsFile value exists under the HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Dnscache\\Parameters\\ key and what the data is. However, I found that neither XP nor 8.1 has this value, but according to previous experiments, XP can read the hosts file normally, so it can be concluded that this is an irrelevant item. (However, according to this judgment, the original Dnscache service (that is, the service named DNS Client in the service is used to cache the DNS resolution) can manually force the host file not to be read, and the key value can be modified. Br> Then I found a weird phenomenon, every time I manually modified the hosts file, under 8.1 will show a process named svchost.exe trying to access the hosts file but the result is Acces Denied. Under XP, a process with the same name tries to access the hosts file but the result is Success.
According to the PID of the process provided by the message logger, a common service that is traced to the services it carries is the DNS Client. Therefore, it can be concluded that there is a problem with the DNS Client service mentioned above. Because the access file was rejected, it is definitely an account problem, so I habitually open the DNS Client property page, go to the login tab, and find that the account it uses is not the default local system account, but the name is "Network Service". Built-in security principal.
After that, everything is clear, and in the end, it is a permission issue. The account used by the DNS Client service is not system, but Network Service. Although I gave the system account full access control, according to the screenshots I opened, I found that I lacked the security principal of Network Service. Now we can conclude that the system account and the Network Service security principal are not associated, so the DNS client service cannot read the hosts file after the startup, and the hosts file is invalid.
The solution is: edit the access permissions of the etc folder, add the Network Service security principal and give at least permission to read, and then restart the DNS Client service. Currently my hosts are all fine.
Based on the above analysis, I believe that everyone can understand more clearly the reasons for the failure of the Hosts file under Windows 8.1 system, and also can solve the countermeasures to solve it. In the end, our Hosts file will be back to normal.