System exception processing method and device and storage medium

Abstract

The invention relates to a system exception processing method and device and a storage medium. The system exception handling method comprises the following steps of: responding to starting a system recovery scheme to carry out system recovery, and acquiring an identifier of the system recovery scheme and a recovery judgment thread; and based on the identifier and the recovery judgment thread, determining an operation result of system recovery performed by the system recovery scheme, the operation result including successful system recovery operation performed by the system and the recovery scheme or failed system recovery operation performed by the system recovery scheme. According to the system exception handling method, whether the recovery operation in the system exception handling is successful or not is determined, so that research and development personnel can know the stability condition of system operation conveniently, and a rescue mechanism can complete the recovery operation again conveniently.

Description

Technical Field

[0001] The present disclosure relates to the field of terminal technology, and in particular to a system exception handling method, device and storage medium. Background Art

[0002] With the development of terminal technology, system exception handling is also constantly improving and developing.

[0003] Many operating systems in the related art provide system recovery solutions for when system anomalies occur. When the system anomalies occur repeatedly, the system recovery solution is triggered to make the system run stably again. However, the related art for system anomalies only provides different system recovery solutions, but does not provide a method for determining whether the system recovery operation is successful. When the system recovery operation is performed according to different system recovery solutions, it is impossible to determine whether the recovery operation taken according to the system recovery solution is successful. That is, after the system recovery solution is executed, the system may still be in an abnormal state, and it is impossible to know whether the system is running stably again, which will cause the system recovery solution to be triggered again for the recovery operation. Summary of the invention

[0004] In order to overcome the problems existing in the related art, the present disclosure provides a system exception handling method, device and storage medium.

[0005] According to a first aspect of an embodiment of the present disclosure, a system exception handling method is provided, comprising: performing a system recovery in response to enabling a system recovery scheme, obtaining an identifier of the system recovery scheme and a recovery judgment thread, the identifier comprising a first identifier or a second identifier, the first identifier being an identifier used when the system recovery scheme was last used to perform a system recovery, and the second identifier being an identifier newly generated for the system recovery scheme when performing a system recovery, the recovery judgment thread being used to record information of the system recovery scheme before the system recovery scheme performs a system recovery operation successfully; based on the identifier and the recovery judgment thread, determining an operation result of the system recovery performed by the system recovery scheme, the operation result comprising a success of the system recovery operation according to the system recovery scheme, or a failure of the system recovery operation according to the system recovery scheme.

[0006] In one embodiment, the operation result of the system recovery performed by the system recovery scheme is determined based on the identifier and the recovery judgment thread, including: if the identifier is the first identifier and the recovery judgment thread is alive, then the operation result of the system recovery performed by the system recovery scheme is determined to be a failure of the system recovery operation.

[0007] In one embodiment, the operation result of the system recovery performed by the system recovery scheme is determined based on the identifier and the recovery judgment thread, including: if the identifier is a second identifier and the recovery judgment thread is not alive, then the operation result of the system recovery performed by the system recovery scheme is determined to be a successful system recovery operation; the second identifier is a newly generated identifier for the system recovery scheme when the system recovery is performed.

[0008] In one embodiment, the identifier is generated in the following manner: in response to performing system recovery, detecting whether there is an identifier in the system recovery solution; if there is an identifier, generating a first identifier, which is the existing identifier; if there is no identifier, generating a second identifier.

[0009] In one embodiment, the recovery judgment thread is created in the following manner: in response to completing the operation of system recovery based on the system recovery plan, the identifier is determined; if the identifier is the first identifier, the operation of the current recovery judgment thread is terminated, and a new recovery judgment thread is re-enabled; or, the current recovery judgment thread is re-enabled; if the identifier is the second identifier, a new recovery judgment thread is enabled.

[0010] In one embodiment, the method further includes: after enabling a new recovery judgment thread, monitoring system abnormalities at set time intervals; if a system abnormality is detected, recording system abnormality information; if no system abnormality is detected within a time threshold, terminating the new recovery judgment thread.

[0011] According to a second aspect of an embodiment of the present disclosure, there is provided a system exception handling device, comprising:

[0012] A processing unit is used to, in response to enabling a system recovery plan and performing a system recovery, obtain an identifier of the system recovery plan and a recovery judgment thread, the identifier including a first identifier or a second identifier, the first identifier being an identifier used when the system recovery plan was used last time to perform a system recovery, and the second identifier being an identifier newly generated for the system recovery plan when performing a system recovery, and the recovery judgment thread is used to record information of the system recovery plan before the system recovery plan successfully performs a system recovery operation; a determination unit is used to determine an operation result of the system recovery plan performing the system recovery based on the identifier and the recovery judgment thread, the operation result including a success of the system recovery operation according to the system recovery plan, or a failure of the system recovery operation according to the system recovery plan.

[0013] In one embodiment, the determination unit determines the operation result of the system recovery scheme performing system recovery based on the identifier and the recovery judgment thread in the following manner: if the identifier is the first identifier and the recovery judgment thread survives, then it is determined that the operation result of the system recovery scheme performing system recovery is a failure of the system recovery operation.

[0014] In one embodiment, the determination unit determines the operation result of the system recovery performed by the system recovery scheme based on the identifier and the recovery judgment thread in the following manner: if the identifier is the second identifier and the recovery judgment thread is not alive, then the operation result of the system recovery performed by the system recovery scheme is determined to be a successful system recovery operation; the second identifier is a newly generated identifier for the system recovery scheme when the system recovery is performed.

[0015] In one embodiment, the processing unit generates an identifier in the following manner: in response to performing system recovery, detecting whether an identifier exists in the system recovery plan; if an identifier exists, generating a first identifier, the first identifier being the existing identifier; if an identifier does not exist, generating a second identifier.

