Fault reason determination method and device, equipment, storage medium and program product

Abstract

The invention provides a fault cause determination method and device, equipment, a storage medium and a program product, the method and device are applied to a host machine, a virtual machine is arranged in the host machine, and the method comprises the steps that in response to an operating system fault of the virtual machine, system starting information of an operating system is obtained in a preset storage space of the host machine, the system starting information is stored in a preset storage space in the starting process of the operating system; acquiring operation information of the virtual machine when the operating system fails; and determining a fault reason of the operating system according to the system starting information and the operation information. And the efficiency of determining the fault reason of the operating system is improved.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a method, apparatus, device, storage medium, and program product for determining the cause of a fault. Background Technology

[0002] A virtual machine can run on a host machine, and an operating system can run on a virtual machine.

[0003] In related technologies, when the operating system in a virtual machine malfunctions, the host machine can pause the virtual machine's operation and determine the corresponding memory dump file. This memory dump file can include the virtual machine's current memory contents. The host machine can then determine the cause of the operating system malfunction based on the memory dump file.

[0004] However, in the above methods, since the memory dump file is usually the same size as the memory occupied by the virtual machine (for example, if the virtual machine occupies 128G of memory, then the memory dump file is usually also 128G), the memory dump file is large and it takes a long time to obtain the memory dump file, resulting in low efficiency in determining the cause of the operating system failure. Summary of the Invention

[0005] This application provides a method, apparatus, device, storage medium, and program product for determining the cause of a fault, in order to solve the problem of low efficiency in determining the cause of operating system faults.

[0006] In a first aspect, embodiments of this application provide a method for determining the cause of a fault, applied to a host machine, wherein a virtual machine is configured in the host machine, and the method includes:

[0007] In response to an operating system failure of the virtual machine, the system startup information of the operating system is obtained from a preset storage space on the host machine. The system startup information is stored in the preset storage space during the startup process of the operating system.

[0008] Obtain the running information of the virtual machine when the operating system fails;

[0009] Based on the system startup information and the running information, determine the cause of the operating system failure.

[0010] In one possible implementation, determining the cause of the operating system failure based on the system startup information and the running information includes:

[0011] The type of fault in the operating system is determined based on the operational information;

[0012] Based on the fault type and the system startup information, determine the cause of the operating system failure.

[0013] In one possible implementation, determining the fault type of the operating system based on the operational information includes:

[0014] The startup status of the operating system is obtained from the running information;

[0015] If the startup status is a startup failure status, then the fault type is determined to be a startup failure type;

[0016] If the startup status is a successful startup status, then obtain the error code of the operating system, and determine the fault type based on the error code.

[0017] In one possible implementation, determining the fault type based on the error code includes:

[0018] If the error code includes a rammer error code, then the fault type is determined to be a rammer type.

[0019] If the error code includes a blue screen error code, then the fault type is determined to be a system blue screen.

[0020] In one possible implementation, determining the cause of the operating system failure based on the fault type and the system startup information includes:

[0021] Based on the fault type, determine the fault-related information in the system startup information;

[0022] The cause of the operating system failure is determined based on the failure type and the relevant failure information.

[0023] In one possible implementation, fault-related information is determined from the system startup information based on the fault type, including:

[0024] If the fault type is a startup failure type, then multiple object abnormalities are identified in the system startup information, and these multiple object abnormalities are identified as fault-related information.

[0025] If the fault type is a rammer type, then the input / output device information is determined in the system startup information, and the input / output device information is determined as the fault-related information;

[0026] If the fault type is a system blue screen, then obtain blue screen related information and identify multiple object exception information in the system startup information, and determine the blue screen related information and the multiple object exception information as the fault related information; the blue screen related information includes the current kernel version number, blue screen error code, and stack information.

[0027] In one possible implementation, the fault type is a boot failure type; determining the cause of the operating system failure based on the fault type and the fault-related information includes:

[0028] The abnormal information of the multiple objects is extracted and processed to obtain multiple key abnormal information, which includes multiple abnormal keywords.

[0029] Retrieve multiple historical fault objects, and the historical object exception information for each historical fault object;

[0030] The cause of the fault is determined based on the multiple key abnormal information, the multiple historical fault objects, and the historical object abnormal information of each historical fault object.

[0031] In one possible implementation, determining the cause of the failure based on the plurality of critical abnormal information, the plurality of historical fault objects, and the historical object abnormal information of each historical fault object includes:

[0032] Determine the first similarity between each key piece of abnormal information and the abnormal information of each historical object;

[0033] The historical fault object corresponding to the anomaly information of the first historical object with the highest similarity is identified as the cause of the fault.

[0034] In one possible implementation, the fault type is a jacking machine type; determining the cause of the operating system fault based on the fault type and the fault-related information includes:

[0035] At least one input / output anomaly is identified in the input / output device information;

[0036] In the at least one input / output exception information, determine the execution time in each input / output exception information to obtain multiple execution times;

[0037] Determine the execution duration between the at least one execution time and the current time to obtain at least one execution duration;

[0038] In the at least one execution duration, the input / output abnormal information corresponding to the execution duration that is greater than or equal to the preset duration is determined as the cause of the fault.

[0039] In one possible implementation, the fault type is a system blue screen; determining the cause of the operating system fault based on the fault type and the fault-related information includes:

[0040] The target file is determined based on the stack information and the current kernel version number;

[0041] The cause of the failure is determined based on the target file, the stack information, and the blue screen error code.

[0042] In one possible implementation, determining the target file based on the stack information and the current kernel version number includes:

[0043] Determine the return address of the currently called function from the stack information;

[0044] The target kernel module corresponding to the currently called function is determined based on the return address;

[0045] In the memory corresponding to the address range of the target kernel module, determine the target debugging information;

[0046] The file name is the target file name corresponding to the target kernel module and the system file corresponding to the target debugging information. The version number of the target file is the same as the current kernel version number.

[0047] In one possible implementation, determining the target kernel module corresponding to the currently called function based on the return address includes:

[0048] The address range of at least one kernel module is determined from the information of at least one kernel module;

[0049] Based on the target address range where the return address is located and the address range of the at least one kernel module, the target kernel module corresponding to the currently called function is determined, and the address range of the target kernel module is the target address range.

[0050] In one possible implementation, determining the cause of the failure based on the target file, the stack information, and the blue screen error code includes:

[0051] The target file is parsed to obtain the target function name and target address offset;

[0052] The target function information of the target function is determined from the stack information based on the target function name;

[0053] Obtain multiple historical fault causes and corresponding historical fault information, including historical function information, historical address offset, and historical blue screen error codes;

[0054] Based on the target function information, the target address offset, and the blue screen error code, a matching process is performed on the multiple historical fault information to obtain multiple second similarities;

[0055] The historical fault cause corresponding to the historical fault information with the highest second similarity is determined as the fault cause.

[0056] Secondly, embodiments of this application provide a fault cause determination device, the device comprising: a first acquisition module, a second acquisition module, and a determination module, wherein,

