有计划的计算机问题诊断和解决及其自动报告和更新

摘要

在计算系统中有计划地诊断问题的根源。在操作系统中监视事件，并且事件至少一个子集被记录到日志文件。响应错误条件的检测激活诊断模块。诊断模块查询日志文件以关联有关问题的诊断的事件，并通过估算查询结果识别根源。一旦诊断了问题的根源，激活对应于该根源的解决模块，以便有计划地解决问题。能遵循策略规则激活诊断和解决模块。此外，记录、诊断和解决模块能按需要自动地更新。

说明书

                          发明的领域

本发明通常涉及软件，尤其涉及有计划地确定在操作个人计算机时发生的问题的根源，并针对那些问题向用户提供有计划的解决方法和/或丰富的诊断数据。

计算技术已经改变了我们工作和游戏方法。近数十年来，计算技术已经变得十分复杂。此复杂性使计算机系统能完成各种各样的高复杂性功能及应用，从而稳定地改善计算系统的利用。另一方面，那样的复杂性也使即使是最熟练的软件工程师也越来越难以开发那样的软件，使其在所有可能的环境下完全兼容和发挥作用。因而，即使先进的计算系统常常遇到一些问题，如崩溃，系统挂起，或性能退化。

现在要容易地诊断或判定在计算系统中许多问题的根源是困难或不可能的。计算系统的操作系统通常包括一些有限的机制以基本错误消息的形式来识别问题的存在。然而，错误消息不向试图诊断和解决此问题根源或识别避免此问题的变通办法的人提供足够信息。

因为许多不同的应用和设备能在给定时刻在操作系统上运行，且因为在那些组件之间的互操作性能导致复杂的问题，操作系统常常难以确定，哪个应用，设备驱动程序或配置是所面临问题的根源。在各种互操作组件由不同的分销商提供时，互操作性尤其会导致复杂的问题。问题可能牵涉到操作系统、应用、或设备驱动程序，但一旦问题暴露(如系统崩溃)，再提供在解决问题方面任何有用的信息已太晚了。当在操作系统上执行的应用或设备驱动程序不遵循操作系统按步就班的引导时，问题被恶化了。

此外，即使有足够的诊断问题的信息，用户还常需要作许多工作来诊断问题的根源并提供解决方法。用户作许多工作来诊断和解决计算系统的问题的要求会降低用户在用计算系统工作时的感受，尤其是在用户期望只有很少计算系统问题时。

此外，许多用户没有足够经验来自己诊断及解决计算系统的问题。因此，他们会采取他们认为正确的动作，但由于问题的不正确的诊断及解决，这些动作不能解决问题。那些动作实际上会更加恶化计算系统的性能或稳定性。用户还能求助于他人来诊断和解决问题，从而导致用户或帮助解决问题的参与者的不必要的时间或经费上的开销。

为此，使操作系统能更好判定计算系统的问题的根源的系统和方法是有益的。此外，提供用于处理所识别的问题的有计划的措施的系统和方法也是有益的。

                          发明的概述

通过本发明的原理能克服以前技术有关的上述问题，该原则的目标是用于有计划地诊断计算系统中问题的根源的系统和方法。在一个实施例中，方法包括监视由操作系统中合适的装置产生的事件，至少记录事件的子集到日志文件中，并检测一个或多个错误条件。作为响应激活诊断模块。诊断模块查询日志文件关于问题的诊断的事件，并通过估计查询的结果识别根源。一旦诊断到问题的根源，激活对应该根源的解决模块，有计划地解决问题。

用户定义的或默认的策略模块能控制是否和何时激活诊断模块和/或解决模决。因而计算系统的问题能被诊断和解决，从而改善用户的感受，同时仍允许用户对一般的诊断及解决过程有某些程度的控制。在一个实施例中，至少某些查询结果被送到错误报告服务，后者返回多个更新之一到计算系统。这些更新修改记录哪些事件、诊断模块如何诊断、和/或解决模块如何解决。

本发明的其他特征和优点将在下面的描述中说明，部分从描述中可见，或通过本发明的实践掌握。本发明的特征和优点能借助特别在附后的权利要求中指出的装置和组合认识到并获得。本发明的这些和其他特征能从下面描述和附后的权利要求完全明白，或能通过后面提出的本发明的实践掌握。

                          附图简介

