RU2521265C2 - System and method for automatic processing of software system errors - Google Patents

Abstract

FIELD: physics, computer engineering.

SUBSTANCE: invention relates to processing errors arising during software operation. The technical result is achieved via automation of software analysis in an emulated runtime environment and generating an expert system of scenarios of processing errors determined during analysis. Use of the invention in practice enables to test software for compatibility with a computer system configuration; determine the full list of errors which may occur during operation of the software in different conditions; determine the cause of system errors and perform modification of the computer system to prevent a particular error.

EFFECT: high efficiency of processing errors occurring when executing a program code in a computer system.

14 cl, 7 dwg

Description

Technical field

The present invention relates to software controls and, more particularly, to systems and methods for handling errors that occur during software operation.

State of the art

One of the important characteristics of software (software) is the fault tolerance of programs under conditions determined by various software and hardware configurations of computer systems. It is in the interests of the software manufacturer to release a product that excludes the occurrence of fatal errors in the operation of the program and the computer system. There are many ways to do this, one of which is designing the program installer, which will perform the installation taking into account the system environment. It is impossible to foresee all variants of user systems, test the program on them and adapt it for each modification even in the conditions of full standardization of the design of computer systems and programs.

Each released application with proper design should correctly handle errors associated with the application. This is primarily necessary to support users, quickly make corrections to the program and release updates. This is especially true for programs that provide services to other applications, for software libraries, etc.

The software design concept leaves the possibility of errors in various situations and computer system configurations, which must be taken into account when installing new software, updating software modules and sharing various applications and system services. To solve this problem related to software management, a new technology is required that allows identifying possible system errors, analyzing and eliminating the causes of their occurrence, and correctly handling errors if they occur in a computer system.

Existing technologies allow testing programs, including in an emulated runtime environment. Among them, there are methods of simulating various system states to detect possible errors, one of which is described in US Pat. No. 7,083,881. But not all errors detected during testing can be corrected by correcting the application code. The problem of post-processing errors when trying to install programs and run them on a computer becomes even more important with the increasing number of applications, their updates and versions.

The technology described in US patent 6378128, allows you to adjust the installer program to solve problems. The application of this method is ineffective when installing software in a corporate computer network (PIC) with a large number of workstations, each of which may require the formation of a unique installer.

Other solutions to the problem of system errors during software installation are to roll back the system state and use virtualization tools for pre-installation. In patent publications US 20060168165, US 6691250 describes examples of such systems, but they do not allow to identify the causes of errors.

Modern computer system administration systems contain tools for tracking system errors, but errors are analyzed after they occur in a real system.

This invention eliminates the described disadvantages and allows you to prevent errors and process errors that occur in computer systems during installation and operation of the software using expert data obtained by analyzing programs for errors in the emulator.

SUMMARY OF THE INVENTION

The present invention is intended to eliminate errors that occur during the operation of the software, including when installing new or updating existing software.

The technical result of the present invention is to increase the speed of processing errors that occur when executing program code in a computer system.

Putting the invention into practice allows testing software for compatibility with the configuration of a computer system; determine the full list of errors that may occur when the program is running in various conditions; identify the causes of system errors and modify the computer system to prevent the occurrence of a specific error.

The technical result is achieved by automating the study of software in an emulated execution environment and the formation of an expert system of processing scenarios defined during the study of errors.

In the main implementation variant, the system consists of an emulator, an expert system, an expert database, and an error handler. The emulator is designed to reproduce the state of a computer system in order to cause an error, execute the software application in the reproduced state of the computer system and determine at least one error in accordance with the conditions that caused this error to occur during the execution of the software application. The expert system associated with the emulator is designed to compile at least one error processing scenario defined by the emulator, depending on the conditions that caused this error and update the expert database with information containing the identifier of the error, the conditions for its occurrence and, at least one error handling scenario. The expert database associated with the expert system is designed to store information about errors, the conditions of their occurrence and their processing scenarios for the corresponding application. The error handler associated with the expert database is designed to determine whether an error occurred while executing a software application on a computer system, load the error processing script corresponding to the given error from the expert database, and execute the corresponding error processing script.

In one embodiment, the invention handles errors of a software application that is a software installer.

One of the proposed implementation options contains an error handler, which is additionally designed to change the state of a computer system before starting to execute a software application in order to prevent an error.

The state of a computer system is determined by the settings of the computer system, the list of installed software, the list of computer system devices, data loaded into the memory, and connections to the data network.

In a particular embodiment, the emulator reproduces the functions of at least the processor and memory of a computer system.

