CN101553769A - 用于跟踪并监控计算机应用的系统和方法 - Google Patents

Abstract

提出了一种用于对来自计算机目标应用程序表示层的事件进行监控的系统和方法。所述方法包括独立于对所述目标应用的源代码的重编译，提供在所述目标应用内的层运行的脚本。该脚本扫描目标应用程序的对象的运行期实例，并实时地为所述对象实例分配结构。对分配的结构进行调整，以创建所述目标应用结构的反映。该反映与检测到的与预定对象结构相匹配的对象实例共同用于捕获检测到的对象的环境谱的至少一部分。此外，所述系统可对发生在服务器和客户/本地化机器中至少之一上的状态机事件进行处理；将状态机事件与环境谱相关联，并基于相关联的状态机事件演绎出用户经验。

Description

用于跟踪并监控计算机应用的系统和方法

版权

本专利文件的一部分公开包含版权保护的资料。当这些资料出现在美国专利和商标局的文件或记录中时，版权所有者不反对任何人对该专利文件或专利公开进行传真复制，但在其它情况下，版权所有者保留全部任何的版权。

技术领域

本发明涉及用于对用户与计算机应用程序的交互进行监控的系统和方法，更特别地，涉及对会话期间的用户/应用程序交互，以及应用程序的性能和其影响用户的行为进行监控和分析。

背景技术

在现在的公司中，企业应用程序提供了进行商业处理的功能。并且，在复杂的全球经济中，为了满足商业需求，这些应用程序已变得非常复杂。无论是对于应用程序上的用户性能还是对于用于用户的应用程序性能的测量来说，获得管理应用程序的技能、构建在日益发展的基础设施上的变化的应用程序以及系统测量的努力都是一种挑战。

通常，用户监控产品可分为几类：性能监控捕获、HTTP监控、HTTP捕获、主机应用程序运行时间源码插入、以及主机应用程序开发源码插入或编译。下列产品代表其各自的类别。

有些产品在终端用户的计算机上监控并捕获性能。包括马萨诸塞州威斯特福特(Westford)市的瑞幅森软件公司(Reflectent Software，Westford，MA)出售的名为EdgeSight视图(EdgeSight views)的产品，其从终端用户的角度对应用程序和IT服务的性能和可用性进行实时的和历史的量化，从而能了解具体的应用程序是如何执行和利用的。当出现崩溃、错误或钩子(hook)时，所需的信息和鉴定数据马上就可用于查明问题的根本原因。其不根据主机应用程序的GUI表示层生成监控数据，且不监控事务之间的任何活动。其不能在泛型分类集中检测GUI对象子集。其不能在GUI层支持主机应用程序的多实例。其不能实现函数调用的方法监控。其不支持用于高效快速处理的分布式的本地和远程状态机。

传统的产品可用于在客户计算机上监控HTTP业务。例如，加利福利亚州芒廷维尤市的水银公司(Mercury Corporation，Mountain View，CA)的终端用户监控(End User Monitoring)就从终端用户的角度主动地对网站和应用程序的可用性进行实时监控。其主动地模仿终端用户对应用程序的业务处理。但是其不根据主机应用程序的GUI表示层生成监控数据，且不监控事务之间的任何活动。其不能在泛型分类集中检测GUI对象子集，且不能执行方法监控。其不能在GUI层支持主机应用程序的多实例。其不支持用于高效快速处理的分布式的本地和远程状态机。

一种由蜡烛公司(Candle Corp.)(IBM/Tivoli)出售的商标为ETEWatch的产品对应用程序加载屏幕或执行动作时的事务层端对端响应时间(即，用户经历的等待时间)进行测量。其不从主机应用程序的GUI表示层生成监控数据，且不监控事务之间的任何活动。其不能在泛型分类集中检测GUI对象子集。其不能在GUI层支持主机应用程序的多实例。其不能实现函数调用的方法监控。其不支持用于高效快速处理的分布式的本地和远程状态机。

一种由密歇根州底特律市的计算软件公司(Compuware，Detroit，MI)出售的商标产品将应用程序性能数据和事件与对业务重要的因素(例如，应用程序、事务、角色和位置)相关联。附加视图将终端用户响应时间度量与扩展的故障诊断能力相结合。这就允许IT组织能解决性能问题并能主动地管理其应用程序和基础设施。其不从主机应用程序的GUI表示层生成监控数据，且不监控事务之间的任何活动。其不能在泛型分类集中检测GUI对象子集。其不能在GUI层支持主机应用程序的多实例。其不能实现函数调用的方法监控。其不支持用于高效快速处理的分布式的本地和远程状态机。

有些产品在服务器上捕获HTTP业务。一种由加利福利亚州旧金山市的茶叶技术有限公司(TeaLeaf Technology，Inc.of San Francisco，CA)出售的名为RealiTea的产品实时地主动捕获每个顾客所做的和所看到的，使得能够对问题进行立即的检测、分析和响应。其根据通过多步骤业务处理的期望输出，对对每个用户的独特动作进行验证。但是其不根据主机应用程序的GUI表示层生成监控数据，且不监控事务之间的任何活动。其不能在泛型分类集中检测GUI对象子集，且不能执行方法监控。其不能在GUI层支持主机应用程序的多实例。其不能透明地实现，且需要对应用程序源码进行修改或需要来自编译处理的某些输出。其不支持用于高效快速处理的分布式的本地和远程状态机。

有些产品在运行时间将代码插入到主机应用程序中。一种由维尔公司(Veritas)出售的商标为i³的产品主动地监控、分析并调谐SAP、Siebel等应用。通过对来自应用基础设施的每个支持级(网络服务器、应用程序服务器、数据库和存储器)的性能度量进行捕获、测量和关联，其提供了应用程序性能的完整观察。当该产品确实地看到GUI事件时，其被限制为网络应用，并且不能对泛型GUI对象集进行检测。此外，其需要在网站插入源码，这种插入是非常侵入性的过程，并且不是透明的实现过程。该Veritas产品不能从操作系统层直接检测到任何事情。其不能从组件方法(即，函数)或从具有Win32应用程序的接口中直接地检测事件或检索属性。此外，通过该Veritas产品，不可能对多种不同应用类型(如web和Win32)同时测量。此外，在没有用于执行实时警报的固定状态机的各页面之间缺乏持久性。此外该产品还不支持用于高效快速处理的分布式的本地和远程状态机。

有些产品使用在开发期对源码进行编译得到的文件。由纽约州纽约市的识别软件公司(Identify Software，New York，NY)出售的服务器和/或客户机上的名为AppSight黑盒(AppSight Black Box)的产品基于动态的用于定义的记录简档(profile)记录多个同步层上的应用程序执行。黑盒(Black Box)不要求改变源码或可执行程序。客户方能够对用户的动作和屏幕事件进行视频捕获。该产品不进行事务响应测量。此外，当该产品执行一种形式的方法监控时，其依赖在源码开发时通过编译生成的文件，并且不严格地支持透明实现过程。该申请中描述的当前发明不需要编译后的源文件就实现了方法监控，并且还对函数返回进行监控。上述产品不在GUI对象模型的GUI对象层根据主机应用程序的GUI表示层生成监控数据；不能在泛型分类集中检测GUI对象子集；不能在GUI层支持主机应用程序的多实例；不能透明地实现，且需要对应用程序源码进行修改或需要来自编译处理的某些输出；以及不支持用于高效快速处理的分布式的本地和远程状态机。

题为“应用程序的端对端响应时间测量和分解(ApplicationEnd-To-End Response Time Measurement and Decomposition)”的第6,108,700号美国专利涉及一种端对端测量，其通常跨越全部同级，并为用于合并各种数据类型的框架。题为“万维网终端用户请求时间监控器(World Wide Web End User Response Time Monitor)”的第6,078,956号美国专利公开了HTTP层的监控请求，其中，先计算与第一HTTP请求相关联的响应时间，然后将其传递至服务器并存入用于之后使用。题为“使用开始和结束队列对计算机程序进行端对端响应时间测量(End-To-End Response Time Measurement for ComputerPrograms Using Starting and Ending Queues)”的第5,991,705号美国专利及第6,202,036号的延续申请涉及用于测量计算机执行的事务的端对端响应时间的系统。题为“用可插入事件队列监控事件序列操作的装置和方法(Apparatus and Method for Monitoring Event QueueOperations With Pluggable Event Queues)”的第6,189,047号美国专利公开了定制消息队列的使用，由于用户GUI交互，其反应了由应用程序使用的系统消息队列。以上所述的每个美国专利的全文都通过引用并入本文。

特别地，现有专利5,991,705、6,108,700和6,078,956都未公开可根据主机应用程序的GUI表示层生成监控数据的方法或系统。现有技术中的技术都不支持用于高效快速处理的分布式(本地的和远程的)状态机，也不对GUI对象集执行简单队列之外的任何建模或树结构，也不支持GUI多实例处理。现有技术中的技术都未公开泛型分类集中的GUI对象的子集的使用，并且也未能提供方法监控。现有技术也没提供用于全部其它形式的非GUI数据的GUI上下文。

本发明申请在于提供与本申请人的公布的专利(题为“使用行为和主机应用程序模型在软件应用中动态协助的系统和方法(Systemand Method For Dynamic Assistance In Software Applications UsingBehavior and Host Application Models)”的第6,340,977号美国专利)以及本申请人的未决的延续申请(2001年11月20日提交的第09/989,716号美国专利)类似的主题。申请人还具有由申请人以商标为“用户性能测量3.0(Knoa操作响应时间监控器，Knoa用户&应用程序错误监控器，Knoa应用程序使用监控器)(User PerformanceMeasurement 3.0(Knoa Operation Response Time Monitor，Knoa User &Application Errors Monitor，Knoa Application Usage Monitor))”、“Knoa商业处理测量3.0(Knoa商业处理监控器)(Knoa Business ProcessMeaurement 3.0(Knoa Business Process Monitor))”和“Knoa兼容测量2.0(Knoa用户兼容监控器)(Knoa Compliance Measurement 2.0(KnoaUser Compliance Monitor))”出售的商业实施。本申请专注于申请人的现有工作并对其做出了改进。

现有技术中缺少能对主机应用程序的多实例进行自动检测并能对GUI结构的子集的多实例进行检测的GUI检测和系统。此外，现有技术中缺少能对主机应用程序的多实例中的GUI对象的类别进行泛型检测、或对主机应用程序的子集进行泛型检测的系统。本发明提供了这些系统并满足其它需要。

发明内容

根据本发明的一个方面，提供了一种用于对来自表示层的事件和目标应用的软件方法进行监控的方法。该方法包括以下步骤：独立于对所述目标应用的源代码的重编译，提供在所述目标应用内的层运行的脚本。该脚本扫描目标应用程序的对象的运行期实例，并实时地为所述对象实例分配结构。对分配的结构进行调整，以创建所述目标应用结构的反映。该反映与检测到的与预定对象结构相匹配的对象实例共同用于捕获检测到的对象的环境谱的至少一部分。

根据本发明的另一方面，提供了一种方法，包括对发生在服务器机器和客户/本地化机器中至少之一上的状态机事件进行处理；将状态机事件与环境谱相关联，并基于相关联的状态机事件演绎出用户经验。

根据本发明的另一方面，提供了一种配之以对计算机目标应用程序的表示层中的事件进行监控的系统。所述系统包括在通信网络中相互连接的服务器和客户计算机。其中，服务器操作指令监控程序，监控程序包括能够在所述表示层以下的层上运行的脚本。监控程序包括能够操作以实现以下步骤的指令：扫描对象的运行期实例，所述对象包括目标应用程序的方法调用、方法返回以及GUI对象；实时地为所述对象实例分配结构；调整分配的结构，以创建所述目标应用结构的反映；检测与预定对象结构相匹配的一个或多个对象；以及至少捕获检测到的对象的内容。

通过附图和对某些示例性实施方式的描述，可进一步预期上述和其它方面、特征及有益效果。

术语定义

在本发明的上下文中且在使用每个术语的特定上下文中，本说明书中使用的术语一般具有其在本领域中的普通含义。下面或在说明书的其它地方对某些术语进行讨论，以在对本发明的装置和方法进行的描述中向实践者对如何制造和使用本发明的装置和方法提供额外的指导。可以认识到，同一个事物可用不止一个方式表达。

因此，对于本文讨论的术语中的任意一个或多个，都可使用替代性的语言和同义词，而并不根据本文是否对术语进行了详细描述和讨论而使其具有任何特别的重要性。提供了某些术语的同义词。列出一个或多个同义词并不排除其它同义词的使用。本说明书中任何地方使用的实施例(包括本文讨论的任何术语的实例)都仅仅是示例性的，而不在任何方面对本发明或任何示例性术语的范围和含义进行限制。同样，本发明不限于优选的实施例。

“代理(Agent)”表示与单一引擎DLL的一个或多个运行实例相关联的主代码单元。

“组件(Component)”表示由待执行的程序代码和数据组成的常规操作系统包。组件程序代码包括用于执行应用程序或服务的功能性的方法或函数调用，并有利于代码的重新使用和用于复杂的主机应用程序的模块化封装。组件执行由公司创建的多种不同技术，以促进外部应用接口的重新使用和公布。包含面向对象的类或程序代码的组件可在组件技术中实现，组件技术例如微软(即，Microsoft Corporation ofRedmond，WA)COM(组件对象模型)、用于开发并支持程序组件对象COM的框架或其它类型的组件技术。

“环境谱(Environmental Spectrum)”表示在目标应用程序中呈现的不变的和时变的条件，这些条件表现为对象、GUI、对象、消息、方法调用和方法返回，但不限于此。

“事件模型(Event Model)”表示这样一组事件，其事件检测和收集反映并表示在主机应用程序中已发生的某些真实过程。

“输出函数(Exported Function)”是一种方法接口，当将该输出函数的名称提供到程序模块头部(header)时，该方法接口被输出至DLL组件中。

“框架(Framework)”表示对GUI对象以及方法调用和返回事件的状态和检测进行建模的工作基本结构。

“泛型的(Generic)”表示检测一组目标的操作。这里的一组可指相似对象的类或范畴，此处用于表示一组GUI对象、一组方法或一组其它事件。“泛型的”的反面是“具体的(Specific)”，其通常指单一的GUI对象、方法或其它事件。

“gMg引擎(gMg Engine)”表示对包含逻辑说明和条件说明的二进制脚本文件进行处理的脚本解释器，所述的逻辑说明和条件说明执行监控目标范围内的选择性监控。

“gMg GUI对象树(gMg GUI Object Tree)”表示本发明中用于对包括主机应用程序的用户接口有用的GUI对象进行建模和表示的分层结构。

“gMg GUI上下文(gMg GUI Context)”表示gMg系统内任何数据类型在GUI数据流中的交叉，其中GUI数据提供用于分析的GUI(用户)上下文，以更好地反映用户对应用程序的经验。

“gMg解决方案(gMg Solution)”表示编译脚本的二进制封装，编译脚本描述了为实现主机应用程序监控而执行的条件、逻辑和选择性目标。

“GUI”是图形用户接口的简写，其由主机应用程序控制。其为用户和主机应用程序之间的主接口。“GUI对象”是一类对象，其为通常在RAM中被编程的GUI结构的一部分，这类对象包括被显示的用户接口，并通过主机应用程序代码对计算机输入装置起作用和受其控制。

“钩子(Hook)”表示传感器的一部分，该部分对操作系统消息和由主机应用程序生成并将由外部系统进一步处理的消息进行捕获，或基于主机应用程序的运行时间消息执行改变动作。

“主机应用程序(Hook Application)”表示用于监控的应用程序。

“IE”代表一种因特网浏览器应用(Microsoft′s Internet Explorer)。

“实例(Instance)”表示一些功能性的程序，其操作代码可被跟踪到派生集，其中单一的派生集可将一个或多个操作单元以实例的形式创建到存储器中以实现功能。存储在已启动的存储器中并作为派生操作的结果而运行的程序代码可称为实例。

“逻辑事件(Logical Event)”表示状态机处理的事件，这些事件代表可被处理到一个或多个层级(即，在不同的物理位置处(例如客户机或服务器)的状态机处理的连续阶段)的目标状态。

“方法”与“函数”在程序函数中相互同义地使用。

“方法事件(Method Event)”表示通过对组件的方法或函数(例如程序函数或方法)进行监控而生成的事件。

“多实例(Multi-Instance)”表示指定单元的不止一个实例同时存储在存储器中。

“对象变量(Object Variable)”表示附接于存储在GUI对象树中的现有GUI对象成员的、本发明的特指对象。

“OS”是计算机操作系统的简写。

“传感器”是一种专门的编码单元，其使用公共的或私有的接口从应用组件处获取实时数据。

“具体的(Specific)”表示一个操作将检测一个逻辑条件，例如单一GUI对象的检测。

“状态机(State Machine)”表示一种处理单元，其具有输入和输出事件，并通过与持久性存储相耦合的输入事件的条件处理，确定序列或发展中的离散的不同状态。

“形实转换程序(Thunk)”表示用于在方法监控中执行代码或存储实例信息的动态分配的结构。形实转换程序结构用于捕获函数调用或函数返回的多种情况。

“虚拟函数(Virtual Function)”表示这样一种函数，当其由子类覆盖时，其将由基类调用。

“V表(VTable)”表示一种虚拟表，其为COM中的表，该表中包含对属于一类的方法或函数的方法指针。

附图说明

计算系统和GUI

图1示出了根据本发明实施方式的计算机以及客户机和服务器硬件；

图2示出了根据本发明实施方式的、在示例性GUI网络应用中的GUI表示层；

监控目标

图3示出了根据本发明实施方式的客户机或服务器上的计算机操作环境(非GUI)中的监控器目标；

gMg系统组件概述

图4示出了根据本发明实施方式的gMg系统组件概观；

gMg系统事件流

图5示出了根据本发明实施方式的gMg系统中的事件和性质流概观；

图6示出了根据本发明实施方式的主事件源；

GUI对象树

图7示出了根据本发明实施方式的对GUI对象树的更新；

图8示出了根据本发明实施方式的对象树gMg事件：对GUI对象树的更新以及gMg创建和破坏事件；

用于多实例支持的函数

图9示出了根据本发明实施方式的加载程序功能性；

图10示出了根据本发明实施方式的对象变量；

图11示出了根据本发明实施方式的WhenObject结构；

图12示出了根据本发明实施方式的具有进程的进程窗口上下文以及不同的窗口元素；

图13示出了根据本发明实施方式的上下文和多个弹出式窗口；

图14示出了根据本发明实施方式的进程钩子；

GUI对象的类属检测

图15示出了根据本发明实施方式的具体的到类属的谱；

方法传感技术

图16示出了根据本发明实施方式的方法监控概观；

图17示出了根据本发明实施方式的用于方法监控的模块树；

图18示出了根据本发明实施方式的方法监控器的创建；

图19示出了根据本发明实施方式的方法签名以及方法代码覆盖；

图20示出了根据本发明实施方式的用于方法监控的形实转换程序分配；

图21示出了根据本发明实施方式的对虚拟函数的监控；

图22示出了根据本发明实施方式的对方法返回的监控-堆栈复制；

图23示出了根据本发明实施方式的对方法返回的监控-堆栈分配；分析

图24示出了根据本发明实施方式的、具有本地和远程状态机处理的状态机层次；

图25示出了根据本发明实施方式的用于状态机中的转变的静态和实例评估；

图26示出了根据本发明实施方式的状态机事件处理；

图27示出了根据本发明实施方式的处理流程图；

图28示出了根据本发明另一实施方式的处理流程图；以及

图29A和29B示出了根据本发明再一实施方式的处理流程图。

具体实施方式

通过介绍，提出了对主机应用程序的多实例中的具体事件或具有遗传结构的事件提供及时跟踪和监控的系统和方法的实施方式。这种跟踪和监控是从应用程序的表示层得到，例如在GUI层得到或在函数或方法层得到。事件和之后的模式检测分析的生成提供了洞察和测量统计，用于对包括但不限于以下各项的测量进行监控：响应时间、错误检测以及应用程序事件的收集。用户监控提供了可用于辨别用户上下文和应用程序交互的信息。

随着企业环境中的应用程序越来越复杂，对实际用户经验的理解和测量也变得越来越困难。当用户经历从慢的加载或响应时间、隐含的错误消息、部分提供的页面到不完整的数据块表和记录等的每一件事情时，可出现各种问题。IT部门现在完全集中于后端基础设施，即使其实际上是推动公司收入和效益的商业用户。

为了确定对用户经验的定量测量，在用户或服务器环境中可能具有许多可用的信息源。由于具有许多与集中式数据源进行交互和事务处理的组件，因此，每个组件都变为包括用户经验的长事件链中的一个链接。这些组件可位于网络层、硬件层(CPU、存储器、虚拟存储器)、GUI表示层、应用程序服务器中等。

由于用户在与应用程序的GUI层交互时驱动关键商业处理，因此，理想地，应该将在应用程序的任何基本架构等级内的全部动作和活动的GUI层的上下文和识别问题追溯到某个用户上下文中的用户动作。来自GUI层的事件正好提供该上下文。系统在该层进行跟踪，并“见用户所见”。该GUI被组织为分层结构，并包含GUI对象的多个子集。根据用户动作和应用程序的组织逻辑，可在运行时间对这些子集进行复制，应用程序的组织逻辑控制GUI对象结构如何生成和如何在运行时间保持在存储器中。系统提供了将各结构区分开了的支持识别机制，这些结构在其它方面可表现为相同的。特别地，如果用户遇到从基本架构任意等级生成的错误消息，那么捕获错误实例以用于之后的分析，从而有利于该应用程序的补救。

在现在的网络世界中，应用程序经常都以多实例运行，其中，多个窗口都具有可同时运行的相同结构，从而给应用程序的多实例中的GUI对象的精确检测带来了问题。特别地，一个问题在于清楚地识别用户看起来不相同、但内部结构可能相同的接口。现代的应用程序可在用户接口上产生用不同文字标记、但具有相同的内部对象结构的许多窗口。这种多实例还是现代编程实践(其努力使程序共享最大化)的一种后期效应(after effect)，并还重新使用组件从而达到更大的运行时间效率和维护效率。

对于透明性问题，监控系统相对于目标的主机应用程序而言需为非侵入性的并为透明的，并且如同不存在监控组件一样地操作。企业应用程序最通常的配置都不向例如监控程序的外部应用程序提供对启动接口并公布定制事件的源码的访问。对于监控系统，问题则变为如何在不改变应用程序的情况下对进行选择性监控的应用程序进行扩展。为了实现这种透明性，监控系统会对输入的事件进行拦截和过滤，并对其进行读取和处理。可选地，该系统还可滤除持续传递到主机应用程序的事件。