为了描述能获得本发明的上述和其他优点和特征的方式，通过参考在附图中说明的特定实施例更具体地描述上面简述的本发明。理解这些附图仅画出本发明的典型实施例而不认为是对其范围的限制，本发明将通过使用附图用特别专一和详细方式加以描述，其中：

图1示出能实现本发明的特征的合适的计算系统；

图2示出能用于实现本发明的特征的更具体的体系结构；

图3示出按本发明的原理在计算系统中有计划地诊断及潜在地解决问题的方法的流程图。

                    较佳实施例的详细描述

本发明涉及在计算系统中有计划地诊断问题的根源的机制。首先加入合适的测试设备以产生描述被诊断的任务的执行状态的事件。这些事件在操作系统中被监视，且至少某些事件被记录到日志文件中。响应错误条件的检测，激活诊断模块。诊断模块查询日志文件关于问题的诊断的事件，并通过估计查询的结果识别根源。一旦诊断了问题的根源，激活对应该根源的解决模块，有计划地解决该问题。能遵循策略规则激活诊断及解决模块。此外，能由更新服务按需要自动地更新检测、诊断和解决模块。

转向附图，其中相同的参考号指的是相同的元件，本发明图示成在合适的计算环境中实现。下面的描述基于本发明的图示实施例，不认为限制不在此直接描述的本发明的其他实施例。

在下面描述中除非特别指出，参考由一个或多个计算机执行的过程及操作的符号表示来描述本发明。因此可以理解，有时称之为计算机可执行的那样的过程和操作包括由计算机的处理单元对以结构形式表示数据的电信号的处理。此处理转换了数据或将其保存在计算机的存储系统的位置中，它以本专业行家众知的方式重新配置或更换计算机的操作。保存数据的数据结构是存储器的物理位置，它们具有由数据的格式确定的特定特性。然而，虽然本发明是在述背景中描述的，但这不意味着限制于此，因为本专业行家将会理解，后面描述的各种过程和操作也能在硬件中实施。

参考图1，本发明涉及监视软件应用和硬件的可靠性及可用性。软件应用驻留在计算机上，它可以具有多个不同计算机体系结构中的一个。为了说明，图1示出可用于这些设备的示例计算机体系结构的原理图。画出的体系结构仅是合适环境的一个例子，不是想要对本发明的使用或功能的范围提出任何限制。对于图1中示出的任何组件或其组合，该计算设备不认为有任何的依赖性或需求。

本发明可选用各种其他的通用或专用计算或通讯环境或配置。适用于本发明的众知的计算系统、环境和配置的例子包括移动电话、口袋计算机、个人计算机、服务器、多处理系统，基于微机的系统、小型机，大型主机和包括任何上述系统或设备的分布式计算环境，但不限于这些。

在其最基本的配置中，计算系统100通常包括至少一个处理单元102和存储器104。存储器104能是易失的(如RAM)/非易失的(如ROM，闪存等)，或者两者的某种组合。此最基本的配置在图1中由虚线106框出。

存储介质设备能具有另外的特征和功能。例如，它们能包括附加的存储器(可移动的及不可移动的)，包括但不局限于PCMCIA卡、磁盘和光盘、和磁带。那些附加存储器在图1中由可移动存储器108和不可移动存储器110示出。计算机存储介质包括以任何方法或技术实现的易失和非易失，可移动和不可移动介质，用于存储如计算机可读指令、数据结构、程序模块、或其他数据那样的信息。存储器104、可移动存储器108、和不可移动存储器110均是计算机存储介质的例子。计算机存储介质包括RAM、ROM、EEPROM闪存、其他存储技术、CD-ROM、数字多功能盘，其他光存储器、盒式磁带、磁带、磁盘存储器，其他磁存储设备、和其他能用于存储所希望的信息并能由计算设备访问的介质，但不限于这些。

这里使用的术语“模块”或“组件”指的是在计算系统上执行的软件对象或例行程序。这里描述的不同组件、模块，引擎和服务能作为在计算系统上执行的对象或过程(如作为独立的线程)实现。虽然这里描述的系统和方法最好以软件实现，以软硬件或硬件实现也是可能的并也是预期的。

