Operating system failure information sensing method and apparatus, terminal, and storage medium

Abstract

This invention discloses a method, device, terminal, and storage medium for sensing operating system fault information, belonging to the field of operating systems. The method includes: deploying a resident lightweight resource detection tool to detect external manifestations of anomalies; when anomalies appear, activating an information collection daemon to periodically collect system resource information using a small amount of resources, closing the resident lightweight resource detection tool, and generating system resource trend information; using the system resource trend information to determine if there is an abnormal trend deterioration; when there is an abnormal trend deterioration, selecting and loading a corresponding medium-weight resource information collection plugin based on the system resource information corresponding to the abnormal trend; using the medium-weight resource information collection plugin to collect system information and recording the system information. This method can simultaneously ensure resource effectiveness and information integrity.

Description

Technical Field

[0001] This invention relates to the field of operating system technology, and in particular to a method, apparatus, terminal and storage medium for sensing operating system fault information. Background Technology

[0002] In the lifecycle of modern operating systems, especially complex graphical operating systems such as desktop operating systems and in-vehicle intelligent cockpit systems, various abnormal failures inevitably occur due to software and hardware incompatibility, resource competition, or underlying driver defects. These failures not only reduce the impact on user experience and system reliability, but also seriously affect the user experience.

[0003] To locate these faults, operating systems typically need to deploy fault information collection mechanisms. In existing technologies, to capture sudden system anomalies, fault information is usually collected by a persistent background resource monitoring daemon. However, this 24 / 7 online, full-data collection mode continuously consumes CPU processing time, memory bandwidth, and interrupt resources. The resource consumption of the monitoring program itself becomes part of the system load, and may even directly induce or exacerbate system lag and anomalies. Furthermore, if daily consumption is reduced and information collection is triggered using static resource thresholds, since system faults are often a cumulative deterioration process, by the time the static threshold is triggered, the system is often already on the verge of irreversible collapse, making it difficult to collect comprehensive and complete system information. Summary of the Invention

[0004] This invention provides a method, device, terminal, and storage medium for sensing operating system fault information, in order to solve the technical problem in the prior art that the collection of system fault information cannot simultaneously guarantee the effectiveness of resources and the integrity of information.

[0005] In a first aspect, embodiments of the present invention provide an operating system fault information perception method, comprising: Deploy a resident lightweight resource exploration tool to explore abnormal external characteristics, which are objective quantitative manifestations of deviations from normal operating thresholds that can be observed by the system. When abnormal external manifestations appear, the information collection daemon is activated, and system resource information is collected periodically with a small amount of resources. The resident lightweight resource exploration tool is closed, and system resource trend information is generated. Use system resource trend information to determine if there is an abnormal trend deterioration; When the trend deteriorates abnormally, select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend deterioration, and load the medium-level resource information acquisition plugin. The system information is collected using the medium-scale resource information acquisition plugin. The system information is panoramic resource information that includes the system resource information, and the system information is recorded.

[0006] Secondly, embodiments of the present invention also provide an operating system fault information sensing device, comprising: The deployment module is used to deploy a resident lightweight resource probing tool to detect external signs of anomalies. The activation module is used to activate the information collection daemon when abnormal external manifestations occur, collect system resource information periodically with a small amount of resources, disable the resident lightweight resource exploration tool, and generate system resource trend information. The judgment module is used to determine whether the trend is deteriorating abnormally by utilizing system resource trend information. The loading module is used to select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend deterioration when the trend deterioration is abnormal, and to load the medium-level resource information acquisition plugin. The recording module is used to collect system information using the medium-scale resource information acquisition plugin, wherein the system information is panoramic resource information including the system resource information, and to record the system information.

[0007] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the operating system fault information perception method as described in any of the above embodiments.

[0008] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the operating system fault information perception method provided in the above embodiments.

[0009] The operating system fault information perception method, device, terminal, and storage medium provided in this invention deploy a resident lightweight resource detection tool to detect abnormal external manifestations. When abnormal external manifestations appear, an information collection daemon is activated to collect system resource information periodically with a small amount of resources. The resident lightweight resource detection tool is then closed, and system resource trend information is generated. The system resource trend information is used to determine whether the trend is deteriorating abnormally. If the trend is deteriorating abnormally, a corresponding medium-weight resource information collection plugin is selected based on the system resource information corresponding to the trend deterioration abnormality, and the medium-weight resource information collection plugin is loaded. The medium-weight resource information collection plugin is used to collect system information, and the system information is recorded. By deploying a resident lightweight resource detection tool to detect only abnormal external manifestations and simultaneously closing the resident lightweight resource detection tool when activating the information collection daemon, the system achieves low-overhead relay switching between different monitoring stages, avoiding the resource superposition consumption caused by the simultaneous operation of multiple monitoring methods. By periodically collecting system resource trend information using limited resources, and then determining whether an anomaly in trend deterioration has occurred based on this information, the criteria for fault diagnosis are expanded from resource status at a single point in time to a resource change trajectory over time. This effectively identifies the process of slow resource degradation and allows for the selection and loading of corresponding medium-scale resource information collection plugins based on the system resource information associated with an anomaly in trend deterioration. An on-demand, targeted loading mechanism is employed, performing in-depth information collection only on specific system dimensions related to the anomaly, effectively avoiding resource waste and additional performance load caused by running irrelevant diagnostic modules. This approach achieves a balance between resource effectiveness and information completeness. Attached Figure Description

[0010] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating the operating system fault information perception method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the operating system fault information perception method provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart illustrating the operating system fault information perception method provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the operating system fault information sensing device provided in Embodiment 4 of the present invention; Figure 5 This is a schematic diagram of the terminal provided in Embodiment 5 of the present invention. Detailed Implementation

[0011] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0012] Example 1 Figure 1 This is a flowchart of the operating system fault information perception method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations involving the perception and collection of operating system fault information. The method can be executed by an operating system fault information perception device, and specifically includes the following steps: Step 110: Deploy a resident lightweight resource exploration tool to explore abnormal external characteristics.

[0013] In this embodiment, the method can run on a Linux operating system environment that supports eBPF (Extended Berkeley PacketFilter) or an equivalent kernel instrumentation mechanism. To capture early-stage anomalies with extremely low system overhead, the aim is to keep the increase in system resource usage to a very low level, for example, less than 0.1%, so that the user is completely unaware of it.

[0014] For example, the resident lightweight resource exploration tool may include probes deployed at specific tracking points or instructions for querying system resource utilization. For example, a resident lightweight resource exploration tool can be constructed by dynamically injecting probes and employing a minimalist tracking strategy at both ends.

