RU2739867C1 - Method of determining application module associated with cause of problem encountered during operation of application - Google Patents

Abstract

FIELD: computer equipment.

SUBSTANCE: invention relates to computer engineering. Disclosed is a method of determining an application module associated with a cause of a problem encountered during operation of an application, implemented by a computer, wherein: a) disabling at least one application module in accordance with a diagnosis rule for said problem; b) checking the troubleshooting due to disconnection of at least one application module; and c) in case of troubleshooting, determining at least one said application module as related to the cause of the fault.

EFFECT: technical result is enabling determination of an application module associated with a cause of a problem encountered during operation of the application.

16 cl, 5 dwg, 1 tbl

Description

Technology area

The invention relates to the field of information security, and more specifically to methods for determining the application module associated with the cause of the problem that occurred during the operation of the application.

State of the art

Modern computer applications (software, software) are technically complex and therefore may inevitably contain software errors. Software errors can affect both the functionality of the application itself and the functionality of third-party software, operating system (OS), and various OS services. And when the application interacts with third-party software or OS, due to a software error of third-party software or OS, computer malfunctions may occur. For example, if an application uses an OS driver that contains a software error, a problem may occur, such as restarting the computer, disabling the specified driver, or other problem. However, even due to an error in the OS, in order to resume the correct operation of the application, it will often be faster to change or disable the functionality of the application using the OS error than to wait for the OS update, which will fix the specified error. A lot of modern software uses a modular architecture. That is, it contains many independent modules (components, drivers, plugins), each of which is responsible for a specific software functionality. Therefore, in case of problems related to the operation of the application (both due to software errors in the application itself, and due to software errors in third-party software and OS), system administrators usually manually search for the application module associated with the problem. After that, the found module is turned off until the true cause of the problem is found and fixed. Therefore, a technical problem arises in that it is difficult to determine the application module associated with the cause of the problem that occurred during the application.

Various methods of searching for errors in applications are known from the prior art, in particular, US Pat. No. 9,442,832 describes a method for detecting errors in an application by simulating user actions that caused the error. Application US 20190129824 describes a module that collects information about user actions in an application. Upon receipt of information about an error, the module transmits to the support service records of user actions and information from the device to further determine the causes of the error.

However, the technologies known from the prior art do not solve the claimed technical problem, therefore, there is a need for a method for determining the application module associated with the cause of the problem that occurred during the operation of the application.

Disclosure of the essence of the invention

The technical result consists in the implementation of the purpose.

According to an embodiment, a computer-implemented method for determining an application module associated with the cause of a problem that occurs during the operation of an application is used, in which: at least one application module is disabled in accordance with a diagnostic rule for said problem; checking the elimination of the problem due to the disconnection of at least one application module; and if the problem is corrected, at least one said application module is determined as associated with the cause of the problem.

In one implementation, the diagnostic rule determines the order in which application modules are disabled to test that the problem has been resolved.

In another implementation, the diagnostic rule further defines the order in which application modules are enabled to test for a problem.

In another embodiment, the order in which the application modules are disabled depends on the frequency of the problem due to the corresponding application module.

According to one of the embodiments, if at least two application modules were disabled, after which the problem was eliminated, the mentioned application modules are turned on and the previous steps are repeated, alternately disabling each of the mentioned application modules in accordance with the diagnostic rule, while if after disabling each of of the mentioned application modules in accordance with the diagnostic rule, the problem was not resolved, identify the mentioned at least two application modules as related to the cause of the problem.

According to another embodiment, if the problem persists, the previous steps are repeated taking into account the diagnostic rule and the results of the performed check until one of the following conditions occurs: elimination of the problem; the failure to resolve the problem after disabling the application modules in accordance with the diagnostic rule, while determining the absence of application modules associated with the cause of the problem.

In another embodiment, at least one previously disabled application module is turned on before repeating the previous steps.