[0016] In one embodiment, the processing unit creates a recovery judgment thread in the following manner: in response to completing an operation of performing system recovery based on a system recovery plan, determining the identifier; when the identifier is a first identifier, terminating the operation of the current recovery judgment thread and re-enabling a new recovery judgment thread; or, re-enabling the current recovery judgment thread; when the identifier is a second identifier, enabling a new recovery judgment thread.

[0017] In one embodiment, the processing unit is also used to: monitor system abnormalities at set time intervals after enabling a new recovery judgment thread; record system abnormality information when a system abnormality is detected; and terminate the new recovery judgment thread when no system abnormality is detected within a time threshold.

[0018] According to a third aspect of an embodiment of the present disclosure, a terminal device is provided, comprising: a processor; and a memory for storing processor executable instructions; wherein the processor is configured to execute the executable instructions to execute the display control method in the first aspect or any one of the implementations of the first aspect.

[0019] According to a fourth aspect of an embodiment of the present disclosure, a storage medium is provided, in which instructions are stored. When the instructions in the storage medium are executed by a processor of a terminal, the terminal device is enabled to execute the system exception handling method in the first aspect or any one of the implementations of the first aspect.

[0020] The technical solution provided by the embodiments of the present disclosure may include the following beneficial effects: the system recovery operation result can be known based on the recovery judgment thread and the identification of the obtained system recovery plan, and the operation result of the system recovery according to the system recovery plan and the information recorded by the recovery judgment thread are helpful for R&D personnel to understand the stability of the system operation and facilitate completing another recovery operation according to the recovery plan.

[0021] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0023] Figure 1 The present invention is a flowchart of a method for handling system exceptions according to an exemplary embodiment.

[0024] Figure 2 The invention is a flowchart showing a method of determining a system operation result failure according to an exemplary embodiment.

[0025] Figure 3 The invention is a flowchart showing a method of determining whether a system operation result is successful according to an exemplary embodiment.

[0026] Figure 4 The present invention is a flowchart showing a method of generating a mark according to an exemplary embodiment.

[0027] Figure 5 The present invention is a flowchart of starting a recovery judgment thread according to an exemplary embodiment.

[0028] Figure 6 The present invention is a flowchart showing a method of terminating and resuming a judgment thread according to an exemplary embodiment.

[0029] Figure 7 The present invention is a flowchart showing a scenario of triggering a system rescue mechanism according to an exemplary embodiment.

[0030] Figure 8 The figure is a schematic diagram showing a system abnormality recovery according to an exemplary embodiment.

[0031] Fig. 9 The figure is a flow chart showing generation of identification information according to an exemplary embodiment.

[0032] Fig.10 The figure is a schematic diagram showing a method of judging whether a recovery judging thread needs to be started according to an exemplary embodiment.

[0033] Fig.11 The figure is a flowchart showing the operation of a recovery judgment thread according to an exemplary embodiment.

[0034] Fig.12 The present invention is a block diagram of a system exception handling device according to an exemplary embodiment.

[0035] Fig.13 The invention is a block diagram of a device for handling system exceptions according to an exemplary embodiment. DETAILED DESCRIPTION

[0036] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present disclosure.

[0037] The method for determining system abnormality recovery provided in the embodiment of the present disclosure is applied to the scenario of recovering system kernel abnormality. The method for determining system abnormality recovery involved in the embodiment of the present disclosure is mainly applied to the scenario of system operation. For example, it is applied to the scenario after the system recovery operation is completed.

[0038] In the related art, when the system monitors an abnormality in the system program, a variety of different system abnormality recovery schemes are provided. When the system abnormalities occur repeatedly, different system recovery operations are triggered to ensure that the system runs stably again. However, the system does not provide a method for determining whether the recovery operation is successful for different recovery schemes. In other words, it is impossible to know whether the system is running stably again, which may cause the system to trigger the recovery operation again.

[0039] Furthermore, when the system starts a recovery operation, the related technology is unable to record the specific cause of the system abnormality, such as the severity of the system abnormality, the duration of the system abnormality when the severity of the abnormality occurs, etc. The recovery operation only performs recovery processing based on the known abnormalities detected, and is unable to determine the specific circumstances that caused the unknown abnormality.

[0040] In view of this, the present disclosure provides a method for determining system abnormality recovery. After executing recovery operations corresponding to different recovery schemes for different system abnormalities, whether the recovery operation performed by the recovery scheme is successful is judged based on identification information that can reflect whether the system recovery operation is successful, and the information obtained by the recovery scheme during the recovery operation is recorded, such as the recovery status and information causing the system abnormality, so as to further judge the success rate of the recovery scheme.

[0041] Figure 1 FIG. 1 is a flowchart of a method for handling system exceptions according to an exemplary embodiment. Figure 1 As shown, the system exception handling method is used in the terminal, including the following steps:

[0042] In step S11 , in response to the system recovery being enabled, the system is recovered, and an identifier of the system recovery scheme and a recovery determination thread are acquired.

[0043] In the embodiment of the present disclosure, after the system recovery operation is completed, the system recovery plan is started, and it is determined whether the system is recovered according to the system recovery plan.

[0044] The system recovery plan can be understood as a plan taken to solve the system anomaly according to the system anomaly that occurs in the system. The plan can also be called a rescue mechanism, and the operation taken to implement the plan can also be called a rescue operation.

[0045] The identifier can be understood as a sign for determining whether the system has returned to a stable operating state after the system rescue operation is completed. The identifier includes a first identifier or a second identifier. The first identifier is the identifier used when the system was last restored using the system recovery plan. The second identifier is the identifier newly generated for the system recovery plan when the system is restored.