[0015] For example, deploying a resident lightweight resource probing tool to detect abnormal external characteristics may include: for peripheral device interaction scenarios, deploying operation event probes at peripheral device interaction event tracking points; deploying display end event probes at interaction display time tracking points; and determining whether preliminary abnormal external characteristics have occurred based on the difference between the operation time collected by the operation event probes and the display time collected by the display end event probes. The abnormal external characteristics can be objective, quantitative manifestations of the system deviating from normal operating thresholds that can be observed, and may include: the system's external interaction response latency exceeding a preset threshold and / or abnormal fluctuations in the system's internal performance statistics.

[0016] Optionally, for mouse or touchpad input responses in peripheral interaction scenarios, when an input event occurs, the lightweight resource probing tool does not insert probes in the intermediate processing stage. Instead, it only captures the event and records the timestamp T_irq at the irq / input_event tracking point when the hardware interrupt enters the kernel; subsequently, it captures the event and records the timestamp T_display at the drm / vblank tracking point when the corresponding frame is rendered and displayed. Based on these two endpoint timestamps, the system calculates the end-to-end response latency (i.e., T_display - T_irq). When this latency exceeds a preset baseline threshold, abnormal external manifestations of mouse interaction stuttering can be detected.

[0017] The baseline threshold can be calculated by sampling 1000 times each under idle and high load conditions during the system's initial startup, and using the P95 quantile as the normal baseline. Thereafter, the baseline is updated weekly. If a valid baseline sample cannot be collected for a week due to the system being in an abnormal state for an extended period (e.g., the system crashes and restarts daily), the current baseline is locked, and an alarm event is generated to prompt manual intervention from the administrator.

[0018] In keyboard input response scenarios, the lightweight resource probing tool only records the timestamp T_irq at the irq / input_event trace point when a key interrupt enters the kernel, and the timestamp T_display at the drm / vblank trace point when characters are rendered and displayed on screen. The key-to-screen latency is obtained by calculating the difference between the two. If an abnormal increase in this latency is detected, an abnormal external manifestation of keyboard interaction is detected.

[0019] For graphics rendering scenarios that do not rely on user triggers, the lightweight resource probing tool records a timestamp T_submit at the GPU / submit tracking point where the application submits a rendering request, and a timestamp T_display at the drm / vblank tracking point where the frame is output to the display. Based on this, the total frame rendering latency is calculated, and the frame interval is continuously counted. Once the frame interval consistently exceeds the target frame time, a frame drop is determined, thus detecting abnormal external manifestations of graphics rendering. In addition to monitoring interaction latency, the resident lightweight resource probing tool also periodically checks changes in CPU and memory usage. When an unexpected, sudden increase in usage is detected within a short period, it is also identified as an abnormal external manifestation. By employing a strategy of only capturing the first and last timestamps, the increase in system resource usage is controlled within 0.1%, thus ensuring accurate detection of user-visible abnormal symptoms while avoiding interference with system operation caused by the monitoring itself.

[0020] Step 120: When abnormal external manifestations appear, activate the information collection daemon process, use a small amount of resources to periodically collect system resource information, close the resident lightweight resource exploration tool, and generate system resource trend information.

[0021] For example, after confirming the existence of initial abnormal characteristics in the system, process data on the fault evolution is obtained under strict resource overhead constraints. Optionally, when the resident lightweight resource probing tool detects abnormal external manifestations, such as the aforementioned UI response latency exceeding the threshold or a sudden increase in CPU usage, a switching of monitoring mode is triggered, activating the information collection daemon process that is in a dormant or standby state. At the same time, to avoid resource contention between the newly activated collection process and the original lightweight probing tool in terms of CPU scheduling or interrupt handling, the resident lightweight resource probing tool is shut down at the same time as the information collection daemon process is activated, or shortly thereafter. Using the above method, it is ensured that the system runs only a single type of monitoring entity at any given time, thereby realizing the relay and replacement of monitoring load and keeping the overall additional resource consumption of the system at an extremely low level.

[0022] The information collection daemon does not perform full or high-frequency data scraping, but rather collects system resource information using a limited number of resource cycles. After activation, the daemon is woken up according to a preset, relatively low-frequency collection cycle. During each wake-up, it reads only basic system resource information from the operating system's core virtual file system nodes: this includes reading total memory, used memory, available memory, and Swap usage from / proc / meminfo; reading CPU user-mode, kernel-mode, IO wait, and idle time percentage from / proc / stat; selectively reading VmRSS (actual physical memory usage), thread count, and number of open file descriptors for key processes from / proc / [pid] / status and / proc / [pid] / fd directories; and reading disk read / write throughput and IO wait time from / proc / diskstats. Because the collection cycle is relatively long and only general statistical nodes are read, deep kernel probing is unnecessary, thus strictly meeting the constraint of utilizing limited resources.

[0023] For the system resource information generated by the aforementioned periodic data collection, a circular buffer can be used for storage management. Newly collected data is continuously written to the circular buffer, and the oldest data is automatically overwritten during writing, ensuring that the buffer always retains historical data from the most recent 24 hours. This fixed-capacity circular overwrite mechanism prevents unlimited expansion of storage space and ensures that the data storage process does not consume excessive system resources.

[0024] Based on this, the system utilizes the accumulated time-series data within the circular buffer to form system resource trend information. To accurately assess whether this trend information represents an abnormal deterioration, a dynamically evolving baseline generation mechanism is introduced. For example, in the first 24 hours after the system's initial installation, since historical data is insufficient to characterize normal system operation, the system uses built-in static thresholds (e.g., memory utilization > 80%, CPU utilization > 90%) as the evaluation criteria, while simultaneously accumulating initial historical data during this period. After the system has run for 24 hours, a temporary baseline is generated based on the accumulated initial data. After the system has run for 7 days and accumulated sufficient historical samples, the system switches to a periodic baseline (μ ± 2σ, i.e., the historical mean plus or minus two standard deviations). Thus, the system compares the periodically collected real-time data with the current dynamic baseline over time, thereby accurately forming system resource trend information that reflects whether resources are in a stable fluctuation or continuously deviating from the normal and gradually deteriorating.

[0025] As the information collection daemon runs periodically, it continuously acquires system resource information at discrete time points. To discern the evolution direction of faults from this discrete data, the values ​​of the same resource dimension acquired in different collection cycles are arranged and stored in chronological order, forming system resource trend information. For example, combining the available memory from multiple consecutive collections in a time series can reflect whether memory resources are fluctuating steadily or declining continuously; combining multiple CPU I / O wait times can reflect whether I / O bottlenecks are instantaneous or continuously worsening. Through periodic low-overhead collection and time-series organization, the system successfully constructs system resource trend information for subsequent judgment of fault evolution without significantly increasing the burden on critical states.