One embodiment includes an emulator that reproduces the state of a computer system by changing at least one return value of an operating system API function.

The proposed implementation options handle errors that occur when an exception is thrown, an error code is returned, an error variable is assigned a value, and an error is detected by the system event handler.

The error processing scenario in one implementation option consists of a sequence of commands that allow you to configure a computer system to eliminate the occurrence of an error.

Another variant of the error handling scenario consists of a sequence of commands that allow transferring information about an error to the administration server.

Brief description of the attached drawings

The accompanying drawings, which are included to provide an additional understanding of the invention and form part of this description, show embodiments of the invention and together with the description serve to explain the principles of the invention.

The claimed invention is illustrated by the following drawings, on

which:

Figure 1 shows a diagram of the execution of an application on a computer device.

Figure 2 shows a diagram of the execution of the application in the emulator.

     Figure 3 shows a block diagram of an emulator.

Figure 4 shows a block diagram of the algorithm of the emulator.

Figure 5 shows a functional diagram of a system for automatically processing system errors.

Fig.6 shows the algorithm of the system for automatic processing of system errors.

7 shows an example of a general purpose computer system.

Description of Preferred Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details necessary to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

The study of programs for possible errors during their execution in a computer system is especially important for the analysis of installers. Modern software is built taking into account the technical requirements for its correct operation, where compliance verification is implemented in distributed installer programs.

Consider the example of the installer (installer) of a user application. In most cases, programs are distributed in a compressed, self-extracting format. The installation process includes a system test for compliance with technical requirements, unpacking and the correct location of files in directories on the disk, adding or changing environment variables. To install some programs and add-ons, the installation process is limited to copying the file to the appropriate directory. There are installers that download files from the Internet and initially do not contain program files. The model of batch installation of programs is also used, in which the installer is part of the operating system, and the software is distributed in the form of a standard format for batch processing.

Depending on the functionality of the program, the installer can check various technical requirements for the user system, which are expressed in the form of certain conditions. As an example, a set of conditional checks consists of:

- access checks for writing / reading the file necessary for the program;

- checking the availability of necessary free disk space;

- checking the availability of libraries and interpreters necessary for the functioning;

- verification of the characteristics of the processor, memory and video controller software requirements for computing resources;

- checking the availability of a remote resource over a data network;

- checking any other system parameter.

The occurrence of system errors and the raising of exceptions is usually preceded by the execution of program operations, which are a condition for the occurrence of an error (system test). After this follows, as a rule, returning the error code, which is the identifier of the error, or calling the exception handler if the corresponding problem was provided by the developer. Otherwise, the error in the program operation will be irreversible, and the interruption or error will be processed by the operating system. Using the error code, you can refer to the documentation provided by the software developers. However, these reference documents contain an incomplete list of errors, are limited to decoding the error code and are not able to indicate the specific cause of the error, and therefore are not applicable for use in expert systems that require more accurate details for the effective application of expert rules in correcting errors.

Depending on the programming language and architecture of the application, various methods are used for processing and reporting emergency situations (errors). The easiest way is to use error codes. The essence of this method is that each subprogram (function, procedure or other block of code, depending on the programming language used) must return a code that calls its main function, the value of which will mean the success of the task or an error. The values of the codes corresponding to errors during the operation of subprograms constitute a set of error codes.

An example of using error codes in program code is shown below. The error can be returned by various operators, including in the form of function return codes.

Examples (error codes) for Adobe Flash Player:

Для хранения ошибок часто используются глобальные переменные, например в языке Си ошибки хранятся в переменной «errno»:

Global variables are often used to store errors, for example, in the C language, errors are stored in the errno variable:

If we consider the operation of the operating system of the Windows family, then most of the functions use error codes. Another applicable failure notification method is exception calls. Exceptions are used in cases where the state of the data, I / O devices or the computer system as a whole makes further execution of the program impossible or pointless. Each exception can be processed with a return when the program corrects the error and continues to function, or without returning, transferring control to another predefined program module.

Most modern programming languages, such as C ++, Delphi, Objective-C, Java, Ruby, Python, PHP, all languages of the .NET platform, etc. have built-in support for structural exception handling. In these languages, when an exception is supported by the language, the call stack is expanded to the first exception handler of the appropriate type and control is transferred to the handler.

In the event of an exceptional (contingency) situation, an exception is generated, which from the point of view of the program is a data object containing the parameters of the exception, for example, conditions or causes of the occurrence. In some languages, an exception object can be an object of any data type (including a string, number, pointer, and so on), in others, an object of only a predefined type and its derived types.