[0046] The recovery judgment thread can be understood as a thread generated when the rescue operation is started and used to judge whether the system has recovered to a stable state after the rescue operation is completed. The recovery judgment thread is used to record the information of the system recovery plan before the system recovery operation is successfully performed.

[0047] In step S12, based on the identifier and the recovery judgment thread, the operation result of the system recovery solution for system recovery is determined.

[0048] In the disclosed embodiment, the result after receiving the system rescue is obtained according to the obtained identifier and the recovery judgment thread, wherein the operation result includes the system recovery scheme performing the system recovery operation successfully, or the system recovery scheme performing the system recovery operation failed.

[0049] In the disclosed embodiment, a recovery judgment thread is started to judge the running state of the system after the rescue operation is completed according to the identification information, and the information of the system recovery plan under the running state of the system is recorded, so that when the system starts the system rescue operation again, the rescue operation can be accurately implemented according to the information recorded by the recovery judgment thread.

[0050] In the disclosed embodiment, the result of the system recovery operation performed according to the system recovery solution is determined according to the identifier obtained by the system and the recovery judgment thread.

[0051] Figure 2 FIG. 1 is a flow chart showing a method of determining a system operation result failure according to an exemplary embodiment. Figure 2 As shown, the following steps are included:

[0052] In step S21, the flag is the first flag, and the thread is judged to be alive after recovery.

[0053] In the embodiment of the present disclosure, the obtained identifier is determined to be the first identifier, and the thread survival is resumed in the case of the first identifier.

[0054] Among them, the first identification can be understood as the sign information that the system has not recovered to a stable operating state after the system adopts the rescue mechanism to perform the rescue operation.

[0055] In step S22, it is determined that the result of the system recovery operation performed by the system recovery solution is that the system recovery operation fails.

[0056] In the disclosed embodiment, it is determined that the system has not recovered to a stable operating state based on the obtained first identification information.

[0057] The system recovery plan may be understood as a plan for performing system recovery operations according to the system recovery plan.

[0058] In the embodiment of the present disclosure, the obtained identifier is the first identifier information and the survival state of the recovery judgment thread is used to facilitate the research and development personnel to determine that the system recovery operation fails.

[0059] Figure 3 FIG. 1 is a flow chart showing a method for determining the success of a system operation result according to an exemplary embodiment. Figure 3 As shown, the following steps are included:

[0060] In step S31, the flag is the second flag, and the recovery judgment thread is not alive.

[0061] In the embodiment of the present disclosure, it is determined that the obtained identifier is the second identifier, and in the case of the second identifier, the recovery judgment thread is not alive.

[0062] The second identification can be understood as the sign information that the system recovers to a stable operating state after the system adopts the rescue mechanism to perform the rescue operation.

[0063] In step S32, it is determined that the result of the system recovery operation performed by the system recovery solution is that the system recovery operation is successful.

[0064] Among them, the success of the system recovery operation can be understood as the current state of the system is the state after the rescue operation according to the rescue mechanism is successfully completed, that is, the current state of the system is not in the system abnormal state included in the rescue mechanism, or the current state of the system is a stable operation state.

[0065] In the embodiment of the present disclosure, according to the obtained identification being the second identification information and the recovery judgment thread not being alive, it is convenient for the research and development personnel to determine that the system recovery operation is successful.

[0066] In the disclosed embodiment, the system determines whether the system rescue operation is successful based on whether the identification is detected.

[0067] Figure 4 FIG. 1 is a flow chart showing a method of generating a mark according to an exemplary embodiment. Figure 4 As shown, the following steps are included:

[0068] In step S41, in response to performing system recovery, it is detected whether there is an identification of the system recovery solution.

[0069] In the embodiment of the present disclosure, after the system performs a recovery operation, it is detected whether there is identification information in the system recovery solution according to the information recorded in the recovery judgment thread.

[0070] Among them, detecting whether there is an identification in the system recovery judgment plan can be understood as further judging whether the system is rescued successfully and how to obtain information after the system rescue is successful, so as to facilitate the operation of the next rescue mechanism.

[0071] In step S42, if the identifier exists, a first identifier is generated, and the first identifier is the existing identifier.

[0072] In the disclosed embodiment, if identification information exists in the detection system recovery plan, a first identification is generated.

[0073] The first identifier may be understood as an identifier recorded when the system resets the last failed rescue operation.

[0074] In step S43, if the identifier does not exist, a second identifier is generated.

[0075] In the disclosed embodiment, if identification information does not exist in the detection system recovery solution, a second identification is generated.

[0076] The second identifier can be understood as an identifier generated after the last rescue operation of the system is successful, and the identifier is a random character string.

[0077] In the embodiment of the present disclosure, it is determined that there is an identifier in the system recovery plan, so that when the next rescue mechanism of the system takes effect, it can be judged according to the identifier in the system whether the system is currently in a stable operating state.

[0078] In the embodiment of the present disclosure, after it is determined that there is an identifier in the system, it is further determined that the system starts a recovery judgment thread.

[0079] Figure 5 FIG. 1 is a flowchart showing a method of starting a recovery judgment thread according to an exemplary embodiment. Figure 5 As shown, the following steps are included:

[0080] In step S51, in response to completing the operation of performing system recovery based on the system recovery solution, an identifier is determined.

[0081] In the embodiment of the present disclosure, according to the completion of the operation of performing system recovery based on the system recovery solution, it is determined that the current identifier is the first identifier or the second identifier.