[0026] Step 130: Use system resource trend information to determine whether the trend is abnormally deteriorating.

[0027] For example, an anomaly inflection point detection algorithm can be used to determine whether a trend of deterioration is abnormal. The core logic of the anomaly inflection point detection algorithm lies in filtering out unavoidable transient fluctuations and spikes in system operation, and accurately capturing the continuous deviation and deterioration rate of resource consumption from long-term time-series data. Its judgment process is similar to eliminating random interference in physiological sign monitoring and only issuing warnings for pathological features that are continuously and rapidly escalating.

[0028] Taking memory leak detection as an example, it can be achieved as follows: First, the system resource information sequence acquired periodically is smoothed. The information acquisition daemon calculates the moving average MA(t) within a sliding window, where the sliding window size is set to 20 sampling points. By extracting the moving average, short-term resource usage fluctuations can be effectively eliminated, reflecting the true evolution of the indicator. Then, the current moving average is compared with the aforementioned dynamically generated periodic baseline. The moving average of the same period over the past 7 days is extracted as the baseline mean μ, and the standard deviation σ of the past 7 days is calculated, thereby constructing a healthy baseline range (μ±2σ). If the current moving average MA(t) exceeds the upper limit of the healthy baseline range (i.e., MA(t)>μ+2σ), and this exceedance is not an instantaneous phenomenon but lasts for more than 3 consecutive windows (i.e., more than 15 minutes), the system determines that the current resource indicator deviates from the normal state and identifies it as an abnormal trend. Based on this, in order to further confirm the degree of deterioration of the deviation, the system continues to calculate the slope of the moving average k=ΔMA / Δt. This slope represents the rate at which resource indicators deviate from the normal state. If the slope k is greater than the preset deterioration slope threshold, for example, setting the leakage slope threshold to increase by 0.1% per minute, it indicates that the system resources are evolving towards severe deterioration at a relatively fast rate. At this time, it can be confirmed that there is a memory leak, that is, it is confirmed that an abnormal trend of deterioration has occurred.

[0029] Step 140: When the trend deterioration is abnormal, select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the trend deterioration abnormality, and load the medium-level resource information acquisition plugin.

[0030] In this embodiment, the deep sampling capability is not normally resident in memory as a process. It is only dynamically loaded when the triggering conditions for abnormal trend deterioration are met, thereby avoiding additional performance impact on the system caused by irrelevant diagnostic tools.

[0031] For example, when the system confirms an anomaly in trend deterioration through the aforementioned inflection point detection algorithm, it extracts the specific type and characteristics of the system resource information that triggered the anomaly, and selects a matching medium-level resource information collection plugin from the plugin mapping table accordingly. Optionally, the mapping relationship includes: if the system resource information reflects a memory leak slope exceeding a threshold, the memleak-probe plugin is selected; if the system resource information reflects a critical process thread count exceeding a threshold, the thread-probe plugin is selected; if the system resource information reflects a process file descriptor count exceeding a threshold, the fd-probe plugin is selected; if the system resource information reflects an IO wait time consistently exceeding 50%, the io-probe plugin is selected; if the system resource information reflects a process receiving an anomaly signal (such as SIGSEGV or SIGABRT), the crash-probe plugin is selected.

[0032] Taking the thread-probe plugin as an example, when it detects a sharp deterioration in the number of threads in a critical process, such as increasing from 100 to 800 and exceeding the threshold of 500, the thread-probe plugin, which is in a dormant state, is dynamically loaded into the runtime environment. Immediately after loading, the plugin establishes a deep sampling channel targeting this specific dimension of deterioration. For example, the plugin dynamically injects probes into system calls such as clone() or pthread_create() using eBPF technology to intercept the underlying behavior of thread creation; on the other hand, the plugin directly reads the status files of all threads in the / proc / [pid] / task / directory to obtain a system-level thread snapshot.

[0033] The plugin correlates and merges call stack information intercepted by the underlying probe with system snapshots, collecting data and structuring it into a standard format, such as JSON. This data can include process identifiers, process names, the total number of current threads, timestamps, and a list of threads containing each thread's identifier, thread state, and complete call stack. Furthermore, the plugin performs aggregated analysis of stack patterns, extracting frequently occurring patterns and calculating the degradation rate based on time-series data.

[0034] Furthermore, downstream diagnostic engines, such as AI diagnostic engines, can be used to perform preliminary root cause analysis based on structured data. This process enables a precise leap from determining macro-level deterioration trends to capturing micro-level targeted data, ensuring that the most critical fault location information is obtained at minimal cost when the system is on the verge of collapse.

[0035] Step 150: Collect system information using the medium-scale resource information collection plugin and record the system information.

[0036] In this embodiment, the system information can be panoramic resource information including the system resource information. The loaded medium-scale resource information acquisition plugin, based on its built-in targeting logic, performs in-depth data capture on specific dimensions that cause trend deterioration anomalies through dynamically injected eBPF probes or invoked system-level tracing tools. The above acquisition process has clear focus and time constraints, which not only surpasses the limitations of only obtaining statistical summary values ​​in the previous steps, but also avoids the devastating I / O pressure caused by indiscriminate full dumping, thus meeting the medium-scale resource constraint characteristics.

[0037] Taking the thread-probe plugin as an example, when it detects a sharp deterioration in the number of threads in a critical process, such as increasing from 100 to 800 and exceeding the threshold of 500, the thread-probe plugin, which is in a dormant state, is dynamically loaded into the runtime environment. Immediately after loading, the plugin establishes a deep sampling channel targeting this specific dimension of deterioration. For example, the plugin dynamically injects probes into system calls such as clone() or pthread_create() using eBPF technology to intercept the underlying behavior of thread creation; on the other hand, the plugin directly reads the status files of all threads in the / proc / [pid] / task / directory to obtain a system-level thread snapshot.

[0038] The plugin correlates and merges call stack information intercepted by the underlying probe with system snapshots, collecting data and structuring it into a standard format, such as JSON. This data can include process identifiers, process names, the total number of current threads, timestamps, and a list of threads containing each thread's identifier, thread state, and complete call stack. Furthermore, the plugin performs aggregated analysis of stack patterns, extracting frequently occurring patterns and calculating the degradation rate based on time-series data.

[0039] Furthermore, downstream diagnostic engines, such as AI diagnostic engines, can be used to perform preliminary root cause analysis based on structured data. This process enables a precise leap from determining macro-level deterioration trends to capturing micro-level targeted data, ensuring that the most critical fault location information is obtained at minimal cost when the system is on the verge of collapse.