计算设备100还能包括允许主机与其他设备通讯的通讯通道112。通讯通道112是通讯介质的例子。通讯介质通常体现在计算机可读指令，数据结构，程序模块，或其他以如载波或其他传输机制那样的调制数据信号形式的数据上，并包括任何信息提交介质。术语“调制数据信号”指的是具有一个或多个以编码信号中信息的方式设置或改变的特征的信号。例如，通讯介质包括如有线网络和直接线连结那样的有线介质，和如声音、无线电、红外和其他无线介质那样的无线介质，但不限于这些。这里使用的术语“计算机可读介质”包括存储介质和通讯介质两者。

计算设备100还具有如键盘，鼠标，输入笔，语音输入组件，接触输入设备等那样的输入组件114。输出组件116包括屏幕显示、扬声器、打印机等，以及驱动它们的演示模块(常称为“适配器”)。计算设备100具有电源供应118。所有这些组件是业内所众知的，不必在此多作讨论。

图2示出能用于实现本发明的特征的更具体的体系结构200。体系结构200包括与远程计算系统236通讯的计算系统201。然而，即使没有远程计算系统236的帮助计算系统201也能实现本发明的特征，但是没有下面描述的更新服务的特征。虽然不是必须，计算系统201和236的每一个可以象上述对于计算系统100描述的那样地构造。

图3示出按本发明的原理用于有计划地诊断和潜在地解决问题的方法的流程图300。因为方法300能在体系结构200的环境实现，将频繁地互相参考图2和3来描述它们。

在图3中，方法300包括监视在操作系统中的事件的过程(过程301)。参考图2，被监视的事件由在这里一起称为“事件提供者262”的一系列操作系统(OS)组件，驱动程序和服务262产生。事件提供者262将事件202通知记录器204。在一个实施例中，在任何给定时刻收集的数据量受限于当时现有的环境。因此，记录器204处理较少量事件。因而，任何给定的事件提供者不必对每个检测到的交互作用产生事件，而只能产生关系到问题根源的更有关的事件。例如，不需要每当盘驱动器写到扇区时产生事件。然而若盘驱动器未能响应读或写的命令，或试图写入禁写扇区时，应产生一事件。

事件提供者262的例子包括管理电源，即插即用(PnP)操作、存储管理、总线控制(如PCI)、和其他低层API(应用程序界面)的软件模块。其他操作系统组件(或应用或驱动程序)也能向记录器204提出事件。其他操作系统组件的例子包括网络模块、图象模块、音频模块、和打印模块。

通知记录器204的事件类型的例子包括用户请求、系统调用、设备连接、通讯请求等。例如，一个事件可描述用户已请求将计算系统201置于低功率或待机状态，和在用户请求不成功时帮助用户或支持工程师诊断或解决待机失败的后续事件。例如，待机失败可包括那个应用或驱动程序禁止该请求置于低功率状态。然而，可由操作系统检测的任何其他事件能由事件提供者262向记录器204提供。

在计算系统201(尤其是记录器204)监视事件(过程301)时，记录器204记录事件的至少一个子集到日志文件(过程302)。例如，事件追踪日志文件248表示那样日志文件的例子，记录器204配置成记录事件202的全部或一部分。可选地，记录器能配置成记录最可能有助于诊断问题的那些事件。记录器204还能通知诊断策略服务208关于这些事件。在某些实施例中，流向诊断策略服务208的事件的量远低于流向事件追踪日志文件248的事件的量。例如，记录器204在事务开始或终止时或在发生错误条件时简单地通知诊断策略服务208。

在记录监视的事件的至少一子集(过程302)的某点处，计算系统201检测一个或多个错误条件(过程303)。参考图2，这能由诊断策略服务208完成。诊断策略服务208例如通过检测预定的单个错误条件，或通过检测已发生的错误条件的预定序列判断，何时发生实际的问题。

一旦检测到问题，计算系统201完成一功能的、面向结果的步骤，来有计划地诊断由一个或多个错误条件证实的问题(步骤310)。这可包括用于完成此结果的任何对应过程。然而在图示实施例中，这包括从311到314的对应过程。

在实际上通过激活诊断模块完成有计划的诊断之前(过程311)，计算系统201可查询规则，以确定应该按该规则激活诊断模块(过程304)。规则能由所接收的用户输入指令设置，或多半是默认设置。因而，诊断策略服务208通过监视服务212间接地连接诊断模块220。

