Method for determining abnormal restart cause, electronic device, and storage medium

Abstract

This application provides a method, electronic device, and storage medium for determining the cause of abnormal restarts. First, abnormal restart data of the electronic device is acquired. Then, it is determined that the abnormal restart data exhibits at least one of multiple abnormal features. Next, it is determined whether the at least one abnormal feature includes a specific abnormal feature. If it is determined that the specific abnormal feature is included, then a non-hardware problem is identified as the cause of the abnormal restart of the electronic device. If it is determined that the specific abnormal feature is not included, then a weight value is added to a preset abnormal restart cause corresponding to the at least one abnormal feature. Subsequently, from multiple preset abnormal restart causes, the preset abnormal restart cause with the highest weight value is determined as the cause of the abnormal restart of the electronic device. In this way, the cause of abnormal restarts can be obtained and analyzed in a timely manner, improving the real-time performance of abnormal restart cause determination. Furthermore, by using multiple abnormal features to more comprehensively analyze the abnormal restart data, the accuracy of the determined abnormal restart cause is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method for determining the cause of abnormal restart, an electronic device, and a storage medium. Background Technology

[0002] With the rapid advancement of technology, electronic devices such as mobile phones and tablets have permeated every aspect of people's lives, becoming indispensable communication and entertainment tools. During daily use, electronic devices may restart without user intervention, resulting in an abnormal restart. Abnormal restarts not only affect the user experience but may also lead to data loss or system instability.

[0003] There can be many reasons for the abnormal restart of electronic devices. Therefore, it is necessary to determine the exact cause of the abnormal restart in a timely manner so as to facilitate effective maintenance of the electronic devices in the future. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method, electronic device, and storage medium for determining the cause of abnormal restarts, with the aim of promptly identifying the accurate cause of abnormal restarts.

[0005] Firstly, this application provides a method for determining the cause of abnormal restarts. For example, this method can be applied to electronic devices, such as mobile phones, tablets, and laptops. In this method, abnormal restart data of an electronic device can be obtained first. For example, this method can be applied to an electronic device that has experienced an abnormal restart, in which case the electronic device can obtain its own abnormal restart data. For example, this method can also be applied to an electronic device that has not experienced an abnormal restart, in which case the electronic device that has not experienced an abnormal restart can obtain the abnormal restart data of the electronic device that has experienced an abnormal restart. Then, it is determined whether the abnormal restart data exhibits abnormal characteristics. It is determined that the abnormal restart data exhibits at least one of multiple abnormal characteristics, such as one, two, or more abnormal characteristics. Subsequently, it is determined whether the at least one abnormal characteristic exhibited by the abnormal restart data includes a specific abnormal characteristic. If so, a non-hardware problem is directly identified as the cause of the abnormal restart of the electronic device, indicating that the specific abnormal characteristic is used to indicate that the electronic device has experienced a non-hardware problem. Otherwise, that is, if it is determined that the abnormal restart data exhibits at least one abnormal characteristic but does not exhibit the specific abnormal characteristic, it indicates that the electronic device has not experienced a non-hardware problem. In this case, the weight value of the preset abnormal restart cause corresponding to the at least one abnormal characteristic can be increased. Finally, from multiple preset abnormal restart causes, the preset abnormal restart cause with the largest weight value is identified as the cause of the abnormal restart of the electronic device. All of these multiple preset abnormal restart causes are used to indicate hardware problems.

[0006] In this way, the cause of abnormal restarts can be analyzed in a timely manner based on the abnormal restart data of electronic devices, without the need for manual analysis by technical personnel, avoiding the lag in analysis, thereby improving the real-time determination of the cause of abnormal restarts and facilitating timely maintenance of the performance of electronic devices. At the same time, comprehensive analysis of abnormal restart data based on multiple abnormal features avoids misjudgments or omissions caused by a single abnormal feature, which can improve the accuracy of determining the cause of abnormal restarts.

[0007] In one possible implementation, the abnormal restart data may include multiple sets of abnormal restart data during multiple abnormal restart processes of the electronic device, that is, one abnormal restart process corresponds to one set of abnormal restart data; the preset abnormal restart cause may include DDR memory jump problem; the above-mentioned step of adding a weight value of at least one preset abnormal restart cause corresponding to an abnormal feature may include: first calculating the similarity value of multiple sets of function call data corresponding to multiple sets of abnormal restart data, which is used to represent the similarity of function call situations; then adding the similarity value to the weight value of DDR memory jump problem.

[0008] Thus, based on the fact that DDR memory jump issues may affect the similarity of multiple sets of function call data, abnormal feature analysis is performed on abnormal restart data, and the weight value of the preset abnormal restart cause, DDR memory jump issue, is increased accordingly. This facilitates subsequent analysis of the probability of multiple preset abnormal restart causes leading to abnormal restarts of electronic devices, and helps to determine the accurate cause of abnormal restarts.

[0009] In one possible implementation, a set of function call data is used to indicate functions called by at least one function layer. For example, a set of function call data can indicate functions called by the function layer 0, or a set of function call data can indicate functions called by the function layers 0, 1, and 2 respectively. The step of calculating the similarity value of the multiple sets of function call data corresponding one-to-one with the multiple sets of abnormal restart data can include: for each function layer of the multiple sets of function call data, for example, if a set of function call data indicates functions called by the function layers 0, 1, and 2 respectively, then each function layer of the multiple sets of function call data refers to the 0th, 1st, and 2nd layers of the multiple sets of function call data, so as to address the multiple sets of functions... Taking layer 0 of the function call data as an example, we can first determine the first function from the multiple functions indicated by the function call data in that function layer. The first function is different from all the other functions in the multiple functions, that is, the first function does not have any identical functions in the multiple functions. The same applies to layers 1 and 2 of the function call data. We need to determine the number of first functions in each function layer of the multiple function call data. Finally, based on the number of first functions in each function layer of the multiple function call data, such as the number of first functions corresponding to layers 0, 1 and 2, we can calculate the similarity value of the multiple function call data. The similarity value is negatively correlated with the similarity of the multiple function call data. The larger the similarity value, the lower the similarity of the multiple function call data.

[0010] In this way, the number of first functions is used to determine the degree of similarity of multiple sets of function call data, and the first function is easy to find, thus improving the convenience of calculating the degree of similarity.

[0011] In one possible implementation, each function layer of the aforementioned multiple sets of function call data includes multiple functions, each with a corresponding tag value. The step of determining the first function from the multiple functions indicated by the function layer in the multiple sets of function call data may include: first, updating the tag values ​​corresponding to the multiple functions to a first value, for example, updating them all to 1; then, from the multiple tag values ​​updated to the first value, determining at least two tag values ​​corresponding to the same function, for example, if two tag values ​​correspond to function 1 and three tag values ​​correspond to function 2, then updating at least two tag values ​​to values ​​different from the first value, for example, updating all five tag values ​​corresponding to function 1 and function 2 to values ​​different from the first value, i.e., values ​​other than 1; finally, determining the function with the first value among the multiple functions as the first function, for example, determining the function whose tag value is still 1 as the first function.

[0012] Thus, by updating the flag value corresponding to the function, it is easier to distinguish the first function that is different from other functions, further improving the convenience of calculating values ​​of the same degree.

[0013] In one possible implementation, the aforementioned multiple marker values ​​are arranged sequentially according to the time order of the abnormal restart, that is, the earlier the time of the abnormal restart, the earlier the marker value corresponding to the function included in the abnormal restart data is arranged; the step of updating at least two marker values ​​to values ​​different from the first value may include: first updating the first marker value among the at least two marker values ​​corresponding to the same function to the second value, and updating the remaining marker values ​​among the at least two marker values ​​to the third value. The second value can be obtained based on the number of remaining marker values. Based on the above example, if there are two marker values ​​corresponding to function 1 and three marker values ​​corresponding to function 2, then the first marker value (time-first) corresponding to function 1 can be incremented by 1 and updated to 2, and the other marker value corresponding to function 1 can be updated to 0; the first marker value corresponding to function 2 can be incremented by 2 and updated to 3, and the two marker values ​​corresponding to function 2 can be updated to 0.

[0014] In this way, the number of identical functions can be represented by the marker value, and the marker values ​​of later times are all updated to 0. When comparing whether functions are the same, we can only compare based on the identical functions with earlier times, without having to compare with the identical functions with later times again. This can reduce computing resources, improve the speed of function comparison, and thus improve the calculation speed of values ​​with the same degree.

[0015] In one possible implementation, before updating the flag values ​​corresponding to the multiple functions to the first value, the method for determining the cause of the abnormal restart may further include: first initializing the flag values ​​corresponding to the multiple functions to the fourth value; correspondingly, the step of updating the flag values ​​corresponding to the multiple functions to the first value may include: for each function, updating the function to the first value before comparing the function with other functions among the multiple functions.

[0016] In this way, the fourth and first values ​​can be used to distinguish whether the function has started comparison, thus avoiding the occurrence of missed comparisons.

[0017] In one possible implementation, a set of function call data can be used to indicate the functions called by multiple function layers respectively. The step of calculating the similarity value of the multiple sets of function call data based on the number of first functions in each function layer of the multiple sets of function call data can include: for each function layer of the multiple sets of function call data, each function layer has a corresponding weight value. First, multiply the number of first functions in that function layer by the weight value of that function layer to obtain the basic weighted value of the function call for that function layer. For example, if there are function layers 0 and 1, multiplying the number of first functions in layer 0 by the weight value of layer 0 yields one basic weighted value of the function call, and multiplying the number of first functions in layer 1 by the weight value of layer 1 yields another basic weighted value of the function call. Then, add the basic weighted values ​​of the function calls corresponding to the multiple function layers respectively, for example, adding the basic weighted value of the function call for layer 0 and the basic weighted value of the function call for layer 1 to obtain the similarity value of the multiple sets of function call data.

[0018] In this way, the weight value of the function layer can characterize the degree of influence of the function layer on the DDR memory jump problem. By fully considering the different degrees of influence of different function layers, it is possible to calculate the degree of similarity that can better characterize the same situation of multiple sets of function call data, thereby ensuring the accuracy of the weight value of the DDR memory jump problem.

[0019] In one possible implementation, the abnormal restart data may include multiple sets of abnormal restart data during multiple abnormal restarts of the electronic device; the preset abnormal restart cause may include a DDR memory jump problem; the step of determining that the abnormal restart data exhibits at least one of multiple abnormal features may include: determining that multiple sets of function call data corresponding to multiple sets of abnormal restart data are identical, and determining that multiple sets of function call data have a preset function, where the preset function is a function with a corresponding problem weight value; correspondingly, the step of increasing the weight value of the preset abnormal restart cause corresponding to at least one abnormal feature may include: increasing the problem weight value corresponding to the preset function to the weight value of the DDR memory jump problem.

[0020] Thus, once the abnormal characteristics corresponding to the DDR memory jump problem are identified, their weight value is increased, which is beneficial for subsequently determining the accurate cause of the abnormal restart from among multiple preset abnormal restart causes.

[0021] In one possible implementation, the step of determining at least one abnormal feature, including a specific abnormal feature, and identifying a non-hardware problem as the cause of the abnormal restart of the electronic device, may include: determining that at least one abnormal feature includes multiple sets of abnormal restart data corresponding to multiple sets of function call data that are all the same, and determining that multiple sets of function call data do not contain a preset function, that is, the specific abnormal feature is that multiple sets of function call data without a preset function are all the same, thus directly identifying a non-hardware problem as the cause of the abnormal restart of the electronic device.