[0040] This embodiment deploys a resident lightweight resource detection tool to detect abnormal external manifestations. When abnormal external manifestations appear, an information collection daemon is activated to collect system resource information periodically with a small amount of resources. The resident lightweight resource detection tool is then deactivated, and system resource trend information is generated. This system resource trend information is used to determine if the trend is deteriorating abnormally. If the trend is deteriorating abnormally, a corresponding medium-weight resource information collection plugin is selected based on the system resource information corresponding to the deteriorating trend, and the medium-weight resource information collection plugin is loaded. The medium-weight resource information collection plugin is used to collect system information, and this system information is recorded. By deploying the resident lightweight resource detection tool to detect only abnormal external manifestations and simultaneously deactivating the resident lightweight resource detection tool when activating the information collection daemon, the system achieves low-overhead relay switching between different monitoring stages, avoiding the resource superposition caused by multiple monitoring methods running simultaneously. By periodically collecting system resource trend information using limited resources, and then determining whether an anomaly in trend deterioration has occurred based on this information, the criteria for fault diagnosis are expanded from resource status at a single point in time to a resource change trajectory over time. This effectively identifies the process of slow resource degradation and allows for the selection and loading of corresponding medium-scale resource information collection plugins based on the system resource information associated with an anomaly in trend deterioration. An on-demand, targeted loading mechanism is employed, performing in-depth information collection only on specific system dimensions related to the anomaly, effectively avoiding resource waste and additional performance load caused by running irrelevant diagnostic modules. This approach achieves a balance between resource effectiveness and information completeness.

[0041] In a preferred embodiment of this example, before using system resource trend information to determine whether the trend is deteriorating abnormally, the method may further include the following steps: when an abnormal external manifestation occurs, obtain the state changes of key processes related to the abnormal external manifestation; if the relevant key process exits abnormally, record the exit information and terminate the activation of the information collection daemon; if the relevant key process does not exit abnormally, it is determined to be a suspected system-level abnormality, and the step of activating the information collection daemon is returned. The state change notifications of a preset list of key processes can be subscribed to by listening to the DBus event channel of the operating system's service manager. The list of key processes covers the core components that maintain basic system interactions, and by default includes the window manager, display server, desktop session, and panel / taskbar, etc. This list also supports user customization by adding or removing processes through configuration files to adapt to different application scenarios.

[0042] After acquiring the status change information, the following traffic splitting and judgment logic is executed: If an abnormal exit of the relevant critical process is detected (e.g., the process exit code is not 0), it indicates that the current abnormal external manifestation is directly caused by the crash of that specific process, belonging to a local single point of failure, specifically indicating that it is caused by a certain application, rather than the system. At this time, two coordinated actions can be performed: On the one hand, the system records the exit information in detail, which includes at least the process name, process identifier, exit time, and exit code, to solidify the crash scene. On the other hand, as a system self-healing mechanism, the system will notify the service manager to attempt to restart the abnormally exited process, for example, setting a maximum of 10 retries, to restore basic services. The system terminates the activation of the information collection daemon process. Since the nature of the process crash is clear, there is no need to consume system resources to start the daemon process for long-term resource trend analysis. Timely termination of activation can effectively avoid introducing additional monitoring load during periods of system instability. Conversely, if the system confirms that the relevant critical processes have not exited abnormally (i.e., the core service processes are still alive), but exhibits the aforementioned abnormal external manifestations such as persistent interface lag, it indicates that the fault is not due to a single point of failure, but rather a high probability of underlying resources being continuously consumed or scheduling being obstructed. In this case, the system classifies it as a suspected system-level anomaly and triggers a subsequent deep diagnostic process. This involves returning to the step of executing the activation information collection daemon, using limited resources to periodically collect system resource information to capture gradual deterioration trends. This mechanism of first identifying the nature of the fault and then distributing the processing effectively avoids meaningless trend analysis of single-point-of-failure faults, improving the overall efficiency of fault perception and response.

[0043] Example 2 Figure 2 This is a flowchart illustrating the operating system fault information perception method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and is optimized. The method may also include the following steps: setting event tracking points in the input driver layer, graphics card driver layer and direct rendering manager of the corresponding peripherals, and deploying lightweight depth information acquisition probes at each event tracking point. The depth information acquisition probes are configured to remain silent and not collect data during the stage of probing the external characteristics of the anomaly and judging the trend of deterioration of the anomaly, and are only triggered to activate when the system freezes, so as to complete the collection of short-term system information snapshots of the underlying driver.

[0044] See Figure 2 The operating system fault information perception method includes: Step 210: Deploy a resident lightweight resource exploration tool to explore abnormal external characteristics.

[0045] Step 220: Set event tracking points in the input driver layer, graphics card driver layer and direct rendering manager of the corresponding peripherals, and deploy a lightweight depth information acquisition probe at each event tracking point. The depth information acquisition probe is configured to remain silent and not collect data during the stage of probing the external characteristics of the anomaly and judging the trend of deterioration. It is only triggered and activated when the system freezes, so as to complete the collection of short-term system information snapshots of the underlying driver.

[0046] To address system freezes that are more extreme than a deteriorating trend, such as hard locks, kernel deadlocks, or critical driver suspensions, the method also includes a step of pre-building a low-level driver-level hard lock orientation capture mechanism to achieve a simple and non-intrusive probe that is synchronized with kernel-level interrupts to capture the final moment's situation.

[0047] Event tracking points can be set in the input driver layer, graphics card driver layer (GPU driver), and direct rendering manager (DRM) of the corresponding peripherals, and a lightweight depth information acquisition probe can be deployed at each event tracking point. The aforementioned driver layer and manager are the lowest-level and most critical links in the graphics interaction chain, and are most prone to causing systemic freezes. Unlike conventional on-demand loading or periodic acquisition mechanisms, the depth information acquisition probe is configured with a special sleep-wake mode: during normal system operation and the aforementioned stages of probing abnormal external manifestations and judging deteriorating trends, the depth information acquisition probe remains silent and does not collect any data. This ensures that even when the system is already under high load or experiencing resource leaks, the depth probe will not increase interrupt processing latency, and absolutely avoids triggering or exacerbating system freezes due to the monitoring behavior itself.

[0048] The deep information acquisition probe is only activated when the system freezes, such as when the kernel watchdog detects a hard lock or the input driver layer detects a prolonged unresponsive anomaly signal in the interrupt context. Once activated, the probe performs a short-term system information snapshot collection operation with the simplest instruction set under the current extremely restricted environment: it quickly reads the current event suspension state of the input driver layer, the fence synchronization wait state of the graphics card driver layer, and the atomic commit blocking state of the direct rendering manager, and captures the register context or core data structure pointers of these key underlying drivers to form a short-term system information snapshot of the underlying drivers. Using the above method, it is possible to complete the black-box snapshot collection of the key context of the underlying drivers with minimal interference in the face of a complete crash and unresponsiveness, providing irreplaceable low-level evidence for subsequent analysis of the root cause of the system freeze.