The error handling methods described are used when writing program code. In this case, the programmer knows all the possible errors that may occur in the application and the system. Error handling at this stage is performed directly in the program itself.

Very often there is a need to define a list of errors and exceptions to be processed already in the compiled program. This task may be especially relevant for supporting poorly documented applications, for testing programs and ensuring security. Moreover, software manufacturers do not always indicate a complete list of possible errors and rarely describe the causes of errors and possible ways to correct and prevent them.

The method proposed in this description solves the problem of determining a complete list of error codes in a third-party software product, allows you to determine the conditions for the occurrence of errors, suggest steps to correct errors and prevent their recurrence.

The main difficulty in analyzing a software product is the closed source code. Proprietary software products are usually available as an executable binary file. The study of the program logic for processed errors is carried out by tracing the program, emulating program execution or disassembling the binary code.

Executing a program in an emulated, virtual or limited environment in standard mode will not allow you to get a complete list of errors that may be caused. Unlike those cases when the error is explicitly defined and the place of its occurrence is clearly defined, an exception can be raised at any time. This leads to another problem - the need to simulate various environmental conditions and program behavior.

In the general case, the program operation algorithm can be represented as a tree-like structure of conditional transitions, where each node is a check of the condition, and the branches proceeding from the node are blocks of consecutive executing commands. One of the branches characterizes the processing of errors or exceptions, while the end of the tree structure characterizes the successful completion of the program or the error call. This method allows you to analyze the executable code of the program in order to build the relationship of the error code with the condition for the occurrence of the error.

For a more detailed disclosure of the principles underlying the study of computer programs in an emulated space, we consider examples of program formats (software applications), the processes of their launch and execution in computer systems.

A computer program is a combination of a sequence of commands designed to control devices of a computer system in order to implement a specific algorithm, and data used to execute these commands. Depending on the chosen programming paradigm, the program can be expressed in object form or in the form of source code. The process of launch and execution directly depends on this.

Some programming languages allow you to do without preliminary compilation of the program and translate it into machine code instructions directly at runtime. This process is called dynamic compilation and allows for greater portability of programs between different hardware and software platforms. Programs that are interpreted by the operating system or special interpreter programs are called scripts or “scripts”. Program data is also stored on disk in the form of single files or sets of files in which the source code and data are contained.

In the case when the program is precompiled and stored on disk as an executable file or a set of files, the download process is faster and consists in transferring the program image from disk to the computer’s RAM. An executable file is a file that can be loaded into memory by the loader of the operating system and then executed. In the Windows family of operating systems, executables, as a rule, have the extensions ".exe" and ".dll". The extension ".exe" have programs that can be directly launched by the user. The extension ".dll" have the so-called dynamic link libraries. These libraries export functions used by other programs. In order for the bootloader of the operating system to correctly load the executable file into memory, the contents of this file must correspond to the format of executable files accepted in the operating system. In modern operating systems, there are many different formats of executable files. Consider, for example, a program written and compiled for execution on a Windows operating system. Portable Executable (PE) format is the main format for storing executable files and libraries in the operating system of the Windows family. Parts of programs can be independently compiled into separate object files, which are then combined by the linker into one executable file. The executable file of the described format has a specific specification. The PE file begins with headers followed by several sections. A section in a PE file represents either code or some data and has a set of attributes defining its properties. An executable file always contains at least one section in which the executable code is placed. In general, a PE file has sections of code (text), data (data), uninitialized data (bss), as well as a dynamically allocated memory area at boot - a heap and a stack. Each section has its own purpose, for example, a code segment contains directly executable instructions.

Figure 1 shows a diagram of the execution of an application on a computer device containing memory and a processor. An application that can have various functionalities, including being a software installer, is presented in the diagram as an executable file 100. In other embodiments, the application file 100 may be unexecutable, and an additional compiler or interpreter will be required to play it. The executable file 100 of the application is stored on disk 27 or other external memory.

Launching programs in operating systems 111 processes a special module — a loader, which creates a process and threads, loads the code and data necessary for starting work, into the process memory and transfers control to the application. A virtual memory allocation circuit 130 is described below. The image of the PE file in memory is almost identical to its representation of 100 on disk. This feature of the format simplifies the work of the loader, which only needs to map the individual parts of the PE file to the address space of the process, change the absolute addresses in the executable code in accordance with the relocation table, create a table of import addresses and then transfer control to the entry point. During the execution of the program, libraries may be required that are loaded from the catalogs of the operating system or a third-party set of libraries, the links to which are indicated in the import section. Thus, when the program starts, the loader performs the following actions: reads the headers and necessary sections of the executable file 100; loads into the memory of the library 134, code 132 and data (resources) 133; Binds addresses creates a new process in memory and plans to execute it.