[0022] In this way, once a specific abnormal feature is identified, there is no need to consider the weight values ​​of each preset abnormal restart cause. The cause of the abnormal restart can be directly determined, fully taking into account the possible hardware and non-hardware problems of electronic devices. The analysis of abnormal restart data is more comprehensive and can improve the accuracy of the identified abnormal restart cause.

[0023] In one possible implementation, the aforementioned preset abnormal restart cause may include a DDR memory transition problem; the step of determining that the abnormal restart data exhibits at least one of multiple abnormal features may include: first determining that a bit reversal occurs at a preset location of the address of the abnormal restart data, i.e., a transition occurs, such as 0 becoming 1; correspondingly, the step of increasing the weight value of the preset abnormal restart cause corresponding to at least one abnormal feature may include: increasing the weight value of the DDR memory transition problem.

[0024] Therefore, considering that DDR memory transition issues may affect the preset address location, abnormal restart data is analyzed for abnormal characteristics. This facilitates subsequent analysis of the probability that multiple preset abnormal restart causes will lead to abnormal restarts of electronic devices.

[0025] In one possible implementation, the abnormal restart data includes multiple sets of abnormal restart data during multiple abnormal restarts of the electronic device; determining whether a bit inversion exists at a preset address position of the abnormal restart data can include: in chronological order from back to front, analyzing each set of abnormal restart data for bit inversion at a preset address position until a set of abnormal restart data is found to have bit inversion at a preset address position, then stopping the analysis of earlier abnormal restart data; correspondingly, increasing the weight value of the DDR memory transition problem can include: increasing a first threshold to the weight value of the DDR memory transition problem, the first threshold increasing as the time corresponding to the determined set of abnormal restart data moves later, that is, the later the time corresponding to the determined set of abnormal restart data with bit inversion at the preset address position, the larger the first threshold.

[0026] Therefore, considering that the set of abnormal restart data from later times of the electronic device is more consistent with the problem it reflects, if a bit reversal is found in the preset position of the address included in the set of abnormal restart data, then the abnormal restart data from earlier times will no longer be analyzed, which can save data analysis time and further improve the speed of determining the cause of abnormal restart.

[0027] In one possible implementation, the abnormal restart data includes multiple sets of abnormal restart data from multiple abnormal restarts of the electronic device; the preset abnormal restart cause includes DDR memory frequency issues; determining that the abnormal restart data exhibits at least one of multiple abnormal features may include: determining that among the DDR memory frequencies included in the multiple sets of abnormal restart data, there are cases where the frequencies are the same; accordingly, increasing the weight value of the preset abnormal restart cause corresponding to at least one abnormal feature may include: increasing the weight value of the DDR memory frequency issue based on the number of identical DDR memory frequencies.

[0028] Thus, considering that the more identical DDR memory frequencies there are, the greater the likelihood of DDR memory frequency issues, it is easier to add a more appropriate weight value to this preset abnormal restart cause.

[0029] In one possible implementation, increasing the weight value of the DDR memory frequency problem based on the number of identical DDR memory frequencies can include adding the minimum value between the number of identical DDR memory frequencies and a threshold to the weight value of the DDR memory frequency problem.

[0030] Thus, by using a threshold as the maximum weighting value for DDR memory frequency issues, we can avoid excessively large weighting values ​​that could affect the determination of the final cause of abnormal restarts.

[0031] In one possible implementation, the preset abnormal restart cause includes cache memory jump problem; determining that the abnormal restart data exhibits at least one of multiple abnormal features may include: determining that the number of jump interrupts in the abnormal restart data is greater than 0; correspondingly, increasing the weight value of the preset abnormal restart cause corresponding to at least one abnormal feature may include: increasing the weight value of cache memory jump problem.

[0032] Thus, if the abnormal characteristic of the number of interrupt jumps being greater than 0 is identified, the weight value of the corresponding cache memory jump problem will be increased, which will facilitate the subsequent comprehensive analysis of the probability of various preset abnormal restart causes.

[0033] In one possible implementation, the abnormal restart data includes multiple sets of abnormal restart data during multiple abnormal restarts of the electronic device; determining that the number of transition interrupts in the abnormal restart data is greater than 0 can include: sequentially determining whether the number of transition interrupts in each set of abnormal restart data is greater than 0 in chronological order from latest to earliest, until a set of abnormal restart data is determined to have a number of transition interrupts greater than 0, at which point the analysis of abnormal restart data from earlier times is stopped; correspondingly, increasing the weight value of the cache memory transition problem can include: increasing the weight value of the cache memory transition problem based on the determined number of transition interrupts in a set of abnormal restart data.

[0034] Thus, if the number of jump interrupts in a set of abnormal restart data is greater than 0, the analysis will not continue. This can improve the speed of determining the cause of abnormal restart and save computing resources. At the same time, considering that the more jump interrupts there are, the greater the possibility of cache memory jump problems in electronic devices, it is easier to add more appropriate weight values ​​to them.

[0035] In one possible implementation, the weight value of the cache memory jump problem is increased based on the number of jump interrupts in a determined set of abnormal restart data. This can include: first, multiplying the number of jump interrupts in the determined set of abnormal restart data by the number of abnormal restarts of the electronic device to obtain a product value; then, adding the minimum value between the product value and a threshold to the weight value of the cache memory jump problem. This threshold increases as the time corresponding to the determined set of abnormal restart data moves later, that is, the later the corresponding time, the larger the threshold.

[0036] Therefore, considering that the set of abnormal restart data from a later time is more consistent with the current problem reflected by the electronic device, a more appropriate threshold is set as the maximum weighting value to avoid the weight value being too large, which would affect the subsequent comprehensive analysis of multiple preset abnormal restart causes.

[0037] In one possible implementation, the abnormal restart data includes multiple sets of abnormal restart data from multiple abnormal restart processes of the electronic device; the preset abnormal restart cause includes cache memory jump issues; determining that the abnormal restart data exhibits at least one of multiple abnormal features may include: determining that the CPU cores included in the multiple sets of abnormal restart data have the same CPU core, and the CPU core included in each set of abnormal restart data is the CPU core that malfunctioned during the operation of the electronic device, that is, the CPU core running the problematic process; accordingly, increasing the weight value of the preset abnormal restart cause corresponding to at least one abnormal feature may include: increasing the weight value of the cache memory jump issue based on the same number of times the same CPU core appears.

[0038] Thus, considering that the more times the CPU core is accessed in the same way, the greater the possibility of cache memory jump problems, a more weighted value representing the likelihood of this pre-defined abnormal restart cause can be added.

[0039] In one possible implementation, the weight value of the cache memory jump problem is increased based on the same number of times the same CPU cores are used. This can include: multiplying the ratio of the maximum number of times the same CPU cores are used to the number of times the electronic device has abnormally restarted by a threshold to obtain a product value. For example, if the number of times the same CPU core 1 is used is 3 and the number of times the same CPU core 2 is used is 4, then the number of times the same CPU core 2 is used for calculation; and then adding the product value to the weight value of the cache memory jump problem.

[0040] Therefore, by using this threshold as the maximum weighted value, we can avoid adding too much weight to the cache memory jump problem and facilitate further comprehensive analysis of multiple preset restart reasons.

[0041] In one possible implementation, the method for determining the cause of the abnormal restart may further include: recording the abnormal restart data of the electronic device when the electronic device changes from a powered-on state to a powered-off state. For example, if this method is applied to an electronic device that has experienced an abnormal restart, the electronic device may record its own abnormal restart data when it changes from a powered-on state to a powered-off state during the abnormal restart. Accordingly, obtaining the abnormal restart data of the electronic device may include: the electronic device that has experienced an abnormal restart may read its own recorded abnormal restart data when it changes from a powered-off state to a powered-on state again.

[0042] In this way, analysis can be performed directly after an abnormal restart, avoiding analysis delays and improving the efficiency of determining the cause of the abnormal restart, thereby facilitating timely maintenance of the performance of electronic devices.

[0043] In one possible implementation, before determining that the abnormal restart data exhibits at least one of a plurality of abnormal features, the method for determining the cause of the abnormal restart may further include: determining that the abnormal restart data meets the abnormal restart analysis conditions.

[0044] Therefore, in the event of multiple abnormal restarts of electronic devices, avoiding frequent analysis of the impact on the boot time of electronic devices is beneficial to improving the user experience.

[0045] In one possible implementation, the above abnormal restart analysis conditions may include one or more of the following: the number of abnormal restarts of the electronic device exceeds a fifth threshold; the time interval between the latest abnormal restart and the previous abnormal restart is less than a sixth threshold; the average time interval between multiple abnormal restarts of the electronic device is less than a seventh threshold.

[0046] Therefore, when an abnormal restart of an electronic device affects user experience, it indicates that the device has a malfunction that cannot be resolved by restarting itself. In such cases, analyzing the abnormal restart data helps to identify the cause of the abnormal restart in a timely manner, thereby enabling effective maintenance of the electronic device.

[0047] In one possible implementation, the method for determining the cause of the abnormal restart may further include: if the cause of the abnormal restart of the electronic device is determined to be a DDR memory jump problem, then the faulty memory cell of the DDR memory can be further identified and the faulty memory cell isolated; or, if the cause of the abnormal restart of the electronic device is determined to be a DDR memory jump problem, then the parameters of the DDR memory can be modified based on the environment in which the electronic device is located, for example, the parameters of the DDR memory can be modified based on the ambient temperature.

[0048] In this way, when electronic devices experience DDR memory jump issues, they can automatically repair themselves and maintain their performance, thus avoiding impacting the user's subsequent experience.

[0049] Secondly, this application provides an electronic device including a memory and a processor; the memory stores computer program code, which includes computer instructions; one or more processors invoke the computer instructions to cause the electronic device to execute the method for determining the cause of abnormal restart described in the first aspect.

[0050] Thirdly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for determining the cause of abnormal restart as described in the first aspect.

[0051] Fourthly, this application provides a computer program product including computer program code, which, when executed by an electronic device, implements the method for determining the cause of abnormal restart as described in the first aspect. Attached Figure Description

[0052] Figure 1 A flowchart illustrating a method for determining the cause of an abnormal restart, as provided in an embodiment of this application;

[0053] Figure 2 A schematic diagram illustrating the determination of the cause of an abnormal restart, provided as an embodiment of this application;

[0054] Figure 3 This application provides a flowchart of a method for calculating the basic weighted value of a function call;

[0055] Figure 4 This is a schematic diagram of function call data provided in an embodiment of this application;

[0056] Figure 5 This application provides a schematic diagram of a calculation of the basic weighted value of a function call, as exemplified by this application.

[0057] Figure 6 This is a schematic diagram of the software architecture of an electronic device provided in an embodiment of this application. Detailed Implementation

[0058] To ensure clarity and conciseness in the description of the following embodiments, the terminology used in the embodiments of this application will first be explained. It should be understood that this explanation is for the purpose of better understanding the embodiments of this application and does not necessarily constitute a limitation on the embodiments of this application.

[0059] Kernel: This refers to the core of the operating system of an electronic device and the foundation upon which the operating system functions. In some embodiments, an abnormal restart of an electronic device refers to an abnormal restart of the kernel.

[0060] Kernel phase during reboot: The kernel phase during reboot refers to the abnormal handling phase of the kernel when an electronic device transitions from a powered-on state to a powered-off state. In some embodiments, during the kernel phase of reboot, the electronic device can record abnormal reboot data for analyzing the cause of the abnormal reboot. For example, abnormal reboot data may include timestamps, virtual addresses, physical addresses, and problematic CPU cores, etc.