[0049] Step 230: When abnormal external manifestations occur, activate the information collection daemon process, collect system resource information periodically with a small amount of resources, close the resident lightweight resource exploration tool, and generate system resource trend information.

[0050] Step 240: Use system resource trend information to determine whether the trend is abnormally deteriorating. If the trend is abnormally deteriorating, select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend, and load the medium-level resource information acquisition plugin.

[0051] Step 250: Collect system information using the medium-scale resource information collection plugin and record the system information.

[0052] This embodiment adds the following steps: Event tracking points are set in the input driver layer, graphics card driver layer, and direct rendering manager of the corresponding peripherals, and a lightweight depth information acquisition probe is deployed at each event tracking point. The depth information acquisition probe is configured to remain silent and not collect data during the stages of probing external anomalies and judging deteriorating trends, only being activated when the system freezes, to complete a short-term system information snapshot collection of the underlying driver. This enables black-box snapshot collection of key underlying driver scenarios with minimal interference even in the event of a complete crash and unresponsiveness, providing irreplaceable underlying evidence for subsequent analysis of the root cause of system freezes.

[0053] In a preferred embodiment of this example, the method may further include the following step: when the system freezes, all lightweight resource probing tools are restarted, and the collection dimensions of the lightweight resource probing tools to be restarted are dynamically adjusted to complete the collection of short-term system information snapshots. When the system freezes (such as kernel deadlock or critical scheduling blockage), the conventional user-mode monitoring process is completely paralyzed because it cannot obtain CPU scheduling. At the same time, freezing is often a chain reaction caused by multiple resource intertwined blockages, and single-dimensional probing cannot reconstruct the true topology of the global deadlock. To address this problem, this embodiment adopts a strategy combining full forced activation and minimalist dimensionality reduction. Optionally, when the system detects a freezing event, all lightweight resource probing tools are restarted. The lightweight resource probing tools include not only all the tools initially deployed, but also the lightweight deep information collection probes deployed at each event tracking point mentioned in this embodiment. At this point, the usual on-demand startup or single-module probing logic is abandoned. Instead, all lightweight probing tools covering all dimensions, including CPU, memory, I / O, network, and process scheduling, are forcibly activated, forming a comprehensive low-level monitoring matrix. This allows for the coverage of all potential concurrent factors that could cause a system crash before complete system failure, preventing the loss of crucial clues to the origin of the deadlock due to the omission of a probe in a particular dimension. All lightweight resource probing tools operate concurrently within a very short, urgent time window, collecting short-term system information snapshots. These snapshots, with minimal processing overhead, capture the core state of the system across all dimensions at the moment of the crash and write the panoramic data directly to non-volatile storage. This provides crucial evidence for subsequent panoramic reconstruction of the deadlock scenario and pinpointing the root cause of the crash.

[0054] Example 3 Figure 3 This is a flowchart illustrating the operating system fault information perception method provided in Embodiment 3 of the present invention. This embodiment is based on the above embodiment and is optimized. The method may also include the following steps: During the system startup phase, a dedicated memory region is allocated in memory. The size of the dedicated memory region matches the size of the collected system information and is set to not participate in the normal memory allocation of the system and not be occupied by other processes or kernel subsystems; an independent kernel thread is set up. The independent kernel thread is used to start all lightweight resource exploration tools and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be started. The priority of the independent kernel thread is set to the highest real-time priority so that the independent kernel thread can be scheduled and executed at any time; when the system is stuck, a reading time threshold is set for reading each process entry. When the reading time exceeds the reading time threshold, the reading of the current process entry is abandoned and the reading of the next process entry is started; the kernel log is read using direct memory access to avoid traversing virtual file system paths that have failed or are blocked; the internal data structure of the kernel's lock dependency tracker is directly traversed, and it is explicitly stated that no attempt is made to acquire any locks.

[0055] See Figure 3 The operating system fault information perception method includes: Step 310: During the system startup phase, a dedicated memory region is allocated in memory. The size of the dedicated memory region matches the size of the collected system information and is set to not participate in the normal memory allocation of the system and not be occupied by other processes or kernel subsystems.

[0056] During normal system operation, memory resources often suffer from severe memory fragmentation due to heavy process usage or frequent allocation and release, leading to a state of memory shortage. If the data acquisition process only dynamically requests memory when it is abnormally triggered or even when it is stuck, it is very easy for the request to fail due to insufficient available memory or fragmentation that cannot meet the continuous allocation requirements, resulting in the complete loss of critical fault scene data.

[0057] To avoid the aforementioned problems and ensure the absolute reliability of the data acquisition execution path, this embodiment performs a reserved memory allocation operation during the system startup phase. Optionally, in the early stages of kernel startup, the system calls a kernel-level memory reservation interface, such as the memblock_reserve() function, to allocate a contiguous dedicated memory region in physical memory. The size of this dedicated memory region matches the size of the system information to be collected, and is specifically estimated and set based on a strict estimate of the preset data acquisition content capacity. For example, based on the capacity requirements of the process list snapshots, kernel logs, and memory mapping data structures required for the complete acquisition process, the size of this dedicated memory region can be estimated and set to approximately 16MB. This ensures sufficient snapshot storage space while avoiding excessive reservation that could waste available system memory resources.

[0058] The dedicated memory region is explicitly marked as dedicated and has corresponding attribute constraints: the memory region is configured not to participate in normal system memory allocation, that is, it is completely excluded from the kernel's regular memory management mechanism. Using these attribute settings, throughout the entire subsequent system runtime, regardless of the overall memory state of the system, other user-mode processes or kernel subsystems cannot request to occupy this region.

[0059] Using the above method, when the system malfunctions and needs to trigger deep information acquisition, the acquisition process can directly use this dedicated memory area as the carrier for data assembly and temporary storage, completely avoiding the risk of dynamic memory allocation failure. At the storage resource level, this ensures the possibility of acquisition tasks being implemented under extreme fault environments.

[0060] Step 320: Set up an independent kernel thread. The independent kernel thread is used to start all lightweight resource exploration tools and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be started. The priority of the independent kernel thread is set to the highest real-time priority so that the independent kernel thread can be scheduled and executed at any time.

[0061] In extreme abnormal scenarios such as system crashes, even if the aforementioned reserved memory mechanism ensures the availability of data storage space, the snapshot collection of on-site information cannot be completed if the code logic responsible for executing the acquisition instructions cannot obtain CPU scheduling execution rights. Since system crashes are often accompanied by the blocking and deadlock of a large number of regular processes or kernel threads, if the acquisition logic relies on a normal scheduling queue, it is very easy to get stuck due to the inability to obtain a time slice.

