如何使用Windows事件查看器排查错误？

首先打开事件查看器，重点查看“windows日志”下的“应用程序”和“系统”类别；1. 通过筛选“错误”和“关键”级别事件，结合问题发生的时间点，快速定位异常记录；2. 分析“事件id”和“事件源”，如“应用程序”日志中“application error”源和事件id 1000表示程序崩溃，“系统”日志中“kernel-power”源和事件id 41表示非正常关机；3. 双击事件查看详细信息，记录故障模块名称、异常代码等关键线索；4. 利用事件id和源作为关键词进行在线搜索，查找已知解决方案；5. 对于系统崩溃，检查id 41前的错误事件以追溯根本原因，如驱动或硬件问题；对于应用无响应，结合.net runtime或windows error reporting等事件综合判断，最终通过日志线索锁定问题根源并解决。

Windows事件查看器是Windows系统内部的“黑匣子”，它忠实地记录着系统运行中的一切活动，从正常的启动关闭到各种错误、警告，甚至是安全事件。当你遇到系统崩溃、应用程序无响应或者一些难以解释的怪异行为时，事件查看器就是你深入挖掘问题根源的关键工具。它能帮助你定位问题发生的时间点、涉及的组件，甚至直接给出错误代码，让你能更快地找到解决方案。

解决方案

要使用Windows事件查看器排查错误，你需要做的，是把它当成一本详细的系统日记来阅读。

首先，打开事件查看器。最简单的方法就是在Windows搜索栏里输入“事件查看器”并打开。你会看到一个左侧导航栏，里面列出了不同的日志类别。对于排查系统和应用程序错误，我们主要关注“Windows 日志”下的“应用程序”和“系统”这两个类别。

• 应用程序日志：这里记录了你安装的各种软件运行时的事件，包括启动、关闭、崩溃以及它们报告的错误和警告。如果某个程序经常崩溃，这里通常能找到线索。
• 系统日志：这部分日志记录的是Windows系统核心组件、驱动程序以及硬件相关的事件。系统蓝屏、服务启动失败、硬件故障等问题，往往在这里留下痕迹。

点击进入这些日志后，你会看到一长串的事件列表。每一个事件都有其独特的“级别”（如“错误”、“警告”、“信息”、“成功审核”、“失败审核”）、“日期和时间”、“源”（哪个组件或程序产生了事件）、“事件 ID”以及“任务类别”。

排查错误时，我的经验是优先关注“错误”和“关键”级别的事件。这些通常是问题的直接表现。你可以通过点击列表上方的列标题来排序，比如按“级别”排序，这样就能把所有错误和警告事件快速地集中起来。

找到可疑事件后，双击它，会弹出一个“事件属性”窗口，里面包含了更详细的信息，比如事件描述、二进制数据等。这个描述往往是解决问题的关键，它可能会告诉你哪个文件损坏了、哪个服务未能启动，或者哪个驱动程序崩溃了。记下“事件 ID”和“源”，这些信息在后续的在线搜索中会非常有用。

你也可以利用右侧的“筛选当前日志”功能，这能极大地提高效率。你可以根据事件级别（只显示错误和关键）、事件源、事件ID，甚至特定的关键词来筛选日志，这样就能迅速缩小范围，聚焦到真正有用的信息上。

如何快速定位关键错误信息？

在海量的日志条目中迅速找到有用的错误信息，确实是件需要技巧的事。我觉得，最有效的方法就是利用好事件查看器自带的筛选和搜索功能，同时结合你对问题发生时间的记忆。

当你打开“应用程序”或“系统”日志时，日志列表可能会非常长。这时，不要急着一条条看。我的习惯是先回忆一下问题大概是什么时候发生的。比如，如果电脑是在今天下午2点突然蓝屏的，那么我就会把日志的时间范围缩小到下午2点前后。你可以通过右侧的“筛选当前日志”功能来设定时间范围，或者直接点击“日期和时间”列头，按时间倒序排列，然后手动滚动到那个时间点附近。

接下来，就是利用“事件级别”筛选器。我通常会只勾选“关键”和“错误”这两个级别。因为大多数时候，我们排查的是问题，而不是正常的系统行为。这样一来，无关的“信息”和“警告”事件就会被隐藏，日志列表会变得清爽很多。

有时，你可能已经知道某个特定的程序或服务出了问题。比如，Photoshop老是崩溃。这时，你就可以在筛选器中指定“事件源”为“Application Error”或者“Photoshop”。这能让你直接跳到与该程序相关的错误记录。

如果这些还不够，你还可以尝试在筛选器中输入特定的“事件 ID”。很多常见的错误都有固定的事件ID，比如系统蓝屏后重启，系统日志中往往会有“Kernel-Power”的事件ID 41。当你对某个错误有了初步判断后，直接搜索这个ID会非常精准。

在具体查看事件的详细信息时，重点关注“常规”选项卡下的描述文字。这里通常会直接指出问题所在，比如哪个模块导致了崩溃，或者哪个文件无法访问。如果描述中提到了特定的文件名（比如

.dll

.sys

事件ID和源是什么，它们如何帮助排查？

事件ID和事件源，在我看来，是事件查看器里最重要的两个标识符，它们就像是错误的“身份证号”和“出生地”。理解它们，能让你在浩瀚的错误信息中迅速找到方向。

事件ID（Event ID） 是一个数字代码，它唯一标识了某个特定类型的事件。比如，所有的应用程序崩溃事件可能都共享一个特定的事件ID（例如，常见的应用程序崩溃是事件ID 1000），而所有成功的服务启动事件则有另一个ID。这个ID本身并不直接告诉你错误是什么，但它是一个通用的“错误类型”标签。想象一下，就像图书馆里的书号，它告诉你这是一本“计算机类”的书，但具体内容还需要看书名。