[0061] Double Data Rate (DDR) memory: This refers to memory with a double data rate (DDR) rating, which may be referred to as DDR memory in the following embodiments. DDR memory can be used as main memory in electronic devices to store programs and data used during the device's operation, and it also provides fast data access and transfer capabilities.

[0062] Cache memory: refers to cache memory, which will be referred to as cache memory in the following embodiments. Cache memory is a type of memory with small capacity but extremely high speed, which can be used to reduce the pressure on main memory and improve the performance of electronic devices.

[0063] The following section compares and explains the technical advantages of the method for determining the cause of abnormal restarts, the electronic device, and the storage medium provided in this application, in conjunction with relevant technologies. For ease of understanding, an example scenario is used for illustration.

[0064] Currently, the most serious problem causing abnormal restarts of electronic devices is data access error, meaning that the data or addresses used by the electronic device when running programs are incorrect. This problem may be caused by hardware failure such as DDR memory, which may experience long-term bad blocks or short-term jumps in various user scenarios, leading to abnormal restarts. However, it could also be caused by software problems within the electronic device.

[0065] In related technologies, after an electronic device experiences an abnormal restart, technicians can, on the one hand, obtain data about the electronic device from a cloud server and summarize relevant data that may have caused the abnormal restart, such as virtual addresses related to DDR memory. They can then check specific bits in the virtual addresses related to DDR memory, and the values ​​of these specific bits are usually fixed. If their values ​​change abruptly (e.g., 0 becomes 1, or 1 becomes 0), it is determined that the DDR memory has failed, causing the electronic device to restart abnormally. On the other hand, technicians can also use hardware testing tools to test whether the hardware of the electronic device, such as the DDR memory, has malfunctioned.

[0066] However, the inventors discovered that after electronic devices are commercially available (i.e., after users have used them), technicians sometimes face the lack of relevant data such as logs, making it difficult to obtain data for testing. Furthermore, hardware testing tools sometimes struggle to detect hardware problems. Additionally, when a specific bit in the virtual address space of the DDR memory of an electronic device exhibits a jump, it may indicate other hardware problems or software malfunctions causing the device to restart abnormally. Conversely, if this characteristic is not present, it could also indicate a hardware malfunction in the DDR memory itself, leading to the abnormal restart.

[0067] The methods in related technologies are lagging in analyzing the causes of abnormal restarts, which can easily affect the efficiency of determining the causes of abnormal restarts, thus making it impossible to take effective maintenance measures in a timely manner and affecting the performance of electronic devices. At the same time, judging the cause of abnormal restarts of electronic devices based solely on this characteristic exhibited by the electronic devices has limitations and makes it difficult to accurately determine the cause of abnormal restarts.

[0068] Therefore, to solve the above problems, this application provides a method for determining the cause of abnormal restart. This method can be applied to electronic devices. Before analyzing the cause of abnormal restart, the electronic device can read abnormal restart data, such as abnormal restart data recorded during the transition from a power-on state to a power-off state when the electronic device restarts abnormally. The read abnormal restart data can include data recorded from multiple abnormal restarts. The abnormal restart data is then analyzed to determine if multiple abnormal features exist. If an abnormal feature is found, and the abnormal feature does not include a specific abnormal feature, the weight value of a preset abnormal restart cause (used to indicate hardware problems, such as DDR memory jump problems, cache memory jump problems, etc.) corresponding to that abnormal feature can be increased. After the analysis, the preset abnormal restart cause with the highest weight value can be determined as the cause of the abnormal restart of the electronic device. Alternatively, if the determined abnormal feature includes a specific abnormal feature, non-hardware problems such as software problems can be directly determined as the cause of the abnormal restart of the electronic device.

[0069] Thus, this application can analyze the cause of abnormal restarts in a timely manner through electronic devices, which can improve the real-time performance of determining the cause of abnormal restarts and is conducive to timely maintenance of the performance of electronic devices. At the same time, compared with the single feature used to determine the cause of abnormal restarts in related technologies, this application provides multiple abnormal features, which can analyze abnormal restart data more comprehensively. On this basis, multiple abnormal features can be used to determine different causes of abnormal restarts, which can reduce the occurrence of false positives or false negatives, thereby improving the accuracy of the determined cause of abnormal restarts of electronic devices.

[0070] Next, taking the electronic device that experienced an abnormal restart as the execution subject, combined with Figure 1 This application describes a method for determining the cause of abnormal restarts, as provided in its embodiments.

[0071] like Figure 1 As shown, the method for determining the cause of this abnormal restart may include the following steps:

[0072] S101: Obtain abnormal restart data.

[0073] Abnormal restart data refers to the data recorded by an electronic device during an abnormal restart process, which can be used to analyze the reasons for the abnormal restart of the electronic device.

[0074] In some embodiments, abnormal restart data may be data recorded when an electronic device restarts due to an address access error.

[0075] Based on the above description, the abnormal restart process of an electronic device includes the process of the electronic device first changing from a powered-on state to a powered-off state, and then changing from a powered-off state to a powered-on state. In some embodiments, this abnormal restart process has multiple stages, which may include a kernel stage and a small system stage when the electronic device abnormally restarts.

[0076] The aforementioned kernel stage refers to the kernel stage during which an electronic device transitions from a powered-on state to a powered-off state. When an electronic device is powered on and the kernel encounters an unrecoverable error, it triggers a kernel panic, enters the kernel stage, records the abnormal reboot data, and then the electronic device transitions to a powered-off state.

[0077] The aforementioned small system stage refers to a phase in the process of an electronic device transitioning from a powered-off state to a powered-on state. When an electronic device boots up from a powered-off state and enters the small system stage, it can acquire abnormal restart data recorded in the kernel stage, allowing for analysis of the causes of abnormal restarts during this phase.

[0078] In some embodiments, after the electronic device records the abnormal restart data during the kernel stage, it can store it in a specific storage area of ​​the electronic device's memory (e.g., Random Access Memory (RAM), Read Only Memory (ROM), etc.). Subsequently, during the small system stage, the electronic device can retrieve the abnormal restart data from the specific storage area of ​​the memory for analyzing the cause of the abnormal restart.

[0079] In one possible implementation, the electronic device can obtain the abnormal restart data recorded at the time of the latest abnormal restart, that is, obtain the latest abnormal restart data recorded this time.

[0080] In another possible implementation, the electronic device, in addition to acquiring the latest abnormal restart data, can further acquire historical abnormal restart data recorded from previous abnormal restarts. For example, if the electronic device experiences its 5th abnormal restart, it can acquire the abnormal restart data corresponding to the 1st through 5th abnormal restarts. The abnormal restart data corresponding to the 5th abnormal restart is a set of the latest abnormal restart data, and the abnormal restart data corresponding to the 1st through 4th abnormal restarts are four sets of historical abnormal restart data. In other words, each abnormal restart process of the electronic device corresponds to one set of abnormal restart data.

[0081] In some embodiments, abnormal restart data may be used to indicate one or more of the following: the number of abnormal restarts, the time of the abnormal restart, the operating state of the electronic device at the time of the abnormal restart, the hardware fault point, and the software fault point. This application does not limit this.

[0082] For example, abnormal restart data may include: index value, timestamp, kernel time, process name, problematic central processing unit (CPU), high-order transition flag, number of cache memory transition interrupts, physical address, virtual address, DDR memory frequency, problem scenario, and function call data.

[0083] It should be noted that the abnormal restart data may include more or less data than the example above, and this application does not limit this.

[0084] The index value is used to represent the number of times the electronic device has abnormally restarted, and can be used to distinguish the abnormal restart data recorded in multiple abnormal restarts of the electronic device. For example, the index value can be 0 for the first abnormal restart of the electronic device, and 3 for the fourth restart of the electronic device.

[0085] A timestamp is used to represent the point in time when an electronic device abnormally restarts. For example, a timestamp can be the current moment when the electronic device records abnormal restart data during the kernel phase; or, for another example, a timestamp can be the current moment when the electronic device triggers a kernel panic. For instance, if the electronic device records abnormal restart data on [date] at [time], then "[date] at [time]" can be recorded as the timestamp of the abnormal restart data.

[0086] Kernel time is used to represent the duration of an electronic device after it starts up; that is, the time the electronic device remains in the powered-on state before transitioning from the powered-on state to the powered-off state. For example, if an electronic device runs for 900 seconds after startup and then experiences an abnormal restart, the kernel time is recorded as 900 seconds.

[0087] The process name is used to represent the name of the problematic process (which can be called the problematic process) that runs when the electronic device restarts abnormally. A process refers to a single execution instance of a program, and each process has a corresponding name. For example, the electronic device includes program 1 and program 2. After the electronic device starts up, process 1 is created and executes program 1 once, process 2 is created and executes program 2 once, and process 3 is created and executes program 1 once. When process 3 is being executed, the electronic device experiences an abnormal restart, and the recorded process name is process 3.

[0088] A problematic CPU core is used to refer to the CPU core that provides the operating environment when an electronic device runs a problematic process. For example, an electronic device includes CPU cores 1 to 8. Process 1 is executed through CPU core 1. If an error occurs in process 1, then CPU core 1 is recorded as a problematic CPU core.

[0089] The high-order transition marker is used to indicate that when the high-order part of the virtual address of the allocated DDR memory changes during the operation of an electronic device, the high-order part is usually a bit with a fixed value in the virtual address. That is, when one or more bits in the high-order part of the virtual address change, it is recorded, for example, from 0 to 1, or from 1 to 0.

[0090] The cache memory transition interrupt count is used to indicate the number of interrupts triggered after the cache memory transitions when the electronic device starts up. Each cache memory transition triggers one interrupt, so the electronic device can directly obtain the interrupt count when recording data.

[0091] A physical address is used to represent the actual address in memory, the actual location of memory (such as DDR memory and cache memory) used for direct access. For example, the physical addresses that an electronic device needs to access when running a problematic process can be recorded.

[0092] Virtual addresses are used to represent the addresses used by processes running on an electronic device. For example, the virtual addresses accessed by processes running after the electronic device starts up can be recorded and mapped to physical addresses through an address translation mechanism, enabling access to the actual memory addresses.

[0093] The DDR memory frequency point is used to represent the frequency of the DDR memory during the kernel stage of an electronic device. That is, when a kernel panic is triggered, the operating frequency of the DDR memory at this time is recorded.

[0094] The "problem scenario" is used to describe the situation in which an electronic device triggers a kernel panic, i.e., the scenario in which the problem occurs. For example, if a user action triggers an electronic device to compress a file, or if the electronic device automatically compresses a file, and this triggers a kernel panic, then the problem scenario is recorded as the "compressed file scenario."

[0095] Function call data is used to represent functions called when an electronic device is running a problematic process. In some embodiments, the recorded function call data may be a function name or a function identifier. In some embodiments, the recorded function call data may also be the function content itself.

[0096] For example, taking the recording of function names as an example, if an electronic device restarts abnormally while running process 1, process 1 includes function a. During the execution of function a, function b is called, and during the execution of function b, function c is called. Function c does not call any other functions, so function c, which does not call any other functions, can be recorded as a level 0 function and denoted as symbol0; function b, which calls level 0 function symbol0, is recorded as a level 1 function and denoted as symbol1; function a, which calls level 1 function symbol0, is recorded as a level 2 function and denoted as symbol2. In cases where the calling relationships are more complex, this recording can be repeated. This can also be described as recording functions called by multiple function levels, with level 0, level 1, and level 2 functions being the functions called by these three function levels respectively.