[0062] An independent kernel thread is pre-configured, dedicated to executing the aforementioned emergency data collection logic. This includes launching all lightweight resource probing tools and dynamically adjusting the collection dimensions of the tools to be launched. This independent kernel thread is not attached to any user-space process or regular kernel subsystem that may cause blocking; its lifecycle and execution logic are completely independent, specifically designed to respond to extreme triggering signals such as system freezes.

[0063] Furthermore, to ensure that the independent kernel thread can still preempt execution opportunities even under extremely poor system conditions, the system configures the scheduling strategy of the independent kernel thread as a real-time first-in-first-out strategy and sets the priority of the independent kernel thread to the highest real-time priority, for example, setting the priority parameter to 99.

[0064] By setting the highest real-time priority as described above, when a deadlock occurs and a trigger signal is sent, the independent kernel thread can immediately interrupt any running low-priority tasks, and can even forcibly seize CPU control from a deadlocked task cluster. This ensures that the independent kernel thread can be scheduled and executed at any time, completely eliminating scheduling delays caused by system overload, congestion in the regular scheduling queue, or thread deadlocks. This guarantees that the startup of the full-scale exploration tool and the dimensionality reduction snapshot collection can be forced and advanced immediately, thereby retrieving valuable on-site data before the system completely crashes.

[0065] Step 330: Deploy a resident lightweight resource exploration tool to explore abnormal external manifestations; when abnormal external manifestations appear, activate the information collection daemon process, collect system resource information using a small amount of resources periodically, close the resident lightweight resource exploration tool, and generate system resource trend information.

[0066] Step 340: Use system resource trend information to determine whether the trend is abnormally deteriorating. If the trend is abnormally deteriorating, select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend, and load the medium-level resource information acquisition plugin.

[0067] Step 350: Collect system information using the medium-scale resource information collection plugin and record the system information.

[0068] Step 360: When the system freezes, set a reading time threshold for each process entry. When the reading time exceeds the threshold, abandon the reading of the current process entry and start reading the next process entry.

[0069] When a system freezes, there are often processes in a deadlock or suspended state within the kernel. During the collection of short-term system information snapshots, when an independent kernel thread traverses the system process list to obtain information about each process entry—such as reading process state, call stack, or memory mapping—if the process being read is in a spinlock holding state, an uninterruptible semaphore sleep state, or its namespace is frozen, regular data read operations will be blocked indefinitely. If local blocking is not controlled, it can easily cause the entire snapshot collection process to stall, making it impossible to capture the global state before the system completely crashes.

[0070] To overcome the aforementioned problems, this embodiment introduces a strict timeout blocking mechanism when snapshot collection is triggered due to system freeze. This involves setting a read duration threshold for each process entry. The read duration threshold is set to an extremely short time window based on the time urgency of extreme scenarios, aiming to quickly test the reachability of process entries. When an independent kernel thread sequentially traverses the process list, it starts a timer simultaneously when initiating a read operation on a process entry. If the read operation successfully completes and returns data within the set read duration threshold, the read process information is normally written to the aforementioned dedicated memory area. If the read operation exceeds the read duration threshold and still fails to return valid data, it is determined that the underlying read path of the process entry is blocked by a deadlock or suspension. In this case, a timeout exit logic is forcibly triggered, the read of the current process entry is abandoned, the blocking state is no longer waited for to be resolved, and the read pointer is directly transferred to read the next process entry to continue the collection process.

[0071] Using the above method, the snapshot collection process effectively achieves logical isolation of faulty nodes. At the cost of discarding a very small amount of abnormal process information, it avoids the phenomenon of global collection task stagnation caused by single-point blockage, ensuring that the overall snapshot collection action can continue to advance and be completed quickly, greatly improving the robustness and timeliness of data collection under extreme failures.

[0072] Step 370: Read the kernel log using direct memory access to avoid traversing failed or blocked virtual file system paths; directly traverse the kernel's lock dependency tracker's internal data structures, explicitly declaring that no attempt will be made to acquire any locks.

[0073] When a system is stuck, conventional data reading paths often become invalid. Traditional virtual file system paths responsible for reading kernel logs (such as reading / proc / kmsg or / var / log) heavily rely on the proper functioning of the file system layer, network layer, or block device I / O layer. When the system is stuck, these underlying subsystems are highly likely to be deadlocked or blocked. If logs are still read through virtual file system paths, the acquisition thread will inevitably be stuck in an infinite wait. Therefore, this embodiment uses direct memory access to read kernel logs. For example, the acquisition logic bypasses all potentially blocking file system API calls, directly locating the starting address and offset of the kernel log circular buffer in physical memory or the kernel virtual address space based on the kernel symbol table. Log data is then extracted to the aforementioned reserved dedicated memory area through direct memory copy operations, thus completely avoiding traversing faulty or blocked virtual file system paths and ensuring the instantaneous and absolutely reliable reading of logs. Furthermore, a common root cause of system stucks is kernel-mode deadlock. To capture the deadlock situation, it is necessary to read the holding and waiting states of various locks in the kernel. Conventional kernel data reading typically requires acquiring a spinlock or mutex protecting the data structure. However, in a deadlock environment, if the acquisition logic attempts to acquire a lock already held by a deadlocked thread, the acquisition thread itself will immediately enter a deadlock, causing the entire snapshot collection process to completely fail. This embodiment, when reading lock states, directly traverses the internal data structures of the kernel's lock dependency tracker (such as lockdep) and explicitly declares in the code execution logic that it will not attempt to acquire any locks. The acquisition logic directly accesses the linked list head, lock instance structure, and wait queue pointer in the lock tracker using a lock-free read-only method, performing only shallow memory value truncation. Although this lock-free reading method may theoretically read inconsistent data being modified by other CPUs within a very small time window, in a life-or-death situation where the system is stuck, obtaining a general deadlock topology is far more valuable for diagnosis than deadlock caused by the acquisition thread itself acquiring a lock. By using the above-mentioned direct memory access to avoid file system blocking and lock-free traversal to avoid self-locking deadlocks, the snapshot collection process can quickly capture and solidify critical state data when faced with any underlying resource deadlocks or suspensions.