对于可用的测量源的问题，企业主机应用程序内的跟踪业务处理在利用可用测量源来执行真实的用户性能监控方面具有很大的挑战。在GUI层，洞察复杂的处理需要从比标准表中已经可用的维数更多的维数中获得更多的数据。尽管企业应用程序卖主公布了许多应用程序接口(API)，但是，多数逻辑仍然是保持隐藏的，通常，有些关键事件或属性仅能从私有组件中获得。通过对这些私有组件的访问，精确性和可访问性都极大增强。

对于监控覆盖的问题，由于现在的企业应用程序的复杂性和规模(scale)，执行监控覆盖可为使人畏缩的任务。通过大数据库的排列和组合，可能具有几百甚至几千个模块以及几千个操作。基于从数据中得到的条件，这些大数据库可动态地生成用户接口。为了监控甚至是基本的使用，系统必须检测上百个状态或条件，并实时高效地捕获数据。此外，方案监控的系统实现必须足够快速，以适应企业的要求并提供足够的反馈和覆盖。

对于聚合实时检测问题，在具有有限资源的环境下，对大的用户基数(user base)的复杂检测在有限资源的编程环境下进行高效编程方面面临极大的挑战。通常，企业应用程序可生成许多事件，其中，鉴于数据业务、传递速度和透明监控的限制，可以证明选择性业务处理或操作的处理和检测是非常具有挑战性的。

因此，为解决上述问题，本发明提供了多种机制。

为解决GUI层的上下文和识别问题，在gMg(泛型多实例方法和GUI检测)系统中，提供了用户上下文，其为可与该环境中任何其它类型的可用数据交错、并可与其它外部源(尤其是来自服务器或环境基础设施的数据)相关联的GUI事件流。在GUI层检测到的事件提供了用户经验和交互与应用程序的表示层之间的直接映射。完全从GUI上下文中的综合角度来看，该系统能用不同传感器的实施方式(即，方法传感器)对多种数据源进行寻址。使用专用的透明GUI传感器，可将全部其它形式的数据交错在GUI事件流中，以便为用户的实际运行时间经验提供直接的事件通信。

在gMg系统中，动态模块与实时主机应用程序结构同步，以解决应用程序的多实例问题，并提供对通常具有多个相似或相同的GUI结构的复杂主机应用程序图形接口的支持。动态GUI对象树对主机应用程序的GUI对象进行建模。可附加动态变量以在树中选择GUI对象，从而支持GUI对象多实例。

企业应用开发的复杂性以及它们的部署使得企业应用程序的任何改变即使完全可能发生，但是改变也会非常慢且麻烦。gMg系统包括各种传感器的实施方式，这些传感器通过从企业应用程序及其环境中获取事件和属性而有助于使应用程序具有透明性，而并不用改变企业应用程序的源码。因此，这些传感器不对主机应用程序的任何组件进行重新编译就能够扩展该应用程序的功能性。这些传感器最小化地且非侵入性地介入，以捕获填充企业应用程序模型所必需的数据。根据这些模型，可生成精确的事件从而允许进行分析。

gMg系统的方法监控功能性极大地扩展了可用的测量源。在主机应用程序环境内，具有两类接口：公共的和私有的。公共接口是公开的，用于和外部系统进行集成。通过编程语言的惯例，API(应用程序接口)能将组件功能与外部系统的外部功能集成到一起。私有接口则是不公开的，但是，如果找出其行为，其则可提供有价值的且有时是关键的事件或属性，以建立用于测量的附加的上下文，全部这些上下文可构成在GUI上下文中。下面介绍传感器，该传感器能透明地(例如，不改变主机应用程序的源码)检查公共组件和私有组件，并能将这些组件在单一的开发编程环境中的其它类型的事件集成到测量处理中，从而使测量处理具有开放的、附加的更大维数。

为了监控GUI层的覆盖，现有技术需要手动实现每个具体的GUI对象的相应描述符，并手动选择应用程序的GUI的广泛设备。为了有效地实现应用程序的足以实现有效监控的覆盖，需要更有效的机制通过合理少量的操作提供广泛覆盖。通过优化并极大地减少执行测量方案所需的努力，gMg系统通过其对方法或GUI结构的泛型检测而实现这种更有效的机制。

在GUI层和其它结构，应用程序的内部组织固有地具有对象的相关集，以实现并提供可视的表现层。利用该固有的组织的优势，可从对相关的实时GUI对象结构的检测中得到事件，这些实时GUI对象结构产生分类的事件，并作为泛型操作执行以监控GUI对象集。这种系统方法的极大益处在于，在开发期内，监控方案的开发者不必描述每个可能的输出，而仅需对将检测目前和将来的全部类似结构的结构化算子表示进行检测。然后将遗传地收集的数据与系统的其它资源集成到一起，以提供用户与主机应用程序的交互的多维观察。

对于聚合实时检测，在gMg系统中提供了对检测到的第一级事件进行处理的分布式本地和远程状态机的可选实施方式。在GUI上下文数据流中，源处的状态机可处理局部化的事件，并生成更高的逻辑状态，然后向收集服务器发出跟踪消息。接收到逻辑状态之后，其它的远程状态机然后可对该逻辑事件类型以及从其它用户计算机接收到的其它类似的逻辑事件类型进一步处理。分布式处理的这种配置提供了用于大的用户基数的非常快的检测速率。

利用本地(客户)或远程(服务器)GUI模型，gM²g(本文中称为“gMg”)是自动的多实例具体和泛型GUI和方法跟踪系统，其用于对多实例的并行的主机软件应用或并行的主机应用程序的子集进行建模。gMg能力可被透明地应用，而无需对目标应用程序源码重新编译。

位于本地客户机或远程服务器上的gMg模型是反映主机应用程序的实际结构的GUI和方法对象框架，并为对收集的数据进行重构并将其翻译为输出分析的系统机制。由对事件和GUI对象属性进行过滤以检测实际GUI对象集的代码命令对逻辑GUI对象进行跟踪。由响应于对组件的主机应用程序方法调用和返回而对翻译器引擎创建的事件进行检测的代码命令对方法对象进行跟踪。然后，GUI和任何其它可用的事件和属性都可从组件中得到。如同使用上述gMg模型的动态系统，gMg处理分配结构，并实时地使这些结构适应于为主机应用程序中的真实GUI和方法对象的多实例。对这些结构进行处理以得到逻辑事件，并对其进行重编以反映不同上下文中的多实例结构，而无需获得主机应用程序的全部关系或属性的先验知识。

动态地将从主机应用程序中实时提取的数据组织到对象、进程和代码模块树中之后，gMg系统则用其对应的多个属性集(例如文本)处理复杂的多个结构，并将这些结构关联到一起用于精确分析。通过由客户机和/或服务器上运行的多种配置的相连状态机的多实例处理，得到对报告、警报或响应的分析。

为了检测单一的主机应用程序的多个相关实例中的事件，提供了不同的可扩展的代码元件用于不同类型的传感器，这些传感器检测在应用中的各个点上出现的事件类别或从GUI层到组件方法调用的其操作环境。该系统包括对专有脚本进行分析的多实例解释器组件，该专有脚本具体地或泛型地对从传感器传递的事件进行过滤和解释。根据事件和属性条件，解释器生成跟踪消息。可选地，在生成跟踪消息之前，解释过的事件可在本地化的状态机组件中的流中被可选地分析。然后，通信组件则封装其解释过的或本地化的状态机跟踪消息，并将其发送至对接收的跟踪消息进一步分析的远程状态机组件。作为一种选择，远程状态机可将消息直接路由至警报或其它状态机，用于更及时地传输并显示在显示控制台上。

报告组件可执行对聚合观点(aggregate viewpoint)、趋向、分组和分类的分析。该分析可绘制在多种图形的、列表的或文字的表格中，并可用于多种用户角色。这些角色可用于技术基础设施支持群组、线式管理、用户支持、教育以及可以是许多其它角色。

本文介绍的系统和方法可用于许多方面。例如，当在产品环境中使用时，其在需要持续监控的、用于用户性能的多种应用中是可用的。对于基础设施支持，系统可用于测量响应事件，并检测用户遇到的全部错误消息。为了进行训练，使用信息可检测用户在应用程序的哪部分遇到了困难。对于顺应性(compliance)，监控进程可检测用户在何处偏离了接受的政策实践并生成警报进行管理。对于安全性应用，检测一个或多个应用程序上的可疑用户活动可生成到安全管理器的警报。对于资源规划，使用信息描述了如何应用资源，并揭露了峰值时间的分布(profile)。对于编程开发，反馈、精确的响应事件和错误可导致快速传输固定的和新的发行版本。GUI事件被测量用于两个事务，并且位于两个事务之间，所述交易使得不同的数据类型相交错，且将它们表现为用户的GUI上下文中的单一集。对于帮助桌面支持，使用、错误和响应事件信息提供了对帮助标签事件(help ticket incidents)的自动成形，并有助于故障诊断处理。

本说明书的组织如下：首先简单概括硬件和GUI环境，然后从讨论不同类型的监控目标开始描述gMg监控系统，接着概述使用的组件。对GUI数据结构(例如，gMg GUI对象树)进行研究之后，讨论事件模型。然后对在多进程和线程环境中实现gMg引擎和脚本的多实例的方法进行介绍。在介绍了在COM对象中使用gMg方法签名和虚拟函数进行方法调用和返回的监控之后，对泛型的和具体的GUI对象检测进行讨论。最后一部分对使用分层的分布式状态机进行分析以实现快速实时检测和动作进行了探索。

图1示出了能实现和操作泛型GUI方法监控系统和方法的客户计算机100和服务器105的配置的实施方式。gMg系统和方法可为由客户计算机100执行的应用程序或软件，客户计算机100可为个人计算机、工作站或其它计算平台(例如，PDA(个人数字助理)或PED(个人电子设备)，PED可包括手机、MP3播放器、照片和视频数码照相机以及个人视频录像机等)。服务器105(通过其服务器软件而区分开来的另一个计算机)从多个客户计算机处收集数据，并补充客户处理任务。网络连接器110提供到例如服务器的外部计算机的连通性。标准的连接协议在远程计算机之间发送和接收任何格式的数据。客户计算机100可包括由内部系统连接到一起的子系统。包含在系统RAM130内的指令由中央处理单元150执行。

大量的外部装置通过端口140连接于I/O(输入/输出)控制器115，端口140在串口(未示出)上提供到例如调制解调器的外部设备的连接。2D和3D图形和视频或任何形式的移动图像的显示都由视频适配器120处理，视频适配器120在监控器125上显示图形缓冲的内容。声音处理由声音硬件135实现。定位装置155和键盘145将用户输入转换为输入数据，用户输入是由用户与显示的可视信息的交互而生成的。永久存储160保留计算机在关机状态和运行时间(需要的话)之间存在的数据。

图2示出了典型的应用程序GUI，本实施例中，其为web因特网应用。实际上，有两类GUI对象被监控，即，Win32和Web IE控件。主窗口205包含全部子目GUI结构，子目GUI结构包括web页面，并包括两类容器应用(即，浏览器)和浏览器的页面内容，页面内容可包括多个web页面(即，html元件)。浏览器容器应用由Win32元件(例如，主窗口205、窗口标题、主窗口控件215、菜单项225、URL接口地址显示220以及导航和操作图标230)构成。主窗口的其它元件提供状态指示符235和安全状态指示符240。主页面本身表示由服务器送达的主机应用程序的html页面，并由用于用户交互和信息获取的各种函数接口构成。

图2示出了简单的日历功能，其中示出了提供不同的视图和过滤操作的各种元件，包括用于以下各项的各种标签控件和图标：应用程序的主要组织部分245、250；项目视图255；用户过滤、项目及分类265；添加260和搜索275操作符；数据显示270；图形日历显示280以及项目状态图标285。该实施例示出了如何将两种GUI应用处理结合绘制GUI，以提供用于gMg Win32和网页(Web)IE传感器的两个目标类型。用户接口提供GUI事件的关键流，根据该关键流，可在GUI上下文中设置多种其它的计数器(从统计数据、响应时间、计算机性能计数器到方法事件计数器)，以直接连接于用户经验，用于对应用程序的性能或商业处理进行更精确的分析。该简单的日历为主机应用程序的一个实施例。本发明不限于任何特定类型或属性的主机应用程序。

监控目标为主机应用程序内的任何实体或有组织的实时处理，其属性、事件或行为可通过检测被翻译为逻辑事件，用于由gMg系统解释和分析。在目标环境中，具有广泛的潜在的监控目标，在操作系统或应用程序中，这些目标环境被分成提供私有方法或公共API。每个监控目标都可包含其自己的值或具有可检测的事件，这些值和事件可用于构建用于关心的和感兴趣的任何范围的行为。

参照图3，用户302对主机应用程序GUI 304进行交互，主机应用程序GUI 304则对由应用程序服务器维护的应用程序组件306进行控制。必要时，GUI和组件层都与操作系统组件310-326进行交互，以实现全部的功能。尽管操作系统具有许多方面，但是此处仅示出与内核312、网络314、322和324、例如CPU、内存、进程和线程的核心操作326、文件320以及其它操作系统组件310、318相关的少数关键功能。主机应用程序组件306与这些OS子系统中的任意或全部进行交互，以执行例如网络通信、图形显示等的基本功能性。

通过公共API(应用程序接口)308和328-336，操作系统发行者提供了可用的、操作环境中不同的标准子系统，这些API被集成到gMg系统中的356处，并被集成到gMg传感器338中。应用程序API 308可根据内部信息的各种类别而提供事件和属性。通常将这些类别公开，以供应用程序伙伴对应用程序功能性进行扩展，用于用户定制或服务定制。操作系统API 318根据OS的进程、线程、内存、内存分配等提供关于OS的全部方面的功能。“PerfMon(性能监控)”是在MicrosoftWindows内公布的特别构建的API 316，其提供关于硬件或服务的多个方面(例如，CPU利用，虚拟存储等)的计数器和数据。浏览器控件API 328提供关于浏览器容器应用程序的DOM(文档对象模型)的属性和事件，并用于支持网页GUI监控应用。浏览器控件对应于Win32GUI API通信接口330，该接口对Win32客户应用程序GUI进行监控。还具有许多其它的GUI API 332，例如用Java(来自加利福利亚州圣克拉拉市的太阳微系统有限公司(Sun Microsystems，Inc.of Santa Clara，CA))、Visual Basic和.NET(均来自华盛顿州雷蒙德市的微软公司(Microsoft Corporation of Redmond，WA))编写的客户应用程序。gMg系统可构建在以上所述全部的接口类别上，以创建不同的监控数据源，用于收集和分析处理。

gMg系统实现了具有各种传感器类型338的数据源的生成和集成。这些传感器通过其适配器链接于各种可用的监控目标接口(308和328到336)。这些传感器被配置，并对馈送至gMg提取层348中的事件进行检测，提取层则输出gMg事件350。这些输出事件然后被馈送至gMg解释器352中用于实时条件分析，实时条件分析又创建另一个跟踪事件层，这些跟踪事件被馈送至收集和分析服务器354中。分析产生从警报、关联到直接动作的大量输出。作为gMg系统的一部分，还具有专用的gMg方法检测器(即，gMg方法监控340、342、344、346)，其对组件范围内从主机应用程序到操作系统的目标方法调用执行一般的监控。方法传感器可在适当的条件和场景中，从私有组件和公共组件中提取事件和属性。假设具有多种可扩展且可适应的传感器，在用户GUI上下文中，gMg系统则可从多种类型的源中调度数据，以提供对主机应用程序和环境处理的全面监控。在服务器环境中，当在操作期间没有经由GUI接口的直接用户交互时，那么，公共的和私有的全部其它监控接口则对生成gMg监控数据源保持有效。在服务器内(不具有用户302)将不会出现GUI运行时间层303、304和327。然而，用户服务器管理工具的GUI则可出现并被监控。

图4示出了在典型企业环境中使用的gMg组件，参照图4，用户402可访问一个或多个主机应用程序404、406、408或由主机应用程序服务器410传送的同一个应用程序的一个或多个实例。

gMg系统开发工具412可创建并封装准备部署到用户的计算环境中的gMg方案426。开发工具包括GUI和方法观察攻击、编译器、调试器、服务器分析状态机工具、管理和部署封装实用程序、以及集成的开发环境。gMg可执行对象包括单一的代理执行程序(AgentgMg.exe)414以及一个或多个Engine.DLLs 416、418、419、420。AgentgMg.exe、一个或多个Engine.DLL以及gMg方案的集合包括gMg系统436的实例。图4示出了多引擎监控主机应用程序406以及Engine.DLLs 419。共享存储机制442对多个引擎之间的协调和共享资源方面起作用。在需要时，gMg系统动态地跟踪主机应用程序内的多个进程，传感器438、439和440则检测主机应用程序内的方法调用或GUI事件，以构建用于收集的数据的用户上下文。对包括系统上下文的用户上下文(例如，方法调用、方法返回以及消息)进行捕获，以创建主机应用程序和系统的环境谱的“快照(snapshot)”。

将Agent gMg.exe和引擎部署在目标环境内，而不论该目标环境是桌面计算机、服务器(GUI模式或非GUI模式)还是终端服务器(在将光栅化的(rasterized)显示数据传递给用户终端服务器上执行客户组件的服务器)。在开发阶段，可选的调试DLL 422、424用于实时调试，其与开发工具结合以提供断点、变量显示、跟踪以及其它类型的调试工具特性。经过小的简单的动态更新之后，gMg方案426、428、430、432、434由编译过的脚本构成，脚本对分离的或重叠的监控目标进行限定和描述，并执行跟踪操作。这些方案由不同的engine.DLL实例运行，并可在需要时对可分离或重叠的监控目标进行跟踪。检测到GUI或方法事件之后，创建跟踪消息，并由通信模块444将跟踪消息发送至服务器和跟踪数据库446。收集服务器根据有效的要求和计算资源进行实时分析、近实时分析、或后期(post time)分析。处理和分析模块448的输出包括警报450、与外部数据源的相关性(例如后端监控统计452)、或报告454。根据与真实GUI用户上下文中与应用程序进程的交互相关的聚合的处理数据显示组或详细的个体行为，报告454可为多种形式。企业中，技术支持、训练、基础设施支持等的不同角色458可对报告的信息或警报进行访问，以产生改进和改正的行动456，或支持终端用户。

参照图5，用户503与具有主机应用程序网站506的桌上型电脑或终端服务器上的一个或多个并发的主机应用程序、相关组件512、以及主机应用程序的表示GUI 509的一个或多个实例545相交互。主机应用程序的元件可位于表示层中，并能够由用户调用操作并接收应用程序响应。主机应用程序可同时运行不止一个实例，或可同时运行作为主机应用程序的子集的GUI集的多实例。

GUI可在存储器内被组织为分级结构，并可具有多个GUI对象子集。这些GUI对象子集根据用户动作和控制GUI对象结构如何生成的应用程序的组织逻辑，在运行时间进行复制。除了表示层之外，应用程序还包含许多执行功能(例如，与服务器的通信、计算、环境属性检索、与计算机操作系统的交互等)组件或DDL 512。组件库包含用于执行功能的方法，方法事件的gMg检测提供对与支持主机应用程序的组件的功能相关的进程的属性、输入、输出、事件或其它信息的访问。从提供GUI或某些其它底层主机应用程序功能的库组件中检测方法事件。

gMg系统利用GUI对象属性528和对象状态信息支持分析。一组名称-值对及其与其它对象的关系反映任何给定时间的对象状态。可使用轮询在任何时间通过程序得到属性的值。对象还可具有与之相关的、由传感器通过脚本定义和控制的定制属性。从状态和之前事件的组合可得到额外的状态信息。反作用于主机应用程序的进程流的gMg传感引擎548可生成一组实时事件515，这组实时事件是从用户、应用程序、OS事件以及GUI对象和方法属性的特定值得到的事件。这些事件反映了满足给定时刻或应用程序的当前状态(即，环境谱)的条件。这些事件可为以下多个类别的事件：由例如计算机鼠标或键盘的输入装置生成的用户事件；从用户动作直接得到的事件；由应用程序自发生成(例如，由消息更新刷新窗口)的应用程序事件；例如由文件操作、注册动作或网络得到的操作系统事件；以及用于监控具体组件功能的方法条用和返回事件。其它事件可具有提供细节或其它限定事件的属性。根据低级事件的输入，可通过条件的逻辑处理随意地获得逻辑事件521，以通过状态机确定状态。当逻辑事件和未处理事件到达通信模块524时，其均准备用于传输至远程收集服务器557。该模块在传输之前控制缓冲和压缩或安全性。缓冲还提供了一种机制，将数据临时存储在收集事件、网络、中断或非连接环境中。

在客户548和服务器557之间提供信息交换。客户通信模块传送逻辑事件值或选择的GUI对象属性，并从服务器接收控制命令。在收集和分析阶段，将数据以跟踪消息的形式传送到收集服务器实例557，该跟踪消息可在数据块中处理或存储。将事件流反多路转换(de-multiplex)为由分析参数动态确定的分离的用户逻辑上下文。

根据数据是否作为GUI对象属性到达，在低层事件或在逻辑层事件中确定如何路由数据554。如果作为低层多事件到达，那么，状态机处理则产生逻辑事件530和上下文。然而，如果数据作为先前已处理的状态机逻辑事件到达，那么，进一步的状态机处理则可产生新的上下文527。当通过泛型检测或具体检测输出时，形成GUI对象集和泛型的或具体的事件集533。进一步的分析完成预定的度量和状态识别模式536，以产生完全处理的数据集。将完全处理形式的数据馈送至分析和报告阶段539，用于图形表示的聚合、趋向和报告处理，并用于在gMg报告控制台内使用。

对于很多用户，控制台是用于例如改变控制、程序修复、支持、调试、优化等。可选地，可将处理过的事件直接路由至系统的动作组件542，动作组件542包括需要更优先地注意的门限条件(例如，错误或慢响应时间)的显示和通信。动作可包括与外部系统560的通信，外部系统560提供例如发出支持权证(support ticket)、自动修复、训练、或最终影响到用户的其它限定的动作。

参照图6，gMg系统使用多个主要类别的事件源。在一般事件610中，具有经由API得到的Windows32操作系统事件、钩子功能和回调(call back)。这些事件提供到许多不同的通信、属性和函数的访问，所述函数使得用户、应用程序和操作系统之间的交互的处理的多个不同方面可访问。另一个事件源可来自浏览器(例如，因特网浏览器事件)，其说明了容器应用程序如何暴露数据模型和类型相关的事件和属性，例如用于由监听程序和可用的COM对象得到的外部处理的DOM(文档对象模型)。例如IE的网页(web)浏览器说明了现代因特网应用程序GUI的动态特性，这些GUI展示了复杂的多实例窗口结构。gMg系统内，COM监听程序被启动，并使用回调函数(IEEvents.cpp)检测IE事件。将类(class)注册到IE，并且，只要事件发生时通过COM接口提供了IE对象属性的检索，就调用该类中的方法。事件类型的另一个实施例是调用-返回方法事件，其提供由gMg传感器监控组件创建的多种传感器事件。