[0097] It should be noted that, in the following embodiments, the abnormal restart data obtained by the electronic device after multiple abnormal restarts includes the latest abnormal restart data and historical abnormal restart data. The abnormal restart data corresponding to each abnormal restart includes the content contained in the above example, which will be used to describe the subsequent steps in detail.

[0098] S102: Determine whether the abnormal restart analysis conditions are met based on the abnormal restart data. If yes, execute S103; otherwise, execute S104.

[0099] It should be noted that S102 is an optional execution step. The electronic device can also directly execute S103 after obtaining the abnormal restart data, that is, make a judgment directly based on the abnormal restart data.

[0100] This allows for a faster determination of the cause of abnormal restarts in electronic devices, preventing disruption to subsequent use by the user.

[0101] It should be understood that after an electronic device obtains abnormal restart data, it takes some time to analyze the cause of the abnormal restart based on the abnormal restart data, that is, to execute the method for determining the cause of abnormal restart provided in the embodiments of this application. If the cause of abnormal restart is determined every time the electronic device restarts abnormally, it will easily increase the time for the electronic device to switch from the off state to the on state, thereby affecting the user experience.

[0102] Therefore, when an electronic device restarts abnormally and affects user experience, such as when the electronic device restarts abnormally many times or frequently, the cause of the abnormal restart can be analyzed based on the abnormal restart data.

[0103] The principle for setting abnormal restart analysis conditions can be: indicating that the electronic device restarts frequently, that is, the fault of the electronic device cannot be resolved by restarting itself, so further analysis is required.

[0104] In some embodiments, based on this setting principle, the abnormal restart analysis condition can be: the number of abnormal restarts of the electronic device exceeds a threshold (which can be referred to as the fifth threshold).

[0105] For example, based on the above description, the number of abnormal restarts can be determined according to the index value included in the latest abnormal restart data. For instance, if the threshold for the number of restarts is 3, and the index value included in the latest abnormal restart data is 3, it indicates that the electronic device has experienced 4 abnormal restarts, thus satisfying the abnormal restart analysis condition. It should be noted that this application does not limit the threshold for the number of restarts; the threshold can also be 2 or 4.

[0106] In some embodiments, the abnormal restart analysis condition can be: the time interval between the latest abnormal restart of the electronic device and the previous abnormal restart is less than the time interval threshold (which can be called the sixth threshold).

[0107] For example, the time interval can be obtained by subtracting the timestamp t1 of the latest abnormal restart data from the timestamp t2 of the previous abnormal restart data. For instance, if the time interval threshold is 3 days, t1 is 0:00 on March 15th, and t2 is 0:00 on March 9th, then t1-t2 can be used to obtain a time interval of 6 days, which is greater than 3 days and does not meet the abnormal restart analysis condition.

[0108] In some embodiments, the abnormal restart analysis condition can be: the average time interval between multiple abnormal restarts of the electronic device is less than the average time interval threshold (which may be referred to as the seventh threshold).

[0109] For example, multiple time intervals can be obtained by subtracting the timestamps of two adjacent abnormal restarts in multiple abnormal restarts, and then the average of these time intervals can be calculated to obtain the average time interval. Assuming the electronic device abnormally restarted a total of 3 times, corresponding to timestamps t0, t1, and t2 respectively, the average of the two time intervals t2-t1 and t1-t0 can be calculated. For example, if the threshold for the average time interval is 5 days, and assuming t0 is March 7th at 0:00, t1 is March 9th at 0:00, and t2 is March 15th at 0:00, then the calculated average time interval is 4 days, which is less than 5 days, satisfying the abnormal restart data.

[0110] It should be noted that this application does not limit the number of abnormal restart analysis conditions, and may include one or more of the above examples. When the abnormal restart analysis conditions include multiple conditions, S103 shall be executed after all of these conditions are met.

[0111] In this way, when the abnormal restart of electronic devices affects user experience, the cause of the abnormal restart can be determined based on the abnormal restart data, thus avoiding affecting the boot time of electronic devices and improving the user experience.

[0112] S103: Based on the abnormal restart data, determine whether there is a significant bit inversion. If yes, execute S105; otherwise, execute S106.

[0113] It should be understood that there are many reasons why electronic devices may restart abnormally. Different reasons for abnormal restarts may cause the electronic device to exhibit certain characteristics (also known as abnormal features). Therefore, it is possible to determine whether the electronic device exhibits these characteristics. If it does exhibit these characteristics, it indicates that the electronic device may have restarted abnormally due to the corresponding abnormal restart reason. If it does not exhibit these characteristics, it indicates that the electronic device may have restarted abnormally due to other reasons.

[0114] In some embodiments, the abnormal characteristics of an electronic device may include a bit reversal (i.e., a value jump) in a specific bit in the virtual address associated with the DDR memory, that is, a significant bit reversal (also referred to as a bit reversal at a preset position of the address).

[0115] In some embodiments, a specific bit may refer to a fixed bit in the high-order portion of the virtual address that has undergone a bit flip. Based on the above example, the high-order transition marker included in the abnormal restart data can be used to determine whether a significant bit flip exists.

[0116] For example, suppose the high-order transition flag is 0, indicating that there is no significant bit reversal, and the high-order transition flag is 1, indicating that there is a significant bit reversal.

[0117] For example, if the virtual address is "0xffffffxxxxxxx", positions 3 through 8 of this virtual address are fixed high-order bits, which normally need to be 6 "f". Suppose that the virtual address of the electronic device during its latest abnormal restart is "0xfffaffxxxxxxx", and the "f" in position 6 changes to "a", resulting in a bit flip, then the high-order transition marker is 1.

[0118] In some embodiments, fixed bits in other parts of the virtual address may be reversed, but this application does not limit this to that.

[0119] In one possible implementation, the system can first determine the cause based on the latest abnormal restart data. If it is determined that a significant bit inversion occurred in the latest abnormal restart, then proceed to step S105. If it is determined that the latest abnormal restart did not occur, then the system can determine the cause based on the historical abnormal restart data of the previous abnormal restart. If it is determined that the previous abnormal restart did occur, then proceed to step S105. This process continues until the subsequent abnormal restarts do not occur. Then, the system can determine the cause based on the historical abnormal restart data of the first abnormal restart. If it is determined that the first abnormal restart did occur, then proceed to step S105. Otherwise, proceed to step S106.

[0120] For example, assuming the electronic device has abnormally restarted 5 times, the judgment can be made first based on the latest abnormal restart data of the 5th abnormal restart. If it is determined that no significant bit inversion occurred in the 5th abnormal restart, the judgment can be made based on the historical abnormal restart data of the 4th abnormal restart, and so on, judging in order from the end to the beginning of time, until it is determined that one of the historical abnormal restarts has a significant bit inversion, then S105 is executed, or until it is determined that no significant bit inversion occurred in the 1st abnormal restart, then S106 is executed.

[0121] Thus, once a significant bit reversal is confirmed in an abnormal restart, previous abnormal restarts are no longer analyzed, which reduces computational resources, saves time in abnormal restart analysis, and improves the speed of determining the cause of abnormal restarts.

[0122] In another possible implementation, the judgment can be made based on the abnormal restart data corresponding to each abnormal restart to determine whether a significant bit reversal has occurred in each abnormal restart. If so, continue to execute S105; otherwise, continue to execute S106.

[0123] For example, assuming the electronic device restarted abnormally 5 times, the abnormal restart data corresponding to each of the 5 abnormal restarts can be used to make a judgment. If it is determined that no bit inversion occurred in any of the 5 abnormal restarts, then S106 is executed; otherwise, S105 is executed.

[0124] Therefore, analyzing each abnormal restart helps to determine a more accurate cause of the abnormal restart.

[0125] S104: Exit the abnormal restart analysis and handling process.

[0126] In some embodiments, if the abnormal restart analysis conditions are not met based on the latest abnormal restart data and historical restart data, the abnormal restart analysis process can be exited and the electronic device can continue to boot up to the power-on state.

[0127] S105: Increase the weight value of the ddr memory transition problem by N1.

[0128] In some embodiments, multiple abnormal restart reasons (also known as preset abnormal restart reasons) can be pre-defined, and each abnormal restart reason may cause the electronic device to exhibit one or more characteristics. The weight values ​​corresponding to each abnormal restart reason can be initialized to 0, and then the abnormal restart data can be analyzed. When it is determined that the electronic device exhibits a corresponding characteristic, the weight value of the corresponding abnormal restart reason can be increased.

[0129] In some embodiments, the preset abnormal restart reasons may include: DDR memory jump issues, DDR memory fixed frequency issues, and cache memory jump issues. It should be noted that this application does not limit the number of preset abnormal restart reasons, and may include fewer or more issues than those mentioned above.

[0130] DDR memory jump issues can cause significant bit inversions in the virtual address during electronic device operation. In the steps above, a significant bit inversion was confirmed, thus greatly increasing the likelihood that the DDR memory jump issue is the cause of abnormal restarts, and its weight value can be increased.

[0131] It should be understood that the latest abnormal restart data of electronic devices can reflect the behavior of the electronic devices at the most recent point in time and may contain the latest information that caused the abnormal restart. Therefore, if there is a significant bit flip in the latest abnormal restart, the probability that a DDR memory jump problem is the cause of the abnormal restart is greatly increased, while the probability decreases if there is no significant bit flip in the latest abnormal restart, and so on, the more recent the significant bit flip, the lower the probability.

[0132] Therefore, in some embodiments, N1 (also known as the first threshold) can be set according to the time (also known as the moment) when the electronic device undergoes a significant bit flip, and the later the time, the larger the first threshold.

[0133] In some embodiments, to avoid the weight value of the preset abnormal restart reason being too large and affecting the final judgment of the abnormal restart reason, a maximum weight value can be set.

[0134] For example, if an electronic device abnormally restarts three times, and a significant bit inversion is determined to have occurred once, then the previous abnormal restarts are no longer considered. Assuming the maximum weighting value is 60, when a significant bit inversion is determined to have occurred in the third abnormal restart, N1 can be 60; when a significant bit inversion is determined to have occurred in the second abnormal restart, N1 can be 40; and when a significant bit inversion is determined to have occurred in the first abnormal restart, N1 can be 20.

[0135] S106: Based on the abnormal restart data, determine whether the number of cache memory transition interrupts is greater than 0. If yes, execute S107; otherwise, execute S108.

[0136] In some embodiments, the abnormal characteristics of an electronic device may include a cache memory jump interrupt number greater than 0.

[0137] In one possible implementation, the electronic device may employ error detection and correction (EDAC) technology or error correcting code (ECC) mechanism. When EDAC technology or ECC mechanism detects an error in the cache memory, it can generate an interrupt.

[0138] Therefore, a cache memory jump interrupt count greater than 0 indicates a memory error in the cache memory, while a cache memory jump interrupt count of 0 indicates no memory error in the cache memory.

[0139] Based on the above description, the latest abnormal restart of an electronic device better reflects the current state of the cache memory. Therefore, in some embodiments, the determination can be made based on the latest abnormal restart data, that is, the number of cache memory transition interrupts recorded in the latest abnormal restart.

[0140] In one possible implementation, the system can first determine the cache memory transition interrupt count recorded in the latest abnormal restart based on the latest abnormal restart data. If the count is greater than 0, then proceed to step S107. If the count is 0, then determine the cache memory transition interrupt count recorded in the latest abnormal restart based on a set of historical abnormal restart data from the previous abnormal restart. If the count is greater than 0, then proceed to step S107. This process continues until no significant bit flip occurs in subsequent abnormal restarts. Then, determine the cache memory transition interrupt count recorded in the first abnormal restart based on a set of historical abnormal restart data from the first abnormal restart. If the count is greater than 0, then proceed to step S107; otherwise, proceed to step S108.

