Win10事件查看器报错Id19 win10事件查看器错误多

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

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

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

首先，打开事件查看器。最简单的方法就是在Windows搜索栏里输入“事件查看器”并打开。你会看到一个左边导航栏，里面列出了不同的日志类别程序错误。对于排查系统和应用程序程序错误，我们关注“Windows 应用程序日志：这里记录了您安装的各种软件运行时的事件，包括启动、关闭、崩溃以及它们报告的错误和警告。如果某个程序经常崩溃，这里通常可以找到线索。系统日志：这部分日志记录的是Windows系统核心组件、驱动程序以及硬件相关的事件。系统蓝屏、服务启动失败、硬件故障等问题，往往在这里留下痕迹。

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

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

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

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

在海量的日志边界中快速找到有用的错误信息，确实是一件需要技巧的事。

我觉得，最有效的方法就是利用好事件查看器自带的筛选和搜索功能，同时结合你对问题发生时间的记忆。

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

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

有时候，你可能已经知道某些特定的程序或服务催生的问题。比如，Photoshop 老是崩溃。最近，你就可以在筛选器中指定“事件源”为“应用程序”

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

在具体查看事件的信息详细时，重点关注“常规选项”卡下的文字。这里通常会直接指出描述问题所在，比如哪个模块导致崩溃，或者哪个文件无法访问。如果描述中提到了特定的文件名（比如.dll登录后或.sys登录后复制复制文件），这往往就是下一步排查的关键线索。有时候，错误描述会非常技术性，甚至包含内存地址，接下来你可能需要将这些信息复制出来，结合事件ID和源，在搜索引擎上进行二次查询。事件ID和源是什么，它们有助于排查？

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

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

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

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

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

举个例子，如果我在“应用程序”日志中看到一个，源是“Application错误”，事件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发生前几秒或三十内的“错误”或“警告”级别的事件。这些事件可能揭示了导致蓝屏的根本原因：驱动程序问题：你可能会看到某些驱动程序（来源可能是磁盘登录后复制登录后复制、nvlddmkm登录后复制（NVIDIA显卡驱动）、igfx登录后复制（Intel显卡驱动）或其他硬件相关源）报告了错误结果，或者在加载时失败。硬件故障：比如硬盘错误（源为磁盘登录后复制登录后复制，事件ID可能是11或153），或者内存相关的问题。服务崩溃：某个关键系统服务在蓝屏前崩溃了。文件系统损坏：Ntfs登录后复制源的错误可能表明文件系统问题。

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

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

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

最常见的崩溃事件是“源”为“应用程序” Error”，“事件ID”为1000。其次这个事件，在“常规”选项卡下，你会看到非常详细的崩溃信息，包括：故障应用程序名称：哪个程序崩溃了（比如Photoshop.exe登录后复制）。

故障模块名称：导致崩溃的具体DLL文件或程序模块（比如mfc140u.dll登录后复制或kernelbase.dll登录后复制）。故障偏移量插件：发生崩溃的代码位置。代码异常：指示了崩溃的类型。

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

除了事件ID 1000，你可能还会看到：“源”为“.NET Runtime”，事件ID通常为1026或1023，这表明基于.NET Framework的应用程序遇到了运行时错误。“源”为“Windows错误报告”，事件ID通常为 1001，这表示Windows错误报告服务已经收集了崩溃信息。

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

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

以上内容就是如何使用Windows查看排查器查错？的详细内容，更多请关注乐知网其他相关文章！

以上内容就是如何使用Windows查看排查器查出错误？