[0074] This embodiment adds the following steps: During system startup, a dedicated memory region is allocated in memory. The size of this dedicated memory region matches the size of the collected system information and is set to not participate in normal system memory allocation and not be occupied by other processes or kernel subsystems. An independent kernel thread is set up to execute the startup of all lightweight resource exploration tools and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be started. The priority of this independent kernel thread is set to the highest real-time priority so that it can be scheduled and executed at any time. When the system freezes, a reading duration threshold is set for reading each process entry. If the reading exceeds the reading duration threshold, the reading of the current process entry is abandoned, and the reading of the next process entry is started. The kernel log is read using direct memory access to avoid traversing virtual file system paths that have failed or are blocked. The internal data structure of the kernel's lock dependency tracker is directly traversed, explicitly stating that no attempt is made to acquire any locks. The reserved dedicated memory is isolated from the normal system allocation to avoid memory exhaustion or fragmentation that would leave data with nowhere to be stored. Setting the highest real-time priority independent kernel thread ensures that it can forcibly preempt the CPU to execute the collection task in any frozen state. By using process read timeout abandonment, direct memory access to bypass the file system, and lock-free traversal of kernel data structures, the data acquisition process itself is completely prevented from being suspended or causing secondary deadlocks, ensuring that critical diagnostic data is captured before the system completely crashes.

[0075] In a preferred embodiment of this example, the method may further include the following steps: A slave system, independent of the current system, listens to a physically or logically isolated communication interface to receive write commands and data, the data including: collected system information and kernel logs, lock information, and process information; the data is written to a solid-state non-volatile storage unit in transaction mode, and the corresponding metadata and checksum are recorded; and the system maintains its running state after the main system crashes, capable of responding to external read requests. The slave system, independent of the current system, listens to a physically or logically isolated communication interface, such as shared memory, serial port, PCIe, or IPMI interface. When the independent kernel thread on the main system side completes the collection of a short-term system information snapshot, it sends a write command and data to be stored to the slave system through the aforementioned isolated communication interface, the data including system information and kernel logs, lock information, and process information collected by the main system. Upon receiving the write command, the slave system immediately receives the snapshot data transmitted in isolation. The slave system writes the received data to its internally equipped solid-state non-volatile storage unit in transaction mode. Under the transactional write mechanism, data is either written successfully in its entirety or rolled back completely in the event of an abnormal interruption during the write process. This ensures the atomicity and integrity of the stored data, preventing the generation of incomplete or corrupted data blocks. Simultaneously, during the data write process, the slave system synchronously records the metadata corresponding to that batch of data. This metadata includes information such as timestamps, data types, and checksums, for subsequent verification of data reliability and consistency. Since the slave system operates independently of the master system, its lifecycle is not dependent on the state of the master operating system. Therefore, even after the master system crashes, the slave system can still maintain its operational state. The slave system can respond to external read requests at any time, outputting complete fault scene data and verification information preserved in non-volatile storage units, thereby enabling black box data forensics and root cause reconstruction after the master system is completely paralyzed.

[0076] Example 4 Figure 4 This is a schematic diagram of the operating system fault information sensing device provided in Embodiment 4 of the present invention. See also... Figure 4 The operating system fault information sensing device includes: Deployment module 410 is used to deploy a resident lightweight resource exploration tool to explore abnormal external characteristics, wherein the abnormal external characteristics are objective quantitative manifestations of deviations from the normal operation threshold that can be observed by the system. The activation module 420 is used to activate the information collection daemon when abnormal external manifestations occur, collect system resource information periodically with a small amount of resources, close the resident lightweight resource exploration tool, and form system resource trend information. The judgment module 430 is used to determine whether the trend is deteriorating abnormally by using system resource trend information; The loading module 440 is used to select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend deterioration when the trend deterioration is abnormal, and load the medium-level resource information acquisition plugin. The recording module 450 is used to collect system information using the medium-scale resource information acquisition plugin, wherein the system information is panoramic resource information including the system resource information, and to record the system information.

[0077] The operating system fault information sensing device provided in this embodiment detects abnormal external manifestations by deploying a resident lightweight resource detection tool. When abnormal external manifestations appear, an information collection daemon is activated to collect system resource information periodically with a small amount of resources. The resident lightweight resource detection tool is then closed, and system resource trend information is generated. The system resource trend information is used to determine whether the trend is deteriorating abnormally. If the trend is deteriorating abnormally, a corresponding medium-weight resource information collection plugin is selected based on the system resource information corresponding to the trend deterioration abnormality, and the medium-weight resource information collection plugin is loaded. The medium-weight resource information collection plugin is used to collect system information, and the system information is recorded. By deploying the resident lightweight resource detection tool to detect only abnormal external manifestations and simultaneously closing the resident lightweight resource detection tool when activating the information collection daemon, the system achieves low-overhead relay switching between different monitoring stages, avoiding the resource superposition consumption caused by the simultaneous operation of multiple monitoring methods. By periodically collecting system resource trend information using limited resources, and then determining whether an anomaly in trend deterioration has occurred based on this information, the criteria for fault diagnosis are expanded from resource status at a single point in time to a resource change trajectory over time. This effectively identifies the process of slow resource degradation and allows for the selection and loading of corresponding medium-scale resource information collection plugins based on the system resource information associated with an anomaly in trend deterioration. An on-demand, targeted loading mechanism is employed, performing in-depth information collection only on specific system dimensions related to the anomaly, effectively avoiding resource waste and additional performance load caused by running irrelevant diagnostic modules. This approach achieves a balance between resource effectiveness and information completeness.

[0078] Based on the above embodiments, the deployment module includes: The first deployment unit is used to deploy operation event probes at peripheral interaction event tracking points for peripheral interaction scenarios. The second deployment unit is used to deploy a display end event probe at the interactive display time tracking point; The determining unit is used to determine whether a preliminary abnormal external characterization has been generated based on the difference between the operation time collected by the operation event probe and the display time collected by the display end event probe.

[0079] Based on the above embodiments, the device further includes: The configuration module is used to set event tracking points in the input driver layer, graphics card driver layer and direct rendering manager of the corresponding peripherals, and to deploy a lightweight depth information acquisition probe at each event tracking point. The depth information acquisition probe is configured to remain silent and not collect data during the stage of probing the external characteristics of the anomaly and judging the trend of deterioration, and to be activated only when the system freezes, so as to complete the collection of short-term system information snapshots of the underlying driver.

[0080] Based on the above embodiments, the device further includes: The acquisition module is used to acquire the state changes of key processes related to the external manifestations of an anomaly when they occur. The exit information recording module is used to record exit information and terminate the activation of the information collection daemon process when the relevant key process exits abnormally. The return module is used to determine a suspected system-level anomaly if the relevant critical process does not exit abnormally, and then return to execute the step of the activation information collection daemon process.

[0081] Based on the above embodiments, the device further includes: The restart module is used to restart all lightweight resource exploration tools when the system freezes, and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be started in order to complete the collection of short-term system information snapshots.