[0141] Thus, if the number of cache memory transition interrupts in an abnormal restart is greater than 0, there is no need to analyze previous abnormal restarts, which greatly reduces computing resources, saves time in abnormal restart analysis, and thus improves the speed of determining the cause of abnormal restarts.

[0142] In another possible implementation, the judgment can be made based on the abnormal restart data corresponding to each abnormal restart to determine whether the number of cache memory jump interrupts for each abnormal restart is greater than 0. If it is, continue to execute S107; otherwise, continue to execute S108.

[0143] Therefore, analyzing each abnormal restart helps to determine a more accurate cause of the abnormal restart.

[0144] S107: Increase the weight of the cache memory transition problem by N2 based on the number of cache memory transition interrupts.

[0145] Based on the above introduction, cache memory jump issues may cause errors in the cache memory, which in turn may lead to interrupts generated by methods such as EDAC or ECC mechanisms for detecting and correcting memory errors.

[0146] It should be understood that the more cache memory jump interrupts there are (which can be simply referred to as the number of jump interrupts or the number of interrupts), the greater the likelihood of a cache memory jump problem, and consequently, the greater the likelihood of the electronic device restarting abnormally.

[0147] In some embodiments, N2 can be set according to the number of cache memory transition interrupts. Meanwhile, considering that the number of interrupts is variable, to avoid the preset abnormal restart cause having an excessively large weight value, which could affect the final determination of the abnormal restart cause, a maximum weighting value can be set.

[0148] For example, the maximum weighted value can be 60, and the number of abnormal restarts is 10, then N2 = min(number of interrupts × 10, 60). For example, when the number of interrupts is 8, N2 is 60, and when the number of interrupts is 4, N2 = 40.

[0149] In some embodiments, the maximum weighting value can be set based on the time (also known as the moment) when the number of cache interrupts in the electronic device is greater than 0. The later the time, the larger the maximum weighting value.

[0150] For example, if an electronic device abnormally restarts three times, and the number of interrupt jumps is determined to be greater than 0 at the first occurrence, then the previous abnormal restarts are no longer considered. When the number of interrupt jumps is determined to be greater than 0 for the third abnormal restart, the maximum weighted value can be 60; when the number of interrupt jumps is determined to be greater than 0 for the second abnormal restart, the maximum weighted value can be 40; and when the number of interrupt jumps is determined to be greater than 0 for the first abnormal restart, the maximum weighted value can be 20.

[0151] S108: Based on the abnormal restart data, determine whether the CPU cores that caused the problem in the multiple abnormal restarts of the electronic device are the same. If yes, execute S109; otherwise, execute S110.

[0152] In some embodiments, the abnormal characteristics of an electronic device may include the presence of the same CPU core that causes problems during multiple reboots.

[0153] Based on the example above, abnormal restart data may include problematic CPU cores. Accordingly, in some embodiments, problematic CPU cores that have experienced multiple abnormal restarts can be identified from the latest and historical abnormal restart data included in the abnormal restart data, and then it can be determined whether these problematic CPU cores are the same CPU core.

[0154] For example, an electronic device includes 8 CPU cores, which have restarted abnormally 5 times. The problematic CPU cores are CPU core 3, CPU core 3, CPU core 1, CPU core 2 and CPU core 3. It can be determined that the problematic CPU cores in the multiple abnormal restarts of the electronic device have the same situation.

[0155] S109: Based on the same number of times the problematic CPU core appears during multiple abnormal restarts, increase the weight value of the cache memory jump problem by N3.

[0156] Cache memory jumps can cause problems with CPU cores, such as affecting the accuracy of the CPU core's data retrieval from the cache, which may lead to errors when processes run on that CPU core in electronic devices. Therefore, the higher the number of times the problematic CPU core appears in multiple abnormal restarts, the greater the likelihood of a CPU core problem, and further, the greater the possibility of cache memory jumps.

[0157] In some embodiments, one or more problematic CPU cores may exhibit the same behavior in multiple abnormal restarts, and the value of N3 can be determined based on the problematic CPU core with the largest number of identical occurrences.

[0158] For example, an electronic device includes 8 CPU cores, which abnormally restarted 5 times. The problematic CPU cores are CPU core 3, CPU core 3, CPU core 2, CPU core 2, and CPU core 2. CPU core 3 was the same number of times, and CPU core 2 was the same number of times. Then, the value of N3 can be determined based on the number of times CPU core 2 was the same (that is, the maximum number of times the same CPU core was the same).

[0159] In some embodiments, assuming the maximum weighting value is 60 and the number of abnormal restarts is 10, then N3 = maximum number of identical restarts / 10 × 60. For example, when the maximum number of identical restarts is 4, N3 is 24; when the number of interrupts is 6, N3 = 36.

[0160] S110: Calculate the weighted value of function calls after multiple abnormal restarts based on abnormal restart data.

[0161] Function call weighting (also known as similarity value) is used to represent the degree of similarity of function calls during multiple abnormal restarts.

[0162] For example, the function call stack can be used to store temporary data during the function call process. During the running process of an electronic device, the program pushes the parameters and return address of the called function onto the stack, and then jumps to the entry address of the function to execute the function code.

[0163] In some embodiments, the function call weighting value can be calculated based on function call data in the latest abnormal restart data and function call data in historical abnormal restart data. The following combines... Figure 3 The method for calculating the weighted values ​​of function calls will be explained in detail later, but will not be elaborated here.

[0164] Based on the example above, function call data includes multi-level function call relationships. Taking a three-level function call relationship as an example, each time an electronic device restarts abnormally, the functions corresponding to level 0 function symbol0, level 1 function symbol1, and level 2 function symbol2 can be recorded as function call data.

[0165] In some embodiments, the abnormal characteristics of an electronic device may include different function calls during multiple abnormal restarts. That is, multiple abnormal restarts may involve different functions or different order of function calls. For example, the first abnormal restart may call functions 1-3, while the second abnormal restart may call functions 4-6.

[0166] S111: Add the function call weighting value to the weighting value of the DDR memory jump problem.

[0167] The lower the similarity of function call patterns, the greater the likelihood that the cause of the electronic device's abnormal restart is a hardware problem. For example, hardware problems could include DDR memory transition issues.

[0168] In some embodiments, a larger function call weighting value indicates a lower degree of similarity in function calls across multiple abnormal restarts, meaning a greater difference in function call patterns across multiple restarts of the electronic device. DDR memory jumps may lead to a lower degree of similarity in function calls across multiple abnormal restarts; that is, the probability of DDR memory jumps is positively correlated with the magnitude of the function call weighting value—a larger value indicates a higher probability of DDR memory jumps. Therefore, the calculated function call weighting value can be added to the weighting value for the DDR memory jump problem.

[0169] S112: Based on the abnormal restart data, determine whether all function calls in multiple abnormal restarts of the electronic device are the same. If yes, execute S113; otherwise, execute S114.

[0170] It should be noted that S112 is an optional execution step. S112 can be executed if the calculated function call weight value is 0, and S116 can be executed directly after S111 if the function call weight value is greater than 0.

[0171] In some embodiments, the abnormal characteristics of an electronic device may include the fact that all function calls are the same in multiple abnormal restarts (also known as multiple sets of function call data are the same), that is, all functions are called in multiple abnormal restarts and the order of function calls is also the same.

[0172] For example, if an electronic device restarts abnormally 10 times, and the function call data included in the abnormal restart data for each abnormal restart is: function a calls function b, function b calls function c, then it can be determined that all function calls in the multiple abnormal restarts of the electronic device are the same; otherwise, it can be determined that the function calls in the multiple abnormal restarts of the electronic device are not all the same.

[0173] S113: Based on the abnormal restart data, determine whether the function calls in the multiple abnormal restarts of the electronic device include typical function calls. If yes, execute S114; otherwise, execute S115.

[0174] Typical functions (also known as preset functions) refer to functions that are frequently used on the CPU core when an electronic device experiences a hardware failure. If all function calls are the same in multiple abnormal restarts, and the called functions include typical functions, the possibility of abnormal restarts caused by DDR memory jumps is greatly increased.

[0175] S114: Based on the hardware problem weight value corresponding to the typical function, increase the weight value of the ddr memory jump problem by N5, and then execute S116.

[0176] In some embodiments, an electronic device may include a list of typical function calls, and a hardware problem weight value (also known as a problem weight value) for each typical function that may cause DDR memory jump problems.

[0177] For example, the typical functions include typical function 1, typical function 2 and typical function 3. Assuming the maximum weighting value is 60, the probability of typical function 1 to typical function 3 causing DDR memory jumps decreases sequentially. Then, the hardware problem weighting value corresponding to typical function 1 can be 30, the hardware problem weighting value corresponding to typical function 2 can be 20, and the hardware problem weighting value corresponding to typical function 3 can be 10.

[0178] If the function calls in the multiple abnormal restarts of the electronic device include calls to typical function 1, then the hardware problem weight value 30 corresponding to typical function 1 can be added as N5 to the weight value of the DDR memory jump problem.

[0179] Assuming that the function calls in the multiple abnormal restarts of the electronic device include calls to typical function 1 and typical function 2, then the sum of the weights of the hardware problems corresponding to typical function 1 and typical function 2, which is 50, can be used as N5 and added to the weight value of the DDR memory jump problem.

[0180] S115: Identify non-hardware issues as the cause of abnormal restarts of electronic devices and exit the abnormal restart analysis and processing flow.

[0181] Typical functions are those called when an electronic device's abnormal restart is caused by a hardware problem. If all function calls are identical in multiple abnormal restarts of the electronic device, and these function calls do not include typical functions (i.e., the abnormal restart data exhibits specific abnormal characteristics), it indicates that the cause of the abnormal restart is highly likely to be a non-hardware problem. Therefore, a non-hardware problem can be identified as the cause of the electronic device's abnormal restart.

[0182] In some embodiments, the non-hardware problem is a software problem of the electronic device.

[0183] In some embodiments, hardware problems may include DDR memory jump problems, DDR memory fixed frequency problems, and cache memory jump problems.

[0184] S116: Based on the abnormal restart data, determine whether the frequency of the DDR memory is the same in multiple abnormal restarts of the electronic device. If yes, execute S117; otherwise, execute S118.

[0185] The frequency of DDR memory refers to the operating frequency of DDR memory.

[0186] In some embodiments, the abnormal characteristics may include the frequency of the DDR memory appearing the same in multiple abnormal restarts.

[0187] In some embodiments, when an electronic device restarts abnormally multiple times, the higher the frequency of the DDR memory that is the same, the greater the likelihood that the electronic device may have a problem at that frequency.

[0188] S117: Based on the number of DDR memory frequencies that are the same, increase the weight value of the DDR memory fixed frequency problem by N6.

[0189] In some embodiments, N6 can be min(number of fixed frequency points, maximum weighting value), where the number of fixed frequency points refers to the number of times the frequency points of the DDR memory are the same during multiple abnormal restarts, and the maximum weighting value refers to the maximum weighting value set for the abnormal restart cause of the DDR memory fixed frequency point problem.

[0190] For example, if an electronic device restarts abnormally 10 times, and the DDR memory frequency points of the abnormal restart data are frequency 1, frequency 2, frequency 1, frequency 1, frequency 1, frequency 1, frequency 1, frequency 1, frequency 3 and frequency 1 respectively, then the number of fixed frequency points is 8.