[0057] The first acquisition module is used to, in response to a virtual machine operating system failure, acquire the system startup information of the operating system from a preset storage space on the host machine, wherein the system startup information is stored in the preset storage space during the startup process of the operating system;

[0058] The second acquisition module is used to acquire the running information of the virtual machine when the operating system fails;

[0059] The determining module is used to determine the cause of the operating system failure based on the system startup information and the running information.

[0060] In one possible implementation, the determining module is specifically used for:

[0061] The type of fault in the operating system is determined based on the operational information;

[0062] Based on the fault type and the system startup information, determine the cause of the operating system failure.

[0063] In one possible implementation, the determining module is specifically used for:

[0064] The startup status of the operating system is obtained from the running information;

[0065] If the startup status is a startup failure status, then the fault type is determined to be a startup failure type;

[0066] If the startup status is a successful startup status, then obtain the error code of the operating system, and determine the fault type based on the error code.

[0067] In one possible implementation, the determining module is specifically used for:

[0068] If the error code includes a rammer error code, then the fault type is determined to be a rammer type.

[0069] If the error code includes a blue screen error code, then the fault type is determined to be a system blue screen.

[0070] In one possible implementation, the determining module is specifically used for:

[0071] Based on the fault type, determine the fault-related information in the system startup information;

[0072] The cause of the operating system failure is determined based on the failure type and the relevant failure information.

[0073] In one possible implementation, the determining module is specifically used for:

[0074] If the fault type is a startup failure type, then multiple object abnormalities are identified in the system startup information, and these multiple object abnormalities are identified as fault-related information.

[0075] If the fault type is a rammer type, then the input / output device information is determined in the system startup information, and the input / output device information is determined as the fault-related information;

[0076] If the fault type is a system blue screen, then obtain blue screen related information and identify multiple object exception information in the system startup information, and determine the blue screen related information and the multiple object exception information as the fault related information; the blue screen related information includes the current kernel version number, blue screen error code, and stack information.

[0077] In one possible implementation, the fault type is a startup failure type; the determining module is specifically used for:

[0078] The abnormal information of the multiple objects is extracted and processed to obtain multiple key abnormal information, which includes multiple abnormal keywords.

[0079] Retrieve multiple historical fault objects, and the historical object exception information for each historical fault object;

[0080] The cause of the fault is determined based on the multiple key abnormal information, the multiple historical fault objects, and the historical object abnormal information of each historical fault object.

[0081] In one possible implementation, the determining module is specifically used for:

[0082] Determine the first similarity between each key piece of abnormal information and the abnormal information of each historical object;

[0083] The historical fault object corresponding to the anomaly information of the first historical object with the highest similarity is identified as the cause of the fault.

[0084] In one possible implementation, the fault type is a rammer type; the determining module is specifically used for:

[0085] At least one input / output anomaly is identified in the input / output device information;

[0086] In the at least one input / output exception information, determine the execution time in each input / output exception information to obtain multiple execution times;

[0087] Determine the execution duration between the at least one execution time and the current time to obtain at least one execution duration;

[0088] In the at least one execution duration, the input / output abnormal information corresponding to the execution duration that is greater than or equal to the preset duration is determined as the cause of the fault.

[0089] In one possible implementation, the fault type is a system blue screen; the determining module is specifically used for:

[0090] The target file is determined based on the stack information and the current kernel version number;

[0091] The cause of the failure is determined based on the target file, the stack information, and the blue screen error code.

[0092] In one possible implementation, the determining module is specifically used for:

[0093] Determine the return address of the currently called function from the stack information;

[0094] The target kernel module corresponding to the currently called function is determined based on the return address;

[0095] In the memory corresponding to the address range of the target kernel module, determine the target debugging information;

[0096] The file name is the target file name corresponding to the target kernel module and the system file corresponding to the target debugging information. The version number of the target file is the same as the current kernel version number.

[0097] In one possible implementation, the determining module is specifically used for:

[0098] The address range of at least one kernel module is determined from the information of at least one kernel module;

[0099] Based on the target address range where the return address is located and the address range of the at least one kernel module, the target kernel module corresponding to the currently called function is determined, and the address range of the target kernel module is the target address range.

[0100] In one possible implementation, the determining module is specifically used for:

[0101] The target file is parsed to obtain the target function name and target address offset;

[0102] The target function information of the target function is determined from the stack information based on the target function name;

[0103] Obtain multiple historical fault causes and corresponding historical fault information, including historical function information, historical address offset, and historical blue screen error codes;

[0104] Based on the target function information, the target address offset, and the blue screen error code, a matching process is performed on the multiple historical fault information to obtain multiple second similarities;

[0105] The historical fault cause corresponding to the historical fault information with the highest second similarity is determined as the fault cause.

[0106] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0107] The memory stores computer-executed instructions;

[0108] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects.

[0109] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects.

[0110] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method shown in any of the first aspects.

[0111] This application provides a method, apparatus, device, storage medium, and program product for determining the cause of a fault. In response to a virtual machine's operating system fault, the host machine can obtain the operating system's boot information from a preset storage space on the host machine and acquire the virtual machine's running information at the time of the operating system fault. Based on the boot and running information, the cause of the operating system fault can be determined. Since the system boot information can be obtained through the target driver and pre-stored in the preset storage space on the host machine, when the operating system in the virtual machine fails, the host machine can quickly obtain the system boot information and determine the cause of the operating system fault based on the boot and running information. Compared to existing technologies, this eliminates the need to pause the virtual machine and determine the corresponding memory dump file, thus improving the efficiency of determining the cause of the operating system fault. Attached Figure Description

[0112] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0113] Figure 1 A schematic diagram of a scenario provided for an exemplary embodiment of this application;

[0114] Figure 2 A flowchart illustrating the principle of a fault cause determination method provided for an exemplary embodiment of this application;

[0115] Figure 3 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 1 ;

[0116] Figure 4 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 2 ;

[0117] Figure 5 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 3 ;

[0118] Figure 6 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 4 ;

[0119] Figure 7 A schematic diagram of a fault cause determination device provided for an exemplary embodiment of this application;

[0120] Figure 8 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

[0121] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0122] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0123] Figure 1 This is a schematic diagram of a scenario provided for an exemplary embodiment of this application. Please refer to... Figure 1 The host machine may include at least one virtual machine. The at least one virtual machine may be virtual machine 1, virtual machine 2, ..., virtual machine n, where n is an integer greater than or equal to 1.

[0124] For any given virtual machine, there is a corresponding pre-defined storage space on the host machine. For example, virtual machine 1 can have a pre-defined storage space 1; virtual machine 2 can have a pre-defined storage space 2; ...; virtual machine n can have a pre-defined storage space n.

[0125] For any virtual machine, an operating system can run within it. During the operating system's startup process, the host machine can determine the operating system's startup information and store it in a preset storage space.

[0126] When the operating system in a virtual machine fails, the host machine can obtain the system startup information from the preset storage space corresponding to the virtual machine and determine the cause of the operating system failure based on the system startup information.