全部这些事件都被传送到gMg解释脚本625中。在达到解释器之前，使用锁定机制620将这些事件串行化。锁定机制还进一步被区别用于引擎的N个不同实例和/或脚本625、630、635。一旦对脚本进行分析并对已串行化的事件进行处理，则在主机应用程序的GUI 605内执行间歇性的轮询操作(通过应用程序扫描640)。同时，具有经由计时器回调过程615到达的操作系统计时器事件，该回调过程以可配置且可调整的设置速率对主机应用程序GUI 640的扫描进行调度。这一过程发生时，由分支记录结构655、660、665构成的gMg GUI对象树660变为其GUI的应用程序状态的系统当前视图的快照的更新、删除或复制。gMg脚本还设置其它计时器645，其它计时器645以低于对象gMg WhenObject命令的优先级被处理。命令WhenObject处理650是当不具有由主机应用程序和操作系统产生的事件时，在640创建用于需要同步的GUI对象的gMg创建和破坏事件的处理。命令WhenObjects提供gMg模拟计时器，以轮询GUI对象的具体集。

不同监控进程的gMg集提供整个应用环境和操作系统中的多种源类别。交互速率可控制用于执行属性检索的只读操作，以提取细节并建立用于跟踪消息和之后的分析的记录。

以下是在启动过程中建立的GUI支持机制、进程多实例以及运行时间脚本处理。gMg特性包括GUI对象树、多脚本的加载和组织、支持主机应用程序多实例处理(例如，对象变量以及WhenObject命令)特性的脚本特性、上下文的提供、截获、以及GUI对象集的泛型检测。

gMg系统可以大量不同的部署方式进行配置。在客户/服务器配置中，可安装本地代理及其引擎和方案，以在本地计算机上执行以检测事件。在网络环境中，当已安装了gMg代理和引擎时，可将gMg方案码注入并安装在服务器上，并将gMg方案码动态地传送到用户的本地计算机。尽管这一种部署都具有优势，但这两种部署都将基于共同的结构检测事件，并能根据需要提取具体的属性。gMg部署配置不限于以上所述，特别地，只要gMg系统是可操作的，其它配置就也在本发明的范围内。

一旦部署了gMg系统，启动激活后，就对命令行进行分析用于例如加载脚本、停止等的选项，命令行还建立与消息队列的通信。对*.ini文件(可包括脚本或脚本目录)中的运行选项进行检查，并将其发送至主分析命令行例程。*.ini文件中的脚本列表可在启动时运行，并可注入到多进程中。对函数changehookTidL的调用使得gMg.exe通过其自身的窗口将引擎注入其中，并且将其自身的解释器(gMg引擎)运行为如同其在监控另一个应用程序。作为一种选择，与gMg关联的窗口与用于与相同的Agent.exe相关联的、已注入其它应用程序的其它gMg引擎的gMg协议也可用作引擎内通信。

文件路径用于构造和注册特殊的窗口消息，该窗口消息将gMg处理登记到操作系统中。使用gMg.exe模块的完整路径名，并且该路径名变为窗口消息的唯一标识符，以在全部其它实例与同时运行的代理和引擎的复制和版本之间区分，从而允许动态的唯一的实例运行。在实例之间区分的能力使得能将安装在多个目录下的gMg.exe分离，以建立其自身的运行时间结构用于适当的同时操作。如果不多于两个的主机应用程序在运行，从而不止一个的gMg引擎实例在运行，并且两个引擎都发出同样的请求(例如，用于输出列表)，那么，在主目录下可出现文件冲突，例如文件未能打开或一个文件改写另一个文件。优选地，为解决这一问题，将文件名附着于实例。这变为了用于动态多实例支持的基础的一部分。在这种条件下，在相同的位置可存在具有相同名称的两个文件。

启动后，一个目标在于，当需要截获程序在应用程序接收窗口消息之前执行对窗口消息的拦截时，使用钩子功能设置gMg监控传感器。钩子程序处于线程级，其中一个线程具有一个钩子程序。监控用于窗口消息的线程使得gMg DLL将注入关联的进程空间，其中一个gMg DLL(通过CALLWNDPROC，具有SetWindowsHookEx的GETMESSAGE钩子)注入一个进程。如果需要的话，gMg脚本将其它进程截获，并将DLL注入进程空间。给定句柄之后，获得属于被监控的对象的线程，并驱动线程对象查找实例(即，线程id)，用于将线程截获或取下。为了进一步控制线程的截获，函数ChangeHookTid具有锁定和解锁的多个版本。当需要设置锁定时，使用锁定版本。如果已经设置了锁定，则调用函数的解锁版本。在将共享存储初始化之后，启动码还调用loadDBGDll，将调试DLL(如果作为选项存在的话)加载至同一个进程空间。由于单一的应用程序中通常具有多个线程，因此，当使用脚本解释器时，gMg gMglock执行锁定进程，并将全部事件强加于单一的线程。如果应用程序中的两个线程试图生成gMg感兴趣的事件，或者如果具有来自不同源的N个事件，引擎则强制实现事件的串行化。串行化指一个接一个处理的事件。解释器操作码执行码首先由gMglock锁定，然后调用DogMgEvent()处理每个事件。

由gMg.exe函数调用的函数LoadProgram传递线程id、脚本文件名和选项(加载/卸载)。gMg系统检查宽字符，并将文件名传递给统一代码。如果指定的线程id调用具有星号“*”的ChangeHook()，那么，解除全部的挂起。由于系统支持引擎的多实例，因此，可运行多个脚本。然而，当请求不止一个脚本时，系统则控制可启动多少个脚本(例如，具有星号通配符的启动脚本不被允许)。如果脚本不具有通配符，那么建立挂起，并挂起具有该挂起的线程。然后Changescript函数向通过其的线程发送消息，告知其文件名及其自身的线程id以及可能的选项，以加载/卸载脚本、直接加载程序、检查运行的全部程序的列表、加载具有卸载选项的单一脚本、或者重载脚本。

一旦脚本在运行，函数Do_gMgEvent()就传递事件中的对象。并且如果已设置了锁定，则对正在处理的事件的数量进行计数。GUI对象树图7和图8必须在脚本刚启动时且在对第一事件进行处理之前就建立。优选地，每个脚本都被处理，但是，如果设置了卸载标记，则执行脚本卸载操作，包括发送脚本结束跟踪消息。然而，如果脚本还未初始化，那么，首先将启动跟踪消息(空事件零对象)发送至脚本，以将其初始化并发送用于全部存在的对象的存在事件。这一动作调用开始监听事件的脚本。对于每个脚本，这一启动循环连续开始，以去除脚本、初始化或向其传递事件。

用于同步传感器和引擎的机制是共享存储器的集中式块，该共享存储器包含全部gMg主要可执行模块的窗口句柄。gMg代码检测可执行程序的终止，或者如果具有另一个运行的版本且如果可执行程序的窗口不再存在，那么，则将标记清除。状态检验完成后，如果设置了另一个标记，那么，可选地将消息框显示为给定状态，并指示是否有另一个gMg.exe在后台运行。如果检测到另一个可执行程序，gMg则使用WM_COPY消息将整个命令行作为数据块传递给全部其它引擎实例，然后退出。然而，如果没有其他实例在运行，则处理继续以创建主窗口。从不显示的gMg.exe的主窗口用于通信以使gMg.exe能作为应用程序对其自身进行监控。将保持在共享存储中的句柄设置为指向gMg.exe自身的实例。

在终止阶段，gMg多实例处理仍是需要的。在关机时，在调用DLLProcessDETACH期间，进程中的标记阻止当前运行的任务执行额外的工作，因为其它的操作仍然是异步运行的。在网页应用程序中调用CleanIEthread()的函数Cleanthread()调用断开和任何回调或释放，或者在IE中留下的COM对象可被清除。DLLProcessDETACH及与其对应的DLLProcessATTACH是递归的，以支持多实例和动态主机应用程序环境。每个主机应用程序进程至少具有一个gMg脚本。作为一种选择，多个gMg脚本可监控单一的进程。脚本设计以处理进程的全部线程，但是单一的脚本监控任何数量的线程，例如在通过一个窗口一个线程而建立的应用程序中发现的线程(例如网页应用程序中通常发现的线程)。脚本被快速处理，而属性检索被极高速缓存，用于实现更好的性能。当在相同的线程中读取属性或安全地检索属性具有不利条件时，则实施高速缓存。

在进行交互线程访问时，或当从调度行为(mashaling behavior)未知的COM对象中访问线程时，尤其是当运行在IE环境中时，可发生潜在的问题。然而，关于COM对象的较差线程访问(尤其是在IE环境中)的问题变得不那么重要，因为gMg事件是由特殊的线程生成的，只对与该线程相关的对象寻址，并且极少对其它线程中的对象起作用。当对其它线程中的对象进行处理时，gMg处理必须在对其它线程的对象进行寻址之前完成对当前线程的处理。通过将事件处理串行化，避免了冲突。串行化防止了例如当两个线程共享和修改共同的变量时产生模糊。gMg中的处理由现有技术中已知的解决通常的并行问题的原则指引。

串行化原则用于例如COM和非COM(组件)应用程序这两种组件环境。在COM环境内，接口方法可在多个线程内激活。不论什么线程模型(例如，安全线程、单一线程等)，都用gMglock使线程的监控串行化。处理IE事件可在每个线程内实现，但是gMg脚本需要为确定性的，并因此对于每个事件串行化。按线程处理对于那些关联的、但由gMg脚本内容确定的事件是重要的。gMg系统对事件进程使用单一线程，并将其延伸至任何事件。传递到调用(Invoke)的全部参数都具有之后用于检索事件属性的指针。如果脚本要求事件属性，那么，其使用事件参数的一个全局指针，并检索事件细节。这一机制使检索保持为集中式，防止其变为分布在太多位置而导致过多的进栈/出栈操作。事件和脚本的串行化必须是有效的。例如，如果由单一线程处理应用程序的GUI，那么，gMg传感则被容易地处理。但是，如果应用程序具有多个窗口，每个窗口都具有各自的线程，那么则可发生线程冲突。优选地，通过使用一个线程A处理事件，而强迫另一个线程B等待全局gMglock，可避免这种潜在的问题。由于允许消息被A处理，因此线程B等待gMglock释放。

gMg系统使用锁定机制建立生成的事件的串行化。BeginLock(其为Lock Macro(锁定宏))执行参数的互锁交换，如果其返回0(也就是先前的值为0)，则完成了锁定。设置线程id，并通过转发锁定在何处使用以及实现锁定的线程id确定调用者的位置。当BeginLock记录线程时，另一个宏gTid使用存储在gMglock中的线程id。一旦确定已设置gMglock，gTid则快速得多，这是因为其仅需要取出存储在锁定中的线程id。

对于调试死锁(deadlock)，如果存在递归锁定，那么beginlockD则可处理具体的动作。与仅执行超时或疏忽而导致失败相反，当在某些情况下一级递归被允许具有执行用于递归的不同动作时，BeginlockD也能处理用于递归锁定的具体动作。Beginlock执行互锁交换并存储线程id。gMg系统的锁定机制等价于临界区，但当锁定位于共享存储器中时，其跨越多个进程工作，并且当不具有冲突时，其还非常快速。如果存在冲突，优选地，gMg进程强迫调用执行快锁定Quicklock，Quicklock测试以查看线程id是否为当前的线程id。如果线程id是当前的线程id，则保持递归计数以用于统计，并返回-1。否则，则对递归进行标记，并将冲突计数加1。然后执行控制回路，其中回路休眠1.0毫秒，然后醒来并具有10秒的超时设定。通过检查使得，如果在全局gMglock上完成了锁定，那么则存在正在被执行的对指令的回路计数(即，脚本计数)。如果gMg脚本很大，当大量的参数和树中每个对象的全部属性都被取出时，超时设定则延伸超过默认设置。如果等待gMglock且执行了脚本代码，那么，如果有冲突的话则仅调用Quicklock。偶尔地，具有递归锁定(函数BegLockD)，并发出消息用于诊断。当对封锁中的超时进行计数时，如果存在完全超时，Quicklock则返回0。如果成功设置了锁定，函数则返回1，如果其自身线程已锁定，则返回-1。应该注意到，线程id(tid)可作为参数传递到Quicklock，这样就不必再对其检索。如果某些其它的进程具有锁定的线程、而解释器仍然在执行脚本代码时，代码可自动扩展gMglock_timeout消息。为了进行诊断，Quicklock结构包含关于锁定的信息、线程id、冲突计数、超时、递归计数、最后的锁定的行数以及模块文件信息。

gMgLock可控制由gMg DbgDLL提供的调试诊断，用于提供了对内联式的诊断以及对代码块的诊断。DbgDLL包含函数诊断，用于将发出的诊断枚举请求传递以用于运行时间分析。为了诊断支持，如果未成功地设置gMgLock锁定，其则作为失效保险机制，并且处理则停止诊断函数并将其设置为低优先级。

为了对来自真实的主机应用程序的事件进行建模，gMg系统可包括三个主要的树：一个用于例如窗口和html元件的GUI对象，一个用于进程和线程对象，一个用于跟踪组件模块和方法。gMg系统还包括计时器对象列表。

图7示出了GUI对象树715，其是为全部收集的跟踪数据提供GUI上下文的基础。GUI对象树715可由全部运行的脚本775共享，并且其维持每个脚本的状态。图7中示出了GUI对象的三个集——即，集P 725、集Q 720、735、740以及集R 730。下面介绍用从主机应用结构的GUI 705提取的动态结构更新GUI对象树715结构的过程。

函数UpdateTree对主机应用程序的GUI或者被监控的其它进程和目标进行建模。为了向gMg脚本引擎提供事件，需要在环境中对动态地改变的对象进行精确检测。为此，函数UpdateTree将全部主要更新处理到其内部结构，以适当地监控在受控的调度中，旧的对象和新的对象之间的差别。

关于调度，UpdateTree函数具有大量机制来控制对象的速率与主机应用程序同步。UpdateTree具有其自身的计时器，以避免过处理，也就是避免当计时器在作为时间的函数的间隔中运行时，其仍然正常地对树进行扫描。如果由于应用程序繁忙而没有调用计时器事件，那么，UpdateTree则会在事件检测过程中被调用。并且，gMg截获的任何事件都可使UpdateTree代码仍然运行。处理优先级上升到更高级别，并且即使应用程序看起来是被阻塞了，其也使UpdateTree扫描、更新对象并捕获信息。UpdateTree还在旁设置一个线程，以处理在此期间来自其它线程的全部窗口。例如，如果三个线程都以每秒两次的轮询速率运行，那么，仅有一个线程被授权用于检查来自其它线程的窗口以提高性能。对象过滤在线程级实现，轮询速率可由gMg脚本进一步调整。此外，还具有大量的其它选项，例如清除对象树，或者处理与仅将处理限制为当前线程的处理相反的全部线程。

为了处理主机应用程序的动态特性，gMg系统包括跟踪机制，跟踪机制对经常改变、删除或创建的GUI对象的变化状态进行跟踪。参照图7，为了适应这些变化的条件，保持了将被破坏的对象的列表760。gMg处理破坏消息并生成发送至脚本解释器745的事件770。列表Slist760是包含一系列旧的对象的列表的结构，例如从旧列表750中移除(如果仍然存在的话)、然后添加到新列表755的结尾处的对象。先前的对象集仍然在旧列表中，但是先前不存在的新对象被添加到新列表755中。在树720的顶部设置指向真实的现有窗口集的指针，将该集的状态变为旧，然后将其腾空，并建立从该点开始的新列表。

当扫描应用程序GUI时，或者如果不再存在的项将窗口项放入破坏列表，Enumwindows函数则通过扫描每个窗口实现更新，并查找旧列表且根据需要将其放入新列表。然后对保留在旧列表中的任何项进行处理。接收到保留在旧列表中的任何被破坏的窗口的通知。更新处理发生在Enumwindowsproc 710中。回调函数Enumwindowsproc由Win32 API调用，用于每个顶层窗口780。Lparam是指向SList结构的指针。还解锁窗口线程进程id。该函数获得窗口线程进程id，并检查旧列表中是否存在该窗口。

对对象进行检查，以确定其是否在旧列表中。包括指向对象树结构的一组指针的旧列表被检索，并将仍然存在的对象标记以使其根据需要变为新列表的成员。完成后，对用于窗口的进程或线程对象进行处理。如果检测到新窗口属于特殊的线程，那么，系统则创建用于所述线程的进程和线程对象。使用访问标记作为状态指示符，以标记对象是否在窗口或线程的给定进程中被列出(作为列表的一部分)。访问标记被检查，并用于告诉脚本，对象已通过破坏事件770终止。

通常情况下，当树结构没有改变时，代码有效地操作。如果没有改变，代码则对对象解除链接，对用于其线程和进程的标记进行更新，并将窗口链接于新列表(例如，将窗口从旧列表移除并放入新列表)。利用线程，检查的窗口处于相同层级，而没有窗口处于被检查的当前层级之下。这一机制跳过属于另一线程的任何顶层窗口，并且一次只处理一个线程。优选地，如果处理不受限制，一个线程的处理将降低到零，这意味着该进程已被授权处理其全部的线程。

参照图8，示出了在读取了窗口806的类之后，对象树832上的操作，其中窗口806与脚本812使用相同的接口808。如果该类已在gMg缓存810中，那么，其则不必从作用的应用程序804中检索。如果检索到的类与(窗口的)IE类相匹配，其则来自属于对象树成员的特殊线程(和当前线程814)。树832中的对象包含关联的线程id，因此树的每个分支都仅由其线程与树对象的线程844匹配的窗口服务。

函数notifydestroytree建立破坏列表816，并废除旧列表820。如果处理不调用notifydestroytree，那么旧列表中的先前的旧树则仍然为保持原样。但是，如果分支对象与当前的线程相匹配，处理则将继续进行。现在，则具有空的新列表822，且全部子窗口都枚举在下一级中。处理递归地继续，以捕获当前窗口结构。图形元件832表示更新之前由P 836、834、Q 838、842、848、850、852以及R 840构成的对象树。参照更新后的树854，如果具有新的IE窗口或GUI对象，则调用GetIETree，用于对层次866、870中的HTML子元件进行检索，然后调用Notifydestroyrealtree()消除树中全部剩余旧对象。这是枚举用于全部窗口(包括从旧列表到新列表都存在856、858、862、860、868、872的窗口或GUI对象)的树的基本处理。一旦对象在旧列表中被标记为废除的，新创建的每个对象866、870都自动链接到全局列表中。该位置剩余的每个对象都调用变体(即，调用函数Notifydestroyevents 818)，并且在对树进行分析的过程中。当期检测到对象不再存在时，将向脚本发出破坏事件828。先前的树结构仍然保持原样，以使得在旧树的上下文中发送破坏事件，以保持gMg脚本的当前上下文有序地对删除或维持的对象进行更新。

函数SynchTree 826处理实际为新树的真实窗口集。Dwindows结构824包含旧树，旧树是gMg系统使用的树。SynchTree代码的这部分已用真实窗口下的相同对象建立新树，其代表全部新的对象并向gMg告知旧树(其保持原样用于之后由脚本使用)上下文中的全部被破坏的对象。调用SynchTree，该调用递归地将真实指针复制到Dwindows中，并导致将真实的当前树转换为gMg树。此时，gMg脚本812现在具有到新树的通道，且旧树不再存在。此外，全部被破坏的对象不再存在于树864中。现在具有创建的全部新对象的全局列表。向gMg脚本发出创建事件830，以向该脚本告知存在的每个新对象866、870。同时，如果在已发现的DOM具有HTML文件对象，那么函数IEEvent将被设置为预定。

完成树更新处理之后，用于存储全部新对象的临时列表被解链接并被清除。然后对新对象列表末端指针重新设定，以指回列表的头部。该列表以创建对象时这些对象被发现的顺序建立，而不是以相反的顺序建立。函数Updatetree对应用程序进行扫描，并生成创建/破坏事件。首先发出用于已消失对象的破坏事件，然后发出用于已检测到的新对象的创建事件。

在属于单一gMg.exe(代理)的一组gMg引擎中，可用登记的OS窗口gMg消息建立gMg引擎的不同实例之间的通信。该消息是唯一的gMg窗口消息，其还使用完整目录路径名和模块文件名(即，gMg.exe)创建。完整目录名包括用于gMg消息的标识符，并且存储在共享的存储区域，用于由并行运行的引擎访问。登记的窗口消息登记在OS中，因为其要求应用程序具有对计算机系统唯一的窗口消息。例如gMg代理及其引擎的应用程序将调用OS API函数传递标识串，OS根据该标识串检查用于识别串的内部表，并且如果存在的话，则返回已分配的标识符。消息第一次被应用程序发送时，其被添加到内部表中，并被分配全局唯一的窗口消息，用于在OS内可执行的且易失的应用程序，如果计算机被重启，该标识符则丢失。例如，对于内部程序通信，如果两个程序都具有OS登记的窗口消息，那么唯一的串将识别每个程序应用。OS将返回分别对应于每个程序对象的唯一标识符。登记之后，窗口消息信息被存储在gMg的共享存储中，以备由被gMg传感器注入的全部目标进程检索。

主目录包含全部gMg代理系统组件，包括主要可执行程序(即，gMg.exe)、DLL、*.ini文件以及其它组件。主目录的完整OS路径名在多实例gMg代理和引擎中起作用。包含主要代理的可执行文件的路径和目录用户包含组件集的关键内部gMg实例。如果在单一的计算机上具有多个代理，那么每个代理都在其自己的目录下。此外，gMg引擎的全部运行时间实例都通过完整文件名和路径键入目录中，使得多个安装的引擎能同时运行。OS对键入每个DLL名及其路径的共享存储块的一部分进行分配，以确保唯一性。该存储块独立地跨越不同的安装的引擎，以防止冲突。对于全部运行时间操作，OS将共享的存储与每个引擎DLL的主目录相关联。

参照图9，每个代理和引擎都可从目录或从远程服务器位置处加载一个或多个脚本939，以支持gMg多实例能力。如果相同的脚本在N个进程中运行以在N个主机应用程序901、902、903中执行，那么脚本945、948、951的N个实例和副本将通过918到936的多个线程在N个进程909、912、915中运行。每个进程中还可运行不同的脚本，每个脚本可处理其各自进程中的线程。或者单一的连接脚本可监控全部N个进程。gMg脚本级的多实例主要由脚本数据区处理。为了处理单一引擎中的N个脚本，函数LoadProgram 942通过命令行执行加载操作，或为gMg脚本本身中的命令的结果。通过大量选项(例如，加载、卸载或重载)传递文件名。程序列表(PGMLIST)957被维护用于同时运行的全部脚本。在程序加载过程中，确定脚本二进制文件的大小，并将存储器分配给具体的大小。一旦文件被成功加载，则关闭文件。执行完整性校验，并在块的起始处查找签名(Signature)。如果有效，则加载有效的文件，并将该文件添加到程序列表(ProgramList)结构的维持的列表957中。