A process is an object of the operating system that contains a set of resources and data 133 that are used to execute a program. At the same time, for each process threads are created, at least one thread per process, which are responsible for the execution of the process code 132 and consist of instructions. An instruction or operating code (opcode) is an operation performed by a processor. Modern processors process instructions in the form of assembler language instructions and then convert them into an internal instruction system in the form of a digital code. Allocation of processor time, synchronization and determining the priority of code execution in the operating system is assigned to the scheduler. Planning in the Windows family of OSs is done at the thread level, regardless of the processes to which they belong. After the process and thread are created, execution of the flow instructions on the processor begins.

As the process flows, sections of memory from the virtual address space 130 are loaded into RAM 120. The real address at which the memory section is located is hidden for this process. Unused sections are transferred from the RAM 120 to the external memory 27 in the swap file 140.

The program execution scheme in the emulator differs from the standard scheme and is shown in FIG. 2. In the presented embodiment, the computer system is supplemented by an emulator 200, which is made in the form of a program executed at the application level. In other special cases, the emulator may be part of the operating system 111 or even a separate device. The emulator 200, loaded into the memory 120 of the computer system and executed on the processor 21, parses the executable file 100 and processes its code. A characteristic feature is that the analyzed application is loaded into the address space of the emulator 200. The software implementation of the emulator allows you to process the code and application resources similarly to the processor 21 and operating system 111.

Figure 3 shows the structural diagram of the emulator 200. The emulator 200 of a computer system is a means of reproducing devices and software of a computer system that interacts with external objects similar to a computer system within the specified accuracy. The accuracy limit of the emulator is a complete copy of all the software and hardware functions (implementation of the operating system, all installed applications, the logic of operation of all devices and connections installed on the computer). In the framework of a certain study, a partial reproduction of the functional and state of a computer system is sufficient. To simplify the emulation of a computer system, methods are used to intercept requests to objects of a computer system that were not emulated, to redirect requests to real objects of a computer system. In one embodiment, to build an emulator capable of executing program code, it is necessary to recreate the processor 300 and memory 310. Additionally, the file system 320, input / output devices 330, and data transmission network 340 are included in the emulator. In some implementation examples, it is possible to reproduce the functions of the operating system and external services. As described previously, the process of the executable file 311 is reproduced in the address space of the emulator, in which it is placed in the recreated memory 310. To control program instructions that are processed in the emulator 200 and, if necessary, must be transferred to execution in a real environment, a separate function block is allocated - a request handler 350. The progress of the program in the emulator as a sequence of executed commands is carried out by the logging module 360.

The emulator 200 in one embodiment may be limited by the request processor 350. Thus, the application will be executed on a real computer system, but all application commands will be intercepted, processed and written to the log for subsequent analysis. Emulation in this case consists in replacing the results of some queries, for example, the results of calls to API functions of the operating system.

Figure 4 displays a block diagram of the algorithm of the emulator 200 to determine the complete list of system errors that may occur during execution of the application code under various conditions and configurations of the computer system. The start of the emulation of the program 400 can be triggered by a series of events (depending on the interpretation), among which the launch of the application for execution; transferring the application (files or application process) for analysis to the emulator; saving in the computer memory an application that has not previously been analyzed and other system events. Interception of events that serve as the beginning of application emulation can be implemented, for example, by introducing a special driver that processes calls to the operating system. After the code, application resources and necessary libraries are loaded into the emulator, the application starts to run in an emulated environment, where each instruction is processed 405 in the emulator by the request processor 350 and stored 420 in the logging module 360.

Consider a system implementation in which a call to an API function acts as a conditional branch. When intercepting the next API function in chronological order, the emulator returns to the application a knowingly false value of 410, after which the program continues to run until an error occurs (return of the specific error code 415). The emulator in each cycle sequentially returns different error codes depending on the specification of the function being called. The error code and the program execution log are saved 420, and the emulation proceeds to the next cycle, in which the whole process is repeated, but a false value is returned only from the next API function 430. The number of cycles corresponds to the number of functions being called, taking into account the fact that each function can return several various error codes. The loop exits when all 425 function calls have been processed. As a result of these manipulations, records are generated in the log about error codes and function calls whose values have been changed. Returning a false result of the function means failure to execute one of the program commands, which leads to an error in the program operation, which is determined by the value of the error code. The function, the call of which led to the formation of the error, is interpreted as the cause of its occurrence. The obtained results constitute expert data giving an idea of the errors and the causes of the indicated errors 435. Next, instructions 440 are determined - actions aimed at processing the error. For example, if the cause of the failure was an attempt to read the file, you need to check its presence and configure access rights differentiation.