[0191] In some embodiments, the likelihood of different preset abnormal restart reasons causing abnormal restarts of electronic devices varies, and therefore the maximum weighting value set for each preset abnormal restart reason can also be different. For example, the fixed frequency point problem of DDR memory is less likely to cause abnormal restarts of electronic devices compared to the DDR memory jump problem and the cache memory jump problem, so the maximum weighting value corresponding to the fixed frequency point problem of DDR memory is smaller.

[0192] For example, when the maximum weighting value for both the DDR memory jump problem and the cache memory jump problem is 60, the maximum weighting value for the DDR memory fixed frequency problem can be set to 10. Then, when the number of fixed frequency points is 8, N6 = 8, and when the number of fixed frequency points is 12, N6 = 10.

[0193] S118: Compare the weight values ​​corresponding to the DDR memory jump problem, cache memory jump problem, and DDR memory fixed frequency point problem.

[0194] Compare the weight values ​​corresponding to the three preset abnormal restart reasons: DDR memory jump problem, cache memory jump problem, and DDR memory fixed frequency point problem.

[0195] S119: The problem with the highest weight value among the DDR memory jump problem, cache memory jump problem, and DDR memory fixed frequency point problem is identified as the cause of abnormal restart of electronic devices.

[0196] The problem with the highest weight value is output as the reason for the abnormal restart of the electronic device.

[0197] In some embodiments, such as Figure 2 As shown, based on judgment point 1, judgment point 2, ..., judgment point x, the abnormal restart data is analyzed, and the problem types 1 to 3 are weighted according to the judgment results. For example, judgment point 1 can be weighted by n1 for problem type 1, judgment point 2 can be weighted by n2 for problem type 2, judgment point x can be weighted by n5 for problem type 3, other judgment points can be weighted by n3 for problem type 1, and other judgment points can be weighted by n4 for problem type 3. Finally, the one with the largest weight value (also called weight value) among the three problem types is output as the reason for abnormal restart.

[0198] For example, the above judgment points 1-x correspond one-to-one with some steps in the embodiment (for example, S103, S106, S108, S110, S112, S113 and S116 each correspond to one judgment point). Problem types 1-3 are respectively DDR memory jump problem, cache memory jump problem and DDR memory fixed frequency point problem.

[0199] Thus, in this embodiment, the electronic device experiencing an abnormal restart can analyze the cause of its abnormal restart, solving the problem of lag in the analysis of abnormal restart causes in related technologies and improving the efficiency of determining the cause of abnormal restart. Simultaneously, it determines whether the electronic device exhibits any abnormal characteristics. If the exhibited abnormal characteristics are not caused by hardware issues, then the non-hardware issue is directly identified as the cause of the abnormal restart. If the exhibited abnormal characteristics are caused by hardware issues, then the weight value of the hardware issue is increased accordingly. Finally, the hardware issue with the highest weight value among multiple hardware issues is identified as the cause of the abnormal restart of the electronic device. In this way, multiple abnormal characteristics can comprehensively analyze the cause of the abnormal restart of the electronic device, solving the problem of limitations in the determination of abnormal restart causes in related technologies and improving the accuracy of the determined abnormal restart cause.

[0200] Furthermore, in some embodiments, the method for determining the cause of abnormal restarts provided in this application can be applied to electronic devices that have not experienced abnormal restarts. That is, the electronic device can analyze the causes of abnormal restarts in other electronic devices. For example, if electronic device 1 experiences an abnormal restart, it can record the abnormal restart data at the kernel stage and send it to electronic device 2. Subsequently, electronic device 2 analyzes the abnormal restart data from electronic device 1, obtains the determined cause of the abnormal restart, and finally sends the cause of the abnormal restart back to electronic device 1. This application does not limit this approach.

[0201] Next, combined Figure 3 The calculation method of the function call weighting value is explained in detail, that is, the calculation process of S110 in the above embodiment.

[0202] like Figure 3 As shown, the method for calculating the weighted value in this function call may include the following steps:

[0203] It should be noted that function call data can include call data for one layer of functions or multiple layers of functions; that is, it can indicate functions called by at least one function layer. When function call data includes call data for multiple layers of functions (i.e., indicating functions called by multiple function layers respectively), the function call weighting value needs to be calculated based on the function call weighting value corresponding to each layer of functions (which can be called the basic function call weighting value). In the following embodiments, the calculation of the basic function call weighting value corresponding to the 0th layer function call is used as an example.

[0204] S1101: Initialize multiple flags to -1.

[0205] In this embodiment of the application, multiple flags are initialized to the same value to facilitate the differentiation of whether the function corresponding to each flag is compared with the function corresponding to other flags when performing subsequent steps (the flag will be set to other values ​​during the comparison). The value of the flag can be called the marker value.

[0206] Furthermore, it should be noted that initializing multiple flags to -1 is merely an example; multiple flags can also be initialized to other values. For example, see the steps below; to distinguish them, multiple flags can be initialized to any negative number.

[0207] Multiple flags are used to represent the flag values ​​of the level 0 functions (sometimes simply referred to as functions in S1101-S1113) corresponding to level 0 function calls during multiple abnormal restarts.

[0208] For example, suppose the electronic device restarted abnormally 10 times, combined with Figure 4 As shown, the acquired abnormal restart data includes records 0-9, that is, record0-record9 represent the abnormal restart data from the 1st to the 10th abnormal restart, respectively. symbol0 is used to represent the called level 0 function, and can be marked with 10 flags one-to-one with 10 symbol0s.

[0209] In some embodiments, it is initially assumed that all 10 symbolo0s are different, that is, all 10 level 0 functions are different, and they can be marked as -1. Therefore, the 10 flags can be initialized to -1. See [link to documentation]. Figure 5 The initial value of all 10 flags is -1.

[0210] In some embodiments, multiple flags can be arranged in the order in which the abnormal restart occurred. For example, the first flag indicates the first abnormal restart, the second flag indicates the second abnormal restart, and so on.

[0211] S1102: Initialize the outer loop counter to 0.

[0212] In some embodiments, an outer loop (also known as an outer loop comparison) is used to represent the process of comparing the function corresponding to one of the multiple flags with the functions corresponding to the remaining flags after that flag (i.e., the abnormal restarts after this abnormal restart).

[0213] For example, the first outer loop compares the level 0 function corresponding to the first flag among multiple flags with the level 0 functions corresponding to the subsequent flags to see if they are the same; the second outer loop compares the level 0 function corresponding to the second flag among multiple flags with the level 0 functions corresponding to the subsequent flags (excluding the first flag from the previous abnormal restart), the level 0 function corresponding to the third flag among multiple flags with the level 0 functions corresponding to the subsequent flags (excluding the first and second flags from the previous abnormal restart), and so on, and the outer loop comparison can be performed multiple times.

[0214] In some embodiments, the value of the outer loop count can be used to indicate the nth outer loop comparison performed.

[0215] In some embodiments, assuming that an outer loop count of 0 indicates that the level 0 function corresponding to the first flag among multiple flags needs to be compared with the level 0 functions corresponding to the subsequent flags, then the outer loop count needs to be initialized to 0 at the beginning of the comparison.

[0216] It should be noted that initializing the outer loop count to 0 is only an example. In some embodiments, if the outer loop count is 1, it means that the level 0 function corresponding to the first flag among multiple flags needs to be compared with the level 0 function corresponding to the next flag. In this case, the outer loop count can also be initialized to 1 to represent the initial state. Therefore, this application does not limit this.

[0217] S1103: Determine if the outer loop count has reached the upper limit. If yes, execute S1113; otherwise, execute S1104.

[0218] Based on the subsequent S1105, it is known that the outer loop count may need to be accumulated multiple times. Therefore, after the outer loop count is updated once, it is necessary to determine whether the upper limit has been reached. If the upper limit has been reached, it indicates that the comparison of the 0th layer function has been completed. Otherwise, it is necessary to continue the next outer loop comparison.

[0219] In some embodiments, based on the above description, the upper limit of the outer loop count is related to the number of flags. The outer loop count starts from 0, so the upper limit of the outer loop count is the number of flags minus 1. That is, when the outer loop count indicates the last flag among multiple flags, it means that all outer loop comparisons have been completed.

[0220] For example, if there are 10 flags, the upper limit of the outer loop count is 9. That is, when the outer loop count is 9, the 10 flags no longer include the flags that are listed later, meaning there is no need to perform function comparisons. However, if the outer loop count has not reached 9, then function comparisons are still required.

[0221] S1104: Check if the outer loop flag is 0. If it is, execute S1105; otherwise, execute S1106.

[0222] The outer loop flag refers to the flag that indicates the outer loop count (it can also be called the flag corresponding to the outer loop count). For example, if the outer loop count is 0, then the outer loop flag refers to the first flag among multiple flags; if the outer loop count is 1, then the outer loop flag refers to the second flag among multiple flags.

[0223] Based on S1101 above, we know that multiple flags are initially initialized to -1. However, S1104 is a step that needs to be executed multiple times in a loop. During the first check, the outer loop flag is initialized to -1, which is not 0. But when executing subsequent steps, as seen in S1111 and S1112, the functions corresponding to the two flags are compared. If they are the same, the flag with the later time sequence is set to 0. Therefore, when S1104 is executed in subsequent loops, the outer loop flag it indicates may be 0 if the outer loop counter changes. It should be noted that in subsequent steps, flags with the same function but a later time sequence can also be set to other values ​​for easy differentiation. In this case, the 0 value in step S1104 also needs to be replaced with other values ​​accordingly.

[0224] S1105: Increment the outer loop counter by 1 and return to execute S1103.

[0225] Based on the subsequent steps, we know that in one outer loop comparison, the functions corresponding to the outer loop flag and the flags that follow in the time sequence are compared. If they are the same, the flag with the later time sequence is set to 0. In this outer loop comparison, the outer loop flag is compared with all the subsequent flags. That is, the function corresponding to the outer loop flag has already been compared with all the subsequent flags. Therefore, the flag corresponding to the same function and with the later time sequence (whose value is already 0) does not need to be compared with the subsequent flags again. In other words, there is no need to perform another outer loop comparison based on the outer loop flag with a value of 0. Therefore, we can directly increment the outer loop counter by 1 and continue to determine whether to perform the next outer loop comparison.

[0226] This avoids repeated comparisons based on the same function, thus saving computational resources.

[0227] For example, suppose there are 5 flags, corresponding to function 1, function 1, function 2, function 1, and function 2 respectively. During the first outer loop comparison, the first flag acts as the outer loop flag. It can be determined that the function corresponding to the first flag is the same as the functions corresponding to the second and fourth flags, so the second and fourth flags are both set to 0. Therefore, during the second outer loop comparison, the function corresponding to the second flag, now acting as the outer loop flag, needs to be compared with the functions corresponding to the subsequent 3 flags. However, the function corresponding to the second flag is the same as the function corresponding to the first flag, and function 1 (corresponding to the first flag) has already been compared with the functions corresponding to the subsequent flags. Therefore, there is no need to repeat the comparison using function 1, i.e., no need to execute the second outer loop comparison. Thus, the outer loop counter can be directly incremented by 1, and the system can continue to determine whether a third outer loop comparison is needed.

[0228] S1106: Set the outer loop flag to 1.