程序列表操作包括移除、添加或替换。如果脚本已运行，则不进行加载。重载操作终止当前运行的脚本，并加载具有相同文件名的脚本。当脚本名作为程序列表中的标识符时，引擎一次仅能运行一个具有相同文件名的脚本。作为一种选择，如果脚本位于不同目录下时，引擎可运行具有相同名称的两个脚本。由于名称也包含了路径名，因此，具有相同名称但在不同路径下的两个脚本可被同时加载和执行，而不具有冲突。卸载函数还允许使用通配符字符(例如，卸载目录名\*(DirectoryName\*))，将所有对象从目录名(DirectoryName)下移除。当脚本在进程中运行时，装载函数(LoadProgram)不能被执行，因为LoadProgram 942要求通常已由执行的脚本设置的gMg被设置。如果试图加载或卸载未处理完事件的脚本，那么在另一个脚本可被加载之前，操作先停止当前的脚本。然后，脚本启动并执行加载操作。

解释脚本将事件串行化，并且由于每一遍仅处理单一的事件，因此脚本运行非常短的时间。当事件发生时，脚本运行并通常在1或2毫秒内就完成对事件的处理。因此，脚本通常都是不运行的，且引擎空闲。当具有可能是在高层级其形式最简单的许多组织和结构时，脚本的作用就像一组“如果(if)”或“切换(switch)”语句。

当需要在调度上对脚本进行远程自动更新时，如果gMg脚本在运行且由gMglock管理，那么则可执行对新版本的更新。通过代理的脚本的控制，可运行各种动作，例如更新、移除、重载等，也就是可如何根据需要加载和激活脚本。指定的主gMgMain组件(即，代理)可从服务器或跨越进程的某些其它源接收GLOBAL_RELOAD_SCRIPT消息(其由RUN命令生成)。该消息可由主gMgmain组件变换或直接转发至全部代理及运行在不同应用程序进程中的其各自的引擎。接收到命令消息之后，目标引擎和/或脚本操作将导致脚本加载或更新命令的执行。

gMg监控系统内的两个附加特性是Object Variables(对象变量)和WhenObject关键字，这两个附加特性对于允许响应、建模以及处理多实例GUI对象集是重要的。

gMg脚本关键字Object Variable提供在经常改变的环境中跟踪不同对象集的机制。优选地，为了跟踪每个不同进程内的动态状态，当具有多个脚本时，每个脚本都具有其自己的变量集。每一个变量集都独立于其它变量集，并支持每个引擎和各自的脚本实例。ObjectVariable提供实时响应于同时在多个进程和线程中运行的GUI对象集和子集的潜在的不同实例的机制。脚本可被书写，以反映应用程序的运行时间的动态多实例结构并对其建模。术语“Object Variables”指gMg脚本“对象”，这些对象趋向于用于抽象操纵、操作或用于响应于动态的主机应用程序GUI结构并与之关联的动态分配。

参照图10，gMg对象变量1035定义了附着于gMg运行时间GUI对象树1015中的GUI对象1020的抽象结构。对象变量用于表示反映主机应用程序的用户接口的目标GUI对象或GUI对象集。

此外，对象变量的将指针存储到对象变量内部的对象的能力进一步在非常动态的应用程序GUI对象环境中支持多实例和多实例管理。可将对象参考存储为对象内的变量或存储为指向另一个对象或对象变量的指针。指向对象变量的指针可动态地创建在位于GUI对象树1015中的每个对象中，并可响应于多实例主机应用程序检测被分配其自己的变量集。此外，可将对象指针存储在不论是否位于某些其它结构内的GUI对象树中任何对象变量中，或者可在别处独立地对该对象指针明确地说明。例如，如果具有同一类型的两个对象变量，那么每个对象变量则具有其自己“私有的”变量集。这些变量位于GUI对象树中的对象内，而不位于脚本的数据区域内。在另一个实施例中，如果对象树中具有二十个对象，那么则具有用于二十个变量集的、由gMg引擎动态分配的二十个相应的位置。

参照图10，任何给定的对象变量1005可附接变量列表1010，其中的关联由函数Setnumobjvar(ObjHandle，Progid)处理。在编译时，可在脚本内生成用于该对象变量的唯一id(例如，分配给其的对象变量名称值)。在gMg脚本1040中，可为分配到物理结构的脚本对象变量分配值。对附着于对象的数字的或字符串的或其它类型的对象变量列表进行扫描，直到发现属于当前程序结构的、并包含在为对象变量编译程序时分配的匹配id的对象变量。由于具有具体的对象变量集1039，每个对象变量集都具有其各自的变量列表用于每个程序脚本，因此，当运行多个脚本或程序时，每个脚本都具有其子集的对象变量，即使其引用1045全部其它并发脚本共享或引用的、应用程序的相同GUI对象。一组脚本将共享反映运行进程的相同GUI对象树1015，每个脚本都具有包含在对象树内的、附着于每个对象变量1039的其自己的独立变量集，用于多实例支持。优选地，具有单一的对象树，其可扩展具有相似的实例支持结构的多个树。

状态变量的这种动态分割带来了同时对应用程序的GUI的多个实例进行跟踪的能力。作为对象变量的实现的实施例，可由多个单独的脚本同时从不同角度对同一个页面进行跟踪。为此，运行脚本并建立监听程序和传感器。当事件发生时，将事件发生到每个单独的脚本，每个脚本确定如何独立地处理事件。

作为一种选择，在另一个实施方式中，每个gMg对象变量(例如，位于对象树中、或为其它结构，并对应于应用程序GUI对象或内部抽象组织)可依次包括在脚本中说明的对象属性值(例如，字符串、布尔值、数值等)。这就提供了进一步的处理深度，用于对不同状态的对象变量及其属性进行比较、条件测试、或实现逻辑。

第二gMg命令，也就是图11所示的WhenObject关键字，是支持gMg监控系统1133中的多实例能力的另一特征。参照图11，WhenObject是在属于主机应用程序1103的GUI对象树1115中附着于任何对象1106、1109、1112的对象。When GUI对象在树中是多实例的，WhenObjects也是多实例的。WhenObject命令的作用是在不存在与主机应用程序GUI的改变相关联的明显事件(由OS、主机应用程序或其容器发出的明显事件)时，检索属性或估计GUI对象属性的变化。有时，当没有事件发生时，也会有GUI属性变化。相反，有时有事件发生但没有GUI属性发生变化。其它时候，识别使用哪些事件检测目标属性的改变变得更加困难或模糊。通过经由轻量轮训机制访问GUI对象属性，WhenObject命令解决了这些问题。

具体的gMg脚本命令WhenObject使得在WhenObjects例程中将调用PollWhenObjects 1148。该例程将脚本代码块1160与WhenObject1157相关联，并保持跟踪其属于哪个脚本。在主机应用程序进程中运行有多个线程1121、1124、1127，在每个线程中，由gMg代码分别实现对Pollwhenobjects()的调用1148。每个线程首先设置gMglock 1120，以使脚本引擎仅执行一个脚本，也就是在事件串行化过程中一次执行一个事件。此时，对全部相关的WhenObjects的列表1151进行处理。具有清除操作，其中，如果WhenObject与GUI对象断开连接，则将其舍弃(即，将GUI对象删除)，并且将其相应的WhenObject对应物从WhenObject列表中移除。

如果GUI对象属于当前运行的线程，那么该线程则运行适当的WhenObject。当前程序被设置以引用发出WhenObject请求的任何gMg程序脚本，然后设置代码指针1157，代码指针1157为指向WhenObject条件表达式的脚本解释器程序计数器，该条件表达式在测试WhenObject执行是否应该激活的脚本代码1160的片段中限定。脚本程序计数器指向脚本代码(即，建立上下文的程序结构)。其指向在脚本代码的主体中被编译的实际布尔表达式，且发出WhenObject事件。在附着有WhenObject的GUI对象树1136中存在对象1139、1142、1145。调用Getnumber()，且如果其估计为真实，那么WhenObject则变为活动的。表达式在脚本程序和事件对象的上下文中被估计，并设置“执行上下文(execution context)”。该上下文确保了处理发生在正确的进程、线程、树中的GUI对象等中。gMg脚本对WhenObject事件进行处理，该WhenObject事件为被处理的全局(当前的)事件。WhenObject事件的对象是对象树中链接于由适当的线程处理的WhenObject结构的对象。如果表达式为真，则将其添加到统计数字中，该统计数字保持关于WhenObjects多少次变为活动的信息。不断地对命令进行处理，直到遇到停止操作码。

在gMg解释器1153(以及主机应用程序进程中的示出的运行1130)中，函数ExecCommand()执行gMg脚本的操作码集。变量gPC指针是指向脚本代码(指向条件表达式并且在条件表达式之后紧接着是一系列语句，然后接着是停止操作码)的全局解释器程序计数器。对表达式进行估计，使得程序计数器通过该表达式。如果表达式为真实的，那么则使其指向第一语句并执行命令，在这种情况下，具有WhenObject命令。

这样，WhenObject命令通过表达式Getnumber执行轮询操作，Getnumber获取对象的属性，然后执行脚本命令。来自全部脚本的全部WhenObject进入集中式列表1151。此外，脚本对象指示与各脚本之间的关联。当脚本终止时，将WhenObject(结构)移除，而当对象终止时，也将具体的对应的WhenObject移除。结构gWhenObject是来自全部并行的多实例脚本的WhenObject的集体列表。

WhenObject需要由脚本的线程执行，由线程控制确定何时在哪个线程中执行哪个脚本。因此，在当前线程中，仅对与当前线程相关联的WhenObjects进行处理。线程在执行函数之前，设置用于各脚本1154的上下文(对1130处位于应用程序进程中的引擎和脚本的扩展表示)。通过设置上下文，线程看到属于该脚本的对象变量，并阻止对其它脚本的对象变量进行访问。WhenObjects可为对于运行的全部脚本而言是集中式的。

以下代码样本示出了gMg系统的多实例能力的实施方式。该脚本检测不限数量的线程，每个线程控制一个同时具有不限数量的消息窗口的弹出式窗口。如果gMg脚本对应用程序中的每个GUI对象的使用期限进行监控以用于完整监控，那么则需要创建多个实例结构。对于每个对象而言，gMg自动维护表示GUI对象的实例的结构。对象树具有用于每个对象的属性高速缓存，并具有用于每个对象的对象变量存储。

//″Manylnstances″-this script handles an unlimited number of objects

objvar createtime：number；

if (create )//on creation

{

createtime＝sys__time；//createtime is an objvar that is created(hence an

//instance)for the current Event.Where an instance is //a resultant

action of the Event

var s＝title；//s is a temporary variable and illustrates gMg′s

s＝class；    //instantiating ability.Here title and class for the

}//current object are stored separately inside the GUI Object Tree

if(destroy)

{

//the current time-createtime(which took place previously)yields the

//lifetime of the object

dbg(objtypename(objtype)+′[′+title+′][′+class+′]existed for′+

string(sys_time-createtime)+′ms\n′)；

}

//---------------------------------------

//Boolean expression that indicates if the current object is a popup

window

function ispopup＝iswindow && title＝＝′blabla′&&class＝′whatever′；

//indicates if the current object is a message window of interest

function ismsgwindow＝iswindow && title＝′blabla′&& class＝

′whatever′；

//if a create event and the create is a popup，and in the thread object of

the popup

//store a ptr to the object that popped up，object is a keyword that refers

to the

//current object i.e.the object that′s being created，creates a ptr to the

popup in

//the thread object whatever thread the object belongs to

objvar mypopup：object；

if(create&&ispopup&&thread.mypopup＝none)//if a create，thread

val would be empty

thread.mypopup＝object//pointer to popup object

//if a destroy evt and the object being destroyed and the object is in

thread.mypopup

if(destroy && object ＝thread.mypopup )

thread.mypopup＝none；//clears thread.mypopup

//when a message window is created a WhenObject is attached to objvar

//prevtitle；checking if the title changed compared to the prev title i.e.the

//changed fn.

objvar prevtitlerstring；

if(create && ismsgwindow )

WhenObject(changed(livejitle，prevtitle)&& thread.mypopup！＝none)

//thread val is non zero

大量关键字或对象变量定义具有响应于当前对象由GUI对象(例如，“prevtitle”、“title”和“class”)的动态分配确定的隐含行为，其中当前对象是反映当前事件和由解释器处理的当前对象的结构。

变量mypopup是对象变量。在处理期间，调用函数Getnumobjvar()。初始化之后，首先发现对象不存在，并返回默认值零。然后调用函数SetObjObjVar()，将当前对象的基准值置于用于弹出式窗口的位置，并且将弹出式窗口的基准值置于其自己的线程对象中。

“Live Title(活动标题)”是当前的，其在标题变化的情况下刷新标题，如果活动标题值与先前的标题不同，则“Live Title”为真，其中先前的标题存储在消息窗口对象中。例如，如果应用程序创建十个消息窗口，那么每个消息窗口则将具有其自己的先前的标题值，并将保持对全部标题变化进行跟踪。十个WhenObject与每个消息窗口相关联。

系统对消息窗口进行监控，每个消息窗口将被监控，以检测“LiveTitle”的内容，即，从先前标题变化为当前标题(改变的命令)。如果其值为真，且弹出式窗口标题为“abc”，那么则检查各弹出窗口是否在与消息窗口相同的线程中运行。因此，当消息窗口标题改变且显示的弹出式窗口标题是“abc”时，当检测到之后，条件分析为正确且执行WhenObject动作。

WhenObject激活用于检测到的每个消息窗口，然后通过用于弹出式窗口的测试进一步对其限定。可具有不限数量的线程，每个线程可具有不限数量的消息窗口，但是只允许一个弹出式窗口用于一个线程。该代码还示出了对象内的对象指针(即，thread.mypopup＝object)。作为实施例，可具有二十个线程，其中的每个线程都具有自己的弹出式窗口。对于每二十个线程，名为mypopup的变量记录关于每个线程的信息及其相应的弹出式窗口。根据这些结构，可跟踪每个线程变量各自的弹出式窗口是否存在。

下面介绍gMg上下文及其在GUI结构的多实例识别中的作用。参照图12，gMg脚本上下文关键字说明了分级的组织实体，该实体表示多实例GUI应用程序结构的一部分，以向服务器提供上下文信息以支持对收集的跟踪数据进行分析。上下文命令可用于全部对象类型。顶层是进程1215，但是如果该进程具有多个顶层窗口1210，那么从当前进程的顶层窗口开始的子上下文则建立窗口的分层关系，以表示并识别用于发送到服务器的生成的跟踪事件的上下文。上下文描述在描述多种对象组织方面是灵活的。如果指定了顶部窗口，那么跟踪消息就形成有顶部窗口及其父类进程，否则，仅发送进程。

为了跟踪进程范围内的事件，可设置上下文以进行处理，但是，如果跟踪例如多个弹出窗口1205的对象，上下文则可相对于发生事件的具体的弹出式窗口设置。根据定义，上下文设置由服务器分析的隐含分级。存在有五层分级的任意门限，该门限与每个跟踪消息记录一起发送。对于多数情况来说，五层被认为是足够的。但是，层级门限可容易地扩展或减少。

参照图13，如果在主机应用程序的GUI树组织1305中，存在GUI对象或GUI对象集或对象的多个相似实例，那么，上下文层级值变得很重要。例如，如果给定具有多个线程1320到1335(其具有多个弹出式窗口1340到1355，即，每个窗口用于一个线程)的进程1315，且每个弹出式窗口包含具有多个标签1360的标签窗口，那么，这就描述为第四层上下文。上下文提供外部信息，该外部信息在每个实例可被识别时是有用的(例如，如果窗口中一组标签中的每个标签是唯一的)。考虑典型窗口GUI对话框的改变字体大小标签中的OK按钮，在此实施例中，当相似的OK按钮的多个相同实例和结构同时出现时，上下文是绝对必要的。尤其是网络应用中的微软IE浏览器允许多线程，其中每个线程可具有与其它线程相同的网页。对于具有这种深层GUI对象的应用程序而言，上下文是绝对必要的，其中每个GUI都具有多实例。由于上下文通常可通过属性和用于检测的其它机制识别，因此，五层是足够的。

在另一个实施例中，对于通常在网页应用程序中发现的具有多个标签的窗口而言，仅发送标签控件名或其它标记就可指示哪个标签存在或被点击。然而，如果全部标签控件都具有相同的结构用于不同位置的应用程序，那么，为了在不同的标签中进行区分以用于活动跟踪，则需要另一个上下文层级定义。附加的上下文层级传递数据(例如唯一id和/或参考值)，并反映每个标签中的具体值。

在另一个实施例中，联系人应用包含顾客信息记录，并向用户显示包括姓名、地址、电话和电子邮件数据的多个顾客记录。在这种情况下，全部记录都具有由单独线程和单独弹出窗口构成的相同的内部结构，但包含对每个顾客唯一的内容信息。弹出式窗口具有相同的结构，但是每个弹出式窗口具有唯一的内容。在顶层结构中，这些弹出式窗口看起来与没有附加信息的gMg系统是相同的。为了解决这种模糊性，将外部上下文层级用于区分不同的弹出式窗口，从而得到重新配置的上下文信息，该信息用每个跟踪消息发送到服务器。在服务器上，将共同的上下文层级分组到一起，以跟踪在每个GUI窗口结构内发生的事件，这样，如果在一个窗口上进行了点击，则不会与其它窗口上的点击混淆。

除了GUI对象，线程对象也可作为识别处理的目标。线程可在上下文中识别，其中GUI多线程应用程序中的每个应用程序线程都指定有其各自的上下文。给定具有多线程和多个相同的顶部窗口的应用程序，将引入额外的层级(进程中的线程对象)和用于识别的线程id。当具有多个相同的线程，其中每个线程都具有相同的顶部窗口，从而需要对每个顶部窗口群中的活动独立于其它相同顶部窗口中的活动进行跟踪时，这样就处理了多线程的情况。由于多个线程可表现为相同的，因此，定义其它的对象或关系(例如，先辈)以识别不同的线程及其相关联的对象。当识别GUI结构并从而识别事件时，在许多网页应用(例如工业标准CRM(顾客关系管理)应用)中都会遇到这种模糊的情况。

在不同的实施中，例如在微软CRM应用(CRM是微软公司的产品)中，发现弹出式窗口可为任何新的活动而打开，然后创建新的线程，然后则需要创建与用于附加弹出式窗口一样多的许多线程。在这种情况下，gMg的线程上下文的使用将分离的弹出式窗口区别开来。然而，如果仅具有一个层级，并且在弹出式窗口内可创建附加的多个相同的窗口实例，那么则需要附加的上下文层级。最终，微软CRM实施例仅要求两个层级。层级数量的扩展可证明为更方便的，并可保留用于将来的扩展。作为一种选择，可在弹出式窗口中利用其它属性进行区分。

通过定义具有足够深度(分辨率)的GUI对象上下文层级，可将其它方面相同的GUI对象结构区分。如果具有多个相同的GUI对象结构窗口，则可使用顶部窗口将其分组。逻辑组中的之间与目标GUI对象相关联。gMg上下文特征支持多实例能力，用于进行对象区分。

下面讨论为了支持多实例以建立挂起而进行识别和事件检测的问题，讨论提供了用于gMg系统的一个主要事件类别。

参照图14，ChangeHook和lockgMgEngine传递线程id，并根据需要挂起应用程序进程1406。然后，发送gMg消息1424，并用函数PostgMgMsg()将其登记到应用程序中。利用传递的线程id，PostgMgMsg函数找到使用该线程id的窗口，然后设置窗口消息。如上所述，gMg使用.exe的完整路径名登记其唯一的窗口消息，该路径名使得多个gMg.exe具有唯一性。PostgMgMsg通用地工作，并发送消息的多个副本以完成登记过程，其中成功的第一消息与丢弃的剩余消息一起在系统中使用。共享存储1454用于对每个gMg代理或引擎实例的gMg消息的废弃进行控制和跟踪。对于诊断支持，tmdiagnostics包含在消息wparam中，具有指向位于共享存储中的诊断数据的lparam。当某些gMg组件需要诊断信息时，gMg窗口消息则发送diag_exports消息，该消息到达一个winhook例程。

在来自操作系统1403的时钟1457的驱动下，所有运行的挂起例程1433到1442最终都拦截消息，并调用例程Handlemsg()1445。在Handlemsg内，在getmessagehook例程1445处，基于当前由系统设置的挂起数量，将getmessagehook与数N相连接。挂起在0-N的一组宏1427中实现，这组宏调用函数handlegetmsghookmessage 1430。当挂起操作完成后，还具有指向每个例程的指针阵列，其中在编译过程中将autoinline设置为关闭，以防止gMgMsg例程在每个实例中被多次复制。此外，在Handlemsg中，具有N个Sendmessagehooks，其也对调用HandleMsgHookMsg 1451的sendmessage 1448消息进行处理。这些例程将拦截消息，而不管消息的来源。

优选地，使用主机线程1409、1412、1418、1421，而不是创建专用的工作线程用于对处理进行监控。仅使用在进程中创建的计时器使窗口创建最小化，以建立回调函数。此外，由于挂起的目标是要透明且最小地侵入，因此不创建工作窗口。即使建立了工作窗口，该窗口也需要计时器用户进程控制。

gMg系统向主机应用程序的现有窗口发送消息，然后拦截消息。消息很少被跨越进程地发送，但是如果的确发生了这样的事情，那么将对主机应用程序中的N个不同窗口进行搜索。一旦查找到gMg，其则在每个窗口中设置挂起，并且在消息到达各自的目标窗口时拦截消息。

当每个线程具有一个挂起时，tid宏得到当前线程id。通常，从拥有当前线程的窗口接收消息。但有时候也从其它窗口线程接收消息。执行sendmessage的线程必须属于相同的进程，否则，DLL必须侵入未明确挂起的另一个外来进程。如果Sendmessage由不同的进程启动，那么则将其放入目标进程中，然后在该进程中分配调用挂起例程的线程。Handlemsgs例程从Getmsghook()和Sendmsghook()1445中调用。消息处理具有一致的行为，即，不论消息如何到达，gMg都尝试进行截获。