In one implementation, the troubleshooting check includes a trace of application activity in the trace log and, if at least one application module is identified as associated with the cause of the problem, the log is used to determine at least one said application module as related. with the cause of the problem, and if it is impossible to eliminate the problem, transfer said trace log to the remote server to determine at least one said application module as associated with the cause of the problem.

According to another embodiment, the diagnostic rule determines the need to restart the application or restart the operating system (hereinafter referred to as OS) after disabling at least one specific application module, while the application or OS is rebooted after the said application module is disabled.

In another embodiment, the type of problem is, in particular, one of: abnormal termination of the operating system; unloading the application process from memory; freezing of the application; freezing of the operating system; increased load on the processor compared to the typical load on the processor during the operation of the said module; a decrease in productivity compared to the typical value of productivity during the operation of the said module; excessive use of resources; decrease in the speed of network traffic; network unavailability; the presence of a program error in the code of the module of the mentioned application; the presence of a software error in the code of at least one third-party application installed on the computer; the presence of a software error in the operating system; providing unauthorized access; a known vulnerability.

One implementation verifies the problem by replaying user actions on the computer and the state of the computer prior to the problem, and then verifying that the problem occurred.

In another embodiment, the application module is, in particular, one of: an application component, a driver, a library.

According to another embodiment, when certain modules are disabled, the user is asked to confirm the disconnection of said modules.

In one embodiment, the diagnostic rules are updated using a remote server.

According to another implementation, each diagnostic rule has a weight that determines how the diagnostic rule is applied for a given problem type, if more than one diagnostic rule is defined for this problem type.

In another embodiment, the diagnostic rule depends, in part, on one of: the version of the application; versions of the modules of the mentioned application; OS version; installed third-party applications; installed computer hardware; installed drivers.

Brief Description of Drawings

Additional objects, features and advantages of the present invention will become apparent from a reading of the following description of an embodiment of the invention with reference to the accompanying drawings, in which: FIG. 1 shows an example of an operating system (OS) architecture.

FIG. 2 shows a possible set of application modules using the example of an anti-virus application.

FIG. 3 shows a method for identifying the application module associated with the cause of an application problem.

FIG. 4 shows an example of the implementation of a method for troubleshooting a problem that occurred during the operation of the application.

FIG. 5 presents an example of a general purpose computer system

Implementation of the invention

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, but may be embodied in various forms. The foregoing description is intended to assist a person skilled in the art for a comprehensive understanding of the invention, which is defined only within the scope of the appended claims.

FIG. 1 shows an example of an operating system (OS) architecture. After loading the operating system installed on the user's computer 100, the computer's processor can operate in user mode or in kernel mode. In user mode, applications only have access to their virtual address space and do not have access to the address space of other applications or the address space reserved by the OS. In this mode, applications 110 and user-mode drivers 130 operate. Applications that run in kernel mode share a common address space. Kernel mode is used by kernel mode 140 drivers, operating system kernel 160 and, accordingly, driver support routines 150.

Applications 110, as well as user-mode drivers 130, interact with the kernel of the operating system 160 through an application program interface (API) 120. Kernel-mode drivers 140 are used to communicate between the OS kernel 160 and the user-mode drivers 130 with the hardware 180 through the Hardware Abstraction Layer (HAL) 170. In addition, kernel mode drivers 140 may include filter drivers that extend or modify device behavior. The invention disclosed in this application serves to define the application module 111 associated with the cause of the problem that occurred during the operation of application 111. To be specific, applications 112-113 will be referred to as third-party applications 112-113 with respect to application 111. Application 111 can be anything software installed on the user's computer 100, in particular, an anti-virus application. Further, for the sake of clarity, application 111 will be considered on the example of an antivirus application.