There is a set of functions, enumeration and analysis of which will not yield results. To speed up the study of the program, these functions are skipped, thereby reducing the number of emulation cycles. The list of functions that do not carry a semantic load for identifying the causes of errors is entered in a special list, which can be further supplemented and modified. Consider an example of application tracing in which many functions will not affect the error code returned. The CreateFileW function did not access the ebO.tmp file, for example, because the file is being used. After that, several function calls and the final call to ExitProcess with a return code of 0 × 401 were made. The call log contains a sequence of called functions and their results, following the functions whose return values have been changed, and is shown below:

Such an approach can optimize the analysis of functions and further reduce the time to identify possible errors.

For each error, it is necessary to generate a description, which in a particular case may consist of the conditions for the occurrence of the error, the causes and methods of its elimination. After the expert database is supplemented with error handling instructions and descriptions, the process of emulation and analysis of the software is completed.

The following describes in more detail the device of the main components of a computer system that participate in the execution of the program code and are part of the emulator 200.

Consider the processor 300 using the architecture of × 86. Each architecture is characterized by a set of processor instructions, a memory operation scheme, an instruction decoding table, etc. In addition to the main set of instructions, that is, instructions with which you can execute any program, processors of the × 86 family have extensions in the form of special capabilities implemented by the manufacturer. Such extensions, as a rule, include instructions for optimizing the execution of instructions, the use of special modes for executing instructions, and others.

The main elements of the processor are executing devices 302, which directly execute all instructions. Two main groups can be distinguished among them: arithmetic logic units (ALUs) and a floating-point unit (FPU).

In modern processors, thread instructions are different from operations that implement runtime devices. This is done to simplify the operation of executing devices and increase the speed of the processor. A decoder 301 is used to convert × 86 compatible code into an internal instruction system of executing devices.

The development of processor technology has led to the emergence of a cache that accelerates the execution of programs. The cache is a temporary memory, access to which is an order of magnitude faster than reading data from RAM (random access memory). When a thread begins to execute, resources loaded from the process are stored in the cache, overwriting obsolete data in it. Further, before downloading data from RAM, the processor checks its presence in the cache, thereby saving time on program execution. Modern processors support multilevel caching, sharing the data cache, instruction cache, mixed cache, etc.

The fastest memory is registers 303, which are located directly in the processor core. An example 32-bit processor contains eight general-purpose registers that can be used to store data and addresses, six segment registers, status and control registers, and special registers.

The processor can work in several modes. The main ones are real and protected modes. Switching between modes occurs programmatically. The processor in real mode is characterized by the execution of 16-bit instructions, 20-bit addressing and the vulnerability of the address space of one program from another. Modern multi-tasking operating systems use protected mode. The new memory addressing method allows you to isolate the address spaces of individual tasks from each other. At the same time, an application program running in an operating system environment that uses protected mode cannot accidentally or intentionally destroy the integrity of the operating system itself. In protected mode, the program can only write data to those areas of memory that are allocated to it by the operating system. This increases the reliability of multitasking and, in particular, multi-user operating systems. It is in protected mode that page memory management is possible, which allows you to place part of the RAM on disk. Page organization of memory is a simple scheme for increasing efficiency, according to which memory is divided into pages from 512 bytes to several kilobytes. An appropriate call pattern allows you to reduce the number of wait states within a page.

All process threads run in a single address space allocated when the process is created. On 32-bit systems, the amount of memory available to each process is 4 GB. The upper half of this space is reserved for the operating system, and the second half is available to user applications.

The virtual memory mechanism allows isolating processes from each other. Threads from one process cannot reference the address space of another process. Virtual memory 130 may not correspond at all to the structure of physical memory 120. The memory manager translates virtual addresses to physical addresses that actually store data. Since not every computer is able to allocate 4 GB of physical memory for each process, the swapping mechanism is used. When there is not enough RAM,

the operating system moves part of the contents of the memory to disk, to a file (swap file or page file), thereby freeing up physical memory for other processes. When a thread accesses a virtual memory page written to disk, the virtual memory manager loads this information from disk back into memory. The device of the random access memory from the point of view of streams is not distinguishable - it is enough to implement the address space, the functions of input and output of information.