GetExtParams()用于在SendMessage调用期间使用gMg进程内窗口消息(例如，加载脚本、卸载引擎等)将额外的参数和信息传递穿过多个进程。其在共享存储中具有锁定，包括版本号和索引。该函数将版本号屏蔽，并可索引到共享存储中的阵列中，以得到将在索引之后用消息传递的附加数据。如果(包括该版本的)共享存储id与要求的id不匹配，该共享存储id则为废弃的条目。32位数id不断增加。最后六位是到ExParams结构中的循环缓冲器的索引。如果缓冲器中的32位id与传递的参数不匹配，那么则确定该id已被重复使用或被废弃。GetExtParams()读取lparam，并且如果其为废弃的，则返回空值。如果lparm不为废弃的，则用外部参数处理消息。具有用于将引擎的释放版本的代码移除的宏。还用测试检查是否加载了dbgdll。

在gMg系统中检测GUI对象集的GUI对象检测机制称为泛型检测。泛型检测方法利用在客户和服务器上均具有分布式处理确定并检测GUI事件。具有两类GUI对象操作：具体的和泛型的。在泛型方法中，通过非常少的操作描述符对对象进行检测，以创建一组或一类GUI对象。可对馈送到函数中的输入参数进行分析，以检测一类GUI对象，而不是仅检测一个具体的GUI对象。

在客户机上，在图15的GUI检测的谱(spectrum)1515中，特意将gMg脚本表达式示为更泛型的1510(例如，用于检测相关GUI对象的整个类别)或更具体的1505(例如，用于检测单一的GUI对象)。检测表达式可检测对该概念谱中任何位置的GUI对象进行检测。gMg传感器收集主机应用程序GUI对象数据，并使用该gMg脚本遗传性地(或分类地)限定用于GUI对象检测的表达式。将得到的GUI对象细节和属性的集合打包并发送至服务器。服务器接收这些分类的事件和伴随的属性，并对其进一步处理以确定具体的GUI对象事件。服务器通过使用跟踪消息层和预定的语义和约定，建立用户上下文。对于具体的GUI检测，将跟踪消息发送至包含关于对象的具体属性的、识别的每个GUI对象。在泛型检测中，发送包含用于服务器的足够数据的跟踪消息，以滞后地确定具体GUI对象分析和识别。

在以下的具体的和泛型的绑定代码实施例中，第一实施例示出了具体绑定(针对单一的GUI对象)，其中客户机滤除并发送不同的跟踪消息，用于被跟踪的四个定义的GUI按钮中的每个：

1.检测类是否为“按钮”，标题是否为“OK”且顶部窗口是否为开放的(Open)窗口。如果全部为真，则发送跟踪消息，指示按下了打开成功(Open OK)；

2.如果其为Save(保存)对话框中的OK按钮，则将发送保存成功跟踪消息(Save OK)；

3.进一步地，如果其为打开对话框中的Cancel(取消)按钮，则将发送打开取消跟踪消息(Cancel Open)；

4.如果其为保存按钮(Save Button)和具有保存/取消(Save/Cancel)消息的保存对话框，则将发送适当的跟踪消息(Cancel Save)。

下面示出了如何对四个具体类型的按钮进行检测。

/*Specific and Generic Binding Code Sample */

context process＝process server ″someserver″

context thread＝thread in process

context topwindow＝topwindow in thread

//Specific Binding-client determines specific object and sends unique

track message for each

if(wlbutdown &&class＝′BUTTON′&&title＝＝′OK′&&

topwindow(title＝Open″&&class＝＝″332767″))

track(priority，pressed，topwindow，″Open Ok″)；

if(wlbutdown &&class＝＝′BUTTON′&& title＝′OK′&&

topwindow(title＝＝″Save″&&class＝＝″332767″))

track(priority，pressed，topwindow，″Save Ok″)；

if(wlbutdown && class＝′BUTTON′&& title＝＝′Cancel′&&

topwindow(title＝″Open″&& class＝＝″332767″))

track(priority，pressed，topwindow，″Open Cancel″)；

if(wlbutdown && class＝′BUTTON′&& title＝＝′Cancel′&&

topwindow(title＝＝″Save″&& class＝″332767″))

track(priority，pressed，topwindow，″Save Cancel″)；

//Generic Binding-client sends one track message for all，but with info

for server to figure out which

if(wlbutdown && class＝′BUTTON′)

track(priority，pressed，topwindow，″Button″，title＝title，

toptitle＝topwindow.title，toρclass＝toρwindow.class )；

与按下事件耦合的、“按钮”类的任何对象上的任何按下按钮消息发送跟踪消息，指示按下了按钮(任何按钮)。顶部窗口和顶部窗口类也可转发至服务器，以对四个按钮中的哪个被激活进行分析和检测。在泛型代码中，与在传输至服务器之前清楚识别目标GUI对象不同，多个跟踪消息结构除了可包含将其区分的不同内容数据之外可为相同的。

在具体的和泛型的情况下，由解释器接收事件，并且，在事件解释器处理中，基于在两种情况下的脚本中描述的条件，事件执行属性检索以允许执行条件表达式。属性检索是条件的一部分或是条件语句(例如，if(Q){R}，其中R可包含一个或多个跟踪消息)的主体的一部分。此外，服务器处理并检测不同的GUI对象，并且查找例如Save(保存)、Cancel(取消)、OK等各类按钮或分析文本以执行字符串匹配。执行字符串匹配将检测处理责任从客户机移至了服务器。

gMg系统的方法监控使用专用传感器监控包含在组件内的方法。该专用灵活的传感器使得本发明可生成并集成跨越客户机或服务器上的操作系统中的目标主机应用程序谱的多种类型的事件。方法监控包含对组件方法的拦截，以支持拦截函数调用并返回被打包为DLL的主机应用程序组件的传感器类型。拦截函数调用使gMg系统能从可被传递到逻辑脚本用于跟踪和监控的组件中检索事件和属性。

假定任何函数都可调用另一个函数或递归地调用其自身，gMg方法监控则基于多种情况和组件环境中的两个基本目标。首先，目标方法的地址将被定位。其次，目标方法被拦截。用于对目标方法的地址进行定位的技术依赖于在其实施中使用了什么组件技术，所述实施包括COM、非COM对象、输出函数、或typelibrary报头中的信息变量、函数参数、函数返回、存储、vtables等。尽管将COM方法(图16，项1624到1636)作为gMg能力的实施例进行讨论，但是，该原理可用于包含在其它公司的不同组件技术中的方法，不同组件技术例如Corba(可从马萨诸塞州尼德姆镇的对象管理集团公司(ObjectManagement Group，Needham，MA)得到)、IBM的SOM(IBM，Armonk，NY)、以及用于建立软件应用程序的许多其它组件系统。对于gMg系统，对这些附加技术的扩展支持是建立不同组件类型适配器的任务。对于本领域技术人员显而易见的是，本说明书中提出的技术可用于其它组件技术。

在另一个实施中，当监控方案在gMg方法传感器可被激活时指示存在包含目标方法的对象时，产生COM内的使用gMg临时对象的附加因素和技术变化。然而，如果对象还不存在，那么对新的对象的操作系统的创建进行监控则将产生这些对象的方法位置。gMg以保存主机应用程序的执行连续性的方式操作(即，在监控方法时不中断地执行)。方法目标嵌入在各种组件技术中，这些组件技术基于操作系统中或主机应用程序中的可用接口。

为了支持COM方法拦截，如果在COM组件已创建之后将gMg方法传感器激活，那么首先对VTables定位以检索方法地址。VTable或虚拟表是COM类中的表，其包含指向该类的方法或函数的方法指针。然后将gMg方法签名拦截的技术用于建立监控。注意到，如果公布了COM接口，那么其则归档为TypeLibs，并在DLLs/OCXs中找到。

另一个组件类别，输出函数具有暴露在DLL组件中的方法接口，其中输出函数名列在程序模块报头中的组件的输出表中。一旦被定位，gMg方法签名监控(指图16中的项1612、1621、1639)则在对方法进行主机应用程序调用或返回时建立捕获点。

确定组件类型(COM或输出函数)之后，图16A中的gMg方法签名监控(项1657)是关键的，并且在目标方法被定位之后在多个情况下深入地用于整个gMg方法监控。方法签名定义为方法的入口点的操作码模式，其在gMg系统中描述并用gMg检查工具发现。定义了操作码模式之后，这些操作码模式用于对方法入口点进行定位和验证，然后这些方法入口点用于调用和返回拦截。方法签名监控可普遍地用于任何定位的函数，而不管其封装、环境或位置。在COM或输出函数中的一个组件类型中发现目标方法地址之后，gMg的方法签名方法监控则用于执行方法拦截。

在另一种配置中，如果当调用以定位的VTable方法开始，并且在VTable方法中，组件还存在对方法的其它内部调用时，gMg方法签名监控也可用于跟踪内部方法调用，那么，则进行方法签名监控。此外，方法签名监控用于作为COM对象内VTable方法监控的设置的一部分。

参照图16，示出了gMg方法监控的一般观察。在操作系统环境1609中运行的主机应用程序1603通过对操作系统代码函数LoadLibraryExW 1618进行调用，而启动其DLL组件1615的加载。gMg监控设置对内核函数LoadLibraryExW的拦截，以确保检测到目标DLL的全部实例。DLL包含输出函数1620或COM Typelibraries 1624。对于COM方法监控，正好在创建目标COM对象之前。为了对COM的VTable 1633进行定位，gMg监控对COM创建1627的不同阶段进行拦截，VTable 1633包括指向其全部接口方法1636的指针。这些执行阶段如下所述：gMg拦截DUGetClassObj ect模块。DllGetClassObject由主机应用程序调用，并返回IClassFactory；gMg拦截IClassFactory::CreateInstance；IClassFactory::CreateInstance由主机应用程序调用并返回新创建的COM对象；以及具有新创建的COM对象的检查和操作产生其VTable的位置。

在COM已启动且将其方法“迟绑定(late bound)”的情况下(方法在运行时间而不是编译时间被启动和登记在例如VTable的结构中)，gMg系统创建其临时COM对象1630，临时COM对象1630向由组件内的其它目标方法(已绑定)使用的相同的VTable提供地址。VTable被定位之后，gMg系统将其方法签名监控1639用于透明地且不引人注目地监控目标方法。对于对输出函数1618进行监控，gMg方法签名监控还用于拦截函数调用。

参照图16A 1657，当方法被定位之后，gMg监控设置签名方法拦截，用于对由应用程序的方法调用程序1606直接或间接产生的目标方法的调用1642和返回1645进行拦截。gMg拦截代码维持原始函数的整体性，并基于主机应用程序的调用和/或返回，向gMg解释程序1660发出适当的gMg事件，并传递由脚本请求的相关信息。

将对方法返回的监控分类为泛型的或具体的(注意：不是在GUI对象的意义上)。图16A示出了用于泛型返回捕获的两种技术，堆栈复制1648和堆栈分配1651(有时也叫做按线程分配堆栈)，这两种技术在下文介绍。具体监控1654指这样的方法，其参数在例如typelibrary的公开的位置找到。然而，泛型方法拦截可与任何函数一起工作，而无需预先知道函数的参数和返回值。在这种情况下，当调用了函数或从函数返回时，仅生成没有具体信息的事件。在泛型拦截方法中，执行调用和返回形实替换程序(Thunk)并执行其代码。

在gMg跟踪和监控系统中的三种重要结构(图7和图8的GUI对象树以及进程/线程树)中，第三种结构，也就是代码模块树，包含被动态地检测以支持方法监控的模块、函数监控器以及COM对象实例。

参照示出了由方法监控传感器使用的模块树的图17，其中示出了在根部具有模块列表1705的分离的模块树。函数监控树项1710、1725和1730可在树中的任何位置。对于来自接口监控1715的function_call事件，如果(function_call事件(Pl，Ptr_to_COM，...)的)一个变元(argument)指向COM对象，那么COM对象1720则可为function_call事件1715的子事件。在脚本的驱动下，仅监控选定的函数。模块树选择性地仅包含满足脚本监控要求所需的。此外，由脚本中的关键字驱动的gMg解释器对GUI对象树和模块树进行更新，以对真实GUI应用程序建模，并支持应用程序中的函数事件。

启动后，由程序模块1705填充模块树。树中的接口和函数对象仅根据脚本的请求而创建。模块树运行后，利用LoadLibraryExW调用和返回拦截对模块树进行维护。

在输出函数中，将请求监控的脚本请求添加到模块树中的模块对象的子函数调用对象中。将感兴趣的COM对象的接口对象也添加为模块对象的子对象，用于参考并监控所述类型的对象的创建。当创建了期望类型的COM对象时，这些对象也添加为接口对象的子类。当脚本请求对接口的方法或对COM对象进行监控时，将方法函数调用对象添加为接口对象或COM对象的子类。从拦截的方法调用中发现的COM对象被临时创建用于脚本参考，并且这些COM对象不总是存在于模块树中。这些对象在使用后由引擎作为无用信息收集。

方法签名监控提供了用于监控函数调用的技术，并且用于在不同的情况下创建gMg方法事件和属性检索。方法签名监控识别字节操作码模式，该模式表示认出的方法函数的方法签名。当对检测到的函数定位之后，检测到的函数可向例如GUI事件和属性以及发生在应用程序组件中的其它内部事件或进程的项提供接口。方法签名可普遍地应用于用于任何类型的调用的任何组件环境，并可用于捕获函数参数。确定了程序的地址之后，gMg使用跳转指令将其链接到调用拦截例程和对目标函数的每个调用进行跟踪的INFO结构实例。INFO结构包含到函数代码的字节指针、到其拦截程序的空指针、以及称为InterceptMultEdxInfo的携带实例的INFO结构。作为多实例支持的一部分，具有携带和传递关于函数调用拦截的相关信息的技术，例如使用CPU寄存器(即，实例寄存器)或其它机制。

参照图18，示出了方法监控器的创建。由包含在gMg脚本1833内的gMg脚本监控命令启动函数之后，首先由MakeFunctionMonitor机制对函数的地址进行定位。给定包含N个方法1827的模块N 1806，如为定位函数地址和执行拦截请求所准备的，适当的模块列表已找到，并利用模块枚举API(例如Createtoolhelp32snapshot 1815、Mod32First1809)，在拦截的LoadLibraryExW调用期间自动维护。本领域技术人员可容易地理解，当发布了更新的操作系统可用函数时，可将这些API替换为更新的操作系统可用函数。模块列表1803已在拦截请求时预先准备好。MakeFunctionMonitor 1851接收函数名和模块对象、接口对象或COM对象，并且一旦输出函数名或COM方法代码地址已被定位，则调用MakeFunction。然后，将函数监控对象1860创建为gMg对象类的派生，其中该对象包含函数拦截结构。实施的属性包含gMg对象实例，该实例返回指向原始程序的指针，并且如果返回成功，则设置为真。

MakeFunctionMonitor执行类型“函数监控对象(Function MonitorObject)”，与窗口、HTNL DOC或计时器不同，该类型是可包含各种属性(例如，目标函数被调用了多少次)的函数对象类型。函数的全部实例和分类都被全局地跟踪。在进行拦截请求时，已知包含期望函数的模块，该模块在拦截请求期间发现或先前就已确定。gMg脚本传递该模块，并且使用GetProcAddress 1824发现函数体的起始地址(例如，用于模块对象的MakeFunctionMonitor在对InterceptCallMultEDX1818的调用中对函数名使用函数GetProcAddress 1824)。

作为gMg脚本命令1839的结果被间接调用之后，Callintercept1848执行拦截并对位于函数对象1860内的INFO结构1863进行访问。为了避免出现递归，如果gMg脚本命令不注意地在拦截处理过程中调用了拦截的函数，则执行gMglock上的lockD。在试图进行拦截之前，锁定机制检查1842Callintercept函数1848未被同样的线程锁定，在这种情况下，调用拦截将被忽略1845。假设拦截成功，那么，拦截代码则将全局指针传递至该INFO结构，然后该INFO结构被转至函数监控对象。

函数Functionintercept 1866具有gMg函数对象1860。成功拦截后发出的gMg事件1869被执行，然后被传递至函数调用Do_gMgEvent1872，该函数调用对运行的事件和全部脚本1875进行处理。Do_gMgEvent接收函数调用事件，作用于该事件，并在结束是清除全局指针和全局锁定。

被gMg解释器接收之后，由Getstring和GetNum函数使用的方法事件称为方法事件属性(Method EventProperty)1869。这些Getstring和GetNum函数被暗含用于每个类型的gMg对象，如果没有识别出这些函数的类型，那么其则相互调用。gMg脚本用索引请求串事件(stringevent)属性，如果该属性未被定位，脚本解释器代码则调用用于每类gMg对象的函数链中的一个其它类型。

如果在event.sl脚本内进行解释，那么该解释则产生一连串调用，用于查找getstring事件属性，并且将传递表示“sl”的索引。对空指针进行检测，并且由全局事件选择值确定函数调用事件是否正在被处理。优选地，如果接收到不同类型的gMg事件，例如正在处理的创建事件，那么，对象树扫描的优先级则提升，从而导致对主机应用程序树进行扫描。如果事件正在处理函数调用，那么，则设置指针，该指针为原始调用参数所处的堆栈中的偏移。每个参数都可从该堆栈定位中得到。

一个实施方式提供了一种函数，其用于处理未知字符串长度的参数。该函数确定字符串是否位于未知的位置，并返回负值或正值，分别指示发现的值是一字节字符还是两字节字符。如果不存在字符串的话，该函数则返回零。其可确定询问的字符串属性是否应用于在脚本中被处理的当前的调用拦截事件1869。当为真时，则在对函数调用Do_gMgEvent 1872进行处理的过程中调用Interceptargument 1878。字符串属性变量仅在此时为非零，并从堆栈(即，堆栈地址处)指向INFO结构的地址。

在物理上位于对象结构内部的位置，具有指向该对象结构本身、并指向宿主类(其为使用该指针的唯一位置)的指针，还包含关于拦截的信息以及指向gMg对象的指针，该gMg对象是函数对象1860。全部这些类都在方法拦截传感器中，并为自包含的。

参照图19，其示出了方法签名。为了实现gMg方法传感器，gMg方法监控系统循环通过称为方法签名1930的目标方法的捕获的字节图案阵列1920，并对运行时间的目标函数字节图案进行比较(其中目标函数字节图案由检查工具发现)，以检测以检测方法1905的位置。为了进行签名定义而创建宏，所述宏是表示不同操作码的字节串。将该定义用于证明函数输入点中的典型操作码。签名还包括特别定义的码，例如don′t_care和signature_end码。例如，具体的库具有固定序列的某些指令，其位于由在不同版本中变化的DLL的版本确定的函数中。对函数的代码进行分析，以确定输入码1910是否可识别，如果可识别的话，则返回执行匹配的签名的指针。这种评估还建议了在插入转移指令之前需要将这些代码中的多少复制到别处，以及返回何处以执行代码的持续时间。例外情况是，发现转移指令已经是拦截的函数的一部分，以及检测到的gMg已拦截了应用程序函数调用。由于gMg监控处理不能递归，因此该处理异常中断。

这种操作码分析技术还在不同的派生CPU的类中起作用。在单一线程的应用中，还可使用其它可选的技术：在输入gMg代码之前恢复原始目标代码，有效地禁止拦截，然后在从gMg代码返回之后通过将转移指令放回在目标函数代码的开头处而重新开始拦截。对于每个归档的签名，处理循环通过每个字节码，直到对Signature_terminator 1935定位。如果值不匹配，处理则移至下一个签名。但是，如果发现signature_terminator值一直匹配，则存储起始定位值，并返回其长度。

一旦找到签名之后，对于成功拦截而言，重要的是需要对gMg代码转移指令覆盖进行定位，并将其放置在清洁的操作码边界1955。转移指令不能转移至操作码的中间，因此需要知道适当的操作码边界的定位。在五字节覆盖中，前四个字节包括两个操作码1960和1965，第五字节码包含相对地址1970。由于该地址是相对于原始函数中的执行起始处的位置，因此，这种相对地址防止了对该覆盖重新定位以及对程序的执行。

在目标函数1940中，对于目标覆盖而言，最少需要5个字节1955(加上signature_end)来设置32位CPU中的转移指令。该覆盖还可为7字节或者10字节，但不大于16字节。一旦发现5个字节之后，则插入具体值signature_end，指示替换函数代码时转制何处。复制原始指令，所有的操作码序列1945被覆盖，以及用跳转至拦截例程1975的跳转指令替代操作码序列。复制的操作码是存储在短值阵列1980中的字节值。从拦截例程1975返回之后，程序流返回代码拦截/延续点1950。

由于函数传递一个或多个参数，因此，还具有获取被监控的方法的参数的gMg函数(即，Getstringfunctioncall())，其中操作码可为数字类型或字符串类型。例如，如果已知存储了event.sl(其中sl是字符串属性)，那么，则具有函数Getstringeventproperty()，其具有一个参数，该参数为从NEP(N-事件属性)列表中得到的字常量。NEP列表定义一系列可能的字常量，这些字常量均为字符串事件属性。调用Getstringeventprops()，传递事件属性号。事件属性单元是字符串事件属性，例如，位于浏览器中的URL帧报头URL S1到Sn中的字符串事件属性。事件属性被枚举为变元和布尔事件属性，并用作操作码中的变元。以相同的方式寻找数字事件属性，并将其枚举为变元和布尔事件属性。字符串事件以“1”开始作为数字属性，布尔事件属性在运行时以“1000”开始。

为了识别参数是ASCII还是Unicode，调用API(例如，IsTexUnicode)或对ASCII Unicode字符以及Unicode strlength参数进行计数。还通过循环ASCII目标并查找总的ASCII长度和字符串中的字符数，而对ASCII字符计数。如果Unicode字符中的大部分都是ASCII代码字符，并且字符串不太长，那么，其则可为有效的Unicode字符串。否则，则认为这些字符不太可能是Unicode字符串，或者其被归零。返回更大比例的字符串，其中负的计数指示ASCII字符串，并且如果指向空指针，则返回零。如果未定位到字符串，则返回空字符串。该例程还返回指向包含一组宽位字符的堆栈的指针。

拦截可发生在目标函数代码的开始或中间。gMg监控使用为零的函数基准偏移，并规定了用于非零的函数基准偏移，在非零的函数基准偏移中，拦截点在函数中间。还可对相同函数的多实例进行拦截，或删除这些拦截。

还可在代码中查找用于gMg形式转换程序的转换指令。如果找到了，函数则已被拦截，并且拦截设置处理异常中断。否则，则对函数进行设置以用于拦截。为了修改目标方法代码，需要控制包含该代码的存储块的功能。gMg Changememory函数用于改变对包含待被拦截的函数的存储块的许可。gMg changememory例程通过去除执行选项和设置读/写选项来改变存储块的属性。函数拦截依赖于存储块的改变的属性，并且如果没有在主机应用程序代码中成功修改的话，函数拦截则会失败。使用句柄返回原始保护并恢复属性。由于可经常改变存储，因此，将进程分为改变存储和恢复存储。