Application 111 contains modules of certain functionality. Such modules may include some of the user-mode drivers 130 and the kernel-mode drivers 140 required to execute the functionality of the application. A feature of most modern applications, in particular antivirus applications, is the presence of a large number of modules, such as a file scanner, emulator, firewall, various drivers, for example, filter drivers and other modules (application modules are described in more detail in Fig. 2). Thus, during the operation of the application 111, various problems may occur (increased load on the processor compared to the normal load on the processor during the operation of the said module, decreased performance, freeze of the OS, etc.). Such problems can be caused by software errors in one of the modules of application 111. Also, problems can be caused by the incompatibility of one of the modules of application 111 with third-party applications 112-113 due to software errors in third-party applications 112-113. In another example, problems can be caused by the incompatibility of one of the application modules with the OS 160 or the user-mode drivers 130 or the kernel-mode drivers 140. For example, if the application module 111 accesses a function of the kernel-mode driver 140, and there is an error in said driver, then a problem such as restarting the computer may occur. To solve the claimed technical problem and achieve a technical result, a method is used to determine the application module associated with the cause of the problem that occurred during the operation of the application, implemented by the computer, namely by the diagnostic tool 115. The diagnostic tool 115 is one of the applications 110. In a particular implementation example, the diagnostic tool 115 is an application module 111. In another particular implementation, diagnostic tool 115 is a separate application.

FIG. 2 shows a possible set of modules for application 111 using an antivirus application as an example. An antivirus application can contain modules designed to ensure computer security: file scanner, mail antivirus, web antivirus, proactive protection module, HIPS module (Host Intrusion Prevention System), DLP module (data loss prevention - data leakage prevention), a vulnerability scanner, an emulator, a firewall, etc. In a particular implementation example, these modules can be part of an anti-virus application. In yet another embodiment, these modules may be implemented as separate software components.

The file scanner contains functionality for detecting malicious file activity on the user's computer system. The file scanner can operate in various modes, for example, in the on-access scanner or on-demand scanner. On-access file scanning mode scans opened, launched and saved files. On-demand file scan mode scans user-specified files and directories at the user's request.

Mail antivirus is required to monitor incoming and outgoing e-mail for malicious objects. Web antivirus is used to prevent the execution of malicious code that may be contained on websites when the user visits them, as well as to block the opening of websites. The HIPS module is used to detect unwanted and malicious program activity and block it at the time of execution. DLP module is used to detect and prevent leakage of confidential data outside the computer or network. Vulnerability Scanner is required to detect vulnerabilities on a computer (for example, some protection components are disabled, outdated virus databases, a network port is closed, etc.). Firewall monitors and filters network traffic in accordance with the specified rules. The emulator's job is to simulate the guest system while executing code in the emulator. The proactive defense module uses behavioral signatures to detect the behavior of executable files and classify them by trust level. The self-defense module is used to prevent unauthorized shutdown of the anti-virus application and other attempts to disrupt its normal operation.

FIG. 3 shows a method for determining an application module associated with the cause of an application problem, implemented by a computer, namely diagnostic tool 115. At step 301, diagnostic tool 115 obtains information about the problem that occurred during application operation. Such information about the problem may include, in particular, the fact that there is a problem, the type of problem. Information about the problem can be obtained, for example, from the computer user or from one of the modules of application 111 that recorded the problem, as well as from the OS (for example, from memory dumps or from a critical error in the OS kernel). The application module 111 can determine if there is a problem and the corresponding type of problem, for example, if the specified module has abnormally terminated or if the resources of the application 111 or the OS become unavailable.

Then, at step 302, at least one application module is disabled in accordance with a diagnostic rule for this type of problem. Next, at step 303, troubleshooting due to disconnection of at least one application module is checked. And, if the problem is resolved (step 304), at step 305, at least one application module is determined as associated with the cause of the problem. At the same time, in one implementation example, if the problem persists (step 306), steps 302-304 are repeated taking into account the diagnostic rule and the results of the check at step 303, until one of the conditions occurs: the problem is resolved or the problem cannot be rectified after the application modules are disabled in accordance with with a diagnostic rule, while determining that there are no application modules associated with the cause of the problem (step 307). In yet another particular embodiment, before repeating steps 302-304, at least one previously disabled module is turned on. In this case, if there are no application modules associated with the cause of the problem, the previously disabled application modules 111 will be re-enabled for the correct operation of application 111.

