电脑蓝屏KERNEL_SECURITY_CHECK_FAILURE怎么解决

2023-07-28 09:32:35来源:互联网  

蓝屏代码0x00000139代表"KERNEL_SECURITY_CHECK_FAILURE",这意味着在内核级别的安全检查中发生了错误。这可能是由于驱动程序或系统文件的问题引起的。出现这个错误时,系统会崩溃并显示蓝屏。

要解决这个问题,可以尝试以下方法:

方法一:检查内存问题


(资料图片)

运行Windows自带的内存诊断工具(Windows Memory Diagnostic),以检查系统内存是否存在问题。

方法二:检查并重置内存配置

使用Windows自带的内存诊断工具进行内存测试,并根据测试结果采取相应的措施,如更换损坏的内存模块或调整BIOS设置。

方法三:回滚驱动程序

如果最近更新了驱动程序,并且问题发生在更新后,请尝试将驱动程序回滚到先前的版本。

方法四:使用一键修复工具助手(强烈推荐)

1、首先你的电脑必须下载与完成安装完成快快蓝屏修复助手。如果你还没有安装点击下方链接下载。

下载地址:>>>快快蓝屏修复助手<<<

提示:安装路径不要选择C盘,避免产生问题造成损失。

2、找到你电脑中的快快蓝屏修复助手,点击进入。看到首页后,点击首页一键扫描按钮开始扫描。等待几分钟,就能获取你急切想要的结果。

3、扫描完成后会显示电脑的所有蓝屏记录以及蓝屏的详细信息。

4、解决方案页面显示了导致该次蓝屏的具体原因和解决方案,点击右上角的一键修复进行修复。

5、切记,当修复完成之后我们还是需要重新启动计算机的。毕竟一切修复的结果,需要重新后,才能被系统认可。

当你完成重启后,你电脑的蓝屏问题已经基本解决了。相信小编,不要急需卸载快快蓝屏修复助手。毕竟它强大的功能是你未来的一个保障,可以随时随地为你服务,让你再次遇到蓝屏问题不在抓狂。

其他相关信息:

KERNEL_SECURITY_CHECK_FAILURE bug 检查 的值为 0x00000139。 此 bug 检查指示内核已检测到关键数据结构的损坏。

bug 检查0x139 KERNEL_SECURITY_CHECK_FAILURE参数

参数描述
1损坏的类型。 有关详细信息,请参阅下表。
2导致 bug 的异常的陷阱帧的地址检查
3导致 bug 的异常记录的地址检查
4保留

下表描述了参数 1 的可能值。

参数 1描述
0基于堆栈的缓冲区已溢出 (旧版 /GS 冲突) 。
1VTGuard 检测代码检测到尝试使用非法虚拟函数表。 通常,C++ 对象已损坏,然后尝试使用损坏对象的 指针进行虚拟方法调用。
2堆栈 Cookie 检测代码检测到基于堆栈的缓冲区溢出 (/GS 冲突) 。
3LIST_ENTRY (损坏,例如双删除) 。 有关详细信息,请参阅以下原因部分。
4保留
5将无效参数传递给认为无效参数致命的函数。
6加载程序未正确初始化堆栈 Cookie 安全 Cookie。 这可能是由于生成仅在 Windows 8 上运行的驱动程序,并尝试在早期版本的 Windows 上加载驱动程序映像。 若要避免此问题,必须生成要在早期版本的 Windows 上运行的驱动程序。
7请求了致命程序退出。
8编译器插入的数组边界检查检测到非法数组索引操作。
9RtlQueryRegistryValues 的调用是在未RTL_QUERY_REGISTRY_TYPECHECK的情况下指定RTL_QUERY_REGISTRY_DIRECT,并且目标值不在受信任的系统配置单元中。
10间接呼叫防护检查检测到无效的控制转移。
11写入防护检查检测到无效的内存写入。
12尝试切换到无效的纤程上下文。
13尝试分配无效的寄存器上下文。
14对象的引用计数无效。
18尝试切换到无效jmp_buf上下文。
19对只读数据进行了不安全的修改。
20加密自测试失败。
21检测到无效的异常链。
22发生加密库错误。
23从 DllMain 中进行的调用无效。
24检测到无效的映像基址。
25保护延迟加载导入时遇到不可恢复的故障。
26调用了不安全的分机。
27调用了已弃用的服务。
28检测到超出边界的缓冲区访问。
29RTL_BALANCED_NODE RBTree 条目已损坏。
37调用了范围外开关跳转表条目。
38尝试对无效目标执行 longjmp 操作。
39无法将导出抑制的调用目标设为有效的调用目标。