监视服务212应用策略来过滤，哪些事件被传播，直到激活用于判断根源的诊断模块220。何时希望过滤那样的事件的例子包括那样的企业环境，在那里信息技术(IT)经理或系统管理员希望操作系统不完成某些自动的根源判断和/或自动地问题解决过程。例如，IT经理希望得知问题的发生，但是没有自动的根源分析或不发生任何自动的解决。或IT经理希望有根源分析，但没有自动解决。

例如，计算系统201在响应判断根源问题时可以采取的一个过程可以是自动安装更新的设备驱动程序。因为在某些情况，更新的设备驱动程序能引起不可预见的操作改变，企业的IT经理可输入216策略214，规定用户不能或无权更新设备驱动程序。IT经理能应用于监视服务212的策略的其他例子是不采取自动的问题解决步骤。这将允许用户或IT经理决定是否完成过程，而不是让计算系统201自动地完成过程。

若其存储的政策允许，当由诊断政策服务208检测到一个或多个错误条件的特定组时，监视服务212激活218合适的一个诊断模块220(过程311)。另选地，合适的诊断模块能由诊断策略服务208或由事件提供者262之一直接激活(如在没有监视服务212的实施例中)。计算系统201可包括多个诊断模块，每个用于诊断预定的错误条件或预定的错误条件序列的根源。

每个诊断模块在激活时被配置成查询和关联242相关的数据源，以诊断由一个或多个错误条件证实的问题(过程312)，确定关于在此问题事件之前的哪些事件和/或状态的信息。例如，那样的相关数据源可包括事件追踪日志248、配置数据库252、如记录、系统兼容性管理程序254、WMI提供程序256、和其他数据源及日志文件250。

根据特定的操作系统实施，除了图中示出的源或代替它们，可以查询。其他日志文件250(如网络状态日志)和其他数据源。

系统兼容性管理程序254是一个服务，它从不同的子系统(如PCI总线子系统、USB子系统、和AGP子系统)和系统中其他总线驱动程序和驱动程序堆栈中接收有关已知硬件异常情况的状态和错误消息，这些异常情况需要设备特定的变通办法，以允许有问题的硬件正常地发挥作用。那样的变通办法能影响设备如何发挥功能，并从而不再成为最终用户感觉到的问题的根源。WMI提供程序揭示了有关系统上硬件设备的诊断信息。

诊断模块估算查询的结果244(过程313)，并响应该估算识别一个或多个错误条件的根源(过程314)。这可通过运行对应于错误条件的诊断例行程序来完成。至少某些诊断模块的每一个(以及至少某些解决模块224和诊断策略服务208)可具有插入能力，以考虑更少地修改对应的诊断模块。尤其在一个实施例中，诊断模块220将查询结果与根源关联的表比较。这就完成了有计划地诊断由一个或多个错误条件证实的问题的步骤(步骤310)。

若查询结果244与识别的根源相关，激活的诊断模块220能激活合适的解决模块224(过程308)，以完成对应于被识别的根源的识别的解决方法。对一个问题已识别的根源的已知存在的某个问题。将查询专门做成能诊断是否存在问题。监视服务212可再次考虑存储的策略，以判断是否按照规则激活解决模块(过程307)。因而，诊断模块首先通知222A监视服务212有关根源。若存储的策略允许，监视服务212激活222B合适的解决模块224。也可有多个解决模块224，每个与一个或多个根源的不同组相关。每个解决模块也可具有插入能力，以考虑较少的所需修改。

每个解决模块224可配置错误解决例行程序，它们能遵循在监视服务212中的策略由合适的诊断模块激活。错误解决例行程序的例子包括搜索和/或安装新的设备驱动程序，或禁止或重新配置冲突的设备驱动程序或应用。在一个实施例中，至少某些例行程序自动地完成(即不需要用户输入)。然而，某些解决模块可利用通过激活228诊断用户界面模块232(如“故障检修导引”)获得的用户输入。可连接诊断用户界面模块232以提示用户输入附加信息，为合适的解决模块(或为整个计算系统)使用，以求识别或解决问题。在一个或多个错误条件的根源在缺少进一步的用户帮助的情况不能有计划地识别和/或解决时，这特别有用。

在解决模块224和诊断用户界面232之间的交互由双向箭头228A表示。在诊断模块220和诊断用户界面232之间的交互由双向箭头228B表示。诊断用户界面232也能允许用户与事件产生器262交互228C以修改产生什么事件。