[0127] For example, if the operating system in virtual machine 1 fails, the host machine can obtain the system startup information from the preset storage space 1 corresponding to virtual machine 1, and can determine the cause of the operating system failure as a failure to read file A based on the system startup information.

[0128] In related technologies, when the operating system in a virtual machine malfunctions, the host machine can pause the virtual machine and determine the corresponding memory dump file, which may include the current memory contents of the virtual machine. The host machine can then determine the cause of the operating system failure based on the memory dump file. However, in this method, since the memory dump file is usually the same size as the memory occupied by the virtual machine (for example, if the virtual machine occupies 128GB of memory, the memory dump file is usually also 128GB), the memory dump file is large, and obtaining the memory dump file takes a long time, resulting in low efficiency in determining the cause of the operating system failure.

[0129] In this embodiment, when the operating system is started in the virtual machine, the host machine can determine the system startup information of the operating system and pre-store the system startup information in a preset storage space on the host machine. When the operating system in the virtual machine fails, the host machine can quickly obtain the system startup information pre-stored in the preset storage space, and then determine the cause of the operating system failure based on the system startup information and running information. Compared with the prior art, it is not necessary to pause the running of the virtual machine or determine the memory dump file corresponding to the virtual machine, thus improving the efficiency of determining the cause of the operating system failure.

[0130] Below, in conjunction with Figure 2 The principles of the technical solution in this application will be briefly explained.

[0131] Figure 2 A flowchart illustrating the principle of a fault cause determination method provided for an exemplary embodiment of this application. Please refer to [link / reference]. Figure 2 ,

[0132] When starting an operating system in a virtual machine, you can first start the operating system's bootloader, then load the operating system's kernel module, and then load the target driver.

[0133] During the operating system startup process, the host machine can obtain system startup information through the target driver and pre-store the system startup information to a preset storage space through a virtual serial port.

[0134] When the operating system fails to boot, or during operation after successful boot, if a system crashes or blue screen occurs, the host machine can obtain operational information and system startup information from a pre-defined storage space. Based on this information, the cause of the failure can be determined. This eliminates the need to pause the virtual machine and determine its corresponding memory dump file, improving the efficiency of identifying operating system failures. Furthermore, since most system startup information consists of abnormal data, the data volume is small and does not require significant storage space.

[0135] The technical solutions shown in this application will now be described in detail through specific embodiments. It should be noted that the following embodiments may exist independently or in combination with each other; for identical or similar content, the description will not be repeated in different embodiments.

[0136] Figure 3 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 1 Please see. Figure 3 The method may include:

[0137] S301. In response to a virtual machine operating system failure, retrieve the operating system's system startup information from the host machine's preset storage space.

[0138] The execution entity in this application embodiment can be a host machine or a fault cause determination device installed in the host machine. The fault cause determination device can be implemented by software or by a combination of software and hardware. The fault cause determination device can be the processor in the host machine. For ease of understanding, the following description will use the host machine as the execution entity.

[0139] System startup information refers to the information generated when the operating system is started in a virtual machine. This information can occur during the operating system startup process, when the host machine executes the target driver and stores it in a preset storage space via a virtual serial port.

[0140] For any virtual machine, a target driver and a virtual serial port can be set up.

[0141] The target driver can be used to obtain system startup information. System startup information may include object exception information for multiple objects, input / output (I / O) device information, and information about at least one kernel module.

[0142] Optionally, the host machine can register callback functions for multiple objects in the operating system through the target driver. These multiple objects include multiple kernel modules, multiple processes, multiple registry entries, and at least one file system.

[0143] When an operation on any object fails, the corresponding callback function can be executed to retrieve object exception information. If the object is a kernel module, the exception information may include module information such as the module name, load time, load status, and corresponding address range. If the object is a process, the exception information may include process information such as the process ID (PID), startup status, process path, and the corresponding parent process. If the object is a registry entry, the exception information may include registry information such as the table name, load status, load time, and storage address. If the object is a file system, the exception information may include file system information such as the file system name, load status, load time, and corresponding address range.

[0144] Optionally, the host machine can execute kernel code through the target driver to obtain I / O device information. This I / O device information may include network transmission and reception information, as well as device read and write information.

[0145] Network information transmission and reception may include the source Internet Protocol (IP) address, destination IP address, content to be sent, time of transmission, and transmission status.

[0146] Device read / write information refers to information related to read or write commands. This information may include the read / write time, read / write completion status, and storage address.

[0147] For any given kernel module, there is corresponding kernel module information, which may include the module name, loading time, loading status, and corresponding address range.

[0148] Virtual serial ports can be used to transfer data between virtual machines and host machines.

[0149] The host machine can have at least one virtual machine, and each virtual machine has a corresponding preset storage space on the host machine.

[0150] During the process of starting the operating system in the virtual machine, the host machine can execute the target driver to obtain system startup information and store the system startup information in the preset storage space of the host machine through the virtual serial port.

[0151] When the operating system in the virtual machine fails, the host machine can respond to the operating system failure by retrieving the operating system's system startup information from the host machine's preset storage space.

[0152] For example, if a host machine hosts a virtual machine 1, and virtual machine 1 has a corresponding preset storage space 1, which stores system startup information when the operating system is started in virtual machine 1, then in the event of a failure in the operating system of virtual machine 1, the host machine can retrieve the system startup information from the preset storage space 1. Assume the system startup information can be as shown in Table 1:

[0153] Table 1

[0154]

[0155]

[0156] S302. Obtain virtual machine running information when the operating system fails.

[0157] Runtime information can be information that arises when an operating system malfunctions. Runtime information can be used to determine the type of malfunction that occurred in the operating system.

[0158] The host machine can obtain the virtual machine's running information when the operating system fails.

[0159] For example, if the operating system of virtual machine 1 fails, the host machine can obtain running information 1, which includes the operating system's startup status as a startup failure.

[0160] S303. Based on the system startup and running information, determine the cause of the operating system failure.

[0161] In an optional embodiment, the cause of the operating system failure can be determined based on system startup information and running information in the following manner: determining the type of operating system failure based on the running information; and determining the cause of the operating system failure based on the failure type and system startup information.

[0162] Optionally, the operating system's failure types may include startup failure type, jacking type, and system blue screen type.

[0163] The host machine can determine the type of operating system failure based on the runtime information. For example, if the host machine can determine from runtime information 1 that the operating system's startup status is a startup failure, then the type of operating system failure can be determined to be a startup failure.

[0164] Since system startup information is pre-stored in a preset storage space during the operating system startup process, the system startup information includes object exception information for multiple objects and I / O device information. Therefore, when the virtual machine's operating system experiences different types of failures, the host machine can determine the cause of the operating system failure based on the failure type and the system startup information.