To emulate processes, it is often necessary to emulate the file system, especially in cases where it is necessary to secure data on the disk or when access to files is limited. A file system is a way of organizing, storing and naming data on storage media. Operating with data objects in the form of files, the operating system uses the file system to place files on the disk and access them, as well as to determine file attributes, access control, etc. From an OS point of view, the entire disk is a collection of clusters. File system drivers organize clusters into files and directories. When the application accesses the file, the file system determines the clusters in which the file is stored and sends a request to read these sectors to the disk driver.

In cases where the program interacts with a data network or external devices (printer, input-output devices), to emulate its operation, it is necessary to implement the functions of these devices. It is necessary, at least, to process commands addressed to devices and emulate their response.

After loading the executable file or processing the code by the interpreter, machine-readable code is written into the process memory. For example, consider several commands in assembly language, which is as close as possible to the description of operations on the processor. Instructions are divided into arithmetic, logical, transition, interrupt and data transfer commands. To process each command, the emulator needs to reproduce the processor, i.e. execute this command in an emulated environment.

For example, a MOV copy command with two parameters Dest (destination address) and Source (copy source) is implemented by one internal Dest: = Source operation (for the processor family × 86). There are commands that are executed in several operations. For example, an Exchange exchange command that changes values stored at two addresses is implemented by two operations Op1: = Op2, Op2: = Op1.

In one embodiment of an emulator for a program executed in a computer system, each of the emulated modules of the system can be an object class: a register class, a memory class, a processor class, etc., in which class methods recreate real operations. In the case of the processor, class methods will be a set of executable instructions and internal commands, and in the case of memory, write, read. Most arithmetic operations and operations for working with addresses are available in programming languages and are not difficult to reproduce. The remaining commands can be implemented using separate functions. At the same time, it is possible to implement such an emulator in the form of a microprocessor or microcircuit.

In modern operating systems, almost all interaction of an application with devices and services of a computer system, for example, opening a file or loading a web page, is carried out through the API functions (Application Programming Interface). The sequence of called functions makes up the application behavior pattern, allows you to determine the nature of the application and in some cases identify the code.

For the analysis of program fault tolerance, the definition of API functions called by the installer or the application itself at the initial stage of work is also essential. Typically, function calls are part of a system check for compliance with a specific condition.

A table of plug-in libraries and function call addresses is contained in an executable file. When the program is loaded into the emulator, addresses are replaced with the address of the emulator handler. During the emulation of the program code, a log of operations and calls is kept. From this log, you can determine the called functions and operations that preceded and followed each of the calls. In particular, it is possible to determine error return codes, exceptions that arise.

Consider an example of a program trace in which the emulation log is the following list:

The list contains function calls with specific parameters. The main task is to determine the behavior of the application if a function call leads to an error. To do this, an error code is returned to the application for each API function instead of the expected value. In one embodiment, the error is returned sequentially and alternately for each function. For example, on the first launch, the application will be tricked and the call to the GetProcAddress function will return 0 even if in the real system the call to the function would return a different value (0x1a494bbe) corresponding to successful execution. On the second start, calling the URLDownloadToFileA function will return not 0 (0xFFFFFFFF), on the third start, Sleep will return not 0, on the fourth start, DeleteFileA will return false, and so on.

Each time the application starts, it will continue to be emulated to the end, given that the function call returns an intentionally changed value, and continues to keep the emulation log. A non-zero return code will indicate certain conditions that must be considered when starting and installing the application. For example, the lack of the URLDownloadToFileA function in the library results in error code 3333; the inability to connect to the URL link on the Internet leads to error code 3334; the inability of the system to enter Sleep mode terminates the application; failure to delete the file leads to error code 7777, etc.

To verify the results in the form of cause-and-effect chains, where the interpretation of the error of the function call is the cause, and the return code or its interpretation is the consequence, you can test the application in real conditions. In this case, it is necessary to change the system configuration or run the application in the environment in which one of the conditions will not be fulfilled intentionally. In the event that the return code matches the result of the emulation, a causal relationship is confirmed. For example, if an attempt to launch the application under investigation in a system disconnected from the Internet results in the return code “3334”, then we can confidently say that the cause of the error identified during the emulation is correct. When conducting the verification, it is important to take into account the fact that all other conditions of the program’s operability must be satisfied, otherwise the program may stop executing before processing the condition being checked and return another return code.

The proposed method for analyzing and processing system errors during software operation is most effective for use in computer networks. One of the possible ways to implement the automatic processing of system errors can be the implementation of a system for emulating and processing errors in a centralized service for installing and managing personal computer software.