[0229] Based on the above introduction and subsequent steps, we know that when the outer loop flag is set to 0, its corresponding function is the same as the function corresponding to the flag that comes before it. Therefore, when the outer loop flag is not set to 0, it means that its corresponding function is different from the function corresponding to the previous flag. Therefore, it is necessary to compare the function corresponding to the outer loop flag with the function corresponding to the flag that comes after it.

[0230] In some embodiments, the flag that needs to be compared in the outer loop can be set to 1, or it can be set to a value other than the initial value of the flag (-1 in this embodiment) and the value that the flag is set to when the function is the same (0 in this embodiment), so as to facilitate differentiation. This application does not limit this.

[0231] This makes it easier to distinguish between flags that require outer loop comparison, flags that do not require outer loop comparison, and flags that do not require outer loop comparison, thus avoiding duplicate comparisons or comparison errors.

[0232] S1107: Initialize the inner loop counter to the outer loop counter incremented by 1.

[0233] In some embodiments, an inner loop (also known as an inner loop comparison) is used to represent the process of comparing the outer loop flag with one of the flags arranged after it in each outer loop comparison.

[0234] For example, in the first outer loop comparison, the first inner loop compares whether the level 0 function corresponding to the first flag is the same as the level 0 function corresponding to the second flag; the second inner loop compares whether the level 0 function corresponding to the first flag is the same as the level 0 function corresponding to the third flag; and so on, one or more inner loop comparisons can be performed in each outer loop comparison.

[0235] In some embodiments, the value of the inner loop count is used to indicate the nth inner loop comparison performed in a single outer loop comparison.

[0236] In some embodiments, in each outer loop comparison, the function corresponding to the outer loop flag can be compared with the function corresponding to the flag that follows in the sequence from front to back. Therefore, the inner loop count needs to be initialized to the outer loop count plus 1.

[0237] For example, based on the example above, in the first outer loop comparison, the outer loop count is 0, indicating that the level 0 function corresponding to the first flag among multiple flags needs to be compared with the level 0 functions corresponding to the subsequent flags. Multiple inner loop comparisons can be performed in this outer loop comparison. Initially, the function corresponding to the first flag among multiple flags needs to be compared with the function corresponding to the second flag, so the inner loop count can be initialized to 1. This represents the first inner loop comparison within the first outer loop comparison.

[0238] S1108: Determine if the inner loop count has reached the upper limit. If yes, return to execute S1105; otherwise, execute S1109.

[0239] As can be seen from the subsequent S1110, the inner loop count may need to be accumulated multiple times. Therefore, after the inner loop count is updated once, it is necessary to determine whether the upper limit has been reached. If the upper limit has been reached, it indicates that the outer loop comparison is complete. Otherwise, the outer loop comparison needs to be continued.

[0240] In some embodiments, similar to the above, the upper limit of the inner loop count is related to the number of flags. Starting from 0, the upper limit of the inner loop count is the number of flags. For example, if there are 10 flags, corresponding to inner loop counts 0-9 respectively, then the upper limit of the inner loop count can be 10. That is, when the inner loop count is 10, all inner loop comparisons in this outer loop comparison have been completed.

[0241] S1109: Check if the inner loop flag is 0. If it is, execute S1110; otherwise, execute S1111.

[0242] Similarly, based on subsequent S1111 and S1112, when the function corresponding to the outer loop flag is the same as the function corresponding to the inner loop flag, the outer loop flag will be incremented by 1, and the inner loop flag will be set to 0. Whether the inner loop flag is 0 is used to indicate whether its corresponding function still needs to be compared with the function corresponding to the next flag in the list.

[0243] S1110: Increment the inner loop counter by 1 and return to execute S1108.

[0244] If the inner loop flag is 0, it means that the function corresponding to this flag is the same as the function corresponding to the previous flag, so there is no need to perform this inner loop comparison again.

[0245] This avoids redundant comparisons and saves computing resources.

[0246] S1111: Determine if the function corresponding to the outer loop flag is the same as the function corresponding to the inner loop flag. If yes, execute S1112; otherwise, execute S1110.

[0247] Based on the above steps, at this point, neither the outer loop flag nor the inner loop flag is 0, indicating that neither the outer loop flag nor the inner loop flag has been found to have the same function in the previous comparison. Therefore, the functions corresponding to the two can be compared separately.

[0248] S1112: Increment the outer loop flag by 1, set the inner loop flag to 0, and execute S1110.

[0249] In some embodiments, if the function corresponding to the outer loop flag is the same as the function corresponding to the inner loop flag, then the outer loop flag can be incremented by 1 and the inner loop flag can be set to 0. Therefore, the higher the final flag value, the higher the number of times the corresponding function is the same. A flag value of 0 indicates that no further comparison is needed, and a flag value of 1 indicates that there is no identical function.

[0250] This avoids redundant comparisons and saves computing resources.

[0251] It should be noted that you can also add other values ​​to the outer loop flag and set other values ​​to the inner loop flag for easy differentiation.

[0252] For example, in S1101, multiple flags can be initialized to 0, in S1106, the outer loop flag can be set to 2, and in S1112, the outer loop flag can be incremented by 2 and the inner loop flag can be set to 1. This application does not limit this.

[0253] by Figure 4 Taking the content shown as an example, based on the above introduction, the outer loop flag is initialized to 1. In the first comparison of the outer loop, that is, the outer loop flag is the flag corresponding to record0. If there is a symbol0 in the symbol0 recorded by records1 to record9 that is the same as the symbol0 of record0, then the outer loop flag can be incremented by 1, and the flag corresponding to the subsequent records with the same symbol0 can be set from -1 to 0.

[0254] For example, see [link to previous article] Figure 5 As shown, assuming that the symbol0 recorded by record0 to record3 are all the same, after the first outer loop comparison, the value of the flag corresponding to record0 first changes from -1 to 1, then to 4, the value of the flag corresponding to record1 to record3 changes from -1 to 0, and the value of the other flags remains -1.

[0255] Combination Figure 5As shown, based on the above steps, the first outer loop comparison sets the second through fourth flags to 0, allowing S1103-S1105 to be executed three times in a loop. After that, the outer loop count becomes 4, indicating that the outer loop comparison starts from the fifth flag. Assuming that the symbol0 recorded in record4 and record9 are the same, after the fifth outer loop comparison, the value of the flag corresponding to record4 first changes from -1 to 1, then to 2, the value of the flag corresponding to record9 changes from -1 to 0, and the values ​​of the flags corresponding to record5 through record8 remain at -1.

[0256] Assuming that the symbol0 recorded in records 5 through 8 are all different, the value of the flag corresponding to records 5 through 8 changes from -1 to 1, while the values ​​of the remaining flags remain unchanged.

[0257] S1113: Obtain the basic weighted value of the function call based on the values ​​of multiple flags.

[0258] When the outer loop count reaches its upper limit, it means that the function comparisons corresponding to multiple flags have been completed, that is, all the outer loop comparisons have been completed. At this point, the basic weighted value of the function call can be determined based on the values ​​corresponding to multiple flags.

[0259] Based on the above steps, the final value of flag is 1, which means that its corresponding function (i.e., the first function) is different from other functions. Therefore, the more 1s there are in the multiple flag values, the lower the degree of similarity of the function calls in multiple abnormal restarts (i.e., negative correlation).

[0260] In some embodiments, a higher function call weighting value indicates a lower degree of similarity between function calls from multiple abnormal restarts; that is, a higher base weighting value for function calls indicates a lower degree of similarity between function calls from multiple abnormal restarts.

[0261] In some embodiments, each function call has a corresponding weight value.

[0262] For example, the number of 1s in the values ​​of multiple flags can be multiplied by the weight value corresponding to the function call at level 0 (also known as the weight value of the function at level 0) to obtain the basic weighted value of the function call at level 0.

[0263] Based on the above description, S1101-S1113 is the process of calculating the basic weighted value of function calls corresponding to the level 0 function. If the function call data includes three levels of function call relationships, then S1101-S1113 needs to be executed twice more to calculate the basic weighted value of function calls corresponding to the level 1 function and the level 2 function, respectively.

[0264] Finally, based on the number of flags with a value of 1 corresponding to these three functions and their corresponding three weight values, the weighted value of the function calls after multiple abnormal restarts can be calculated.

[0265] In some embodiments, the function call weighting value = (number of function calls with a flag of 1 at level 0) × A1 + (number of function calls with a flag of 1 at level 1) × A2 + (number of function calls with a flag of 1 at level 2) × A3.

[0266] For example, A1 can be 3, A2 can be 2, and A3 can be 1; this application does not limit this.

[0267] As described in S1101-S1113, the call data of the same function at the same level for multiple abnormal restarts indicates that each abnormal restart corresponds to a specific function at that level. In other words, multiple abnormal restarts at that level correspond one-to-one with multiple functions. When calculating the basic weighted value of the function call data at that level, multiple flags can be used as marker values ​​for these functions. Then, based on the similarities among the functions at that level, the values ​​of these flags are updated. Finally, the basic weighted value of the function call at that level is calculated using the final values ​​of these multiple flags.

[0268] In multiple functions, all flags can be updated to the value 1 first (e.g., value 1 can be -1), also known as the fourth value. Then, comparisons are made for each function. Before the comparison, the flag corresponding to that function is updated to the value 2 (e.g., value 2 can be 1), also known as the first value. During the comparison, the flags corresponding to at least two functions that are identical are updated separately. The flag corresponding to the function with the earliest chronological order among the at least two functions is updated to the value 3, also known as the second value. The value 3 is determined based on the number of functions that are identical to a given flag (e.g., for a function corresponding to a certain flag, if several functions are identical, then the value is the sum of those functions). Then, for the remaining functions among the at least two functions, the flag corresponding to the remaining functions can be updated to the value 4 (e.g., value 4 can be 0), also known as the third value. When the basic weighted value of function calls indicates the difference in function calls, it can be determined based on the number of flags with a value of 1. See the example above for a detailed explanation.

[0269] Furthermore, based on the flag with a value of 3 among multiple flags, the number of functions that are identical to the function corresponding to that flag can be determined.

[0270] In this way, the final value of the updated multiple flag values ​​represents the degree of similarity in function calls at the same level. This makes it easier to calculate the function call weighting value that indicates the degree of similarity in function calls, thereby accurately indicating the probability of corresponding DDR memory jump problems and improving the accuracy of the cause of abnormal restarts.

[0271] Furthermore, in some embodiments, after determining the cause of the abnormal restart of the electronic device, it can be stored in a specific storage area of ​​the electronic device's memory (such as RAM, ROM, etc.). Subsequently, the cause of the abnormal restart can be retrieved from this specific storage area, packaged into a file, and finally uploaded to a cloud server. This facilitates the provision of clusterable data support for the commercial analysis of electronic devices, thereby improving the efficiency of repairing the cause of the abnormal restart.

[0272] In some embodiments, assuming that the cause of the abnormal restart of the electronic device is a DDR memory jump problem, a DDR memory repair strategy can be triggered.

[0273] In one possible implementation, the DDR memory repair strategy may include inspecting the DDR memory to check whether each storage cell of the DDR memory is functioning properly.

[0274] For example, if storage cell 1 in a plurality of storage cells has a problem (also known as a faulty storage cell), it can be isolated and the electronic device no longer uses the faulty storage cell 1.

[0275] In one possible implementation, the DDR memory repair strategy may also include modifying the parameters of the DDR memory. For example, modifying the DDR memory parameters according to the environment in which the electronic device is located.

[0276] For example, the parameters of DDR memory can be modified based on the ambient temperature of the electronic device to make them more adaptable to the current environment.