[0165] For example, if the operating system of virtual machine 1 malfunctions, and the host machine determines that the malfunction type is a boot failure, and if the system boot information is as shown in Table 1, the host machine can determine the cause of the operating system malfunction based on the malfunction type and the system boot information. Let's assume that the cause of the operating system malfunction can be determined to be the failure to load kernel module 2.

[0166] In this embodiment, the host machine can respond to a virtual machine operating system failure by retrieving the operating system startup information from its preset storage space and obtaining the virtual machine's running information at the time of the operating system failure. Based on the system startup and running information, the cause of the operating system failure can be determined. Since system startup information can be obtained through the target driver and pre-stored in the preset storage space on the host machine, the host machine can quickly retrieve the system startup information when the operating system in the virtual machine fails and determine the cause of the operating system failure based on the system startup and running information. Compared to existing technologies, this eliminates the need to pause the virtual machine's operation and determine the corresponding memory dump file, thus improving the efficiency of determining the cause of the operating system failure.

[0167] Since there are three types of faults in the technical solution of this application, therefore, below, Figure 3 Based on the illustrated embodiments, combined with Figure 4 This section provides a detailed explanation of the methods for determining the cause of a startup failure; combined with... Figure 5 This paper provides a detailed explanation of the method for determining the cause of failures when the failure type is a rammer; combined with... Figure 6 This document provides a detailed explanation of the methods for determining the cause of system blue screen errors.

[0168] Figure 4 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 2 Please see. Figure 4 The method may include:

[0169] S401. In response to a virtual machine operating system failure, retrieve the operating system's system startup information from the host machine's preset storage space.

[0170] S402. Obtain virtual machine running information when the operating system fails.

[0171] It should be noted that the specific execution process of steps S401 to S402 can be found in the specific execution process of steps S301 to S302, and will not be repeated here.

[0172] S403. Determine the operating system fault type based on the running information.

[0173] In an optional embodiment, the fault type of the operating system can be determined based on the running information as follows: obtain the startup status of the operating system from the running information; if the startup status is a startup failure status, then determine the fault type as a startup failure type.

[0174] The runtime information may include the operating system's startup status. Optionally, the "Successed" flag can be used to indicate a successful startup, and the "failed" flag can be used to indicate a failed startup.

[0175] For example, if the operating system of virtual machine 1 fails, and the host machine obtains running information 1, if the host machine determines that the startup status of the operating system is "failed" in running information 1, then the host machine can determine that the startup status of the operating system is a startup failure state, and thus determine that the failure type is a startup failure type.

[0176] S404. Determine the fault-related information in the system startup information according to the fault type.

[0177] If the fault type is a startup failure, then the abnormal information of multiple objects can be identified in the system startup information, and the abnormal information of multiple objects can be identified as fault-related information.

[0178] For example, if the fault type is startup failure, and if the system startup information is as shown in Table 1, the host machine can determine the object exception information for three objects from the system startup information to obtain the exception information for those three objects. Assume that the exception information for these three objects can be as shown in Table 2:

[0179] Table 2

[0180]

[0181] The host machine can then identify the three object anomalies shown in Table 2 as fault-related information.

[0182] S405. Extract and process the abnormal information of multiple objects to obtain multiple key abnormal information.

[0183] Since the fault type is startup failure, the fault-related information consists of multiple object exception information. Therefore, for any object's object exception information, the host machine can extract and process the object exception information to obtain the corresponding exception key information, which includes multiple exception keywords.

[0184] For example, if multiple object anomaly information is shown in Table 2, then the anomaly information for each object can be extracted and processed to obtain the key anomaly information corresponding to each object. Assume the key anomaly information for each object is shown in Table 3:

[0185] Table 3

[0186]

[0187] S406. Obtain multiple historical fault objects and the historical object exception information for each historical fault object.

[0188] Optionally, the host machine may store multiple historical fault objects and the historical object exception information corresponding to each historical fault object.

[0189] For example, if there are 10 historical fault objects, and assuming that the 10 historical fault objects and the historical object anomaly information of each historical fault object are as shown in Table 4:

[0190] Table 4

[0191]

[0192] S407. Determine the cause of the fault based on multiple key abnormal information, multiple historical fault objects, and the historical object abnormal information of each historical fault object.

[0193] Optionally, the cause of the fault can be determined by the following method, based on multiple key abnormal information, multiple historical fault objects, and historical object abnormal information of each historical fault object: determine the first similarity between each key abnormal information and each historical object abnormal information; and determine the historical fault object corresponding to the historical object abnormal information with the highest first similarity as the cause of the fault.

[0194] If multiple key anomaly information are as shown in Table 3, and multiple historical fault objects, along with the historical object anomaly information for each historical fault object, are as shown in Table 4, then the host machine can determine the first similarity between each key anomaly information and each historical object anomaly information, resulting in 30 first similarity scores. Assume these 30 first similarity scores are as shown in Table 5:

[0195] Table 5

[0196]

[0197] If, among the 40 first similarity scores, the first similarity score between the abnormal key information 2 and the historical object abnormal information 2 is the highest at 90%, then the cause of the failure can be determined as the failure to load kernel module 2.

[0198] In this embodiment, the host machine can respond to a virtual machine operating system failure by retrieving the operating system startup information from its preset storage space and obtaining the virtual machine's running information at the time of the operating system failure. Based on this running information, the host machine can determine the operating system failure type. If the failure type is a startup failure, the host machine can determine the failure-related information (i.e., multiple object exception information) from the system startup information based on the failure type, and extract and process this information to obtain multiple key exception information. The host machine can obtain multiple historical failure objects and the historical object exception information for each historical failure object. Based on this key exception information, the host machine can determine the cause of the failure. Since system startup information can be obtained through the target driver and pre-stored in the preset storage space of the host machine, when the operating system in the virtual machine fails, the host machine can quickly obtain the system startup information and determine the failure-related information based on the failure type. Based on this information, the cause of the operating system failure can be determined. Compared to existing technologies, this eliminates the need to pause the virtual machine and determine the corresponding memory dump file, thus improving the efficiency of determining the cause of the operating system failure.

[0199] Figure 5 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 3 Please see. Figure 5 The method may include:

[0200] S501: In response to a virtual machine operating system failure, retrieve the operating system's system startup information from the host machine's preset storage space.

[0201] S502, Obtain virtual machine running information when the operating system fails.

[0202] It should be noted that the specific execution process of steps S501 to S502 can be found in the specific execution process of steps S301 to S302, and will not be repeated here.

[0203] S503. Determine the operating system fault type based on the running information.

[0204] In an optional embodiment, the fault type of the operating system can be determined based on the running information in the following manner: obtain the startup status of the operating system from the running information; if the startup status is a successful startup status, obtain the error code of the operating system, and determine the fault type based on the error code.

[0205] Optionally, the runtime information may also include operating system error codes. Error codes can be used to indicate the type of failure that has occurred in the operating system.

[0206] Optionally, the error code can be sent from the first device to the host machine, or it can be an error code generated by the virtual machine.