[0082] Based on the above embodiments, the device further includes: The partitioning module is used to partition a dedicated memory region in memory during the system startup phase. The size of the dedicated memory region is matched with the size of the collected system information and is set to not participate in the normal memory allocation of the system and not be occupied by other processes or kernel subsystems. The configuration module is used to configure an independent kernel thread. The independent kernel thread is used to start all lightweight resource exploration tools and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be started. The priority of the independent kernel thread is set to the highest real-time priority so that the independent kernel thread can be scheduled and executed at any time. The abandon module is used to set a reading time threshold for each process entry when the system is stuck. When the reading time exceeds the reading time threshold, the reading of the current process entry is abandoned and the reading of the next process entry is started. The read module is used to read kernel logs using direct memory access, avoiding traversing faulty or blocked virtual file system paths; The direct traversal module is used to directly traverse the internal data structures of the kernel's lock dependency tracker, explicitly declaring that it does not attempt to acquire any locks.

[0083] Based on the above embodiments, the device further includes: The monitoring module is used to monitor physically or logically isolated communication interfaces using a slave system independent of the current system, and to receive write commands and data, including: collected system information and kernel logs, lock information and process information; The write module is used to write data to the solid-state non-volatile storage unit in transaction mode and record the corresponding metadata and check value. The runtime persistence module is used to maintain the running state after the main system crashes and can respond to external read requests.

[0084] The operating system fault information sensing device provided in this embodiment of the invention can execute the operating system fault information sensing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0085] Example 5 Figure 5 This is a schematic diagram of the structure of a terminal provided in Embodiment 5 of the present invention. Figure 5 A block diagram is shown of an exemplary terminal 12 suitable for implementing embodiments of the present invention. Figure 5 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0086] like Figure 5 As shown, terminal 12 is presented in the form of a general-purpose computing terminal. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0087] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0088] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0089] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0090] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0091] Terminal 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing terminal, display 24, etc.), and with one or more terminals that enable a user to interact with terminal 12, and / or with any terminal (e.g., network card, modem, etc.) that enables terminal 12 to communicate with one or more other computing terminals. This communication can be performed via input / output (I / O) interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0092] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the operating system fault information perception method provided in the embodiments of the present invention.

[0093] Example 6 Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the operating system fault information perception methods provided in the above embodiments.

[0094] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0095] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0096] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0097] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or terminal. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0098] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for sensing operating system fault information, characterized in that, include: Deploy a resident lightweight resource exploration tool to explore abnormal external characteristics, which are objective quantitative manifestations of deviations from normal operating thresholds that can be observed by the system. When abnormal external manifestations appear, the information collection daemon is activated, and system resource information is collected periodically with a small amount of resources. The resident lightweight resource exploration tool is closed, and system resource trend information is generated. Use system resource trend information to determine if there is an abnormal trend deterioration; When the trend deteriorates abnormally, select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend deterioration, and load the medium-level resource information acquisition plugin. The system information is collected using the medium-scale resource information acquisition plugin. The system information is panoramic resource information that includes the system resource information, and the system information is recorded.

2. The method according to claim 1, characterized in that, The deployment of a persistent, lightweight resource probing tool to detect abnormal external characteristics includes: For peripheral device interaction scenarios, deploy operation event probes at peripheral device interaction event tracking points; Deploy display end event probes at interactive display time tracking points; Whether a preliminary abnormal external characterization has been generated is determined based on the difference between the operation time collected by the operation event probe and the display time collected by the display end event probe.

3. The method according to claim 2, characterized in that, The method further includes: Event tracking points are set in the input driver layer, graphics card driver layer and direct rendering manager of the corresponding peripherals, and lightweight depth information acquisition probes are deployed at each event tracking point. The depth information acquisition probes are configured to remain silent and not collect data during the stage of probing the external characteristics of anomalies and judging the trend of deterioration anomalies, and are only triggered to activate when the system freezes, so as to complete the collection of short-term system information snapshots of the underlying driver.

4. The method according to claim 1, characterized in that, Before using system resource trend information to determine whether the trend is abnormally deteriorating, the method further includes: When an abnormal external manifestation occurs, obtain the state changes of key processes related to the abnormal external manifestation; If the relevant critical process exits abnormally, the exit information is recorded, and the activation of the information collection daemon process is terminated. If the relevant critical processes do not exit abnormally, it is determined to be a suspected system-level anomaly, and the process returns to execute the activation information collection daemon process.

5. The method according to claim 1, characterized in that, The method further includes: When the system freezes, restart all lightweight resource exploration tools and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be launched in order to complete the collection of short-term system information snapshots.

6. The method according to claim 5, characterized in that, The method further includes: During the system startup phase, a dedicated memory region is allocated in memory. The size of the dedicated memory region matches the size of the collected system information and is set to not participate in the normal memory allocation of the system and not be occupied by other processes or kernel subsystems. An independent kernel thread is configured to start all lightweight resource exploration tools and dynamically adjust the collection dimensions of the lightweight resource exploration tools to be started. The priority of the independent kernel thread is set to the highest real-time priority so that the independent kernel thread can be scheduled and executed at any time. When the system freezes, a reading time threshold is set for each process entry. If the reading time exceeds the threshold, the reading of the current process entry is abandoned and the reading of the next process entry is started. Use direct memory access to read kernel logs, avoiding traversing faulty or blocked virtual file system paths; Directly traversing the kernel's lock dependency tracker's internal data structures explicitly declares that no attempt will be made to acquire any locks.

7. The method according to claim 6, characterized in that, The method further includes: The system uses a slave system independent of the current system to listen to a physically or logically isolated communication interface to receive write commands and data, including: collected system information and kernel logs, lock information and process information; Data is written to solid-state non-volatile storage units in transaction mode, and the corresponding metadata and check values ​​are recorded. It remains operational even after the main system crashes, and is able to respond to external read requests.

8. An operating system fault information sensing device, characterized in that, include: The deployment module is used to deploy a resident lightweight resource exploration tool to explore abnormal external characteristics, which are objective quantitative manifestations of deviations from the normal operating threshold that can be observed by the system. The activation module is used to activate the information collection daemon when abnormal external manifestations occur, collect system resource information periodically with a small amount of resources, disable the resident lightweight resource exploration tool, and generate system resource trend information. The judgment module is used to determine whether the trend is deteriorating abnormally by utilizing system resource trend information. The loading module is used to select the corresponding medium-level resource information acquisition plugin based on the system resource information corresponding to the abnormal trend deterioration when the trend deterioration is abnormal, and to load the medium-level resource information acquisition plugin. The recording module is used to collect system information using the medium-scale resource information acquisition plugin, wherein the system information is panoramic resource information including the system resource information, and to record the system information.

9. A terminal, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the operating system fault information perception method as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the operating system fault information perception method as described in any one of claims 1-7.

Images