In one particular implementation, during a troubleshooting test at step 303, diagnostic tool 115 may prompt the user to reproduce steps prior to the problem occurring. After that, the user will inform about the elimination of the problem or the persistence of the problem. In another particular implementation, the diagnostic tool 115 can independently reproduce the steps prior to the problem and see if the problem is resolved. For example, if the problem was OS resources being unavailable, then after repeating the above steps, diagnostic tool 115 will check to see if OS resources are available.

In a particular implementation, after disabling at least one application module, the diagnostic tool 115 can restart the application 111. In another particular implementation, after disabling at least one application module, the diagnostic tool 115 can restart the OS 160. For example, if the driver was disabled, for completely disabling said driver will require a reboot of OS 160.

In a particular implementation example, the diagnostic rule determines the order in which the application modules 111 are disabled (or enabled) to verify that the problem is resolved. In yet another particular implementation, the order in which the application modules are disabled depends on the frequency of the problem due to the corresponding application module.

In another particular embodiment, if at step 302 at least two application modules have been disabled and the problem has been resolved, steps 302-304 are repeated, alternately disabling each of said application modules in accordance with a diagnostic rule. In this case, if, after disconnecting each of the mentioned application modules in accordance with the diagnostic rule, the problem has not been eliminated, the mentioned at least two application modules are determined as related to the cause of the problem. This corresponds to step 304a.

In a particular implementation example, after troubleshooting the problem, change the order in which application modules are disabled in the diagnostic rule in such a way as to reduce the time it takes to detect the problem. For this, for example, data on the results of the problem detection from various user computers can be collected on a remote server according to the method of FIG. 3. Such information may include, but is not limited to: the type of problem; time from the moment information about the problem is received until the problem is resolved; Diagnostic rules used to troubleshoot the problem the number of repetitions of the method (according to the order of disconnecting application modules), after which the problem was resolved. After analyzing the information received, the diagnostic rules can be changed to reduce the time it takes to detect a problem. In particular, if a diagnostic rule was not used to troubleshoot a particular type of problem, the weight of the said diagnostic rule may be reduced or the diagnostic rule may be deleted. Conversely, if for a particular type of problem, a rule with a lower weight was more likely to fix the problem than a rule with a higher weight, then the weights of the rules can be adjusted in proportion to the frequency with which they were used to solve the problem.

In another example, if a diagnostic rule contains a module that has not been identified as associated with the cause of the problem on any of the user's computers, the module can be excluded from the diagnostic rule. This will reduce the number of modules to be disabled according to the diagnostic rule and reduce the time it takes to detect a problem.

In another example implementation, machine learning algorithms can be used to train on the data on the results of the detection of the problems listed above to change the diagnostic rules in order to reduce the time to detect a problem.

Possible diagnostic rules for application 111 using an anti-virus application as an example (see Fig. 2) are presented in Table 1. Thus, when the network traffic decreases, according to rule 1 from Table 1, at step 302, the self-defense module is disabled first. Then, after step 303 is performed, step 304 checks the troubleshooting. And if the problem is not resolved, steps 302-303 are repeated for the firewall. Similarly, if the problem persists, steps 302-303 are repeated for the vulnerability scanner. Because Vulnerability Scanner is the last module in Rule 1, then if the problem persists after disabling the vulnerability scanner, at step 307 it is determined that there are no application modules associated with the cause of the problem. That is, the cause of the problem is not in application 111 or in modules in application 111.

Rule 2 is also used to identify a low traffic problem. Rule 2 corresponds to step 304a. Rule 2 first disables the entire application 111 (that is, all application modules) to determine if the problem is with application 111. Then, the module or multiple modules associated with the problem are localized. Thus, the application 111 is then resumed, after which the firewall is turned off and, if this does not fix the problem, the web antivirus is turned off.