事件源（Source） 则指明了生成这个事件的应用程序、服务、驱动程序或操作系统组件。这就像是错误的“制造者”或者“报告者”。例如，“Application Error”通常表示是某个应用程序自身的问题；“Service Control Manager”表示某个服务启动或停止时出现了问题；“Disk”可能意味着硬盘出现了故障；而“Kernel-Power”则通常与系统电源管理或非正常关机有关。

那么，它们如何帮助排查呢？

挖错网

一款支持文本、图片、视频纠错和AIGC检测的内容审核校对平台。

28

查看详情

它们共同构成了一个独特的“签名”。当你在事件查看器中看到一个“错误”级别的事件时，记下它的“事件ID”和“源”是非常关键的第一步。

举个例子，如果我看到一个在“应用程序”日志中，源是“Application Error”，事件ID是1000的错误，我立刻就知道这是一个程序崩溃了。更进一步，详细信息里通常会显示“故障模块名称”和“故障偏移量”，这会告诉我具体是哪个程序文件或DLL库导致了崩溃。

更重要的是，有了“事件ID”和“源”，你就可以把它们作为关键词，直接扔到搜索引擎里进行查询。比如，搜索“Event ID 1000 Application Error”或者“Event ID 41 Kernel-Power”。通常，你会找到大量的在线论坛讨论、微软官方文档、或者其他技术博客，它们会详细解释这个ID和源组合通常代表什么问题，以及可能的解决方案。这就像是拿到了问题的诊断报告，很多人可能已经遇到并解决了同样的问题。

在我看来，事件ID和源的结合，是连接本地问题和全球解决方案的桥梁。很多时候，我们不需要自己从零开始分析，因为前人已经踩过坑，并分享了他们的经验。

如何利用事件查看器分析系统崩溃和应用程序无响应？

分析系统崩溃（比如蓝屏死机，BSOD）和应用程序无响应（程序卡死、闪退）是事件查看器最常见的用途之一。这需要一些侦探工作，因为直接的“错误”事件可能只是结果，而不是原因。

分析系统崩溃（蓝屏死机）

当你的电脑发生蓝屏并重启后，第一时间应该去查看系统日志。

通常，系统日志中会有一个“关键”级别的事件，其“源”为“Kernel-Power”，“事件 ID”为 41。这个事件表示系统在未正常关机的情况下突然重启。它本身并不直接指出蓝屏的原因，但它告诉你确实发生了非预期的关机。

真正有价值的信息，往往隐藏在这个事件ID 41 之前的日志条目里。你需要倒着看时间线，寻找在事件ID 41发生前几秒或几分钟内的“错误”或“警告”级别的事件。这些事件可能揭示了导致蓝屏的根本原因：

• 驱动程序问题：你可能会看到某个驱动程序（源可能是

  Disk

  登录后复制
  、

  nvlddmkm

  登录后复制
  （NVIDIA显卡驱动）、

  igfx

  登录后复制
  （Intel显卡驱动）或其他硬件相关源）报告了错误，或者在加载时失败。
• 硬件故障：比如硬盘错误（源为

  Disk

  登录后复制
  ，事件ID可能是11或153），或者内存相关的问题。
• 服务崩溃：某个关键系统服务在蓝屏前崩溃了。
• 文件系统损坏：

  Ntfs

  登录后复制
  源的错误可能指示文件系统问题。

有时，系统会生成一个内存转储文件（dump file）。事件查看器中可能会有相应的事件指示这个文件的生成。你可以使用专门的工具（如WinDbg）来分析这个转储文件，它会更精确地指出导致蓝屏的驱动程序或模块。但对于大多数用户来说，事件查看器中的前置错误已经足够提供方向了。

分析应用程序无响应或崩溃

对于应用程序的无响应或崩溃，我们主要关注应用程序日志。

最常见的崩溃事件是“源”为“Application Error”，“事件 ID”为 1000。双击这个事件，在“常规”选项卡下，你会看到非常详细的崩溃信息，包括：

• 故障应用程序名称：哪个程序崩溃了（比如

  Photoshop.exe

  登录后复制
  ）。
• 故障模块名称：导致崩溃的具体DLL文件或程序模块（比如

  mfc140u.dll

  登录后复制
  或

  kernelbase.dll

  登录后复制
  ）。
• 故障偏移量：崩溃发生的代码位置。
• 异常代码：指示了崩溃的类型。

这些信息至关重要。例如，如果故障模块名称指向某个显卡驱动相关的DLL，那可能就是显卡驱动有问题。如果指向某个第三方插件的DLL，那问题可能出在那个插件上。

除了事件ID 1000，你可能还会看到：

• “源”为“.NET Runtime”，事件ID通常是 1026 或 1023，这表明基于.NET Framework的应用程序遇到了运行时错误。
• “源”为“Windows Error Reporting”，事件ID通常是 1001，这表示Windows错误报告服务已经收集了崩溃信息。

与系统崩溃类似，你也要留意崩溃事件发生前几秒或几分钟内，应用程序日志中是否有其他“警告”或“错误”事件，它们可能指示了内存不足、文件访问权限问题、网络连接中断等，这些都可能是导致最终崩溃的诱因。有时候，一个程序表面上“无响应”，但在事件日志里，它可能一直在尝试访问某个不存在的资源，或者某个后台服务未能及时响应，最终导致程序挂起。

总而言之，无论是系统崩溃还是应用无响应，事件查看器都是你了解“案发现场”的关键工具。它不会直接告诉你“凶手是谁”，但它会提供大量的线索，指引你找到真相。

以上就是如何使用Windows事件查看器排查错误？的详细内容，更多请关注php中文网其它相关文章！