[0082] In step S52, if the identifier is the first identifier, the operation of the current recovery judgment thread is terminated, and a new recovery judgment thread is re-enabled; or, the existing recovery judgment thread is reused.

[0083] In the disclosed embodiment, how to start the system recovery judgment thread is determined according to the determined first identifier, for example, reusing the current system recovery judgment thread, or re-enabling a new recovery judgment thread.

[0084] In step S53, if the mark is the second mark, a new recovery judgment thread is started.

[0085] In the embodiment of the present disclosure, how to start the system recovery judgment thread is determined according to the determined second identifier, for example, a new recovery judgment thread is enabled.

[0086] In the embodiment of the present disclosure, according to the last running state of the system, it is determined to enable the recovery judgment thread in the corresponding state, so that the system can quickly perform a second rescue operation.

[0087] Figure 6 FIG. 1 is a flowchart showing a method of terminating and resuming a judgment thread according to an exemplary embodiment. Figure 6 As shown, the following steps are included:

[0088] In step S61, after the recovery determination thread is enabled, the system abnormality is monitored at set intervals.

[0089] In the disclosed embodiment, after the recovery judgment thread is enabled, the system operation status is detected at regular intervals, such as setting a fixed time and detecting system abnormalities after the fixed time interval.

[0090] The setting time may be understood as setting the time according to an average time interval between consecutive system anomalies, or a time interval between multiple system anomalies.

[0091] In step S62, if a system abnormality is detected, the system abnormality information is recorded.

[0092] In the embodiment of the present disclosure, when the system detects a system abnormality, the recovery judgment thread records the system abnormality information.

[0093] The system abnormality information may be understood as identification information when the system abnormality occurs, abnormality level information, and abnormality status information.

[0094] In step S63, if no system abnormality is detected within the time threshold, the new recovery determination thread is terminated.

[0095] In the embodiment of the present disclosure, when the system is within the time threshold and no system abnormality is detected, the current recovery judgment thread is terminated and a new recovery judgment thread is started.

[0096] The time threshold can be understood as the recovery judgment thread recording the system recovery status at fixed intervals until the system does not have an abnormality after a number of fixed times, indicating that the system is within the time threshold and no system abnormality is detected. For example, if the system does not detect an abnormality within the fixed time of the first level, and then the system does not detect an abnormality until the fixed time of the sixth level, then the system is in a state where no system abnormality is detected.

[0097] In the disclosed embodiment, the purpose of determining the recovery judgment thread in the state of the started system is to determine whether the state of the system is a normal state after the rescue operation is completed. If so, it indicates that the current state of the system is not in the state recorded by the rescue mechanism, that is, the current recovery judgment thread has successfully functioned, and a new recovery judgment thread is started; if not, it indicates that the current state of the system is still in the state recorded by the rescue mechanism, and the current recovery judgment thread is reused, or a new recovery judgment thread is enabled.

[0098] In the disclosed embodiment, whether the recovery operation is successful is determined based on different reasons for system startup, and a recovery judgment thread is started, thereby avoiding unnecessary restarts of the system due to abnormalities in the upper-layer mechanism of the system and improving the accuracy of the implementation of the system recovery plan.

[0099] In the disclosed embodiment, when an exception occurs during the operation of the system, the system executes different system recovery plans according to different exception situations. After the system recovery operation is completed, the system starts a recovery judgment thread and detects the system operation status within a certain period of time to determine whether the system recovery operation taken according to the system recovery plan is successful.

[0100] Figure 7 FIG. 1 is a flowchart showing a scenario in which a system rescue mechanism is triggered according to an exemplary embodiment. Figure 7 As shown, the following steps are included.

[0101] In step S71, the terminal device operates.

[0102] In one implementation, when the terminal device is started, the system kernel is started first, that is, the system rescue program is started.

[0103] The operation of the terminal device can be understood as starting all the applications required for the rescue operation, for example, starting the resident system applications, starting the system desktop, starting the system services and core components, etc.

[0104] In step S72, the system core services are detected.

[0105] In one implementation, the system starts a monitor to detect system core services, for example, to detect all application programs that need to be run for rescue operations of the system.

[0106] In step S73, a rescue operation is performed.

[0107] In one embodiment, when the system detects that multiple system anomalies have occurred, a rescue operation is performed, for example, a system recovery plan is determined, the system anomaly type is obtained based on the system anomaly label, and the system anomaly levels of different system anomaly types are analyzed based on the system anomaly type, and a system recovery plan that matches the anomaly level in the current anomaly type is determined.

[0108] Among them, multiple exceptions can be understood as the system detecting multiple exceptions occurring in the system.

[0109] In one implementation, for different exceptions and exception severity levels, a recovery plan matching the exception level in the current exception type is determined, and system recovery operations are accurately performed to avoid unnecessary system data loss due to recovery of upper-layer applications of the system.

[0110] In one embodiment, when an exception occurs during system operation, the system's recovery judgment thread determines the type of system exception and the level of the exception based on the recorded information, which is conducive to quickly implementing the corresponding recovery operation at the exception level of the exception type when performing a second recovery operation due to a failed recovery operation according to the system recovery plan.

[0111] Figure 8 FIG. 1 is a schematic diagram showing a system abnormal recovery according to an exemplary embodiment. Figure 8 shown.

[0112] In one implementation, the system starts a monitor to execute system monitoring core services, rescue mechanisms, and recovery judgment threads. After the rescue operation is completed, the recovery judgment thread is started to determine whether the system rescue is successful, and the rescue situation is recorded. It is also recorded whether the rescue of the exception is successful, and the exception information that caused the current system exception is captured.