However, if disabling Web Antivirus did not resolve the problem, the entire application 111 is identified as related to the problem. Rule 3 in Table 1 can be applied when the type of problem is the unavailability of third-party application resources, for example, if the mail client does not send or receive mail. In this case, mail antivirus will be disabled.

In a particular example of implementation, the diagnostic rules additionally depend, in particular, on one of:

a) application version;

b) versions of the modules of the mentioned application;

c) OS version;

d) installed third-party applications;

e) installed computer hardware;

f) installed drivers.

In one particular implementation example, during a troubleshooting check, a trace of application operation is included in the trace log and, in the event that at least one application module is identified as associated with the cause of the problem, the log is used to determine at least one object of said application module as related to the cause of the problem. And if it is impossible to eliminate the problem, the mentioned trace log is transmitted to a remote server (not indicated in the figures) to determine at least one object of the mentioned application module as associated with the cause of the problem. In this case, the execution trace contains a continuous sequence of instructions executed on the processor and snapshots of the internal state of the processor during the execution of each instruction of the process called from application 111.

In another particular example of implementation, the diagnostic rule determines the need to restart the application or reboot the operating system (hereinafter referred to as the OS) after disabling at least one specific application module, while the application is restarted or, accordingly, the OS is rebooted after the said application module is disabled.

In a private example of implementation, a problem with the application, in particular, affected the mentioned application or third-party application. In addition, the problem can affect operating system services, network connection, or file system.

In this case, the type of problem is, in particular, one of:

a) emergency shutdown of the operating system;

b) unloading the application process from memory;

c) freezing of the application;

d) freezing of the operating system;

e) increased load on the processor compared to the typical load on the processor during the operation of the said module;

f) a decrease in performance compared to the typical value of performance during the operation of the said module;

g) excessive use of resources;

h) reducing the speed of network traffic;

i) network unavailability;

j) the presence of a software error in the code of the module of the mentioned application;

k) the presence of a software error in the code of at least one third-party application installed on the computer;

l) the presence of a software error in the operating system;

m) providing unauthorized access; o) the presence of a known vulnerability.

It should be noted that this list of problems is not complete and may include other types of problems. For example, a problem may arise when application 111 hangs, after which one or more third-party applications 112-113 hang along the chain, waiting for data from the first application. At the same time, using the claimed invention, it will be possible to determine the application module or modules that cause the mentioned problem, after the disconnection of which, the operability of the application 111 and applications 112-113 will be restored.

Another particular example of an implementation tests the problem by replaying user actions on the computer and the state of the computer prior to the occurrence of the problem, and then checking the problem. In another particular example of implementation, the application module is, in particular, one of: an application component, a driver, a library (dynamic or static).

In one of the private examples of implementation, when certain modules are disabled, the user is asked to confirm the disconnection of said modules. A confirmation request may consist in the need to enter a password, enter a captcha (English from CAPTSNA - English Completely Automated Public Turing test to tell Computers and Humans Apart - a fully automated public Turing test to distinguish between computers and people), press the confirmation button, send a confirmation command etc.

In another particular implementation, the diagnostic rules are updated using a remote server.

In another particular example of implementation, each diagnostic rule has a weight that determines the order in which the diagnostic rule is applied for a given type of problem, if more than one diagnostic rule is specified for this type of problem.

FIG. 4 shows an example of the implementation of a method for troubleshooting a problem that occurred during the operation of the application. After troubleshooting the problem (step 304), it is tested if it is possible to disable fewer application modules (step 304a). This is necessary to more accurately determine which application module is associated with the cause of the problem in the event that two or more application modules were disabled in step 302. If the answer is yes, at step 401, at least one application module from the disabled application modules is turned on in accordance with the diagnostic rule for the mentioned problem. Then, at step 402, it is verified that the problem persists due to the inclusion of at least one application module.

If the problem persists, at least one said application module is determined as associated with the cause of the problem (step 305). And if the problem is resolved, repeat steps 401-402 for at least one other application module from among the disabled application modules.

