win8.1系统中遇到Hosts文件失效的问题
windows 8.1系统下hosts文件一直可以正常使用,今天突然失效了。
以下分析了host文件失效的可能原因,并提供了简单可行的解决方法,供大家参考。
可见hosts文件路径是对的,而且只有一行映射,确保没有其他的干扰项。
使用ipconfig /flushdns清理DNS缓存,而且其实我还停止了DNS Client服务的。然后继续ping,依然返回的是真实DNS解析的地址。
可见system的权限也是有分配的。下面那个我自己的账户和Admin组的账户的权限也是完全控制的。
分析处理:
根据猜想,我使用了消息记录器来跟踪与hosts文件有关的系统消息。为了对比,我同时在windows 8.1和虚拟机中运行的windows XP下操作,以便作为对比。
首先,所有有网络通信功能的程序都会去检测HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDnscacheParameters这个键下面是否存在UseHostsFile值是否存在,数据是多少。但是我发现无论XP还是8.1都没有该值,但是根据之前的实验可知是XP可以正常读取hosts文件的,所以可以断定这个是无关项。(不过根据这个判断,原来Dnscache服务(也就是在服务中显示名称为DNS Client的服务,用于缓存DNS解析的结果)是可以手动强制不读取hosts文件的,修改这个键值即可)。
然后,发现一个怪异的现象,每次我手动修改hosts文件后,在8.1下会显示出一个名为svchost.exe的进程试图访问hosts文件但是结果为Acces Denied。
在XP下,也有同样名称的进程试图访问hosts文件但是结果却是Success的。
根据消息记录器提供的进程的PID,追踪到其承载的服务中有一个共同的服务就是DNS Client。
于是,断定肯定是上述提到的DNS Client服务出现问题了。因为出现访问文件被拒,肯定是帐户问题,于是我习惯性地打开DNS Client的属性页,转到登录选项卡,发现其使用的帐户不是默认本地系统帐户,而是名为“Network Service”的内置安全主体。
权限问题
DNS Client服务使用的帐户不是system,而是Network Service。
虽然给system帐户赋予了完全的访问控制,但是根据开篇截图发现,缺少了Network Service的安全主体。
现在,可以断定system帐户和Network Service安全主体是没有关联的,所以才导致了DNS Client服务启动后无法正常读取hosts文件,而导致hosts文件无效。
解决办法:
编辑etc文件夹的访问权限,添加Network Service安全主体并赋予至少允许读取的权限,然后重新启动DNS Client服务即可。目前我的hosts已经一切正常。
理解了Windows 8.1系统下Hosts文件失效的原因,参考如上方法,Hosts文件即可恢复正常。