[0113] Among them, the system startup monitor can be understood as a device used to monitor various operations occurring in the system and execute the system monitoring core service. The system monitoring core service can be understood as a component that monitors the system for abnormalities after the system is started. The rescue mechanism can be understood as judging the severity and type of the system abnormality based on the abnormal components monitored by the system monitoring core service, and starting the system rescue mechanism.

[0114] The recovery judgment thread can be understood as a thread that determines whether the system's rescue mechanism is successful after the system performs a recovery operation according to the rescue mechanism. The recovery system can be understood as a backup system when the system rescue mechanism does not work.

[0115] Recording the rescue situation at regular intervals can be understood as the system recording the normal operating status of the system at certain time thresholds. Whether the record is successful can be understood as the recovery judgment thread recording the recovery information, exception information, and identification information, etc. Capturing exception information can be understood as when the recovery judgment thread is started, the system runs normally for a certain period of time, and if an exception occurs, the information that caused the system exception is captured.

[0116] In one implementation, the system core monitoring service monitors whether the rescue mechanism has ended, and uses a recovery judgment thread to determine whether the rescue operation is successful after the rescue mechanism takes effect, records recovery information or captures abnormal information and identification information, and starts the recovery system when the rescue operation fails.

[0117] In one implementation, identification information is generated when the system is started, and a recovery judgment thread records the identification information generated when the system is started again. When the system is started again, the recovery judgment thread determines the reason for starting the system based on the recorded identification information. The obtained identification information is identification information in two cases, namely, the last identification information that is reset, or the newly generated identification information when the system is started again. The success rate of the system rescue mechanism is obtained based on the identification information recorded by the recovery judgment thread when the system is started again and the identification information when the system is started each time.

[0118] In one implementation, the success of the rescue operation is determined based on the recovery to understand the success rate of the system rescue mechanism, and the system rescue situation is obtained to understand whether the system is running well, helping R&D personnel to quickly locate and handle problems, thereby improving user experience.

[0119] Fig. 9 FIG. 1 is a flowchart showing generation of identification information according to an exemplary embodiment. Fig. 9 As shown, the following steps are included:

[0120] In step S91, the system starts.

[0121] In one implementation, system startup can be understood as restarting the system after a rescue mechanism processes the system exception when an exception occurs, or starting the system for the first time.

[0122] In step S92, whether bootID exists.

[0123] In one implementation, it is determined whether the identification information exists, for example, the identification information is set as bootID.

[0124] Among them, bootID can be understood as a bootID stored in a file or partition when the system starts, that is, the bootID is an identification information saved by the system in a storage file or partition after the system executes a rescue operation of a rescue mechanism. The identification information can determine whether the rescue operation performed according to the rescue mechanism has failed at a certain stage when restoring the system.

[0125] In step S93, the bootID is read.

[0126] In one implementation, when the bootID exists, it indicates that the rescue operation performed by the system rescue mechanism has failed, and the bootID is a bootID stored in a file or partition. Then, the current bootID is read, the reason for the system restart is analyzed based on the current bootID, and the bootID is deleted after reading.

[0127] In step S94, a bootID is set, which is a random character string.

[0128] In one implementation, when the bootID does not exist, it indicates that the system has successfully executed the rescue operation performed by the rescue mechanism. At this time, the bootID does not exist in the storage file or partition. A bootID is randomly generated based on the effect of a certain level of an abnormality of a certain type in the system where the rescue mechanism is located. The bootID can be understood as a random string.

[0129] In step S95, the system rescue mechanism is started.

[0130] In one implementation, based on the determined bootID, the generated bootID is saved and a system rescue mechanism is started.

[0131] In one implementation, the system starts up and determines whether there is a bootID generated by a rescue operation performed by the last rescue mechanism. If so, it indicates that the current system operating state is the system operating state caused by the unsuccessful execution of the rescue operation in the system rescue mechanism. If not, it indicates that the current system operating state is the system operating state after the successful execution of the rescue operation in the system rescue mechanism. This helps the system to accurately determine the reason for the system restart when performing the rescue operation for the second time, and thus efficiently perform the rescue operation.

[0132] Fig.10 FIG. 1 is a schematic diagram showing a method for determining whether a recovery determination thread needs to be started according to an exemplary embodiment. Fig.10 shown.

[0133] In one implementation, based on system startup, a reason for restarting the system is analyzed.

[0134] In one implementation, when the system enters Recovery, that is, restores the system, or restarts the system, the bootID is recorded. At this time, the terminal device is restarted. When the terminal device checks the existence of the bootID after restarting, the bootID checked at this time can be understood as the one generated after the system rescue mechanism takes effect.

[0135] If the bootID checked is the bootID reset by entering Recovery, that is, restoring the system, then the reason for the restart is determined to be Recovery, that is, restoring the system, and the recovery failure is recorded at this time.

[0136] If the bootID checked is a randomly generated bootID after the system is restarted, it is determined that the restart reason is other, and the recovery judgment thread is started at this time.

[0137] Among them, entering Recovery can be understood as the system entering the recovery system, and recording bootID can be understood as recording the identification information generated in the current system, such as recording the bootID reset after the system enters Recovery or recording the newly generated bootID after the system is restarted.

[0138] Restart can be understood as a system restart caused by the system entering the recovery system due to a failed recovery operation, or a system restart caused by the current state of the system being not any abnormal state recorded in the rescue mechanism after the system recovery operation is successful.

[0139] Checking whether the bootID exists can be understood as checking whether the identification information currently generated by the system exists. If the restart reason is Recovery, recording the recovery failure can be understood as the identification information currently generated by the system is the bootID generated by the system restart due to the system recovery failure entering the recovery system. At this time, the system recovery failure is recorded, and the restart reason is other. Starting the recovery judgment thread can be understood as, after the system recovery operation is successful, the bootID generated by the system restart caused by non-system operation failure indicates that the system recovery operation is successful, and the recovery judgment thread is started to judge the next system recovery operation.