In a particular example of implementation, if after disconnecting at least two application modules, the problem is eliminated (step 403), then at least one application module is turned on from among those disabled in accordance with the diagnostic rule for the mentioned problem and the problem persistence is checked. In this case, if, after turning on at least two application modules, the previously resolved problem is reproduced (step 402), then at least one application module is turned off from among those included in accordance with the diagnostic rule for the mentioned problem and the troubleshooting is checked (steps 403, 302 , 303). This is necessary to more accurately determine which application module is associated with the cause of the problem if two or more application modules were included in step 401.

Finally, at step 404, the problem is resolved by disabling at least one application module that has been determined to be associated with the cause of the problem. Thus, following the above steps of the method will allow you to more accurately identify those modules that are associated with the cause of the problem and disable them, without disabling other modules not related to the cause of the problem.

A possible example of the operation of the method of FIG. 4 is reflected in rule 4 of table 1. In this case, if the resources of a third-party application are unavailable, the entire application is first disabled, then all application modules are turned on except for the mail antivirus and the problem is checked. It is also obvious that when using rule 3 with the method of FIG. 3 and rule 4 using the method of FIG. 4 will achieve the same result.

In a particular implementation example, if the problem is eliminated due to the inclusion of at least one application module, steps 303-304a, 401 are repeated for at least one other application module from among the disabled application modules, taking into account the diagnostic rule and the results of the check performed, while in if the problem is resolved after enabling all application modules in accordance with the diagnostic rule (that is, those modules that are specified in the diagnostic rule), define at least one application module that was not included (that is, the module that is not in the diagnostic rule) as linked with the cause of the problem. Obviously, after enabling all application modules in accordance with the diagnostic rule, those application modules that were previously identified in step 304 will be determined as related to the cause of the problem.

In one particular example of implementation, the choice of diagnostic rules can be made - use diagnostic rules that determine the order of disabling modules or diagnostic rules that determine the order of enabling modules, or use all diagnostic rules. For this, a criterion can be selected, depending on which one of the diagnostic rule options will be selected. The criterion can be, for example, one of the following: reducing the time for determining the module, reducing the number of iterations for determining the module. For example, according to the criterion "reducing the time for determining the module" rule 3 of table 1 will be preferable to rule 4 of table 1. Since in the case of rule 4, you will first need to disable the entire application, and then enable all application modules except for mail antivirus. It is obvious that disabling an application and enabling modules will take longer than disabling one module, as in rule 3. In addition, this example also satisfies the criterion of "reducing the number of iterations to define a module", since rule 4 has two iterations, and rule 3 has one iteration.

It should be noted that the particular embodiments described for the method of FIG. 3 are also applicable to the method of FIG. 4.

Thus, the claimed invention allows solving the technical problem posed and achieving the claimed technical result.

FIG. 5 is an example of a general-purpose computer system with which the present invention may be implemented. The personal computer or server 20 contains a central processor 21, a system memory 22 and a system bus 23, which contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any bus structure known from the prior art, which in turn contains a bus memory or a bus memory controller, a peripheral bus and a local bus that can interact with any other bus architecture. System memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains basic procedures that transfer information between the elements of the personal computer 20, for example, at the time of loading the operating room systems using ROM 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 CD-ROM, DVD -ROM and other optical media. The hard disk 27, the magnetic disk drive 28, and the optical drive 30 are connected to the system bus 23 via the hard disk interface 32, the magnetic disk interface 33, and the optical drive interface 34, respectively. Drives and corresponding computer storage media are non-volatile storage media for computer instructions, data structures, program 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 can be used that are capable of storing data in a computer readable form (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.), which 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 (operator) has the ability to enter commands and information into the personal computer 20 through input devices (keyboards 40 , manipulator "mouse" 42). Other input devices can be used (not shown): microphone, joystick, game console, scanner, etc. Such input devices are conventionally connected to the computer system 20 through 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, game port, or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via 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), for example, speakers, a printer, etc. ...