形实转换程序是用于多种支持机制的技术，所述多种支持机制为从标识符的后联编到实时的真实对象的支持机制，或在方法调用期间对多实例进行跟踪的支持机制。在不同的情况下，形实转换程序可为指向实函数的指针(就像指向代码的指针)，或可在返回实函数的形实转换程序空间内，或为原始目标的实函数的地址。指针建立在被监控的代码内，以指向拦截形实转换程序，拦截形实转换程序是具有重写和可执行属性的存储部分。形实转换程序用于跟踪多调用或返回实例。为了帮助对拦截大量函数的支持，除了拦截形实转换和恢复形实转换之外的拦截代码可共享。每个函数的输入码都由跳转替代，以根据函数跳转到单独的拦截形实转换程序。同时，拦截形实转换程序提供指向表示具体拦截的INFO(引擎数据结构)的指针，然后调用由大量被拦截的函数共享的公共句柄函数。在虚拟表和COM监控部分对形实转换程序的作用及其应用进一步讨论。

在泛型函数调用拦截的情况下(不知道函数的参数或格式)，句柄函数在脚本处理之后返回，并且，在跳转至拦截的函数的剩余部分之后，拦截形实转换程序跳转至恢复形实转换程序，该恢复形实转换程序具有对原始拦截程序的覆盖输入码的复制。对于具体的函数拦截(其中函数的参数和格式是已知的)，句柄函数以与实函数完全相同的格式接收由应用程序传递的参数，并且，句柄函数还额外地接收由拦截形实转换程序提供的用于拦截的函数的INFO指针。通过将INFO指针添加到堆栈中或将其置于未使用的CPU寄存器中，拦截形实转换程序可传递额外的INFO指针参数。句柄函数通过恢复形实转换函数(其可通过INFO结构定位)调用原始的函数，并将原始函数结果返回至调用的应用程序。句柄函数向脚本通知该调用以及描述调用了什么的INFO的引用。句柄函数还记录堆栈上参数的定位，以使脚本可将参数引用为数字或字符串。当拦截的参数已知时(公开的函数、COM类型的库中的COM方法、输入的参数等)，还将参数引用到脚本中作为COM对象(“this”指针除外)或Windows对象(从窗口句柄中得到)。对于具体情况(LoadLibraryExW、DllGetClassObject和IClassFactory::CreateInstance除外)，句柄函数还在调用原始函数之前或之后进行额外的工作(分别为增加新的模块对象，拦截IClassFactory::CreateInstance，以及检查返回的值)。

通过形实转换程序，支持N个线程，其中需要通过每个线程将形实转换分配锁定。通过线程锁定是必须的，这是因为，例如，两个线程可调用两个不同的函数，或可调用相同的函数而每个函数线程需要其自身的返回形实转换程序。在某些情况下，一个调用的每个实例可递归地调用相同的函数。此外，如果处理可在使用形实转换程序的每个调用期间动态地释放创建的闲置堆栈，而不管函数使用的是C调用还是Pascal调用，那么，创建用于每个线程的并行堆栈则变得更容易。在gMg方法监控内的形实转换程序的应用用于根据主机应用程序组件方法调用和返回生成多种事件。

图20示出了当发现了有效长度大于或等于5的方法签名时，用于方法监控的形实转换程序分配。如果发现了有效值，虚拟位置函数(Virtualallocation Function)2006则分配具有重写属性的一段存储2009，并每次动态分配24字节。对于形实转换分配而言，使用一段可重复使用的缓冲存储。在程序内具有一个固定的缓冲器，用于全部公式串，并且在公式串的计算期间，缓冲器使用需要在每个gMg指令之后清空的自由临时串。这种开销需要周期性地设置。专用的gMg堆也用于替代使用应用程序堆，以便更独立并避免在出现任何gMg错误时影响主机应用程序。专用堆函数创建堆，并然后提供句柄以执行全部分配，以使全部新的操作符可与新的专用堆一起使用。InterceptcallmultEDX 2003分配两块存储：一块用于拦截调用的代码2012，另一块用于存储原始代码2015以确保对目标函数的处理连续性。在gMg拦截部分内，插入一系列代码：用于将全部数据推入寄存器的PUSHAD指令2018，然后是长值(long value)的进栈，该长值为需要与拦截实例相关联的INFOstructure 2021的地址。

InterceptmultEDX()函数基于这样的假设：实例寄存器(例如，EDX寄存器)可用于由调用的函数使用，而无需首先保存该寄存器，从而提高效率。由于需要避免修改CPU堆栈，因此插入移动EDX寄存器，用于信息数据。然后移动数据EDX寄存器以将实例信息传递至下一部分代码。这种方法可在已知拦截了什么函数之后使用，并且还可用于使用完全相同的参数创建相同的模板，所述参数例如Loadlibrary之类的内核函数。由于可能因为共享的访问而导致与其它线程出现冲突，从而使得存储在RAM(即，HEAP)中的信息不能用于同样的EDX目的，因此，该信息不是线程安全的。使用寄存器或堆栈是不需要进行同步或其它昂贵操作而传递实例信息的唯一线程安全的方式(thread-safe way)。RAM可用于传递实例信息，但其效率会较低。通过使用RAM，拦截器在每次调用时都需要基于拦截的函数的地址进行查找。此外，需要对查找表(函数地址到信息实例的映射)的维护进行同步以使其为线程安全的，这一点可为昂贵的操作。

在某些情况下可使用堆栈，但是，与RAM类似，这种方法在维持透明性方面具有缺陷。拦截函数必须完全取代原始函数，并且很可能在进程中对其进行调用。从控制角度上来看，这是困难的。在这种情况下，拦截进程必须以与原始函数相同的方式清空堆栈，并必须具有完全相同的参数，同时，还增加一个参数(即，实例或上下文信息)以支持监控系统的拦截。某些目标函数通过跳转指令而被激活，并且堆栈不能由进栈改变(进栈导致将附加的信息置于目标函数的参数的返回地址之后，并返回地址)。在这种情况下，拦截例程的代码对原始参数访问本来是不容易的，并且不能以与原始函数相同的方式清空堆栈。例如：

Stack：

…

dwFlags

hFile

lpLibFileName

Return-address

//A push does not″add″a parameter.It follows the return-address：

dwFlags

hFile

lpLibFileName

Return-address

Info//for interception routine

对于EDX方案，可用“PUSH infoAddr”代替“MOV EDX，infoAdrr”，这种选择也是线程安全的，但这种方案比使用CPU寄存器要更慢。

使用CPU寄存器是有益处的。例如，对于传递实例上下文信息而言，通过寄存器传递实例地址是最佳方式。这种方法只在没有参数通过相同的INFO传递寄存器传递至被监控的方法/函数的时候才起作用。已发现，通过EDX寄存器传递参数的方式从不用于输出函数。然而，可以编写这样的代码，这些代码会导致在使用EDX的gMg监控中产生崩溃，但是可能会需要汇编器并且不可能与可用的编译器一起使用。这种崩溃对于输出函数和COM函数来说是及其不可能的。此外，使用EDX不会对通过“sysenter(系统进入)”指令实现的内核级调用或通常使用EAX和EDX作为参数的其它内部调用的拦截起作用。然而，在这些情况下，另一个寄存器可被替代。使用EDX还减小了代码大小。本发明并不局限于在“泛型拦截”时一定需要使用EDX，而是在堆栈上传递也是可以的。然而，当用一个新的句柄函数取代原始句柄函数的多实例时，传递CPU寄存器中额外的上下文信息资料要优于传递堆栈上或存储器中的额外的上下文信息资料。

多实例：

HRESULT STDMETHODCALLTYPE iIClassFactory_CreateInstance(

   IClassFactory*This，

/*[unique][in]*/IUnknown *pUnkOuter，

/*[in]*/REFIID riid，

/*[iid_is][out]*/void **ppvObject)

HRESULT_stdcall iDHGetClassObject(REFCLSID rclsid，

REFIID riid，

LPVOID *ppv )

单一实例：

LoadLibraryExW

参照图20，已知目标函数2036的参数之后，对函数进行拦截，并且将其替代为gMg“代理”(或拦截)函数2045。原始调用程序2024保持为被阻止的，等待函数结果。gMg代理函数(proxy function)2045调用原始函数2048、2042，接收返回值，并将结果2051返回至原始调用程序2024。gMg创建具有与原始函数2030完全相同的参数的代理函数2045，但增加至少一个额外的gMg参数2033用于实例信息。这些是为了防止需要在不同DLL 2060、2063、2066中挂起全部具有相同方法名2072、2075、2078以及相同函数签名的多个函数。为了将信息转发至拦截例程，EDX寄存器还可用于传递额外的gMg INFO参数，该参数避免在调用拦截期间对原始应用程序的堆栈进行修改。

gMg拦截函数对INFOstructure的实例的地址的进栈进行汇编，然后建立调用拦截处理，该处理被指定为在拦截2045、2048期间内被调用。gMg对被替换的函数的原始代码的副本进行处理和保存2048。在返回之后，将全部寄存器退栈，从而跳转至形实转换程序内的代码(保持地址或指针的结构)2054，以返回原始的调用例程。通过指向真实例程的prealproc，可对用于原始例程的代码进行访问。

在从主机应用程序代码中进行调用期间，对跳转指令2039进行汇编，该指令从原始目标函数代码中的拦截点形实转换至相关联的gMg拦截例程2045。对原始代码进行复制2048，然后对另一个跳转指令进行汇编，该指令形实转换回拦截例程返回的(目标代码中的)延续点2042。

这就实现了两个形实转换程序的构建：一个用于拦截，另一个用于返回。在可选的实施方式中，将这两个形实转换程序合并为一个更大的形实转换程序，其能从gMg拦截例程内部对原始例程直接调用，或能对跳转至原始例程的地址prealproc进行调用，从而绕过拦截。

在设置或方法监控进程和形实转换程序的使用中出现了大量问题：多线程应用程序之间的线程冲突以及与gMg GUI对象树更新相关的事件处理。如果另一个线程正在调用执行该线程的形实转换程序，那么，在对原始的形实转换程序代码进行修改或重写时可出现一个问题，可能将疏忽地执行被替代的代码。为了避免这种问题，gMg系统使用可用于动态地适应不同情况(也就是睡眠或线程挂起)的技术。

为了避免方法监控中的线程冲突，如果多个线程试图在gMg试图修改代码时执行相同的代码，那么，睡眠技术则发出N毫秒的睡眠函数，尝试避免冲突。睡眠将线程中止，并重新启动用于该线程的时间片。这意味着，线程具有完整的时间片来完成其操作，以减少错误发生的可能。如上所述，作为修改原始指令的一部分，对跳转至gMg拦截例程的跳转指令进行汇编。这可作为宏或内联函数实现，输入跳转操作码并计算偏移地址。

另一个技术是用API调用短暂地中止进程中的全部线程。如果线程的确引起了异常，那么则可响应于某些消息使用异常分支指令拦截该异常，并且该异常可允许线程引起异常但使线程适度地重新启动。为了进一步减少出现问题的可能性，除了睡眠之外，可将线程优先级升为“高”。其它线程也可被启动，但具有较小的冲突机会。除了在多CPU环境中监控的情况下，单独使用睡眠技术可能就已足够。在具有多CPU的情况下，OS通常在函数/方法拦截过程中向不同的进程分配处理。

关于多线程，对于通过输入表调用的函数而言，使用输入表的额外拦截机制基本锁定该调用，改变用于拦截的代码，然后通过改变输入表的值对调用解锁。函数Getprocaddress将地址提供到输入表中。此外，通过GUI对象树扫描对方法监控进行交叉存取，以与主机应用程序一致，并使树与主机应用程序保持同步。具有事件和树扫描控制机制，该机制调用以ObjectlnterfaceEPT开始的一串函数。首先调用GetStringEventProperty()并传递索引，但是如果未出现属性，则调用GetStringWinEventsProperty()，然后调用StringGetWebEvent PropertyQ。在调用被监控的函数之前，并在应用程序调用被拦截的函数之前，进行测试以确定gMg是否可能正在监控当前事件。如果其它事件此时正在被处理，并且具有检测到的事件时，那么，则以对扫描应用程序树的优先级进行更新的方式对主机应用程序的GUI树重新扫描。否则，通常仅根据计时器事件对应用程序树进行扫描。如果应用程序忙，那么则可生成许多被拦截的事件。此外，控制OS ws_timer事件，从而在检查中保持应用程序的变化。在某些情况下，如果在处理gMg事件时没有完成，则对树重新扫描，这样就会在内部产生处理另一类事件的创建或破坏事件。为此，需要重新检查。

不同类型的应用程序组件封装将呈现不同的方法结构，并因此需要不同的方法对目标方法/函数及其接口进行定位。由于COM是用于构建用于Microsoft Windows的企业主机应用程序的重要组件技术，因此，对于组件监控而言，通过用于属性检索或事件检测的VTable对COM方法进行检测是必需的gMg技术。

在为类的特定实例的COM对象的实例中，最主要的gMg目标是定位对象的VTable。如果对象不存在，那么则可在VTable的创建阶段对其进行检索。但是，如果对象已存在，那么，gMg则通过创建其临时对象而定位VTable。当创建了任何新的对象时，该对象访问与已示例的现有对象相同的VTable。gMg创建临时对象，该临时对象用于对由属于组件的一组方法共享的现有VTable进行定位。一旦对VTable定位，gMg方法签名拦截例程则可设置为执行监控进程。

使用类将对象示例在存储器中，并通过GUID(Microsoft Windows中通常用于识别任何编程组件的唯一标识符)和接口名对类进行识别。在类别库中找到之后，gMg脚本编写程序使用gMg检验工具通过接口名提供id。由DLL公布之后，在例如gMg工具VTree或微软OLE View的使用程序中可找到该id。DLL包含具有对COM对象的描述的类型库。一旦id被发现，与对象内的类相关联的接口的GUID也可发现。在运行时，对象接口的id则从脚本中得出。

类可实现多种接口(例如，IUnknown、IDispatch等)。在对象中实现的该类的全部其它接口通常在登记处公开。类的id用于创建对象实例，以创建到感兴趣的对象的接口。相反地，一旦知道了接口的id，则可得到实现该接口的类的id。

给定了类id和接口id之后，则可创建对象实例。该实例被创建用于非常短的时间，并且在对象被破坏之前，当在存储器中发现VTable的地址时将其存储。尽在加载了实现接口的模块之后，才对接口进行监控。接收模块对象上的gMg创建事件，这意味着存在该模块。当Vtable此时被示例在存储器中时，可对接口进行监控。编译器已事先创建，并在编译时生成全部可能的VTable，这些VTable在运行时位于源代码中。

编译为包含指向代码的指针的固定表的VTable由全部实例共享。当创建了对象实例之后，向一段存储分配指向VTable的第一双字。例如，如果具有相同类型的十个对象，那么，其全部通向相同的VTable，该VTable与接口是同义的。

关于不同计算机编程语言中的编译，当例如标准C编程接口将使用数据结构实现其方法时，以C++构建的组件使用虚拟函数。如上所讨论的，虚拟函数实现为VTable，并包含指向相应方法的指针。此外，VTable包括大量的接口集，作为COM定义的一部分(即，IUnknown、IDispatch以及其它可选的定制集)。给定可具有多实例的COM对象，全部接口集都可从IUnknown中派生出。此外，派生确定VTable的内容。例如，如果从Invoke中派生接口，VTable则包含指向Invoke指针的指针，Invoke指针指向方法。但是，如果接口不是从IDispatch中派生出并且执行了Querylnterface，那么，将构建不同的VTable。

作为依赖于例如多类继承的不同因素的IUnknown的一部分，图21中VTable的前三个条目2106总是指向IUnknown接口的方法：Querylnterface，然后是AddRef和Release(释放)。从IUnknown中派生出的下一个接口集是包含Invoke的IDispatch。Invoke是用于访问组件内一组方法的泛型方法。

VTable不总是奇异的，因为例如在多继承情况下，可有多于一个的VTable指向相同的方法。此外，其它VTable可位于连接于相同方法集的其它地方。例如，可具有需要返回的两个VTable(例如，方法X)。方法X可用作具有特定接口的VTable内的索引N，或其也可通过调用不同的VTable用作调度(dispatch)id Q。

当由VTable起作用时，会遇到大量问题。包含指针的拦截VTable是监控方法调用的一种方法。然而，在某些情况下，VTable指针的VTable拦截可证明为不合适的，因为在可绕过VTable的函数调用内可发生内部调用。其它问题可包括：主机应用程序能直接调用函数而无需使用VTable定位函数，并且可具有全部指向相同函数的多个VTable。这就暗示了，对于给定的目标函数，监控系统将必须拦截全部相关的VTable，这可证明是禁止的或者可证明访问全部这些VTable是否为困难的。通过一个已知的接口(iKnown)，Querylnterface可用于定位多个VTable，但可创建相当多的处理开销。然而，Querylnterface是一种可选的方法，其中可使用数字签名函数拦截技术。

IDispatch是来自微软公司的可用产品Automation的一部分，其提供到应用程序的组件的接口，其中Automation用于执行后结合(即，在运行时间而不在编译时间确定待调用的函数)。IDispatch是从IUnknown中派生出的。IDispatch包含在VTable中时，如果调用(Invoke)和直接方法接口都可用，那么其则具有双接口。

在Automation(微软的组件技术)中规定了方法id，Automation使用泛型激活方法激活索引方法，其中Invoke是IDispatch的一部分。Invoke执行具体方法，且每个对象都映射到方法用于检索或设置属性。当没有实现双接口时，Invoke由于一些因素可为更慢的，这些因素例如必须准备全部参数、或者需要在调用之前设置变量列表。然而，如果双接口是可用的，那么，虚拟函数则存在且具有指向VTable中的函数的指针，指向位于实际代码中的方法。

第一目标是拦截新的COM对象实例的创建，定位iKnown接口，以及确定虚拟函数是否存在，即使其并不从IDispatch中派生出。客户调用输出函数DLLGetClassObject()，其要求类工厂接口。一旦其得到类结构接口，其则调用Method Createlnstance()，该函数需要参数计算出用于待示例的对象的接口GUID的id。作为gMg方法监控的一部分，还对Createlnstance进行拦截。该方法需要接口的GUID作为参数，该接口是将要创建的实例所实现的。当DLLGetClassObject完成处理之后，其返回IKnown、接口的GUID、以及ThisPointer，其中从ThisPointer指向VTable的指针可被发现。

如果接口不是从IDispatch方法派生出的，其则暗示了，该应用程序使用的是早结合，也就是说，调用的函数是已知的，并在编译时就链接到了一起，全部这些都是得到gMg系统的支持的。通常，指向Idispatch的指针与对象的实例同义。如果接口是从IDispatch派生出的，那么，该接口则创建其自身的VTable，但是相反地，如果接口不是从IDispatch派生出的，那么，则创建完全分离的VTable。

在发现创建了新的COM之后，下一个对象将对实现包含在COM组件内的功能性的真实方法代码进行定位和访问。实际的COM方法执行具体的动作并可被直接访问或通过Invoke访问，在Invoke中，通过具有id的切换状态，每个对象都是可访问的。有时，方法还可被直接暴露和调用。如果在Typelibrary中将对象说明为虚拟表中的双接口，并且具有指向虚拟表的指针时，可对表进行检查以对目标函数的地址定位。

该方法实际仅存在于例如组件日历控制实施例的特定接口的上下文中。如果具有接口的GUID，那么VTable及其接口则都已知。IKnown提供方法的VTable(如果其可用的话)。此外，必须完成Querylnterface，以得到可返回不同VTable的IDispatch。

图21进一步示出了COM对象及其内部自动接口和VTable。尽管可具有COM对象的多个实例2109、2112、2115，但是这些实例将共享相同的VTable，该VTable反过来也共享相同的代码2135。在DLL2115内，具有指向DLL的VTable的指针。位于VTable 2136中的虚拟函数是作为间接查找方法(例如2139、2142、2145)的结构的一部分的指针。由于是虚拟的，因此可从不同的类中派生出新的类，以形成新的类。例如，可从IDispatch接口2124中派生出新的类。在编译期间，可对原始VTable进行复制，除了将有新的指针指向新派生出的Invoke类。从宣布(declare)为具有纯虚拟方法的类中派生出的固定类必须在编译时具有这些实际定义的方法的实现，并可覆盖其各自的接口定义。如果未提供方法，那么则会发生编译错误。标记为“VTable详情”的附图部分提供了VTable 2136的特写视图2118。COM的Iunknown 2121和IDispatch 2124(包含Querylnterface 2127、Addref2130、Release 2133和Invoke 2134)对于创建的类而言是具体的，并且必须具有在组件编译时链接的其各自的实现。图21将用于Invoke方法的具体拦截例程表示为监控虚拟函数的一部分。在对被监控的函数和暗示的gMg参数进行gMg调用期间，与原始函数完全相同的参数被复制和使用。根据实施方式的设计，可有许多不同的派生出的Invoke包含在组件中。例如，可有任何数量的Invoke方法从IDispatch中派生出(例如，A类Invoke 2148、B类Invoke 2154、C类Invoke 2157等)，还可有对任何实现的Invoke类方法的许多调用。对各Invoke(A、B、C)的不同调用使得gMg拦截例程向每个Invoke分配各自的上下文形实转换程序2169、2172，用于任何数量的调用2175。将Invoke A类作为实例，gMg调用拦截使程序流从2163处的重定向移动，以到达适当的类A的形实转换程序2169，用于具体调用实例数据结构的、调用包含的上下文数据。从Invoke派生出的不同IDispatch会具有不同的形实转换程序，例如具有Invoke B的信息2172。然而，gMg拦截处理例程2166对于全部实例都是一样的，并且服务于全部VTable方法2135。此外，通过检索适当的调用上下文信息和代码2178，gMg处理从拦截例程路由至适当的方法目的地2148。这将是包含在上下文数据结构中的适当的目的地指针。上下文信息保持在包含指向形实转换程序的指针的gMg对象、监控函数延续定位2160(在由gMg拦截处理插入输入跳转指令之后)以及其它信息中。

gMg拦截的流程如下进行：通过使用临时gMg创建对象的技术对拦截代码进行设置。然后，当调用程序2103激活目标函数时，拦截设置进程在2148中的被监控函数2163的入口点覆盖原始代码的一部分，但将被覆盖的代码的副本存储到2178中。为了执行实函数，拦截调用从2178中检索输入代码部分，并在跳转至延续定位2160之前首先执行该部分。对于待执行其自身调用以实现例如从方法调用中检索某些属性的任务的gMg而言，在2178中通过建立的被拦截接口实现调用执行。如果被监控的方法由主机应用程序调用，那么将生成gMg事件。然而，如果该调用是由gMg解释器通过检查全局gMg锁定而启动的(参见图6)，那么，gMg则具有阻止对调用进行拦截的保护机制。仅有主机应用程序启动的调用变为gMg方法事件。