[0207] For example, the first device can obtain and analyze the virtual machine's runtime logs to determine if the virtual machine is experiencing a crash. If a crash is detected, a crash error code can be sent to the host machine so that the host machine can receive the crash error code.

[0208] Optionally, if a rammer error code is present in the error message, the fault type can be identified as a rammer. The rammer error code can be used to indicate that the operating system is unresponsive.

[0209] For example, if the operating system of virtual machine 1 malfunctions, and the host machine obtains runtime information 1, if the host machine determines that the operating system's startup status is "Successed" from runtime information 1, then the host machine can determine that the operating system's startup status is successful, and the host machine can obtain the error code from runtime information 1. If the error code includes a jacking machine error code, the host machine can determine the fault type as a jacking machine based on the jacking machine error code.

[0210] S504. Determine the fault-related information in the system startup information according to the fault type.

[0211] If the fault type is a ramming machine type, the I / O device information can be determined in the system startup information and identified as fault-related information.

[0212] For example, if the fault type is a jackhammer type, and if the system startup information is as shown in Table 1, the host machine can determine the I / O device information from the system startup information. Assume the I / O device information can be as shown in Table 6:

[0213] Table 6

[0214]

[0215]

[0216] The host machine can then identify the I / O device information shown in Table 6 as fault-related information.

[0217] S505. Identify at least one I / O anomaly information in the I / O device information.

[0218] Since the fault type is ramming machine type, the fault-related information is I / O device information, so the host machine can identify at least one I / O abnormality information in the I / O device information.

[0219] I / O error information may include incomplete device read / write information and / or incomplete network transmit / receive information.

[0220] For example, if the I / O device information is as shown in Table 6, and both device read / write information 2 and device read / write information 3 include "read command not completed", then the host machine will identify device read / write information 2 and device read / write information 3 as I / O abnormal information in the I / O device information.

[0221] S506. In at least one I / O exception message, determine the execution time in each I / O exception message to obtain multiple execution times.

[0222] The execution time refers to the execution time of the I / O command in the I / O exception information. For example, if the I / O exception information is device read / write information, the execution time can be the read time or the write time; if the I / O exception information is network send / receive information, the execution time can be the send time or the receive time.

[0223] For example, if there are two I / O exception messages as shown in Table 6, namely device read / write message 2 and device read / write message 3, then the host machine can determine the execution time 2 as 2024-04-17 9:46:18 from device read / write message 2; and determine the execution time 3 as 2024-04-17 9:46:25 from device read / write message 3, so the host machine can obtain two execution times.

[0224] S507. Determine the execution duration between at least one execution time and the current time, and obtain at least one execution duration.

[0225] For example, if there are two execution times, execution time 2 and execution time 3, execution time 2 is 2024-04-17 9:46:18 and execution time 3 is 2024-04-17 9:46:25, and the current time is 2024-04-17 9:47:20, then the host machine can determine that the execution duration 2 between execution time 2 and the current time is 62 seconds; and can determine that the execution duration 3 between execution time 3 and the current time is 55 seconds.

[0226] S508. In at least one execution duration, the I / O exception information corresponding to the execution duration that is greater than or equal to the preset duration is determined as the cause of the fault.

[0227] Optionally, the preset duration can be manually preset. For example, the preset duration can be 60 seconds.

[0228] For example, if there are two execution durations, execution duration 2 and execution duration 3, execution duration 2 is 62s and execution duration 3 is 55s, and the preset duration is 60s, then the host machine can determine that execution duration 2 is greater than the preset duration and execution duration 3 is less than the preset duration. The host machine can then determine the device read / write information 2 corresponding to execution duration 2 as the cause of the fault, that is, the cause of the fault is that read command 2 was not completed.

[0229] In this embodiment, the host machine can respond to a virtual machine operating system failure by retrieving the operating system startup information from its preset storage space and obtaining the virtual machine's running information at the time of the operating system failure. It then determines the operating system failure type based on the running information. If the failure type is a crash, the host machine can determine fault-related information (i.e., I / O device information) from the system startup information and identify at least one I / O exception in the I / O device information. The host machine can determine the execution time of each I / O exception in at least one I / O exception, obtaining multiple execution times, and determine the execution duration between at least one execution time and the current time, obtaining at least one execution duration. Then, within at least one execution duration, the I / O exception corresponding to an execution duration greater than or equal to a preset duration is identified as the cause of the failure. Since system startup information can be obtained through the target driver and pre-stored in the preset storage space of the host machine, when the operating system in the virtual machine fails, the host machine can quickly obtain the system startup information and determine the fault-related information based on the fault type in the system startup information, and then determine the cause of the operating system failure based on the fault-related information. Compared with the existing technology, there is no need to stop running the virtual machine and determine the corresponding memory dump file of the virtual machine, thus improving the efficiency of determining the cause of the operating system failure.

[0230] Figure 6 A flowchart illustrating a method for determining the cause of a fault, provided as an exemplary embodiment of this application. Figure 4 Please see. Figure 6 The method may include:

[0231] S601: In response to a virtual machine operating system failure, retrieve the operating system's system startup information from the host machine's preset storage space.

[0232] S602. Obtain virtual machine running information when the operating system fails.

[0233] It should be noted that the specific execution process of steps S601 to S602 can be found in the specific execution process of steps S301 to S302, and will not be repeated here.

[0234] S603. Determine the operating system fault type based on the running information.

[0235] In an optional embodiment, the fault type of the operating system can be determined based on the running information in the following manner: obtain the startup status of the operating system from the running information; if the startup status is a successful startup status, obtain the error code of the operating system, and determine the fault type based on the error code.

[0236] Optionally, the runtime information may also include operating system error codes. Error codes can indicate the type of failure that occurred in the operating system. Error codes can be generated by a virtual machine. For example, a virtual machine can generate a blue screen error code when the operating system experiences a blue screen.

[0237] Optionally, if a blue screen error code is present in the error message, the fault type is determined to be a system blue screen. Blue screen error codes can be used to indicate that a blue screen has occurred in the operating system.

[0238] For example, if the operating system of virtual machine 1 malfunctions, and the host machine obtains runtime information 1, if the host machine determines that the operating system's startup status is "Successed" from runtime information 1, then the host machine can determine that the operating system's startup status is successful, and the host machine can obtain the error code from runtime information 1. If the error code contains the blue screen error code "0x0000003B", then the host machine can determine the fault type as a system blue screen based on this blue screen error code.

[0239] S604. Determine the fault-related information in the system startup information according to the fault type.

[0240] If the fault type is a system blue screen, then blue screen related information can be obtained, and at least one kernel module information can be identified in the system startup information. The blue screen related information and at least one kernel module information can then be identified as fault related information.

[0241] Blue screen information can include the current kernel version number, the blue screen error code, and stack trace information.

[0242] For the operating system within a virtual machine, the operating system may include multiple kernel version numbers, which can be used to identify a specific version of the kernel. For example, the kernel version number could be "4.15.0".

[0243] The current kernel version number refers to the version number of the kernel currently used in the operating system.