The personal computer 20 is capable of operating in a networked environment using a network connection with other 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 of the entity the personal computer 20 shown in FIG. 5. There may also be other devices in a computer network, such as routers, network stations, peer-to-peer devices, or other network nodes.

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

In accordance with the description, the components, stages of execution, 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 given in the description are examples, which do not limit the scope of the present invention defined by the claims.

Claims (41)

1. A method for determining the application module associated with the cause of the problem that occurred during the operation of the application, implemented by a computer, in which: a) disable at least one application module in accordance with the diagnostic rule for the problem; b) checking the elimination of the problem due to the disconnection of at least one application module; and c) in case of troubleshooting, at least one said application module is identified as associated with the cause of the problem. 2. The method of claim 1, wherein the diagnostic rule determines the order in which application modules are disabled to verify that the problem has been resolved. 3. The method according to claim 2, wherein the diagnostic rule further defines the order in which application modules are enabled to verify that the problem has been resolved. 4. The method of claim 2, wherein the order in which the application modules are disabled depends on the frequency of the problem due to the corresponding application module. 5. The method according to claim 1, in which if at step a) at least two application modules are disabled, after which the problem has been eliminated, turn on said application modules and repeat steps a) -c), alternately disabling each of said application modules in accordance with the diagnostic rule, and if the problem has not been resolved after disconnecting each of the mentioned application modules in accordance with the diagnostic rule, the at least two application modules are determined as related to the cause of the problem. 6. The method according to claim 1, in which, if the problem persists at step b), steps a) -b) are repeated, taking into account the diagnostic rule and the results of the test performed before one of the conditions occurs: a) troubleshooting; b) the impossibility of eliminating the problem after disabling the application modules in accordance with the diagnostic rule, while determining the absence of application modules associated with the cause of the problem. 7. The method of claim 6, wherein prior to repeating steps a) to b), at least one previously disabled application module is turned on. 8. The method of claim 6, wherein during the troubleshooting check, the application is traced to the trace log, and if at least one application module is identified as related to the cause of the problem, the log is used to determine at least one said application module as related. with the cause of the problem, and if it is impossible to eliminate the problem, the mentioned trace log is transmitted to the remote server to determine at least one said application module as related to the cause of the problem. 9. The method according to claim 1, in which the diagnostic rule determines the need to restart the application or restart the operating system (hereinafter referred to as OS) after disconnecting at least one specific application module, wherein the application or OS is rebooted after the said application module is disconnected. 10. The method of claim 1, wherein the type of problem is, in particular, one of: a) emergency shutdown of the operating system; b) unloading the application process from memory; c) freezing of the application; d) freezing of the operating system; e) increased load on the processor compared to the typical load on the processor during the operation of the said module; f) a decrease in performance compared to the typical value of performance during the operation of the said module; g) excessive use of resources; h) reducing the speed of network traffic; i) network unavailability; j) the presence of a software error in the code of the module of the mentioned application; k) the presence of a software error in the code of at least one third-party application installed on the computer; l) the presence of a software error in the operating system; m) providing unauthorized access; o) the presence of a known vulnerability. 11. The method according to claim 1, in which the problem is checked by reproducing the user's actions on the computer and the state of the computer prior to the problem, and then checking the problem. 12. The method according to claim 1, wherein the application module is, in particular, one of: an application component, a driver, a library. 13. The method according to claim 1, wherein when certain modules are disabled, the user is requested to confirm the disconnection of said modules. 14. The method of claim 1, wherein the diagnostic rules are updated using a remote server. 15. The method according to claim 1, in which each diagnostic rule corresponds to a weight that determines the order in which the diagnostic rule is applied for this type of problem, if more than one diagnostic rule is specified for this type of problem. 16. The method according to claim 1, wherein the diagnostic rule depends, in particular, on one of: a) application version; b) versions of the modules of the mentioned application; c) OS version; d) installed third-party applications; e) installed computer hardware; f) installed drivers.

Images