5 shows a functional diagram of an embodiment of a system for automatically processing system errors. The system consists of an administration server 500 and administration agents 530 distributed over the FAC. Administration agents 530 installed on personal computers 510, mobile devices, and other elements of the PIC connected to the administration server 500 are designed to collect information about the execution of program instructions, system setup, and processing of system events, including errors. The agents are monitored by the installation management module 520 installed on the administration server 500, which generates tasks for installing 523 new software, analyzes errors that may occur during installation, and stores expert data necessary for making decisions during error handling and tuning computer systems.

Functional blocks can be distinguished as part of the agent and the installation control module, which in various implementations are special software modules or microcircuits.

Updating existing applications and installing new software are some of the key tasks of the network administrator, who creates a list of installation tasks 523. The installation list of new software components can be generated either manually or automatically, for example, adding new tasks when receiving information about updates and new software versions.

After the task is formed, it is necessary to install the program on the corresponding devices 510 KBC transparently for their users. The principle of transparency is that for the successful installation and the correct operation of the program, the user does not need to perform any actions, including installing additional devices, connections, drivers and services, configure system components and take other actions in case of a system error.

To comply with this principle, you must have an idea of all possible errors and process them automatically. The analysis is performed using a file (or several files) containing the program code. This can be a file with source code, an executable file, a file in a special format, according to which you can reproduce the program or at least the logic of the program. The analysis consists in emulating certain conditions when executing the code of a given file or group of files, as described previously. The analysis tool in the control module is shown in the figure as an emulator block 522.

The results obtained in the form of an error tree for each installer, indicating the reasons for the error and options for eliminating it, are stored in the 521 expert database and are used to configure systems, display help for errors that have occurred, and test compatibility programs.

To determine the ways of eliminating system errors, an expert system 524 is used as an example in the described implementation method, which is based on the rules for the correspondence of application instructions and script commands that lead to error correction, description and error circumvention. The rules are causal in nature. In the case of an analysis of installers, the number of errors has a limited set, in which for each error a separate rule for solving it can be established. A rule can be associated with a specific API function, the call of which leads to an error. A rule can also be created for the application as a whole. For example, if an error occurs due to lack of access to the file, the rule will map the error to a solution that will change the file attributes and the application’s data access rights setting.

Having received the task for installing the software, the 530 administration agent downloads the 531 software installer (installer) and the associated expert data, which may contain recommendations for changing the system configuration and additional software packages, without which the installation task will be completed with errors or incorrectly. Configuring the computer system and all its components is performed by the configurator 533. In some implementations, the configurator and installer of software 531 are embedded services of the operating system.

The user can perform the installation on their own by downloading the installer and sending it for execution. In this case, as well as if recommendations on changing the system configuration were not accepted, errors may occur during the installation of the program and during its operation, which is difficult to process without contacting the support service. The solution to this problem without the use of the described technology is completely dependent on external factors. To correct this situation, the automatic error handling system provides an error handler 532 on the side of the personal device 510, which intercepts the error code, contacts the expert database 521 for help, and performs the actions defined therein to prevent error repetition.

The 521 expert database is replenished based on the results of program analysis. Moreover, the database 521 can be stored on the server 500 in the local network, on a personal device 510, or on the remote server 540, which is accessed through the global Internet. This database partitioning scheme is most optimal when the analysis of the software is performed distributed. In the event that the solution for the error that is missing is not in the local database, the request is sent to the upstream administration server. The central service for replenishment and storage, as well as synchronization of expert data, is a program research laboratory. In another implementation example, updating and synchronizing data can be decentralized, for example, using P2P networks.

Figure 6 shows the algorithm of the system for automatic processing of system errors with an indication of the steps, each of which can be performed on the administration server 500 and on the personal device KVS 510. The process of automatically installing new or updating existing software starts by downloading new software 600 (installers, packed files source files). This software must be tested for compatibility with the runtime environment in which it is planned to install the software. To do this, at step 605, the installation process is emulated. By means of the emulator, the corresponding environment is reproduced: processor, memory, OS, file system and more. The lack of granularity of the emulator can be compensated by redirecting requests to real objects of the system. For example, part of the program instructions can be executed on a real processor, an API function call can be addressed to a real OS, and a request to a web server can be sent via a connected data network. The next step is to build the error tree 610, which reflects the causal relationship of the return value of the error and the conditions of its occurrence, fixed by the emulator in the logging module. For each error, a set of instructions (script) is created to correct this error.