原因

使用参数 1 表和转储文件,可以缩小此类型许多 bug 检查的原因范围。

LIST_ENTRY损坏可能难以追踪,并且此 bug 检查,表示在向列表) 添加或删除单个列表条目元素时, (检测到双重链接列表中引入了不一致。 遗憾的是,在损坏发生时不一定能检测到不一致,因此可能需要一些侦探工作来确定根本原因。

列表条目损坏的常见原因包括:

驱动程序已损坏内核同步对象,例如 KEVENT (例如,当线程仍在等待同一 KEVENT 时对 KEVENT 进行双重初始化,或者允许基于堆栈的 KEVENT 超出范围,而另一个线程正在使用该 KEVENT) 。 这种类型的 bug 检查通常发生在 nt!Ke* or nt!Ki* 代码。 当线程完成等待同步对象或代码尝试将同步对象置于信号状态时,可能会发生这种情况。 通常,发出信号的同步对象是已损坏的同步对象。 有时,如果损坏的同步对象位于已) 释放的池块中,则具有特殊池的驱动程序验证程序可以帮助跟踪罪魁祸首 (。驱动程序损坏了定期 KTIMER。 这种类型的 bug 检查通常发生在 nt!Ke* 或 nt!Ki* 代码 和 涉及向计时器发出信号,或者从计时器表中插入或删除计时器。 正在操作的计时器可能是损坏的计时器,但可能需要使用 !timer(检查计时器表,或手动遍历计时器列表链接) 以确定哪个计时器已损坏。 有时,如果损坏的 KTIMER 位于) 已释放的池块中,则具有特殊池的驱动程序验证程序可以帮助跟踪罪魁祸首 (。驱动程序管理不了内部LIST_ENTRY样式的链接列表。 典型的示例是在同一列表条目上调用 RemoveEntryList两次,而不在两个 RemoveEntryList调用之间重新插入列表条目。 可能还有其他变体,例如将条目重复插入到同一列表中。驱动程序释放了包含LIST_ENTRY的数据结构,而不会从其相应的列表中删除数据结构,从而导致稍后在重新使用旧池块后检查列表时检测到损坏。驱动程序在没有正确同步的情况下以并发方式使用LIST_ENTRY样式的列表,导致列表更新撕裂。

在大多数情况下,可以通过向前和向后移动链接列表来识别损坏的数据结构, (dldlb命令可用于此目的) 和比较结果。 向前和向后走之间的列表不一致通常是损坏的位置。 由于链接列表更新操作可以修改相邻元素的列表链接,因此应仔细查看损坏列表条目的邻居,因为它们可能是潜在的罪魁祸首。

由于许多系统组件在内部利用LIST_ENTRY列表,因此驱动程序使用系统 API 管理的各种资源错误可能会导致系统管理的链接列表损坏。

解决方法

确定此问题的原因通常需要使用调试器来收集其他信息。 应检查多个转储文件,以查看此停止代码是否具有类似的特征,例如显示停止代码时正在运行的代码。

有关详细信息,请参阅 使用 Windows 调试器故障转储分析 (WinDbg) 、 使用 !analyze 扩展 和 !analyze。

使用事件日志查看是否存在导致此停止代码的更高级别事件。

这些常规故障排除提示可能会有所帮助。

如果最近向系统添加了硬件,请尝试删除或替换它。 或与制造商联系,查看是否有可用的修补程序。

如果最近添加了新的设备驱动程序或系统服务,请尝试删除或更新它们。 尝试确定系统中导致新 Bug 检查代码出现的原因。

检查事件查看器中的系统日志,以获取可能有助于查明导致错误的设备或驱动程序的其他错误消息。 有关详细信息,请参阅打开事件查看器。 在系统日志中查找与蓝屏同时出现的严重错误。

查看设备管理器,查看是否有任何设备标有感叹号 (!) 。 查看驱动程序属性中显示的事件日志,了解是否有任何故障驱动程序。 请尝试更新相关驱动程序。

运行病毒检测程序。 病毒可能会感染所有针对 Windows 格式化的硬盘类型,由此产生的磁盘损坏可能会检查代码生成系统 bug。 确保病毒检测程序检查主启动记录中的感染。

有关其他常规故障排除信息,请参阅 蓝屏数据

另请参阅

使用 Windows 调试器 (WinDbg) 进行故障转储分析

使用 WinDbg 分析内核模式转储文件

标签:

相关阅读

相关词

推荐阅读