故障检修应用264提供一用户界面，允许用户直接向监视服务212报告问题，而不是等待监视策略服务208检测此问题。然后诊断模块220诊断所报告问题的根源，接着解决模块224解决该问题。

有时，修改记录什么事件，诊断模块如何诊断，或解决模块如何解决所识别的问题的根源是有益的。例如，也许诊断模块不能根据记录的事件诊断问题，或也许解决模块不作修改不能恰当地解决问题。因而，从诊断策略服务208、诊断模块220、解决模块224和/或诊断用户界面模块232来的信息能传递给过程日志230，用于向错误报告服务238报告(过程305)。例如，解决模块如箭头226所示地向过程日志230报告。

还能向用户显示过程日志230，允许用户看到检测到的问题、诊断的结果是什么、和如何解决被诊断到的问题。过程日志也能提供给远端，以允许技术支持部门看到有关事实，而不必依赖用户讲述有关事实。过程日志230也能送到的错误报告服务238，以协助形成有关在用户系统通常发生那些问题的统计信息。

更新服务240可用来发送更新到计算系统201的一个或多个模块，让计算机系统201接收(过程306)。例如，更新服务240能用附加的事件或事件序列，更新记录器，以存储到事件追踪日志文件248，帮助解决由错误报告服务238，或由其它有关用户经历故障的信息源检测到的新问题的根源。更新服务240也能更新诊断策略服务208，以改变如何检测问题。更新服务240也能用于更新(改变现有模块，提供新的模块，或增加或修改插入模块)一个或多个诊断模块220和解决模块224，以反映对特定问题确定的新的解决方法。在一个实施例中，更新服务240由分销商的计算系统236操作，并通过因特网发送更新的计算系统201的模块。另选地，第三方能提供定制改变或整个新模块以及配置信息。

若错误事件没有已知的与其相关的根源，诊断模块220将报告此信息到过程日志230，它转而发送错误报告234到错误报告服务238。

若分销商能够从由过程日志230发送的信息判定根源，根源相关的信息和对应的问题解决信息通过更新服务240被送到计算系统201。若分销商不能判定根源，分销商能使用更新服务240，命令诊断策略服务204以存储附加的事件或状态信息到事件追踪日志文件248。解决模块224能类似地命令260记录器存储附加事件224，以保证达到合适的解决。当附加的信息在下次发生问题之后发送到错误报告服务238时，该附加信息使分销商能更好地识别问题的根源。

错误报告234能在诊断已知的根源之前被发送。早期报告错误允许更新服务240在试图诊断和解决之前更新要更新的诊断模块220和/或解决模块224。另选地，错误能在诊断之后而在解决之前报告234。在那种情况，更新服务240能更新专用于解决特定诊断的问题的特定解决模块。

可配置诊断策略服务208、诊断模块220、和解决模块224，以报告它们的过程到过程日志230(如检测到错误、诊断模块被激活、诊断模块采取某些步骤、根源被找到且就是它、根源不能判定、解决模块被激活、解决模块采取这些步骤、问题被解决，问题未解决等)。这就向分销商提供关于系统是否正诊断问题和问题是否被解决的信息。此信息对分销商是有价值的，因为它可用于判断诊断模块220或解决模块224是否需要更新。信息对于分销商理解哪些问题对终端用户是最普遍的是有用的，从而允许分销商按此信息工作。例如，分销售能通过创建新的体系结构作出响应，以避免将来再发生该普遍的问题。

错误报告234甚至能在诊断已知根源之前发送。早期报告错误允许更新服务240在试图诊断及解决之前更新诊断模块220和/或解决模块224。另选地，错误能在诊断后但在解决前报告234。在此情况，更新服务240能更新专用于解决特定的诊断出的问题的特定的解决模块。

如上所述，能通过更新服务240更新的一个例子是用于解决模块224的新的问题解决方法。若已识别出特定类型的错误，但根源难以判定，更新能命令事件提供者或记录器存储更多的事件信息到事件追踪日志文件248。将允许诊断模块220发送更详细的住处到过程日志230，后者发送更详细的信息到错误报告服务。在判定根源和解决问题时，附加信息有时能帮助分销商的计算系统236。接着，能下载新的诊断及解决模块以处理此问题。

因而已描述了遵循内部的策略约束有计划地诊断和解决问题的机制。此外，该机制在需要时自我更新，以便更好地诊断错误条件的根源，并解决此根源。