gMg拦截例程对在被监控的函数的输入中检测到的原始参数进行捕获，并将其传递至函数的原始代码。其结果是，gMg拦截例程从堆栈中获取实际参数。从方法返回之后，参数则主要从寄存器或包含在寄存器中的间接指针获得。

尽管之前在方法监控部分的讨论集中于对存储对象预创建后创建以定位和监控方法调用，但是，在gMg监控系统中同等重要的是对方法返回的监控。除了捕获调用之外，对于捕获方法结果并将其传递至gMg系统用于进一步处理而言，捕获方法返回值的技术也是有用的。对方法返回的监控产生方法调用的结果，该结果对于gMg脚本在多种环境中的操作都是有用的。函数返回拦截的原则可针对组件封装中多种不同类型的目标，本文讨论两种捕获函数返回的方法。第一种是堆栈复制方法，其包括复制堆栈。第二种是堆栈分配方法，其动态地对形实转换程序进行分配和解分配，以保留调用和返回上下文。

对于监控方法返回，第一种“堆栈复制”技术是基于对堆栈的一部分进行复制(使用调用程序的堆栈帧)，并使用该复制影响目标函数的通往gMg调用和返回拦截例程的程序流或来自该例程的程序流。堆栈复制方法拦截堆栈，而不修改原始堆栈。通过复制堆栈的一部分并拦截函数返回的执行点，程序执行转而移动至gMg拦截例程，该例程检测堆栈移动并在堆栈的gMg代码版本内执行堆栈操作。假定gMg系统是透明的，并且不需要对应用程序的源代码进行修改，还假定组件是私有的，那么，则推测没有可用于目标监控程序的文件，并且不会知道有多少参数正在传递至函数。因此，当对捕获的堆栈部分(其足够大从而能够捕获N个参数)进行复制时，该堆栈部分包含所需的函数参数以及可能与监控进程不相关的某些额外的数据。

堆栈复制技术包含指向gMg拦截代码的返回地址，该地址识别多少堆栈指针移动了。例如，如果gMg代码增加了二十个字(作为预设配置)，那么，在返回gMg代码之后，则将堆栈指针加二十，将堆栈指针定位于堆栈中适当的位置。对堆栈上全部的函数参数进行复制，并且函数返回具有返回地址的调用。最后，当完成了对方法的调用之后，在返回原始调用程序之前，将堆栈上的参数的副本移除。本实施例中的方法通常在每次返回时复制参数中的二十个字。在参数被从解除程序中传递和调用的位置，UninterceptcallEDX()解开函数，释放任何使用的存储，并且如果需要的话，将任何保存的存储重新存储至原始方法的状态，并且，当gMg对象的参考计数变为零时，该函数毁坏对象并释放拦截。在建立拦截例程时，还必须考虑计时问题。

参照图22，其中示出了堆栈复制技术监控返回。调用程序2202调用正在被监控的方法。到达之后，堆栈2210则可包含方法的参数2215，以及调用程序的返回地址2220，程序流在完成方法调用之后在该地址上继续。

然而，当方法被监控时，从gMg监控设置阶段开始(参照图18)，被监控的函数调用的入口地址就已被定位，并且在拦截的调用阶段，用跳转指令2230对入口进行修改。在覆盖原始代码之前，已被覆盖的函数操作码被保持，并且对于拦截的对原始函数代码调用2245的调用是有用的。因此，当应用程序调用被监控的函数2225时，程序流则输入函数的代码地址。由于修改了入口，因此，执行gMg跳转指令2230，将程序流切换至gMg拦截设置例程2240。首先，拦截设置例程制造堆栈一部分的副本2250。gMg系统对被监控函数调用中的参数的最大数量做出假设，确定待捕获的堆栈字节数。基于这种假设，gMg使用配置的大小限制，根据函数的输入捕获堆栈的一部分。该堆栈部分包含函数参数值2255、原始返回地址2260以及一些附加数据。在返回设置阶段的另一个步骤是在堆栈副本中修改返回地址2260，其结果是产生指向返回捕获执行2280的指针，返回捕获执行在程序流返回调用程序2205之前进行。此时，完成了返回捕获的设置，并且对方法返回值的捕获已就绪并如下进行。

为了执行对监控函数的调用，在跳转至方法代码2235的延续点之前，获取并执行已由跳转指令2230在gMg拦截例程设置期间覆盖的操作码。监控函数的剩余代码现在执行(由拦截例程的跳转指令覆盖的)初始输入操作码以及必要的堆栈操作，以传递来自原始调用程序2205的参数。堆栈操作在堆栈的拦截例程副本2255上执行，而不是在应用程序的原始堆栈2215上执行。完成堆栈操作之后，程序流到达方法的结尾处，并执行位于gMg拦截例程的堆栈副本2260中的返回指令。该指令将执行流移至拦截例程的返回捕获代码2280。此时，从寄存器捕获返回值，或使用从堆栈副本2250中查找到并的指针捕获返回值，并将返回值2265存储到调用程序可访问的存储器中。在gMg脚本级，如果脚本涉及函数调用拦截的当前事件对象，那么，则可向该脚本分配脚本变量，然后该变量则可被引用。假定分配的变量是条件的一部分(用于调用或返回检测)，如果接收到方法调用(或返回)事件，那么，通过跳转至包含调用程序2205的地址的原始堆栈，脚本逻辑则将脚本执行路由至原始调用程序2275。返回代码的执行使堆栈以正常方式出栈，即，通过由在拦截进程开始时复制的量调整堆栈指针寄存器实现，而程序流在主机应用程序中继续执行。

作为一种选择，堆栈分配方法提供了用于捕获返回值的另一种方法。与堆栈复制方法不同，在堆栈分配方法中，不对调用程序的堆栈进行复制。而是对小的形实转换程序进行动态分配，以对调用上下文及其各自的返回保持跟踪。为了跟踪函数返回值，形实转换程序包含堆栈上修改过的返回地址，该地址指向检查返回值的另一个形实转换程序。与支持调用监控的形实转换程序不同，返回监控使用被动态管理的形实转换程序。也就是说，在每次调用和返回后，这些形实转换程序都被分配或解除分配。在堆栈分配方法中，具有多个阶段：首先是从调用程序到被监控函数的输入，接着在调用被监控函数时设置返回拦截例程。然后，调用原始被监控函数，接着返回并捕获返回值，最后情况并返回到调用程序。

如图23所示的堆栈分配返回监控方法动态地分配形实转换程序内存，其中形实转换程序用于代码重定向和保留调用或返回的上下文，以保持主机应用程序的连续性。当函数被拦截之后，将被覆盖的原始代码保存到形实转换程序空间中，其之后是恢复执行被监控函数的跳转指令。设置了多个形实转换程序，一个用于进行拦截，另一个用于在输入拦截的启动部分之后恢复执行，在一个用于处理返回。

由于任何给定方法的共有特征，需要拦截上下文使用个体数据(即，调用形实转换程序2330、2327、2354、2357、2342、2351)处理主机应用程序调用和返回的合适路由，上述个体数据描述不同调用实例的细节。例如，如果给定均调用方法Q的两个主机应用程序函数X和Y，gMg拦截例程P则将跟踪两个不同的返回地址，一个用于函数X，一个用于函数Y。对不同上下文保持跟踪以确保保持不同主机应用程序函数的程序流和连续性是gMg形实转换程序的重要任务。

调用程序2303调用被监控的函数2315，并遇到已在被监控方法的入口被覆盖的跳转指令2318。该跳转指令到达开始返回拦截例程的设置进程，以处理成功执行拦截所需的动态信息的代码。在堆栈2306中修改返回地址2312，该堆栈还包括指向形实转换程序的参数2309，该形实转换程序提供到gMg共享形实转换解分配(deallocation)和返回捕获例程2366的跳转连接，返回捕获例程2366连接于方法调用的上下文的返回部分2348，其中该上下文跟踪不同的调用实例。这种动态分配的形实转换程序包含原始返回地址2348。返回拦截例程设置在调用期间的另一个动作是分配另一个形实转换程序2330，该形实转换程序提供用于当前调用实例的上下文信息，并且也是返回阶段设置的一部分(每个实例中都对返回重定向)。然后处理到达共享的分配例程2336，该例程对形实转换程序2342进行分配，形实转换程序2342存储在用于当前实例的调用程序原始返回地址中，并设置到返回捕获进程2360的链接。

通过调用形实转换程序2354，在2339中执行被监控方法的处理例程2333调用，形实转换程序2354已将被跳转指令覆盖的操作码存储于在方法2318的入口点。方法的执行在延续点2321恢复并继续，直到处理完成后到达返回指令2324。由于原始返回地址在返回拦截设置阶段已被修改2312，因此程序执行现在到达gMg例程2345，该例程包含到返回捕获代码的链接而不是返回调用程序2303。程序流现在到达捕获进程2366的结尾，在该结尾处，对形实转换程序进行解分配2363，捕获返回值2360，并且将gMg事件发给gMg解释器。在gMg脚本级，如果脚本涉及函数调用拦截的当前事件对象，则可为该脚本分配脚本变量，然后这些变量就可被引用了。假定分配的变量是条件的一部分(用于调用或返回检测)，如果接收到了方法调用(或返回)事件，脚本逻辑则将脚本执行路由至适当的动作。通过捕获的输出，程序流遵循调用程序2348的原始返回地址，并且间接跳转将返回处理至调用程序2303。

在堆栈分配方法中，gMg形实转换程序的作用类似于按线程的堆栈，其对堆栈次序中的形实转换程序进行分配和解分配。gMg形实转换程序需要相互兼容(compliment)，这是因为信息必须与返回地址是成对的。预分配一块内存，用于高效操作的增加的内存分配，且其属性同时为可重写和可执行的。

总之，gMg方法监控提供了对从操作系统到应用程序的多种组件的访问，并提供了对公开且归档的功能性(用于其它非gMg工具)或对未公开且未归档的功能的访问。方法监控实现为用于gMg系统的附加的传感器，其和GUI传感器一起与gMg解释器通信，以通过独特的GUI上下文和用于描述主机应用程序行为的附加信息提供集成、扩展、或关联。尽管本文描述了COM和输出函数，但是，在gMg方法监控中应用的原理还适用于许多其它组件技术，并且可容易地适用于gMg的抽象模型。

在这一阶段，全部gMg监控源都生成为能产生不同数据类型的复合物的gMg事件的形式，特别地，全部都生成在GUI上下文中。低层级事件，即，在gMg源点处检测到的事件，则可由状态机在最可用和最高效位置处进行的处理的不同阶段进行处理。原则上，只要知道了某个事件，就应该马上考虑该事件，用于给定要求的状态处理。为此，在gMg系统内，状态机执行可用于本地的和远程的处理。

图24示出了gMg状态机层次。给定本地的和远程的状态机机制，gMg系统能建立轻量(light weight)分布的状态机层次，以提供最大的灵活性和对网络间实时响应的及时传送。被监控的目标主机应用程序2418、2421。2424表现为具有侵入其中以检测和收集事件的gMg传感器。一旦检测到事件，则将事件作为gMg消息发送给其各自的解释器2412、2413、2414，每个解释器都正在运行脚本(例如2409)。例如，脚本可定义小且快的“本地”状态机2403，该状态机将低级触发事件(用gMg传感器检测到的)翻译为逻辑事件。对这些逻辑事件进行过处理之后，则可将其封装为由远程(这里为第二级处理)状态机接收的一个或多个跟踪消息2415，这种封装通常是在gMg收集服务器2406上完成的。这些逻辑事件反过来则可进一步由其它的一组或多组状态机处理，以基于连续多组状态产生多层逻辑事件，该多层逻辑事件可作为检测响应2427向前传递。

该过程进一步由层次2430中的状态机2432示出。单一的状态机2442(特写的)具有一系列输入触发事件2445、2448、2451和输出2454。该示出可馈送至其它的状态机中，其它状态机在本地2409或远程2406位于相同的脚本中。状态机层次树2430表示了一系列状态机(即，2430、2433、2436、2439)，这些状态机可为本地状态机和远程状态机的任意组合，并具有与输入兼容的输出，以基于gMg事件形成灵活的状态检测机制。链接分布式的状态机的能力使得能在集中式服务器上对事件进行快速检测和路由，这是因为大部分状态处理都可根据用户或某些本地主机应用程序动作而得到的检测在本地立即地执行。

根据需要，可在客户机上(即，本地)运行状态机，以显著减少大的用户基数中对服务器资源的需求。保持事件之间的状态的命令有利于用于实时警报和其它时间敏感操作的优化处理，和减少网络业务。为此，gMg脚本语言具有序列(Sequence)命令，其在客户计算机或虚拟客户空间上(例如在终端服务中)处理状态。gMg Sequence命令将目标主机应用程序的不同状态检测为事件，这些事件是用包含在Sequence命令语法中的逻辑表达语句描述的。

下列代码样本示出了对由单一的动作导致的一组状态进行跟踪的Sequence命令的使用，也就是跟踪命令的使用。

代码样本：

  init

  {function filesavemenuitem＝...；

  function savedialogmydocuments＝...；

  function savedialogsavebutton＝...；

  function savedialogfilename ＝...；

  var filename＝nostring；

  }；

  if(sequence(

    wlbutdown && filesavemenuitem，//(1)

    wlbutdown && savedialogmydocuments：filename＝_//statement

       continues to next line findsibling (savedialogfilename).title，//(2)

    wlbutdown && savedialogsavebutton ))//(3)

    track(saveend，topwindow，′File Save To My Documents Completed′，

file＝filename )；

在代码实施例中，在不同的打开对话框菜单项上按下“left buttondown(左按钮向下)”。状态命令通过SaveEnd事件和SavedMyDocumentsCompleted事件的触发，在“file menu open(文件菜单打开)”项中查找一系列左按钮向下事件(1)，然后查找“(打开文件保存)”对话框(2)，最后查找“保存执行的命令”(3)。该实施例中出现的“if”语句包含一系列条件，每个条件表示检测为一系列事件的GUI对象。解释器接收每个事件，并对事件之间的状态保持跟踪，其中序列按照由其命令确定的某种顺序将状态聚合。在完成全部条件之后，条件变为真，执行就落入了序列命令的主体中并执行其内容。通常，这些内容可为单一的跟踪消息，该消息反映由序列命令或其它动作满足的状态和条件。

序列命令的其它特征将允许更复杂的操作，例如OR′s或Compound操作，这些操作是有序序列或任意顺序的序列。对于All_Of序列而言，当全部事件A、B和C都发生时，用于事件A、B和C的序列群条件变为真。对于Any_Of序列而言，只要事件A、B或C中的任意事件发生一次，群序列条件则变为真。在序列层，操作允许用逻辑布尔操作符将序列命令结合。或(OR)、与(And)、非(NOT)等可以任何组合使用。序列命令还可进行嵌套，也就是，一个序列命令可包含另一个序列命令，如以下代码段所示：

If(Sequence(S1a，Sequence(S2a，S2b，S2c)，SIb ))

    {Action...

    SendTrackMsg(Q)

    }

在此实施例中，第二序列命令包含在第一序列命令的基本条款内。在处理时，解释器遇到第一序列1，并设置用于其条件的状态跟踪。其条件之一是另一个序列2命令，该命令反过来设置其自己的分开的状态跟踪。序列2命令等待事件，直到其完成了其定义的、可使其变为真的逻辑序列。当对序列1再次估计时，其表达式完善其逻辑，并且处理继续进行。通常，整个操作在计算环境允许的可接受的资源级(内存、CPU等)内递归N次。

此外，gMg脚本作为输入的代码生成器，例如Java代码生成器，可用于在如gMg脚本的各种配置下的客户组件上、或在gMg跟踪和监控服务器状态机组件上生成并使用状态机。这种本地状态机机制和灵活配置的全部益处在于，服务器资源需求和网络业务都明显减少。

再参照图4，其示出了使用的组件的概观。如图所示，gMg应用程序生成由gMg收集服务器和跟踪数据库收集和接收的跟踪消息或gMg事件。在这个阶段，基于设计用于进行灵活性和高效处理的远程状态机进行gMg分析处理。进入处理机制后，将事件保存至数据库，然后由内存内的状态机(实时的)立即对其进行处理，或基于调度(接近于实时或延时分批)状态机事件将其分批用于之后执行。此外，在状态机分析中，还具有大量的检测GUI对象集的多实例的机制，这些对象集来自分离的gMg脚本或为来自单一脚本的GUI对象集。

状态机的初始配置定义在使用铁路图(railroad diagram)范例的XML文件中。铁路图以简明的形式描述并行的进程和条件，并且通常是本领域公知的。在第一次从文件中加载XML时调用启动例程，并且创建初始状态机设置。分析例程检查每个元素、属性、子元素等。XML文件用限定状态机内容和转变的块描述服务器状态机方案的属性。所述块体现了容器的概念，所述容器为XML内帮助将多个元素结合用于逻辑关系的结构。容器为例如OR的布尔结构，其中OR是用于转变的容器。容器对于其全部子类是唯一的。

块内的编程语句描述事件进程处理或逻辑动作，逻辑动作例如链接、阻塞、转至或转变。转变是由包括布尔表达式或截止时间构成的条件保护。

通常，通过对任何给定跟踪消息或事件当前正在给定状态机内的何处被处理保持跟踪，而在状态机内定义状态。给定状态之后，下一个转变目的地则依赖于定义在跟踪消息记录的字段中的后面的事件。接收到的事件具有变为状态的处理定位。如果事件与转变标准相匹配，则到达该状态定位，并且该到达定位变为新的状态。因此，状态变为转变执行的网络结果。当前状态依赖于先前遇到的状态事件，并且如果转变标准与任何给定的当前事件相匹配的话，当前状态则发生改变。

在用于其状态机的gMg语法中，转变标准通过链接和转向语句链接到一起。转向执行状态改变，而链接则不会。链接类似于附加分支，而转向则改变状态。链接的作用类似于并列的分裂路径(或并列的如果语句)，用于对进入系统的输入事件进行估计和路由。链接创建用于下一个转变的可能的路径或遍历，但其将不会引起任何的状态变化。可将标签作为转向语句(状态)的目的地，或作为链接语句(无状态)的目的地。

另一个重要命令是与出现在块的末尾处的监听程序类似的任何时候(Anytime)语句，每当该语句的条件与输入事件匹配、且当前状态在块内时，执行该语句。Anytime语句可与用于全部转变的OR相比拟(例如，假定块的结尾处具有Anytime语句)，当状态存在于块中的任意位置时，处理则检测在转变之外执行的全部Anytime语句。在需要完成某个动作而不用管给定块中的精确状态的情况下，则使用Anytime语句。Anytime的作用就像是监听程序。如果处理到达块，并且接收到事件，那么，则对该事件感兴趣，但是根据条件和标准，状态不必受到Anytime语句的执行的影响。在给定的状态中，当接收到另一个事件时，给定块中的全部Anytime语句以及全部父类块都被检查。然后对与事件匹配的全部Anytime进行调用，并对全部接下来的潜在转变进行检查。执行匹配的第一个Anytime。对于每个新的事件，都可能执行状态转变并可能执行多个Anytime块。对于块列表中的每个条件，都对Anytime命令进行一次评估，并且对于每次匹配都将执行一次合成操作。

例如，如果将对多个页面的响应时间进行监控和测量，那么，Anytime语句则允许用更少的程序语句对测量进行编程。将目标页面列在块语句中，并增加Anytime语句。然后，通过定义的事件将Anytime语句应用于其对全部目标页面进行测量的进程，并且不管用户遍历页面的顺序而将其枚举在列表中。如果用页面定义了序列，也就是，主题＝页面1、主题＝页面2、主题＝页面3等，并且这些页面表现了一系列转变，那么，不管用户在哪个页面上，Anytime语句都导致对每个页面的加载时间进行测量。使用Anytime的应用的另一个实施例是对给定进程进行计数。对于块内的每个事件，执行一次Anytime，并且状态机每次对一个事件进行评估。Anytime单独地与块相关联，并且位于给定的块中。

检测多个脚本的存在需要代理和脚本标识符的组合。代理会话id必须是唯一的，并且在该代理会话id内还具有脚本会话，脚本会话也由脚本会话id唯一地识别。这些标识符使得能进行实例检测。在状态机内，例如在检测登记或错误时，代理会话id用于对状态机进行组织，这些状态机也是可识别的并且是唯一的。通常，创建的全局状态机并不具有全局可见性，但是如果需要的话也可能具有全局可见性。通常不具有遍布全部用户的状态，而是相反地，每个用户或进程都需要其自身的状态，该状态由状态机实例进行跟踪。

除了具有清除的标识符之外，允许对事件进行有效处理的另一个重要的处理结构机制是从跟踪消息发起的作用域定义，该跟踪消息是由gMg数据源发生器发送的。作用域识别并进一步支持GUI对象集、事件或发生在gMg数据源(客户)上的其它进程的多实例检测。

将来自不同会话的事件收集到队列中。基于字段值，为事件对象分配作用域。通常，作用域也是会话，但是作为一种选择，还可通过使用例如主题(Topic)字段的某些其它的跟踪消息字段定义作用域。在每个作用域内，具有状态机的一个或多个实例。例如，如果任务是检测错误，那么则可创建一个用于该会话的状态机以确定消息，而无需多个状态机。

为了避免状态机的扩散化(以及对服务器资源的更高要求)，如果新的事件与初始转变匹配的话，那么，在作用域内已存在状态机的情况下，则不需要创建新的状态机。新的事件可被传递，以用于对现有状态机进行处理。例如，如果页面出现在应用程序中，那么，页面事件则用于对转变进行初始化，该转变仅发生在页面第一次被创建和显示时。仅在此时，才创建新的状态机。创建的状态机是唯一的，这里的唯一意味着单一的作用域内的单一实例。

基于触发其创建的事件的作用域，将状态机实例分配给该作用域。作用域通常由会话id识别，其中作用域由L1到L5的跟踪消息层级定义限定。具有会话和脚本层作用域。如果包括了脚本层作用域，则具有检测脚本id的状态机。该脚本id相对于代理会话id而言是唯一的，并且由服务器通知客户有关代理id的创建，并且对于每个客户机上的每个代理都重复上述过程。

以下两种实施示出了作用域特征的应用。在第一实施方式中，到应用程序的登录过程仅需要简单的初始转变。对于安全登录过程，用户输入id信息，然后提出其进入。在最初出现登录屏幕之后(通常在会话的生存期中出现一次)，生成事件。服务器接收事件，且初始转变上的状态引擎创建新的状态机。在另一个实施方式中，在gMg监控中具有两个线程(一个线程对应于一个窗口)的窗口应用程序将对两个窗口中的每个窗口中的处理进行跟踪。在这种情况下，在会话中或在状态机中识别用户。在用于相同用户的相同会话中还可具有多个作用域。服务器分析将利用两个作用域，每一个作用域用于一个窗口，单数将仍然与相同的用户相关联。此外，在状态机集合内，可具有用于每个窗口的不同的状态机。