[0244] A blue screen error code can have multiple values. For example, a blue screen error code "0x0000007B" indicates that the operating system cannot access the boot device; a blue screen error code "0x0000003B" indicates that a system service exception has occurred.

[0245] Stack information refers to the information recorded during program execution that shows the sequence of function calls. Stack information can include the function call chain, the call stack pointer, and function information for each function (including function parameters, local variables, and return address).

[0246] Optionally, when a blue screen occurs in the operating system of the virtual machine, the host machine can execute a blue screen callback function through the target driver to obtain blue screen related information, and can store the blue screen related information to a preset storage space through a virtual serial port.

[0247] For example, if the fault type is a system blue screen, the host machine can obtain blue screen-related information, assuming that the blue screen-related information is as shown in Table 7:

[0248] Table 7

[0249]

[0250] If the system startup information is as shown in Table 1, the host machine can determine at least one kernel module information from the system startup information to obtain at least one kernel module information. Assume that the at least one kernel module information can be as shown in Table 8:

[0251] Table 8

[0252]

[0253] The host machine can then identify the blue screen related information shown in Table 7 and the three kernel module information shown in Table 8 as fault-related information.

[0254] S605. Determine the target file based on the stack information and the current kernel version number.

[0255] When the fault type is a system blue screen, the fault-related information includes blue screen information and at least one kernel module information. The blue screen information includes the current kernel version number, the blue screen error code, and the stack information. Therefore, the host machine can determine the target file based on the stack information and the current kernel version number.

[0256] The target file can be a system file. For example, the target file can be a .sys file.

[0257] Optionally, the target file can be determined based on the stack information and the current kernel version number in the following way: determine the return address of the currently called function in the stack information; determine the target kernel module corresponding to the currently called function based on the return address; determine the target debugging information in the memory corresponding to the address range of the target kernel module; and determine the file name as the target file name corresponding to the target kernel module and the system file corresponding to the target debugging information as the target file.

[0258] Since the stack information includes information such as the function call chain, the call stack pointer, the function parameters of each function, local variables, and the return address, the return address of the currently called function can be determined from the stack information.

[0259] Optionally, the host machine can determine the function call chain from the stack information, determine the currently called function based on the function call chain, and then determine the return address of the currently called function from the stack information.

[0260] For example, if the stack information is as shown in Table 4, and the host machine determines the function call chain as "Main function calls function 1, function 1 calls function 2, function 2 calls function 3" in the stack information, then it can determine that the currently called function is function 3 based on the function call chain, and thus determine that the return address of function 3 is address 14.

[0261] Since the exception information of multiple objects includes module information of at least one kernel module, after determining the return address of the currently called function, the target kernel module corresponding to the currently called function can be determined based on the return address.

[0262] In an optional embodiment, the target kernel module corresponding to the currently called function can be determined based on the return address by: determining the address range corresponding to at least one kernel module from at least one kernel module information; and determining the target kernel module corresponding to the currently called function based on the target address range where the return address is located and the address range corresponding to at least one kernel module.

[0263] The address range of the target kernel module can be the target address range.

[0264] For example, if at least one kernel module information is as shown in Table 8, the host machine can determine that the address range corresponding to kernel module 1 is address 9-10; the address range corresponding to kernel module 2 is address 1-2; and the address range corresponding to kernel module 3 is address 11-12. If the return address of the currently called function is address 14, and the target address range is address 11-12, the host machine can determine that the target kernel module corresponding to the currently called function is kernel module 3 based on the target address range of the return address and the address ranges corresponding to the three kernel modules.

[0265] For any given system file, there can be corresponding debugging information. This debugging information can be used to debug system files.

[0266] Optionally, the host machine can determine the target debugging information in the memory corresponding to the address range of the target kernel module. The target debugging information can be obtained by debugging or determining the target file.

[0267] For example, if the target kernel module is kernel module 3, and the corresponding address range is address 11-address 12, then the host machine can determine the target debugging information in the memory corresponding to address 11-address 12. Assume the target debugging information is debugging information 3.

[0268] For any given kernel module, there can be at least one corresponding system file. The filename of this system file is the filename corresponding to the kernel module.

[0269] It should be noted that the file names of at least one system file are the same, but the version numbers of at least one system file are different.

[0270] For example, if kernel module 3 corresponds to 3 system files, then the file name of these 3 system files can all be tcpip.sys. That is, the file name corresponding to kernel module 3 is tcpip.sys, and this file name corresponds to 3 system files, and the version numbers of these 3 system files are different.

[0271] The host machine can determine the target file name corresponding to the target kernel module, and can also determine the current kernel version number from the blue screen information. Therefore, it can identify the file whose file name corresponds to the target kernel module and the system file corresponding to the target debugging information as the target file. The version number of the target file can be the same as the current kernel version number.

[0272] For example, if the target kernel module is kernel module 3, and the target file name corresponding to kernel module 3 is tcpip.sys, and if this target file name corresponds to 3 system files, namely system file 1, system file 2, and system file 3, and if the debugging information corresponding to these 3 system files can be as shown in Table 9:

[0273] Table 9

[0274] System files Corresponding debugging information System file 1 Debugging Information 1 System File 2 Debugging Information 2 System File 3 Debugging Information 3

[0275] If the blue screen information is as shown in Table 7, and the host machine determines that the target debugging information is debugging information 3, then the host machine can identify the file named tcpip.sys and the system file corresponding to debugging information 3, i.e., system file 3, as the target file. Since the current kernel version number is 4.15.3, the version number of system file 3 can also be 4.15.3.

[0276] S606. Determine the cause of the failure based on the target file, stack information, and blue screen error code.

[0277] In an optional embodiment, the cause of the fault can be determined as follows: the target file is parsed to obtain the target function name and address offset; the target function information of the target function is determined from the stack information based on the target function name; multiple historical fault causes and corresponding historical fault information are obtained; based on the target function information, address offset, and blue screen error code, matching is performed on the multiple historical fault information to obtain multiple second similarities; the historical fault cause corresponding to the historical fault information with the highest second similarity is determined as the fault cause.

[0278] Optionally, the host machine may have a disassembler. The host machine can use the disassembler to parse the object file and obtain the object function name and the object address offset.

[0279] The function corresponding to the name of the objective function is the objective function. The target address offset refers to the address offset corresponding to the objective function.

[0280] For example, if the target file is system file 3, the host machine can use a disassembler to parse and process the target file to obtain the target function name and address offset. Let's assume the obtained target function name is "Aa" and the target address offset is 1.

[0281] Since stack traces can include information about multiple functions, the target function's information can be determined from the stack trace based on the target function's name. For example, if the target function name is "Aa" and the corresponding target function is function 2, then the target function information for function 2 can be determined from the stack trace. Assume that the target function information for function 2 includes input parameter b, local variable c, and return address 14, etc.

[0282] Optionally, the host machine may store multiple historical fault causes and historical fault information corresponding to each historical fault cause.

[0283] Historical fault information can include historical function information, historical address offsets, and historical blue screen error codes.

