iis web core 0x80070002
0x80070002，这个错误码翻译成人话就是“系统找不到指定的文件”。但IIS Web Core报这个错，十有八九不是文件真丢了，而是配置和现实对不上号。
我见过最典型的场景：运维把站点文件从D盘挪到E盘，顺手改了应用程序的物理路径，却忘了IIS里还挂着一个旧的应用池。或者反过来，代码里写死了某个虚拟目录的相对路径，结果发布时少拷了一层文件夹。你盯着事件查看器里的红色感叹号，IIS管理器里站点状态明明是“已启动”，可浏览器就是给你甩个500.19，内网群里哀嚎一片。
排查这问题有个笨办法，但特别管用——直接看C:\Windows\System32\inetsrv\config\applicationHost.config。用记事本打开，搜那个报错站点的名字，看它的physicalPath属性指向哪。八成能找到惊喜：路径末尾多了个反斜杠，或者指向了一个早就被改名/删除的目录。改回来，回收应用池，问题通常秒解。
还有一种隐蔽情况，跟权限有关。IIS_IUSRS组对那个物理路径没有读取权限，系统也会报这个错，但提示信息往往含糊其辞。这时候别光顾着改路径，右键文件夹→属性→安全，把IIS_IUSRS的“读取和执行”勾上。特别提醒：别图省事把Everyone塞进去，后患无穷。
对了，如果你是刚把站点从IIS 7迁移到IIS 8.5或更高版本，那更得留神。老配置里有些模块在新版本里被拆分或改名了，比如URL Rewrite的某些规则文件，路径写的是旧格式。系统找不到那个文件，直接给你这个错误码。解决办法是重新装一遍对应模块，或者手工把applicationHost.config里失效的模块配置清掉。
最后说个邪门的案例。有次客户报这个错，我远程看了半天，路径、权限、模块全没问题。最后发现是站点根目录下有个web.config文件，里面某个配置节引用了不存在的程序集，导致IIS在初始化时去加载那个DLL，找不到就报0x80070002。删掉那行没用的配置，世界清净了。
所以遇到这错，别慌。按顺序查：路径对不对、权限给没给、模块装没装、web.config里有没有引用了不存在的东西。八成能解决。剩下那两成，多半是你改了系统环境变量或者注册表里跟IIS相关的键值，那属于玩脱了，退回还原点吧。