[0140] In one implementation, the reason for system restart is determined according to the existence of the bootID, and how to start the recovery determination thread is determined according to the reason for system restart.

[0141] Fig.11 FIG. 1 is a flowchart showing a recovery judgment thread operation according to an exemplary embodiment. Fig.11 As shown, the following steps are included:

[0142] In step S111, the system rescue ends.

[0143] In one implementation, it is determined that the rescue operation performed by the system is completed, and the information recorded when the rescue operation is performed is uploaded to a storable application, such as uploading to the cloud.

[0144] In one implementation, the rescue mechanism may attempt to fix the problem by clearing application data, uninstalling the application, or restarting the device. Failure of the rescue operation performed by the rescue mechanism may cause the system to enter a recovery system, where data needs to be cleared to restore the system to a stable operating state.

[0145] In step S112, it is resumed to determine whether the thread is running.

[0146] In one implementation, after the rescue operation is completed, a recovery judgment thread is started to determine whether the rescue operation executed according to the system rescue mechanism is successful, and the rescue situation is recorded, whether the abnormality is successfully recovered, and the abnormality information of the system is captured.

[0147] The recovery judgment thread is judged whether it is running according to the information recorded during the rescue operation performed by the system rescue mechanism. Whether the recovery judgment thread is running can be understood as whether the basis for the system to enable the recovery judgment thread is to reset the last identification information.

[0148] In step S113, the thread execution is terminated.

[0149] In one implementation, the thread is terminated based on the recovery judgment thread running, that is, after the system is started, it is checked that the bootID exists, indicating that this system startup is a recovery measure taken by the rescue mechanism, and the thread is terminated at this time.

[0150] Among them, terminating the thread operation can be understood as terminating the recovery judgment thread that causes the system to restart due to resetting the last identification information. Resetting the last identification information indicates that the rescue operation of the rescue mechanism executed by the system last time failed. BootID can be understood as being used to identify multiple rescues triggered by repeated crashes in the system.

[0151] In step S114, a recovery determination thread is started.

[0152] In one implementation, the recovery determination thread is started based on the fact that the recovery determination thread is not running, that is, after the system is started, it is checked that the bootID does not exist, and a random string is generated as the bootID.

[0153] Among them, starting the recovery judgment thread can be understood as starting the recovery judgment thread of newly generated identification information, or reusing and resetting the recovery judgment thread of the last identification information. If the recovery judgment thread of newly generated identification information is started, it indicates that the last rescue operation performed by the rescue mechanism of the system was successful. If the recovery judgment thread of the last identification information is reused and reset, it indicates that the last rescue operation performed by the rescue mechanism of the system failed.

[0154] In step S115 , the sleeping state is maintained within a time threshold.

[0155] In one implementation, after the recovery determination thread is started, the system is kept running stably for a certain period of time, such as being in a sleep state within a time threshold.

[0156] The time threshold can be understood as the time value used by the recovery judgment thread to record the system operation status at fixed intervals when an abnormality occurs in the system, and the sleep state can be understood as a state in which the system operates smoothly.

[0157] In step S116, recovery information is recorded or abnormal information is captured.

[0158] In one implementation, after the rescue operation is completed, the state of the recovery judgment thread is detected, and according to the state of the recovery judgment thread, the recovery information is recorded in a designated file, or the system abnormality information is recorded.

[0159] Among them, recording recovery information can be understood as that the rescue operation taken by the system according to the rescue mechanism is successful, and the current state of the system is not the state recorded by the rescue mechanism, then the recovery information is recorded, such as the recovery operation information recorded by the rescue mechanism according to the severity of the system abnormality, and capturing abnormal information can be understood as that the rescue operation taken by the system according to the rescue mechanism fails, and the current state of the system is the state recorded by the rescue mechanism, then the abnormal information is captured, such as the recovery failure information recorded by the rescue mechanism according to the severity of the system abnormality.

[0160] In step S117, the sleeping state is maintained within a plurality of time thresholds.

[0161] In one implementation, it is determined whether the system remains in a sleep state within a plurality of time thresholds. If not, it indicates that the system is not in a stable operation state, and a recovery determination thread is started.

[0162] The multiple time thresholds may be understood as maintaining a sleep state of a fixed time threshold under multiple different abnormality levels.

[0163] In step S118, the recovery determination thread stops running.

[0164] In one implementation, if the system is determined to be in a sleep state within multiple time thresholds, it means that the current state of the system is not the state recorded by the rescue mechanism, that is, the system rescue operation is successful and the recovery determination thread stops running.

[0165] In one implementation, a recovery judgment thread is used to obtain information on whether a system rescue mechanism is successful without destroying the device. The success rate of the system rescue mechanism is obtained based on multiple identification information recorded by the system and identification information of different system restart reasons represented in the multiple identification information. The rescue situation of the rescue operation in the rescue mechanism is then understood, and the operating status of the system is understood, helping R&D personnel to improve the user experience in a targeted manner and quickly locate and resolve problems.

[0166] Based on the same concept, the embodiment of the present disclosure also provides a system exception handling device.

[0167] It is understandable that the system exception handling device provided by the embodiment of the present disclosure includes hardware structures and / or software modules corresponding to the execution of each function in order to realize the above functions. In combination with the units and algorithm steps of each example disclosed in the embodiment of the present disclosure, the embodiment of the present disclosure can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solution of the embodiment of the present disclosure.