[0284] For example, if there are 5 historical fault causes, and assuming that the 5 historical fault causes and the historical fault information corresponding to each historical fault cause are as shown in Table 10:

[0285] Table 10

[0286]

[0287] If the objective function information includes input parameter b, local variable c, and return address 14, and if the address offset is address offset 1 and the blue screen error code is 0x0000003B, then based on the objective function information, address offset, and blue screen error code, matching processing can be performed on the five historical fault information to obtain five second similarities. Assume that these five second similarities are shown in Table 11:

[0288] Table 11

[0289]

[0290] If the second similarity between the target function information, target address offset, and blue screen error code and historical fault information 5 is the highest at 95%, then the historical fault cause corresponding to historical fault information 5 can be determined as the fault cause, i.e., the fault cause is function 2.

[0291] In this embodiment, the host machine can respond to a virtual machine operating system failure by retrieving the operating system startup information from its preset storage space and obtaining the virtual machine's running information at the time of the operating system failure. The host machine then determines the type of operating system failure based on the running information. If the failure type is a system blue screen, the host machine can determine the relevant failure information (i.e., at least one kernel module information and blue screen-related information) from the system startup information based on the failure type. The host machine can determine the target file based on the stack information and the current kernel version number, and determine the cause of the failure based on the target file, stack information, and blue screen error code. Since system startup information can be obtained through the target driver and pre-stored in the preset storage space on the host machine, when the operating system in the virtual machine fails, the host machine can quickly obtain the system startup information and determine the relevant failure information based on the failure type, and then determine the cause of the operating system failure based on the relevant failure information. Compared with the prior art, this eliminates the need to pause the virtual machine and determine the corresponding memory dump file, thus improving the efficiency of determining the cause of the operating system failure.

[0292] Figure 7 This is a schematic diagram of a fault cause determination device provided for an exemplary embodiment of this application. Please refer to... Figure 7 The fault cause determination device 10 includes: a first acquisition module 11, a second acquisition module 12, and a determination module 13, wherein,

[0293] The first acquisition module 11 is used to, in response to a virtual machine operating system failure, acquire the system startup information of the operating system from a preset storage space on the host machine, wherein the system startup information is stored in the preset storage space during the startup process of the operating system;

[0294] The second acquisition module 12 is used to acquire the running information of the virtual machine when the operating system fails;

[0295] The determining module 13 is used to determine the cause of the operating system failure based on the system startup information and the running information.

[0296] The fault cause determination device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0297] In one possible implementation, the determining module 13 is specifically used for:

[0298] The type of fault in the operating system is determined based on the operational information;

[0299] Based on the fault type and the system startup information, determine the cause of the operating system failure.

[0300] In one possible implementation, the determining module 13 is specifically used for:

[0301] The startup status of the operating system is obtained from the running information;

[0302] If the startup status is a startup failure status, then the fault type is determined to be a startup failure type;

[0303] If the startup status is a successful startup status, then obtain the error code of the operating system, and determine the fault type based on the error code.

[0304] In one possible implementation, the determining module 13 is specifically used for:

[0305] If the error code includes a rammer error code, then the fault type is determined to be a rammer type.

[0306] If the error code includes a blue screen error code, then the fault type is determined to be a system blue screen.

[0307] In one possible implementation, the determining module 13 is specifically used for:

[0308] Based on the fault type, determine the fault-related information in the system startup information;

[0309] The cause of the operating system failure is determined based on the failure type and the relevant failure information.

[0310] In one possible implementation, the determining module 13 is specifically used for:

[0311] If the fault type is a startup failure type, then multiple object abnormalities are identified in the system startup information, and these multiple object abnormalities are identified as fault-related information.

[0312] If the fault type is a rammer type, then the input / output device information is determined in the system startup information, and the input / output device information is determined as the fault-related information;

[0313] If the fault type is a system blue screen, then obtain blue screen related information and identify multiple object exception information in the system startup information, and determine the blue screen related information and the multiple object exception information as the fault related information; the blue screen related information includes the current kernel version number, blue screen error code, and stack information.

[0314] In one possible implementation, the fault type is a startup failure type; the determining module 13 is specifically used for:

[0315] The abnormal information of the multiple objects is extracted and processed to obtain multiple key abnormal information, which includes multiple abnormal keywords.

[0316] Retrieve multiple historical fault objects, and the historical object exception information for each historical fault object;

[0317] The cause of the fault is determined based on the multiple key abnormal information, the multiple historical fault objects, and the historical object abnormal information of each historical fault object.

[0318] In one possible implementation, the determining module 13 is specifically used for:

[0319] Determine the first similarity between each key piece of abnormal information and the abnormal information of each historical object;

[0320] The historical fault object corresponding to the anomaly information of the first historical object with the highest similarity is identified as the cause of the fault.

[0321] In one possible implementation, the fault type is a rammer type; the determining module 13 is specifically used for:

[0322] At least one input / output anomaly is identified in the input / output device information;

[0323] In the at least one input / output exception information, determine the execution time in each input / output exception information to obtain multiple execution times;

[0324] Determine the execution duration between the at least one execution time and the current time to obtain at least one execution duration;

[0325] In the at least one execution duration, the input / output abnormal information corresponding to the execution duration that is greater than or equal to the preset duration is determined as the cause of the fault.

[0326] In one possible implementation, the fault type is a system blue screen; the determining module 13 is specifically used for:

[0327] The target file is determined based on the stack information and the current kernel version number;

[0328] The cause of the failure is determined based on the target file, the stack information, and the blue screen error code.

[0329] In one possible implementation, the determining module 13 is specifically used for:

[0330] Determine the return address of the currently called function from the stack information;

[0331] The target kernel module corresponding to the currently called function is determined based on the return address;

[0332] In the memory corresponding to the address range of the target kernel module, determine the target debugging information;

[0333] The file name is the target file name corresponding to the target kernel module and the system file corresponding to the target debugging information. The version number of the target file is the same as the current kernel version number.

[0334] In one possible implementation, the determining module 13 is specifically used for:

[0335] The address range of at least one kernel module is determined from the information of at least one kernel module;

[0336] Based on the target address range where the return address is located and the address range of the at least one kernel module, the target kernel module corresponding to the currently called function is determined, and the address range of the target kernel module is the target address range.

[0337] In one possible implementation, the determining module 13 is specifically used for:

[0338] The target file is parsed to obtain the target function name and target address offset;

[0339] The target function information of the target function is determined from the stack information based on the target function name;

[0340] Obtain multiple historical fault causes and corresponding historical fault information, including historical function information, historical address offset, and historical blue screen error codes;

[0341] Based on the target function information, the target address offset, and the blue screen error code, a matching process is performed on the multiple historical fault information to obtain multiple second similarities;

[0342] The historical fault cause corresponding to the historical fault information with the highest second similarity is determined as the fault cause.

