这是一次可能是及其危险的一次被恶意程序引起的 Google Chrome 浏览器崩溃了吧！
起因
之前还好好使用着的 Google Chrome 浏览器，虽然前一段时间不知道是什么原因导致的地址栏剪切会有问题，但这都没有发现有什么异常的感觉。
谁知前面一会还算是正常使用着的浏览器，在洗澡归来时发现服务器有重启的迹象，这时再打开浏览器时虽然可以恢复被关闭的标签页，但大部分页面都是空白的界面只有标签栏能显示网站的 TITLE ，极个别页面就会显示：“喔唷，崩溃啦！ 以及一些建议的操作方法。 及其错误代码‘STATUS_INVALID_IMAGE_HASH’”。
不仅是网页页面无法显示，就连浏览器自己的插件页面乃至是设置页面都不能正常显示，隐身模式下也同样的问题。
后果
问题排查
刚开始遇到这个崩溃错误的时候，第一时间就是再次重启服务器尝试是否能解决，无奈即使时再次重启服务器后仍旧是无法解决该错误。这时就只有着手进行一番搜索解决方案，一开始搜索到的解决方案就是修改注册表来解决，但是一看这个解决方法是解决几年前的一个错误。
稍作纠结就自认为这个解决方法是几年前的，现在浏览器的版本号都三位数了，再按照两位数的版本解决或许无法解决，于是不得不需求其他的解决方案。其中找到的“以兼容模式运行”的方式无法解决，加-no-sandbox以-no-sandbox模式运行也不是一个长久之计。
排查方式
后面就干脆在 cmd 命令行手动执行"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -no-sandbox命令启动试试，或许是因为没有关闭其他标签的原因这次没有以-no-sandbox模式运行。为了试验验证找到的一个方法是否能解决问题，还是把全部打开的标签页关闭后再执行一次"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -no-sandbox命令启动浏览器，这次终于以-no-sandbox模式运行打开浏览器，在这个模式下网页终于能正常显示就可以进行排错测试了。
1、在-no-sandbox模式下，在浏览器里面输入chrome://conflicts#R
2、查看那些dll随着浏览器打开时启动，并且签名不是Google或Microsoft的
3、通过这个打开的界面，发现有一个没有签名的 .dll 文件
排查结果
从中发现Version Checking and File Installation Libraries 10.0.26100.1150 687E057720000 BR %systemroot%\system32\version.dll没有签名，通过后面给出的路径前去一观发现，一个明显不正常的地方：“version.dll文件下面赫然就是一个version.dll.bak文件。更不用说两者的修改时间属性不对了”。随即右键属性查看各自的数字签名，不出意料的有问题的那个dll文件直接连签名都没有，而被bak的就有Microsoft Windows的签名。
虽然已经知晓问题所在，但是看着创建时间（2025年8月14日，5:49:54）、修改时间（2024年5月2日，10:41:30）、访问时间（2024年5月2日，10:41:30）不由得怀疑出现这个危险的问题有多久了？特别是后面细看之下才发现创建时间直接服务器时间乃至是当时的确实的北京时间（2025年8月14日，00:14:15）还快了几个小时。第一眼看到的是在文件列表时的修改时间，当时一看到这个时间顿时感到天都塌了，不知道这个【恶意DLL】有什么动作，有没有把我这段时间以来所输入的全部账号密码之类的全部都给窃取了。
被窃取什么这个现在暂时无法做出判断，当务之急就是将这个有问题的dll清理干净且排查是否还有其他的安全隐患。不想安装杀毒软件就决定把之前关闭的Microsofts Defender重新开启，打开 Windows 安全中心一看，界面就只有防火墙、浏览器、设备安全性这三个的配置选项，当时最多就是把内存完整性给再次开启（需要重启生效）。至于病毒与威胁防护忘记多久前因为老是“干扰”我当时手动给关闭了，这一次不得不再次启动否者就要安装其他安全软件，就是不知道为何一顿操作之后就是没有运行起来。根据官网的教程，在服务器管理面板中添加功能发现已经添加，使用 PowerShell 安装也出现错误，最后查看状态是未运行状态。
找不到启动的命令就再次转而着手处理这个有问题的dll先吧，查杀排除其他隐患的事就又先放一边。一个正在运行的系统，我无法通过文件资源管理器删除一个正在使用的dll，又不像下载安装第三方强删工具。就想着通过把version.dll.bak重命名回version.dll的方式看看，可以的是因为有重名的文件得到的是重命名为version（2）.dll的提示。重命名不行就把version.dll.bak复制到桌面再重命名成version.dll后拖回system32文件夹，可惜却因为权限不足而操作失败。
这时的我不太想修改权限，就是不知道这个恶意dll是不是修改后放进去再改回来的，还是放进去后再去掉这个权限的？远程服务器的进入安全模式也不是很方便的说。
处理方案
后面通过搜索得知有一个系统自带的命令修复
sfc /scannow
通过运行系统文件检查器修复被篡改的系统文件，检查完成后重启后该version.dll就恢复，且浏览器也能正常使用了。
总结
不得不说到现在还是心有余悸的，这个恶意dll比正常的dll大了78KB的体积，不知道其里面包含了何种代码。甚至是当时通过virustotal在线查杀单独的一个dll文件只有“3/71 security vendors flagged this file as malicious”。
同时重启系统后 Windows 安全中心的病毒与威胁防护又能正常运行了，于是进行了一次全盘查杀，就是不知道病毒特征库中有没有该dll的特征了？
结语
在复盘写这个文章的时候，查看到当时拍的照片发现，浏览器同时也引用了被改成version.dll.bak这个名字的动态链接库，若不是浏览器有对签名进行验证的要求或许还一直就发现不了。就是不知道是不是每次启动时就引用并验证的。还是在运行时有变化就会验证，如果是前者就很难判断是何时被修改的了，若是后者也难解释服务器重启的原因。难道是被篡改DLL而导致的重启系统？
参考
Google Chrome 错误代码“STATUS_INVALID_IMAGE_HASH”，Edge报错“STATUS_INVALID_IMAGE_HASH”。
https://www.cnblogs.com/programer-xinmu78/p/12996326.html
【彻底解决】Chrome/Edge都出现了的”STATUS_INALID_IMAGE_HASH”错误
https://zhuanlan.zhihu.com/p/662587368
virustotal在线查杀报告
https://www.virustotal.com/gui/file/ed39ab6c7f38052cd896db2c039873f441897686e370a9aa49f9495f5d7422b5
ChiuYut
2025年08月14日