[0168] Fig.12 is a block diagram of a system exception handling device according to an exemplary embodiment. Fig.12 , the device 100 includes a processing unit 101 and a determining unit 102.

[0169] The processing unit 101 is used to obtain an identifier of the system recovery plan and a recovery judgment thread in response to enabling a system recovery plan and performing a system recovery. The identifier includes a first identifier or a second identifier. The first identifier is an identifier used when the system recovery plan was used to perform a system recovery last time, and the second identifier is an identifier newly generated for the system recovery plan when performing a system recovery. The recovery judgment thread is used to record information about the system recovery plan before the system recovery plan successfully performs a system recovery operation.

[0170] The determination unit 102 is used to determine the operation result of the system recovery scheme based on the identifier and the recovery judgment thread, and the operation result includes whether the system recovery scheme performs the system recovery operation successfully or fails.

[0171] In one implementation, the determination unit 102 determines the operation result of the system recovery plan performing system recovery based on the identifier and the recovery judgment thread in the following manner; if the identifier is the first identifier and the recovery judgment thread survives, then the operation result of the system recovery plan performing system recovery is determined to be a failure of the system recovery operation.

[0172] In one embodiment, the determination unit 102 determines the operation result of the system recovery plan performing system recovery based on the identifier and the recovery judgment thread in the following manner: if the identifier is the second identifier and the recovery judgment thread is not alive, then the operation result of the system recovery plan performing system recovery is determined to be a successful system recovery operation; the second identifier is a newly generated identifier for the system recovery plan when performing system recovery.

[0173] In one embodiment, the processing unit 101 generates an identifier in the following manner: in response to performing system recovery, detecting whether there is an identifier for the system recovery solution; if there is an identifier, generating a first identifier, the first identifier being an existing identifier; if there is no identifier, generating a second identifier.

[0174] In one embodiment, the processing unit 101 creates a recovery judgment thread in the following manner: in response to completing an operation of performing system recovery based on a system recovery plan, determining an identifier; if the identifier is a first identifier, terminating the operation of the current recovery judgment thread and re-enabling a new recovery judgment thread; or, reusing an existing recovery judgment thread; if the identifier is a second identifier, enabling a new recovery judgment thread.

[0175] In one embodiment, the processing unit 101 is also used to: after enabling a new recovery judgment thread, monitor system abnormalities at set time intervals; if a system abnormality is detected, record system abnormality information; if no system abnormality is detected within a time threshold, terminate the new recovery judgment thread.

[0176] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0177] Fig.13 2 is a block diagram of an apparatus 200 for system exception handling according to an exemplary embodiment. For example, the apparatus 200 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0178] Reference Fig.13 , the device 200 may include one or more of the following components: a processing component 202 , a memory 204 , a power component 206 , a multimedia component 208 , an audio component 210 , an input / output (I / O) interface 212 , a sensor component 214 , and a communication component 216 .

[0179] The processing component 202 generally controls the overall operation of the device 200, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 202 may include one or more processors 220 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 202 may include one or more modules to facilitate the interaction between the processing component 202 and other components. For example, the processing component 202 may include a multimedia module to facilitate the interaction between the multimedia component 208 and the processing component 202.

[0180] The memory 204 is configured to store various types of data to support operations on the device 200. Examples of such data include instructions for any application or method operating on the device 200, contact data, phone book data, messages, pictures, videos, etc. The memory 204 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0181] The power component 206 provides power to the various components of the device 200. The power component 206 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device 200.

[0182] The multimedia component 208 includes a screen that provides an output interface between the device 200 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 208 includes a front camera and / or a rear camera. When the device 200 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0183] The audio component 210 is configured to output and / or input audio signals. For example, the audio component 210 includes a microphone (MIC), and when the device 200 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 204 or sent via the communication component 216. In some embodiments, the audio component 210 also includes a speaker for outputting audio signals.

[0184] I / O interface 212 provides an interface between processing component 202 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0185] The sensor assembly 214 includes one or more sensors for providing various aspects of the status assessment of the device 200. For example, the sensor assembly 214 can detect the open / closed state of the device 200, the relative positioning of components, such as the display and keypad of the device 200, the sensor assembly 214 can also detect the position change of the device 200 or a component of the device 200, the presence or absence of user contact with the device 200, the orientation or acceleration / deceleration of the device 200 and the temperature change of the device 200. The sensor assembly 214 can include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 214 can also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 214 can also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor or a temperature sensor.

[0186] The communication component 216 is configured to facilitate wired or wireless communication between the device 200 and other devices. The device 200 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 216 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 216 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0187] In an exemplary embodiment, the apparatus 200 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components to perform the above method.

[0188] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 204 including instructions, and the instructions can be executed by the processor 220 of the device 200 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0189] It is to be understood that in the present disclosure, "plurality" refers to two or more than two, and other quantifiers are similar. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. The singular forms "a", "the" and "the" are also intended to include plural forms, unless the context clearly indicates other meanings.

[0190] It is further understood that the terms "first", "second", etc. are used to describe various information, but such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other, and do not indicate a specific order or degree of importance. In fact, the expressions "first", "second", etc. can be used interchangeably. For example, without departing from the scope of the present disclosure, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information.

[0191] It will be further understood that the terms “center”, “longitudinal”, “lateral”, “front”, “back”, “up”, “down”, “left”, “right”, “vertical”, “horizontal”, “top”, “bottom”, “inside”, “outside”, etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the present embodiment and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation.

[0192] It can be further understood that, unless otherwise specified, “connection” includes a direct connection without other components between the two, and also includes an indirect connection with other components between the two.