参照图25，在包含转变2505的一组状态机定义内，给定连续事件2550，这一组状态机定义2565内涉及事件(2510到2520)的每个静态条件由EvalStatic 2555处理，EvalStatic 2555将剩余一组条件2570保留在状态机实例的上下文中，剩余一组条件2570涉及必须进行估计的状态机实例变量2525到2545。通过用于每个状态机实例的函数Evallnstance 2560对这些实例条件进行检查，并执行第一匹配转变。这对于现有的或新创建的状态机都会发生。初始转变不是局部的，除非在其创建新的实例时。但是，初始转变对事件的处理类似于任何其它转变。如果匹配的转变可从当前状态接受，那么，则具有到开放路径的链接。如果转变条件为真，那么，在事件的实例层则还可具有条件。

例如，如果跟踪消息到达，且其状态字段等于5，那么则将该值存储在实例中，但是此时该值不能被验证，因为实例还不能被访问。只有在处理到达到实例的通路时，这些值才能被估计，并检查状态是否与接收到的事件匹配。这是与静态条件相反的实例条件的实施例。如果条件可接受并且转变条件为真，那么，对静态(假)的评估则导致对实例条件的评估。服务器状态机编译器在静态和实例条件之间进行区分，并调用适当的处理例程。如果这些转变事件条件为真，那么，则选择并执行与该转变相关联的代码动作。然后，转变处理则转至后转变阶段，或者，如果具有转向指令的话，则将在转向目的地进行状态处理。

参照图26，大多数的处理都在估计进程、以及对成千的非常高速的接收的事件2603的路由和调度中。在这种大的集合中，为了避免状态的模糊，将全部事件串行化2609，然后将其输入到一组状态机2621中。状态引擎2627用定义的状态机(例如2624)对接收到的事件进行检查。上文所述的状态机定义及其实例之间的区别在这里是可用的。状态机是状态检测机制的定义，而全部定义的状态机将处理每个输入事件。如果事件条件(静态的)被匹配2612，那么，状态机引擎则相对于作用域检查事件2633，并且仅处理匹配作用域2639内的实例中的事件。某些实例的状态的条件不能在更高状态机定义级确定。如果状态机对接收到的事件感兴趣，那么，事件则必须根据每个实例的状态被状态机的实例所捕获。给定全部转变的集合，总体目标是首先测试静态条件2615，然后测试全部实例条件2618。检查静态条件是更高级的操作，其首先实现以提高效率。

状态机由作用域分组，并且，对于给定的事件，使用事件作用域作为键值在映射中对状态机实例进行查找。在静态结构的集合中，对转变以及与输入事件2612匹配的全部Anytime进行检索。静态估计可作为快速测试来排除与事件不匹配的转变。不对每个实例重复一次事件处理，处理可在顶层(即，状态机定义层2615)完成，并且不由条件中的当前输入事件发起的转变将不在执行转变列表中出现。然而，如果事件与转变或Anytime语句匹配，那么，则将每类匹配添加至其各自的匹配转变或Anytime列表2612中。

如果某些满足了某些条件，下一个步骤则创建状态机实例。如果转变列表里包含了初始条件(即，初始转变被匹配)，并且状态机不是唯一的，则需创建某个范围内所需的尽可能多的实例，否则，如果该范围内没有创建的实例的话，则需创建新的实例2636。换句话说，不管匹配了什么条件，(状态机制不唯一，或者如果该范围内没有实例)，都必须在该范围内创建实例。如果条件为真，就创建新的状态机实例。

实体方法(Utility Method)也由状态、超时等维持。如果转变匹配2642，则验证该转变有效2645(即，函数IsAnytimeValid验证了Anytime在当前状态下是有效的)。函数(转变)执行发生在转变内，并且在有效转变内被调用2648。进行检查，以确定是否已执行了转变2651。如前所述，可在顶层(状态机定义)验证公共gMg实例，但是，如果条件涉及已存在的状态机实例，那么，每个状态机实例都可以具有用于这些实例的不同值，因此，每个状态机都必须在精确的实例中被检查。

在转变处理完成之后，可能会有另一个实例，也可能没有另一个实例。如果驱动数据源的进程被中断，或者如果状态机到了达其最后一个转变，则发生这种情况。如果没有转变符合当前状态的话，过一段时间之后，转变则超时，以防止gMg系统死锁。

如果执行了任何的转变，那么则检测超时2654。超时必须被寄存在超时缓冲器中，该缓冲器之后可能被触发。在每个状态下，超时记录可接受的最短的超时位置。例如，如果具有两个超时(例如，5分钟和10分钟)，则记录较短的一个超时。由于5分钟的超时将首先到时，因此将10分钟的超时丢弃，然后首先执行随后的状态改变。任何情况下，状态机中都仅有一个可能的超时，该超时将为最短的超时。因此，如果执行了任何的转变，超时则必须更新，新的状态被传送，查找新状态中全部可能的超时，并且登记新的超时请求。当事件到达时，检测超时。具有超时请求的缓冲器，该缓冲器中包含登记的超时请求。当事件到达时，基于事件时戳，在缓冲器中检查任何的超时，调用登记方法2654，并更新关于状态机的信息。例如，如果系统处于给定的状态，并且如果存在30分钟的超时，那么，在30分钟结束之前，如果转到了另一个状态，则将进入另一组超时。然而，如果不存在超时，则将超时登记删除。如果系统在等待事件，但是不确定时间将何时到达，那么，可创建某个时间间隔(例如，一分钟)的并行超时。然后，如果事件在一分钟内到达了，则继续进行状态处理。然而，如果事件未到达以防止处理被阻塞，那么，通过一分钟超时的登记，系统则可继续。处理转变之后，当前的超时登记将被移除2654。仅有新的超时被登记(如果其可接受的话)，也就是说，具有来自当前检查位置的适当的转变路径。另一方面，如果在一分钟之后未在当前位置接收到事件，则检查超时缓冲器，使用超时，并执行转变且转至下一个状态。从该下一个状态，完成对新的状态转变的搜索，并且将新的状态转变登记。

优选地，在对事件进行处理之后对超时进行处理。超时是在常规处理之后进行，这是因为转变的执行可能会去除超时。当条件是具有代码行动的超时时，将超时登记至缓冲器中，并且将其视为转变。超时是不具有事件的具体转变，因为其实际由不存在事件而触发，其中转变经过时间间隔(其间不具有转变)之后被触发的。代码动作通常具有用于外部事件的参数，但是，在超时内，是不具有这样的参数的。具有在状态引擎层使用的一个超时缓冲器2630。缓冲器输入项对应于分钟，并且对于每个输入项，都具有调度以在该分钟超时的一系列转变。处理完成后，将当前事件的时间用于将相应的分钟锁定在超时缓冲器中。直到该分钟并包括该分钟的、位于输入项中的全部转变都可被暂停，其中超时的发生将删除状态机。在全部未决的超时上不具有循环，并且，对用于全部状态机的转变进行调用的处理是非常快速的。实现转变之后，引擎调用IfEndStateQ，用于当前处理的状态机。如果该状态机处于最后的状态时，方案则终止。

在关闭时，具有多个可能的监控对象的gMg监控系统创建数据源，所述对象是由该监控系统的用于公共或私有的组建方法接口提供的，所述数据源可在丰富的GUI用户上下文中被分析，以反映支持企业应用程序的底层系统的性能简档。gMg系统能够支持具有GUI对象的泛型或具体检测的多实例应用程序GUI，这种能力提供了操作环境内内部动态应用程序进程内的最大灵活性和适应性。此外，本地和远程分布的状态机提供了对多种应用内的多种事件的及时分析，所述事件例如检测慢响应次数、错误条件、商业处理分析等。

参照图27，流程图示出了用于分析方法事件的进程2700。在步骤2710，独立监控程序436(包括代理414、引擎416以及方案426)是可操作的，以对不同的树结构形式的对象进行建模，所述树结构包括主机应用程序的分层GUI对象树660(用于识别GUI对象)、代码模块树图17(用于识别代码模块和方法监控器，COM实例)以及进程/线程树(用于识别主机应用程序的进程和线程)。在步骤2715，得到环境谱的指示(即，列在对象、GUI对象、消息、方法调用以及方法返回中的目标应用程序的条件)，用于应用程序窗口。在步骤2720，对可出现在两层(或更多层)用于及时传输有意义的事件(例如，第一层本地用户的桌面2403和第二层远程服务器2406)的状态机事件进行处理。在步骤2725，对一个或多个状态机生成事件进行关联，所述事件是由gMg系统的传感器或状态机处理响应于主机应用程序的动态环境谱指示(例如，用户、应用程序、OS以及方法事件)而创建的。在步骤2730，基于关联状态机的结果，推导出用户经验的指示。在步骤2735，根据状态机事件，将与环境谱指示同义的逻辑事件数据聚集在服务器557上。在步骤2740，识别字节操作码模式1920，并将其用于定位和检测组件函数的方法入口点。在步骤2745，识别字节操作码模式中的接口函数，该接口函数提供到事件和属性的接口。在步骤2750，确定接口函数的地址。使用的技术依赖于被拦截的函数的类型(例如，是输出函数1620还是COM类型库(COM TypeLibrary)1624)，并依赖于监控进程是在对象创建之前(1627)还是之后(1630)启动。操作码模式允许执行调用1642和返回1645拦截以识别对象，包括方法调用、方法返回和GUI对象。在步骤2755，进程2700利用拦截例程(图18)1848链接至接口函数，以跟踪函数调用。

图28示出了用于对主机应用程序功能进行监控的进程2800的流程图。在步骤2810，从目标方法的一组被捕获的字节模式(即，方法签名1930)中识别表示主机应用程序内的方法函数的字节操作码模式。在步骤2815，进程2800将运行期函数字节操作模式1910与方法签名列表进行比较，以确定方法的位置1905。在步骤2820，利用跳转例程指令2039建立目标方法函数、调用拦截例程2012以及信息结构实例2045之间的链接。在步骤2825，进程2800可选地使用两个堆栈操纵技术对调用方法函数的返回进行监控，两个堆栈操纵技术为返回捕获堆栈复制1648和返回堆栈分配1651。结果是捕获可用于检索关于应用程序的内部进程的附加信息的返回值。

参照图29A和29B，示出了进程2900的流程图，该进程对来自计算机目标应用程序表示层的事件进行监控。在步骤2904，在目标应用程序的本地客户计算机436上提供“方案”426形式的脚本。脚本426能在目标应用程序内运行。在步骤2906，对来自目标应用程序545的多实例的对象509的运行期实例进行扫描。扫描对象的结果是得到一组实时事件515，这些事件从用户、应用程序、OS事件以及来自目标应用程序的方法调用和方法返回的GUI对象和方法属性的特定值获得。在步骤2908，分配内部GUI对象树832以组织数据结构，这些结构然后在步骤2910被调整，以反映真实应用程序的GUI的实时动态改变。调整后的“多类”事件流反映真实应用程序1115、1103的实际状态。GUI结构反映一类事件，这类事件提供供全部其它类型的数据交错和引用的上下文。在步骤2912，通过利用能检测相关对象(指代码样本)类别的脚本表示，从目标应用程序中检测与预定的对象结构匹配的对象实例。图15示出了可为泛型的1510、用于检测相关GUI对象的全部类别的gMg脚本表示(其也可为具体的1505，用于检测单一的GUI对象)。检测表示可检测该概念谱中任何位置的GUI对象，以反映在应用程序运行期结构中发现的许多变体。在步骤2914，在从任何目标应用程序实例中检测到的对象的内容中，捕获检测到的对象的至少一部分环境谱。

在步骤2916，使用脚本逻辑序列表示(逻辑状态机)或状态机(远程状态机)处理，根据来自gMg传感器428、429、440的事件得到逻辑事件521，所述事件是从环境谱(即，方法、OS、用户以及应用程序事件)中接收到的。在步骤2918，对于处理的内容进行重新汇编(即，在服务器446上收集数据)，以反映由gMg传感器检测到并由GUI对象树反映的多实例结构。gMg系统的分层状态机处理2430和2442检测重新事件序列，所述事件序列创建如用户感受到的上下文的应用程序状态。在步骤2920，将重新汇编的结构关联为通过范围2639检测的数据集，范围2639被定义用于唯一的状态机，该状态机将应用程序实例和GUI对象集实例分离到用户会话中，以反映应用程序的先前状态。在步骤2922，在多个脚本945、948、951中共享目标引用程序的反映(即，多个脚本使用相同的GUI对象树660)，多个脚本中的每个都与目标应用程序中的各实例901、902、903相关联。中间处理使用接收到的跟踪消息形式的捕获的事件(436和446之间)，该跟踪消息被处理用于实时显示和检测或被收集到数据源中用于进一步分析。在步骤2924，附加数据源允许对跟踪数据集进行复杂的历史趋势分析，该数据源使用通常理解的同义定义，该定义与具有目的地的源同步，以重新创建用户经验条件并提供对该条件的观察。

参照图29B，进程2900在步骤2932继续，其中，对使用gMg上下文(图12)的分层组织实体进行说明，该实体表示目标应用程序的一部分并且包含上下文信息(例如，上下文层级1205、1210、1215)。在步骤2934，对捕获的、受到分层组织实体支持的环境谱(例如，对象树1015及其对象变量特征(例如1035)或对象变量集1039)进行分析。在步骤2936，进程2900利用图14中的钩子感知与用户的目标应用程序交互，或感知与出现在进程1406或线程1409、1412、1418、1421中的目标应用程序生成事件的交互。在步骤2938，利用逻辑脚本表示变量(指先前描述的题为“Specific and Generic Binding CodeSample”的代码样本以及对象变量1005)，基于响应于感知步骤的结果而进行的脚本执行，生成事件(例如，利用如WhenObjects 1151的机制生成gMg事件)。

在步骤2940，将生成的事件中的一个或多个传递至解释器745。在步骤2942，对这种选择性生成的事件进行分析。选择使用gMg系统的例如脚本中逻辑表示的各种机制描述检测条件、变量和对象变量、WhenObjects以及GUI对象树结构内的条件。在步骤2946，将分析与关于外部源的参数相关联，尤其是与来自服务器或环境基础设施的数据相关联。在步骤2948，将脚本与目标应用程序内的窗口的单一进程1315相关联。在步骤2950，检测与线程id相关联的唯一消息。在步骤2952，由活动的钩子例程1433到1442拦截消息。在步骤2954，用脚本表示和操作(指代码样本“Manylnstances”)对消息内容进行评估，以获得事件和属性，从而获得目标应用程序上的信息。在步骤2956，进程2900生成报告454、警报450、关联452、以及动作/响应456，上述各项中都包含分析步骤和关联步骤的结果。在步骤2958，以由检测到的事件唤醒的预定间隔(例如由OS时钟或由其它某些条件驱动)重复以下步骤：对不断地用反映应用程序GUI的结构填充gMg GUI对象树660的应用程序进行扫描、动态地分配、调整、检测(例如，有图11中的WhenObject机制、图14中的钩子执行的间歇轮询操作)和捕获。

由于已对本发明进行了详细描述，因此，对于本领域技术人员而言，各种改进、变化或等同都将显而易见。因此，应该理解，详细的说明是示例性地提供的，而非限制性的。在详细构造和组件的组合和配置中，可采用大量的变化，而不偏离本发明的精神和范围。本发明仅由权利要求及其等同限定。

Claims (31)

1.一种用于对来自表示层的事件和目标应用的软件方法进行监控的方法，包括以下步骤：

独立于对所述目标应用的源代码的重编译，提供能够操作以在所述目标应用内的层运行的脚本，其中所述目标应用具有结构；

扫描对象的运行期实例，所述对象包括所述目标应用的方法调用、方法返回以及GUI对象；

实时地为所述对象实例分配结构；

调整分配的结构，以创建所述目标应用结构的反映；

检测与预定对象结构相匹配的一个或多个对象；以及

捕获检测到的对象的环境谱的至少一部分。

2.如权利要求1所述的方法，进一步包括以下步骤：

将捕获到的所述检测到的对象的环境谱处理至逻辑事件中；

将所述逻辑事件重新汇编，以反映不同上下文内的多实例结构，其中所述不同上下文是所述目标应用的先前状态；以及

将所重新汇编的多实例结构相互关联，以分析所述目标应用的所述先前状态。

3.如权利要求1所述的方法，其中所述捕获的环境谱包括与所述检测到的对象相关的各类信息，所述信息提供了与所述目标应用环境相关的知识。

4.如权利要求1所述的方法，其中所述扫描步骤进一步包括以下步骤：

基于至少一个预定的监控标准，选择对象实例。

5.如权利要求1所述的方法，其中所述提供步骤在客户计算机上提供所述脚本。

6.如权利要求1所述的方法，进一步包括以下步骤：

在多个脚本中共享所述目标应用结构的反映，其中所述多个脚本中的每一个都与所述目标应用中其各自的实例相关联，其中所述目标应用结构的反映为收集的跟踪数据提供GUI上下文。

7.如权利要求1所述的方法，进一步包括以下步骤：

使用能够检测多种相关对象的脚本表示，检测所述对象的泛型实例；以及

对所检测到的泛型对象实例的内容和属性进行处理，以确定上下文中目标应用事件的发生。

8.如权利要求7所述的方法，进一步包括以下步骤：

通过使用跟踪消息层和预先定义的语义和约定，建立用户上下文。

9.如权利要求1所述的方法，进一步包括以下步骤：

声明分层组织实体，所述实体表示所述目标应用的一部分并包含来自至少一部分所述捕获的环境谱的上下文信息；以及

分析由所述分层组织实体支持的所捕获的环境谱。

10.如权利要求9所述的方法，包括以下附加的步骤：

评估上下文层的值，以在执行所述目标应用期间对多个对象实例进行区分。

11.如权利要求2所述的方法，其中具有所述目标应用的多个实例，进行扫描的所述步骤对每个目标应用实例进行扫描，进行检测的所述步骤对与所述目标应用的多个实例相关的对象实例进行检测。

12.如权利要求11所述的方法，其中所述捕获步骤从任意的目标应用实例中捕获所检测到的对象的内容。

13.如权利要求4所述的方法，其中所述客户计算机上的所述脚本位于所述目标应用本地。

14.如权利要求1所述的方法，进一步包括以下步骤：

检测与用户交互的目标应用和目标应用生成事件中的至少之一；

响应于所述检测步骤的结果，基于所述脚本的执行选择性地生成事件；

将所生成的事件中的一个或多个传递至解释器；

分析选择性地生成的所述事件；以及

通过到外部源的函数映射，对所述分析进行关联。

15.如权利要求14所述的方法，进一步包括以下步骤：

生成包含所述分析步骤和所述关联步骤的以下各项中的至少之一：报告、警报、关联以及响应。

16.如权利要求1所述的方法，其中所述扫描、分配、调整、检测和捕获的步骤以预定的间隔重复，以创建对所述目标应用的更新反映。

17.如权利要求1所述的方法，其中所述扫描、分配、调整、检测和捕获的步骤由检测到的事件唤醒，以创建对所述目标应用的更新反映。

18.如权利要求1所述的方法，进一步包括以下步骤：

将所述脚本与所述目标应用中的窗口的单一进程相关联；

检测与线程标识符相关联的消息；

通过所述脚本内活动的钩子例程拦截所述消息；

评估所述消息的内容；以及

从所述消息中得到事件和属性，以获得关于所述目标应用的信息。

19.一种用于分析方法事件的方法，包括以下步骤：

提供独立的监控程序，所述监控程序能够操作地对应用窗口的对象进行建模，并能基于预定的监控标准识别待被监控的对象；

得到用于所述应用窗口的环境谱的指示；

处理发生在服务器和客户/本地化机器中至少之一上的状态机事件；

将所述状态机事件与所得到的环境谱指示相关联；

基于所述相关步骤的结果，推导出用户经验的指示；以及

将推导出的指示报告给系统用户。

20.如权利要求19所述的方法，其中所述推导步骤基于由服务器方接收到的指示符。

21.如权利要求20所述的方法，其中所述关联步骤进一步包括：

从所述状态机事件中收集与所述环境谱指示协作的逻辑事件数据。

22.如权利要求19所述的方法，其中所述独立监控程序包括能够操作以实现以下步骤的指令：

识别字节操作码模式；

在所识别出的字节操作码模式中检测至少一个接口函数，所述接口函数为应用进程的事件和属性、所述应用窗口或窗口GUI对象提供接口；

确定所检测到的接口函数的地址；以及

通过利用调用拦截例程，链接到所检测到的接口函数，其中，对所检测到的接口函数的调用是被跟踪的。

23.如权利要求22所述的方法，其中所述链接步骤使用返回拦截函数，其中，返回被跟踪。

24.如权利要求22所述的方法，其中所述独立监控程序进一步包括能够操作以执行以下步骤的指令：

以不同于处理具体函数拦截的方式处理泛型函数拦截，其中所述泛型函数拦截不需要预先知道所检测到的接口函数的参数和格式。

25.如权利要求22所述的方法，其中所述独立监控程序进一步包括能够操作以实现以下步骤的指令：

以不同于处理具体函数拦截的方式处理泛型函数拦截，其中所述具体拦截函数包含对所检测到的接口函数的公共参数和格式的指示，所述具体函数拦截能够将所检测到的函数参数直接用于脚本中。

26.如权利要求22所述的方法，进一步包括以下步骤：

通过利用实例信息寄存器，传递用于方法调用的实例信息；

其中，主机应用程序中的堆栈未被修改，且所述实例信息寄存器包含指向调用函数的实例信息的指针，以保存方法调用上下文。

27.一种用于对计算机目标应用程序的表示层中的事件进行监控的系统，所述系统具有预定的结构，所述系统包括：

在通信网络中相互连接的服务器和客户计算机；

在所述服务器上执行的监控程序，所述监控程序包括能够在所述表示层以下的层上运行的脚本；

所述监控程序能够操作以实现以下步骤：

扫描所述目标应用的对象的运行期实例；

实时地为所述对象实例分配结构；

调整分配的结构，以创建所述目标应用结构的反映；

检测与预定对象结构相匹配的一个或多个对象；以及

至少捕获检测到的对象的内容。

28.如权利要求27所述的系统，其中所述脚本提供在所述目标应用的本地计算机上。

29.如权利要求28所述的系统，其中所述客户计算机为以下各项之一：个人计算机、工作站、个人数字助理以及能执行计算机操作指令的平台。

30.一种监控主机应用程序的功能的方法，包括以下步骤：

识别表示所述主机应用程序内的方法函数的字节操作码模式；

确定用于至少一个方法函数的地址；

通过所述地址，将所述方法函数链接于调用拦截例程，并链接于信息结构实例；以及

用堆栈操作对调用所述方法函数的返回进行监控。

31.如权利要求30所述的方法，其中所述链接步骤包括使用跳转例程指令。

Images