[0277] Next, we will use the Android system, which has a layered architecture, as an example to illustrate the software structure of an electronic device.

[0278] like Figure 6 As shown, the layered architecture divides the software structure into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system consists of, from top to bottom, the application layer and the kernel layer, etc.

[0279] The application layer can include a series of application packages. For example... Figure 6 As shown, the application package can include applications such as camera and gallery.

[0280] In some embodiments, such asFigure 6 As shown, the application layer can also include a file generation program and a file upload program. The file generation program detects the cause of the abnormal restart from the memory in the hardware layer, packages the cause into a file, and sends it to the file upload program. The file upload program uploads the packaged file to a cloud server. The cloud server can then use the received file to statistically analyze the causes of abnormal restarts in electronic devices, providing clusterable data support for commercial analysis of electronic devices and thus improving the efficiency of fixing abnormal restarts.

[0281] For example, the file generation program can be a multi-functional maintenance program xmaintain (which can be abbreviated as xmntn) or an Android engine exception program (AEE), the file upload program can be a cross-platform terminal device maintenance service set hiview, and the cloud server can be the Apache Portable Runtime (APR).

[0282] The kernel layer is the layer between hardware and software.

[0283] In some embodiments, the kernel layer may include a kernel panic detection module and an abnormal reboot data recording module. When the electronic device is powered on, if the kernel panic detection module detects a kernel panic, it will trigger the abnormal reboot data recording module to record the relevant data of this kernel panic as abnormal reboot data.

[0284] For example, the abnormal restart data recording module may include a small dump file microdump, which can be used to record abnormal restart data. The abnormal restart data recording module may also include a small storage dump file minidump, which is also used to record relevant abnormal restart data when an electronic device experiences a kernel panic.

[0285] In some embodiments, an inspection algorithm module and a repair strategy module are included between the kernel layer and the hardware layer.

[0286] In some embodiments, the inspection algorithm module includes a record reading unit and a feature library.

[0287] In some embodiments, the record reading unit of the inspection algorithm module can perform... Figure 1 As shown in S101; the feature library of the algorithm module can be checked and executed. Figure 1 As shown in S102-S119; checking the feature library of the algorithm module can also be performed. Figure 3 S1101-S1113 are shown.

[0288] In some embodiments, the reading and recording unit is used to retrieve abnormal restart data from the memory in the hardware layer of the electronic device, and the feature library is used to analyze the abnormal restart data to determine whether the abnormal restart data exhibits certain characteristics, thereby determining the cause of the abnormal restart of the electronic device. The electronic device can obtain the abnormal restart data recorded in the kernel stage by checking the algorithm module during the small system stage, so as to determine the cause of the abnormal restart of the electronic device during the small system stage.

[0289] For example, abnormal characteristics may include bit reversal of fixed bits in virtual address, number of cache memory jump interrupts, the same proportion of problematic CPU cores (i.e., the same number of problematic CPU cores in multiple abnormal restarts), the same degree of function calls, typical function calls, and fixed frequency points of DDR memory, etc.

[0290] In some embodiments, the repair strategy module is used to repair electronic devices based on the cause of abnormal restarts determined by the algorithm module.

[0291] For example, if the checking algorithm module determines that the abnormal restart is caused by a DDR memory jump problem, then the repair strategy module can be triggered to repair the DDR memory.

[0292] In some embodiments, the repair strategy module may include a DDR memory inspection unit and a DDR memory parameter modification unit.

[0293] The DDR memory inspection unit is used to inspect whether each memory cell of the DDR memory is normal, and to isolate memory cells with problems so that electronic devices no longer use the memory cells.

[0294] The DDR memory parameter modification unit is used to modify the parameters of the DDR memory.

[0295] The hardware layer includes memory.

[0296] In some embodiments, the storage area of ​​the memory can be used to store abnormal restart data recorded by the abnormal restart data recording module, as well as the abnormal restart cause determined by the feature library of the checking algorithm module. For example, the memory may include storage area 1 and storage area 2. Storage area 1 can be used to store abnormal restart data, and storage area 2 can be used to store the abnormal restart cause. Both can also be stored in the same storage area; this application does not limit this.

[0297] In some embodiments, the memory may be RAM, ROM, etc., and this application does not limit it.

[0298] It should be noted that the mobile phone used as an electronic device in the above embodiments is merely an example. In some embodiments, the electronic device can be a tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), or other terminal device. This application does not impose any special limitations on the specific form of the aforementioned electronic device.

[0299] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement one or more steps in any of the methods for determining the cause of an abnormal restart described above.

[0300] Computer-readable storage media can be non-transitory computer-readable storage media, such as ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage devices.

[0301] Another embodiment of this application provides a computer program product containing instructions. When this computer program product is executed by a computer, it can implement one or more steps in any of the methods for determining the cause of an abnormal restart described above.

[0302] The electronic device, computer-readable storage medium, and computer program product provided in this embodiment are all used to execute the method for determining the cause of abnormal restart provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the method for determining the cause of abnormal restart provided above, and will not be repeated here.

[0303] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0304] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0305] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for determining the cause of abnormal restart, characterized in that, The method includes: Acquire abnormal restart data of electronic devices; The abnormal restart data was determined to exhibit at least one of several abnormal features. Determining that the at least one abnormal feature includes a specific abnormal feature, a non-hardware problem is identified as the cause of the abnormal restart of the electronic device; If it is determined that the at least one abnormal feature does not include the specific abnormal feature, the weight value of the preset abnormal restart reason corresponding to the at least one abnormal feature is increased, and the preset abnormal restart reason with the largest weight value among the multiple preset abnormal restart reasons is determined as the abnormal restart reason of the electronic device; the multiple preset abnormal restart reasons are all used to indicate hardware problems; The abnormal restart data includes multiple sets of abnormal restart data during multiple abnormal restart processes of the electronic device; the preset abnormal restart reasons include DDR memory jump problems; the addition of weight values ​​for the preset abnormal restart reasons corresponding to the at least one abnormal feature includes: For each function layer of multiple sets of function call data, a first function is determined from the multiple functions indicated by that function layer; the first function is different from all other functions in the multiple functions; each set of function call data is used to indicate at least one function called by a function layer; Based on the number of the first function in each function layer of the multiple sets of function call data, calculate the similarity value of the multiple sets of function call data; the similarity value is negatively correlated with the similarity of the multiple sets of function call data. The same degree value is added to the weight value of the DDR memory jump problem.

2. The method according to claim 1, characterized in that, The plurality of functions each have a corresponding tag value, and determining the first function from the plurality of functions indicated by the function layer from the plurality of function call data includes: Update the flag values ​​corresponding to the plurality of functions to the first value; From multiple marker values, at least two marker values ​​corresponding to the same function are determined, and both marker values ​​are updated to values ​​different from the first value. The function whose marked value is the first numerical value among the plurality of functions is identified as the first function.

3. The method according to claim 2, characterized in that, The plurality of marker values ​​are arranged sequentially according to the time order of the abnormal restart; updating at least two marker values ​​to values ​​different from the first value includes: The first of the at least two marker values ​​is updated to a second value, and the remaining marker values ​​are all updated to a third value; the second value is obtained based on the number of remaining marker values.

4. The method according to claim 2 or 3, characterized in that, Before updating the marker values ​​corresponding to the plurality of functions to the first value, the method further includes: The flag values ​​corresponding to the multiple functions are all initialized to the fourth value; The step of updating the marker values ​​corresponding to the plurality of functions to the first value includes: For each function, the function is updated to the first value before being compared with other functions among the plurality of functions.

5. The method according to any one of claims 1-4, characterized in that, The abnormal restart data includes multiple sets of abnormal restart data from multiple abnormal restart processes of the electronic device; the preset abnormal restart reasons include DDR memory jump problems; determining that the abnormal restart data exhibits at least one of multiple abnormal features includes: It was determined that the multiple sets of abnormal restart data corresponded to the same set of function call data, and that the multiple sets of function call data contained a preset function; the preset function had a corresponding problem weight value. The addition of a weight value for the preset abnormal restart reason corresponding to the at least one abnormal feature includes: The problem weight value corresponding to the preset function is added to the weight value of the ddr memory jump problem.

6. The method according to any one of claims 1-4, characterized in that, The determination of the at least one abnormal feature includes specific abnormal features, identifying non-hardware problems as the cause of the abnormal restart of the electronic device, including: If the at least one abnormal feature is determined to be that the multiple sets of function call data corresponding to the multiple sets of abnormal restart data are all the same, and it is determined that the multiple sets of function call data do not contain a preset function, then a non-hardware problem is determined to be the cause of the abnormal restart of the electronic device.

7. The method according to any one of claims 1-6, characterized in that, The abnormal restart data includes multiple sets of abnormal restart data from multiple abnormal restart processes of the electronic device; the preset abnormal restart reasons include DDR memory jump problems; determining that the abnormal restart data exhibits at least one of multiple abnormal features includes: The process continues in reverse chronological order, determining whether a bit inversion exists at the preset location of the address for each group of abnormal restart data, until a bit inversion is found at the preset location of the address for a group of abnormal restart data. The addition of a weight value for the preset abnormal restart reason corresponding to the at least one abnormal feature includes: The first threshold is increased to the weight value of the ddr memory jump problem; the first threshold increases as the time corresponding to the determined set of abnormal restart data shifts backward.

8. The method according to any one of claims 1-7, characterized in that, The abnormal restart data includes multiple sets of abnormal restart data from multiple abnormal restart processes of the electronic device; the preset abnormal restart reasons include DDR memory frequency issues; determining that the abnormal restart data exhibits at least one of multiple abnormal features includes: It was determined that the multiple sets of abnormal restart data contained the same DDR memory frequency. The addition of a weight value for the preset abnormal restart reason corresponding to the at least one abnormal feature includes: The weight value of the DDR memory frequency issue is increased based on the number of identical DDR memory frequencies.

9. The method according to any one of claims 1-8, characterized in that, Also includes: When the electronic device changes from a powered-on state to a powered-off state, record the abnormal restart data of the electronic device; The acquisition of abnormal restart data of electronic devices includes: When the electronic device switches from a powered-off state to a powered-on state, read the abnormal restart data of the electronic device.

10. The method according to any one of claims 1-9, characterized in that, Before determining that the abnormal restart data exhibits at least one of multiple abnormal features, the method further includes: The abnormal restart data was determined to meet the abnormal restart analysis conditions.

11. The method according to claim 10, characterized in that, The abnormal restart analysis conditions include one or more of the following: the number of abnormal restarts of the electronic device exceeds the fifth threshold; the time interval between the latest abnormal restart and the previous abnormal restart is less than the sixth threshold; the average time interval between multiple abnormal restarts of the electronic device is less than the seventh threshold.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: If the cause of the abnormal restart of the electronic device is determined to be a DDR memory jump problem, then the faulty memory cell of the DDR memory is identified and isolated. If the cause of the abnormal restart of the electronic device is determined to be a DDR memory jump problem, then the parameters of the DDR memory are modified based on the environment in which the electronic device is located.

13. An electronic device, characterized in that, Including memory and processor; The memory is coupled to the processor, and the memory is used to store computer program code, the computer program code including computer instructions, wherein one or more of the processors call the computer instructions to cause the electronic device to perform the method for determining the cause of abnormal restart as described in any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method for determining the cause of an abnormal restart as described in any one of claims 1-12.

15. A computer program product, characterized in that, It includes computer program code, which, when executed by an electronic device, implements the steps of the method for determining the cause of an abnormal restart as described in any one of claims 1 to 12.

Images