[0193] It is further understood that, although the operations are described in a specific order in the drawings in the embodiments of the present disclosure, it should not be understood as requiring the operations to be performed in the specific order shown or in a serial order, or requiring the execution of all the operations shown to obtain the desired results. In certain environments, multitasking and parallel processing may be advantageous.

[0194] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any modifications, uses or adaptations of the present disclosure, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the art that are not disclosed in the present disclosure.

[0195] It should be understood that the present disclosure is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the scope of the appended claims.

Claims

1. A system exception handling method, characterized in that: The method comprises: In response to enabling a system recovery scheme and performing system recovery, obtaining an identifier of the system recovery scheme and a recovery judgment thread, the identifier including a first identifier or a second identifier, the first identifier being an identifier used when the system recovery scheme was used last time to perform system recovery, and the second identifier being an identifier newly generated for the system recovery scheme when performing system recovery, the recovery judgment thread being used to record information of the system recovery scheme before the system recovery scheme performs a system recovery operation successfully; Based on the identifier and the recovery judgment thread, an operation result of the system recovery performed by the system recovery solution is determined, wherein the operation result includes success of the system recovery operation performed according to the system recovery solution, or failure of the system recovery operation performed according to the system recovery solution.

2. The method according to claim 1, characterized in that The determining, based on the identifier and the recovery judgment thread, an operation result of performing system recovery by the system recovery solution includes: If the identifier is the first identifier and the recovery judgment thread survives, it is determined that the operation result of the system recovery scheme performing system recovery is a failure of the system recovery operation.

3. The method according to claim 1, characterized in that The determining, based on the identifier and the recovery judgment thread, an operation result of performing system recovery by the system recovery solution includes: If the identifier is the second identifier and the recovery judgment thread is not alive, determining that the operation result of the system recovery scheme for performing the system recovery is that the system recovery operation is successful; The second identifier is an identifier newly generated for the system recovery solution when the system is recovered.

4. The method according to any one of claims 1 to 3, characterized in that The identification is generated in the following manner: In response to performing system recovery, detecting whether the system recovery solution has an identifier; If the identifier exists, generate a first identifier, where the first identifier is the existing identifier; If the identifier does not exist, a second identifier is generated.

5. The method according to any one of claims 1 to 3, characterized in that: The recovery judgment thread is created in the following way: In response to completing the operation of performing system recovery based on the system recovery solution, determining the identification; If the identifier is the first identifier, the operation of the current recovery judgment thread is terminated, and a new recovery judgment thread is re-enabled; Or, re-enable the current recovery judgment thread; If the identifier is the second identifier, a new recovery determination thread is started.

6. The method according to claim 5, characterized in that The method further comprises: After the recovery judgment thread is enabled, the system abnormalities are monitored at set intervals; If a system abnormality is detected, the system abnormality information is recorded; If no system abnormality is detected within the time threshold, the new recovery judgment thread is terminated.

7. A system abnormality handling device, characterized in that: include: a processing unit, configured to, in response to enabling a system recovery scheme and performing system recovery, obtain an identifier of the system recovery scheme and a recovery judgment thread, wherein the identifier includes a first identifier or a second identifier, the first identifier being an identifier used when the system recovery scheme was used last time to perform system recovery, and the second identifier being an identifier newly generated for the system recovery scheme when performing system recovery, and the recovery judgment thread being configured to record information of the system recovery scheme before the system recovery scheme performs a system recovery operation successfully; A determination unit is used to determine the operation result of the system recovery according to the system recovery scheme based on the identifier and the recovery judgment thread, wherein the operation result includes whether the system recovery operation according to the system recovery scheme is successful or whether the system recovery operation according to the system recovery scheme is failed.

8. The system abnormality handling device according to claim 7, characterized in that: The determining unit determines the operation result of the system recovery scheme based on the identifier and the recovery judgment thread in the following manner: If the identifier is the first identifier and the recovery judgment thread survives, it is determined that the operation result of the system recovery scheme performing system recovery is a failure of the system recovery operation.

9. The system abnormality handling device according to claim 7, characterized in that: The determining unit determines the operation result of the system recovery scheme performing system recovery based on the identifier and the recovery judgment thread in the following manner: If the identifier is the second identifier and the recovery judgment thread is not alive, determining that the operation result of the system recovery scheme for performing the system recovery is that the system recovery operation is successful; The second identifier is an identifier newly generated for the system recovery solution when the system is recovered.

10. The system abnormality handling device according to any one of claims 7 to 9, characterized in that: The processing unit generates the identifier in the following manner: In response to performing system recovery, detecting whether the system recovery solution has an identifier; If an identifier exists, generate a first identifier, the first identifier being the existing identifier; In the absence of an identifier, a second identifier is generated.

11. The system abnormality handling device according to any one of claims 7 to 9, characterized in that: The processing unit creates a recovery judgment thread in the following manner: In response to completing the operation of performing system recovery based on the system recovery solution, determining the identification; When the identifier is the first identifier, terminating the operation of the current recovery judgment thread and re-enabling a new recovery judgment thread; Or, re-enable the current recovery judgment thread; When the identifier is the second identifier, a new recovery determination thread is started.

12. The system abnormality handling device according to claim 11, characterized in that: The processing unit is also used for: After the new recovery judgment thread is enabled, the system abnormalities are monitored at set intervals; When a system abnormality is detected, record the system abnormality information; When no system abnormality is detected within the time threshold, the new recovery judgment thread is terminated.

13. A system abnormality handling device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to execute the method according to any one of claims 1 to 6.

14. A storage medium, characterized in that: The storage medium stores instructions, and when the instructions in the storage medium are executed by a processor of the terminal, the terminal is enabled to execute the method according to any one of claims 1 to 6.

Images