Record of the obtained results in an ordered form in the expert database is carried out at step 615. Subsequently, this database may also contain information about the effectiveness of the applied rules and the accuracy of the error description. Next, a task is formed to install new software 620, after which the action goes to the personal device. The task for installing the new 625 software contains the installer and / or a link to it and instructions for bringing the system configuration to the required state, which are added to the task from the expert database. Having received a new task 625, the administration agent 530 installs additional software modules, configures programs and devices in accordance with the recommendations contained in the task. The configuration of the user's computer to prevent the occurrence of system errors is performed at step 630. This step may be preceded by an additional step of testing the computer system to determine the points of discrepancy between the current configuration of the personal device and the technical requirements for the correct installation and operation of the software.

The next stage of the installation of new software is stage 635, where the operations of the installer are performed: unpacking, copying and creating files, editing the system registry, registering on a remote server and others. During the execution of this process, errors or exceptions may occur that need to be processed 645 automatically. Errors are tracked at block 640. The system event characterizing the error is intercepted and analyzed, the error code and the conditions under which it occurred are determined. Based on these data, the search for related information in the expert database is performed. Error processing 645 involves the execution of a processing script to correct it, notifying the user and / or administrator about the error with a full description of the causes and methods of error correction. Optionally, error handling allows you to refine expert data, supplementing the list of system conditions that lead to these errors, and adjust instructions for correcting them. The installation process ends 650 when all errors that have occurred are processed and the software is correctly installed on the personal device.

The following describes an example of a computer system, the architecture of which is the basis of the administration server, personal device and computer system, the elements of which are reproduced by the emulator.

7 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented like any bus structure known in the art, which in turn contains a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26, contains basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating ROM systems 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 through an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment, using a network connection with another one or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description creatures of the personal computer 20 of FIG. 7. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in FAC, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In accordance with the description, components, execution steps, data structure described above can be performed using various types of operating systems, computer platforms, programs.

In conclusion, it should be noted that the information provided in the description are only examples that do not limit the scope of the present invention defined by the claims.

Claims (14)

1. A method for automatically processing software errors, consisting of the stages in which:
- run the software application for execution in a computer system emulator;
- emulate at least one state of the computer system in order to cause at least one error in the execution of the application;
- determine at least one error in accordance with the conditions that served as the reason for the occurrence of this error;
- form at least one error processing scenario;
- update the expert data with information containing the identifier of the error mentioned, the conditions for its occurrence, and at least one error processing scenario;
- run the application on a computer system;
- when an error occurs, download and execute the script for processing the error that occurred. 2. The method according to claim 1, further comprising the step of changing the state of the system before starting the application on the computer system in order to prevent an error from occurring. 3. The method according to claim 1, in which the state of the computer system is determined by the settings of the computer system, a list of installed software, a list of computer system devices, data loaded into the memory, and connections to the data network. 4. The method of claim 1, wherein the software application is a software installer. 5. The method according to claim 1, in which the emulator reproduces the functions of at least the processor and memory of the computer system. 6. The method according to claim 1, in which at the stage of emulating the state of the computer system, at least one return value of the API function of the operating system is changed. 7. The method according to claim 1, in which an error occurs when an exception is thrown, an error code is returned, an error variable is assigned a value, and an error is detected by the system event handler. 8. The method according to claim 1, in which the error processing scenario consists of a sequence of commands that allow you to configure a computer system to eliminate the occurrence of an error. 9. The method according to claim 1, in which the error processing scenario consists of a sequence of commands allowing to transfer information about the error to the administration server. 10. A system for automatically processing software errors, consisting of:
- an emulator designed for:
- reproducing the state of the computer system in order to cause an error;
- execution of the software application in the reproduced state of the computer system;
- determination of at least one error in accordance with the conditions that caused this error to occur during the execution of the software application;
- expert system associated with the emulator and designed for:
- compiling at least one error processing scenario defined by the emulator, depending on the conditions that caused this error to occur;
- updating the expert database with information containing the identifier of the mentioned error, the conditions for its occurrence and at least one error processing scenario;
- expert database related to the expert system and intended for:
- storing error identifiers, error conditions, and error processing scenarios for the corresponding application;
- an error handler associated with an expert database intended for:
- determining the occurrence of an error when executing a software application on a computer system;
- loading the error processing script appropriate for the given error from the expert database;
- execution of the script for processing the corresponding error. 11. The system of claim 10, wherein the software application is a software installer. 12. The system of claim 10, in which the error handler is additionally designed to change the state of the computer system before starting the execution of the software application in order to prevent the occurrence of errors. 13. The system of claim 10, in which the state of the computer system is determined by the settings of the computer system, a list of installed software, a list of computer system devices, data loaded into the memory, and connections to the data network. 14. The system of claim 10, in which the emulator reproduces the functions of at least the processor and memory of the computer system.

Images