[0343] The fault cause determination device provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0344] Figure 8 This is a schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this application. Please refer to... Figure 8 The electronic device 20 may include a processor 21 and a memory 22. Exemplarily, the processor 21 and the memory 22 are interconnected via a bus 23.

[0345] The memory 22 stores computer-executed instructions;

[0346] The processor 21 executes the computer execution instructions stored in the memory 22, causing the processor 21 to perform the method as shown in the above method embodiment.

[0347] Figure 8 The electronic device shown can be the host machine described in any of the above embodiments.

[0348] Accordingly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the above-described method embodiments.

[0349] Accordingly, embodiments of this application may also provide a computer program product, including a computer program, which, when executed by a processor, can implement the methods shown in the above-described method embodiments.

[0350] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0351] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0352] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0353] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0354] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0355] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAQ) and / or non-volatile memory, such as read-only memory (ROQ) or flash memory (flash RAQ). Memory is an example of computer-readable media.

[0356] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAQ), static random access memory (SRAQ), dynamic random access memory (DRAQ), other types of random access memory (RAQ), read-only memory (ROQ), electrically erasable programmable read-only memory (EEPROQ), flash memory or other memory technologies, optical disc read-only memory (CD-ROQ), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media do not include transient computer-readable media, such as modulated data signals and carrier waves.

[0357] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0358] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for determining the cause of a fault, characterized in that, Applied to a host machine, wherein a virtual machine is configured on the host machine, the method includes: In response to an operating system failure of the virtual machine, the system startup information of the operating system is obtained from a preset storage space on the host machine. The system startup information is stored in the preset storage space during the startup process of the operating system. Obtain the running information of the virtual machine when the operating system fails; Based on the system startup information and the running information, determine the cause of the operating system failure.

2. The method according to claim 1, characterized in that, Based on the system startup information and the running information, determine the cause of the operating system failure, including: The type of fault in the operating system is determined based on the operational information; Based on the fault type and the system startup information, determine the cause of the operating system failure.

3. The method according to claim 2, characterized in that, Determining the fault type of the operating system based on the operational information includes: The startup status of the operating system is obtained from the running information; If the startup status is a startup failure status, then the fault type is determined to be a startup failure type; If the startup status is a successful startup status, then obtain the error code of the operating system, and determine the fault type based on the error code.

4. The method according to claim 3, characterized in that, Based on the error code, the fault type is determined, including: If the error code includes a rammer error code, then the fault type is determined to be a rammer type. If the error code includes a blue screen error code, then the fault type is determined to be a system blue screen.

5. The method according to any one of claims 2-4, characterized in that, Based on the fault type and the system startup information, determine the cause of the operating system fault, including: Based on the fault type, determine the fault-related information in the system startup information; The cause of the operating system failure is determined based on the failure type and the relevant failure information.

6. The method according to claim 5, characterized in that, Based on the fault type, fault-related information is determined from the system startup information, including: If the fault type is a startup failure type, then multiple object abnormalities are identified in the system startup information, and these multiple object abnormalities are identified as fault-related information. If the fault type is a rammer type, then the input / output device information is determined in the system startup information, and the input / output device information is determined as the fault-related information; If the fault type is a system blue screen, then obtain blue screen related information and determine at least one kernel module information from the system startup information, and determine the blue screen related information and the at least one kernel module information as the fault related information; the blue screen related information includes the current kernel version number, blue screen error code, and stack information.

7. The method according to claim 5 or 6, characterized in that, The fault type is a startup failure type; Determining the cause of the operating system failure based on the failure type and related failure information includes: The abnormal information of the multiple objects is extracted and processed to obtain multiple key abnormal information, which includes multiple abnormal keywords. Retrieve multiple historical fault objects, and the historical object exception information for each historical fault object; The cause of the fault is determined based on the multiple key abnormal information, the multiple historical fault objects, and the historical object abnormal information of each historical fault object.

8. The method according to claim 7, characterized in that, Based on the multiple key abnormal information, the multiple historical fault objects, and the historical object abnormal information of each historical fault object, the cause of the fault is determined, including: Determine the first similarity between each key piece of abnormal information and the abnormal information of each historical object; The historical fault object corresponding to the anomaly information of the first historical object with the highest similarity is identified as the cause of the fault.

9. The method according to claim 5 or 6, characterized in that, The fault type is a rammer type; Determining the cause of the operating system failure based on the failure type and related failure information includes: At least one input / output anomaly is identified in the input / output device information; In the at least one input / output exception information, the execution time in each input / output exception information is determined to obtain multiple execution times; Determine the execution duration between the at least one execution time and the current time to obtain at least one execution duration; In the at least one execution duration, the input / output abnormal information corresponding to the execution duration that is greater than or equal to the preset duration is determined as the cause of the fault.

10. The method according to claim 5 or 6, characterized in that, The fault type is a system blue screen. Determining the cause of the operating system failure based on the failure type and related failure information includes: The target file is determined based on the stack information and the current kernel version number; The cause of the failure is determined based on the target file, the stack information, and the blue screen error code.

11. The method according to claim 10, characterized in that, Based on the stack information and the current kernel version number, the target file is determined, including: Determine the return address of the currently called function from the stack information; The target kernel module corresponding to the currently called function is determined based on the return address; In the memory corresponding to the address range of the target kernel module, determine the target debugging information; The file name is the target file name corresponding to the target kernel module and the system file corresponding to the target debugging information. The version number of the target file is the same as the current kernel version number.

12. The method according to claim 11, characterized in that, Determining the target kernel module corresponding to the currently called function based on the return address includes: The address range of at least one kernel module is determined from the information of at least one kernel module; Based on the target address range where the return address is located and the address range of the at least one kernel module, the target kernel module corresponding to the currently called function is determined, and the address range of the target kernel module is the target address range.

13. The method according to any one of claims 10-12, characterized in that, Based on the target file, the stack trace, and the blue screen error code, the cause of the failure is determined, including: The target file is parsed to obtain the target function name and target address offset; The target function information of the target function is determined from the stack information based on the target function name; Obtain multiple historical fault causes and corresponding historical fault information, including historical function information, historical address offset, and historical blue screen error codes; Based on the target function information, the target address offset, and the blue screen error code, a matching process is performed on the multiple historical fault information to obtain multiple second similarities; The historical fault cause corresponding to the historical fault information with the highest second similarity is determined as the fault cause.

14. A fault cause determination device, characterized in that, The device includes: a first acquisition module, a second acquisition module, and a determination module, wherein, The first acquisition module is used to, in response to a virtual machine operating system failure, acquire the system startup information of the operating system from a preset storage space on the host machine, wherein the system startup information is stored in the preset storage space during the startup process of the operating system; The second acquisition module is used to acquire the running information of the virtual machine when the operating system fails; The determining module is used to determine the cause of the operating system failure based on the system startup information and the running information.

15. An electronic device, characterized in that, include: At least one processor; as well as a memory communicatively coupled to the at least one processor; The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, cause the electronic device to perform the method according to any one of claims 1-13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in any one of claims 1-13.

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-13.

Images