Software exception handling method and apparatus, electronic device, and computer program product

Abstract

This application provides a software anomaly handling method, apparatus, electronic device, and computer program product, belonging to the field of software operation and maintenance. The method includes the following steps: obtaining anomaly event data from a third-party monitoring platform, and obtaining user behavior trajectory and network request data within a preset time window before the occurrence of the anomaly event from a designated log system; generating an anomaly context dataset based on the anomaly event data, user behavior trajectory, and network request data; preprocessing the anomaly context dataset, extracting key anomaly feature information from the preprocessed data, and generating anomaly fingerprints; obtaining candidate cases from a preset knowledge base based on the anomaly fingerprints, inputting the candidate cases and the anomaly context dataset into a large language model to obtain anomaly diagnosis results; restoring the obfuscated stack to the source code location through a symbolic mapping table, and determining the code modifier information at that source code location; generating an anomaly work order based on the anomaly diagnosis results and the code modifier information.

Description

Technical Field

[0001] This application relates to the field of software operation and maintenance, and in particular to a software exception handling method, device, electronic device, and computer program product. Background Technology

[0002] Currently, online crashes of internet software mainly rely on third-party monitoring platforms for collection and alerts. These platforms can record basic information such as anomaly types, obfuscated stack traces, and device metadata. However, they still generally suffer from isolated log information, lack of business context, poor readability of obfuscated stack traces, low troubleshooting efficiency, reliance on manual repair responses, lack of intelligent closed-loop systems, and privacy leaks and excessively high computing costs associated with directly uploading raw logs to large models.

[0003] In addition, enterprises often have multiple heterogeneous systems such as monitoring platforms, logging systems, version control systems and collaboration tools. The data formats, interface protocols and time precision of these systems are inconsistent, and there is a lack of unified data alignment and automated collaboration mechanisms. This results in the fragmentation of each link and makes it impossible to achieve a complete processing flow of fault detection, multi-source context reconstruction, intelligent diagnosis, repair suggestion generation and accurate assignment of responsibilities. Summary of the Invention

[0004] This application provides a software exception handling method, apparatus, electronic device, and computer program product, which can solve the problems of isolated log information, lack of business context, poor readability of obfuscated stacks, and low troubleshooting efficiency in existing methods.

[0005] In a first aspect, embodiments of this application provide a software exception handling method, which includes the following steps: In response to an abnormal event notification sent by a third-party monitoring platform in real-time event push mode, abnormal event data is obtained from the third-party monitoring platform, and user behavior trajectory and network request data within a preset time window before the occurrence of the abnormal event are obtained from a designated log system; an abnormal context dataset is generated based on the abnormal event data, user behavior trajectory and network request data; The abnormal context dataset is preprocessed, and key abnormal feature information is extracted from the preprocessed data to generate an abnormal fingerprint. Candidate cases are obtained from a preset knowledge base based on the abnormal fingerprints, and the candidate cases and abnormal context dataset are input into a large language model to obtain abnormal diagnosis results. The obfuscated stack in the abnormal event data is restored to the source code location through a symbolic mapping table, and the code modifier information of the source code location is determined; an abnormal work order is generated based on the abnormal diagnosis result and the code modifier information, and the abnormal work order is pushed through a preset message interface.

[0006] Secondly, embodiments of this application provide a software exception handling apparatus, which includes the following: The data acquisition module responds to abnormal event notifications sent by a third-party monitoring platform in a real-time event push manner, acquires abnormal event data from the third-party monitoring platform, and acquires user behavior trajectories and network request data within a preset time window before the occurrence of the abnormal event from a designated log system. The context building module is used to generate an abnormal context dataset based on the abnormal event data, user behavior trajectory, and network request data. The fingerprint extraction module is used to preprocess the abnormal context dataset, extract key abnormal feature information from the preprocessed data, and generate abnormal fingerprints. The intelligent diagnosis module is used to obtain candidate cases from a preset knowledge base based on the abnormal fingerprint, input the candidate cases and abnormal context dataset into the large language model, and obtain the abnormal diagnosis result. The source tracing module is used to restore the obfuscated stack trace in the abnormal event data to the source code location through a symbolic mapping table, and to determine the code modifier information at that source code location; and The work order management module generates abnormal work orders based on the abnormal diagnosis results and code modifier information, and pushes the abnormal work orders through a preset message interface.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the software exception handling method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer program product, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, implement the steps of the software exception handling method as described in the first aspect.

[0009] This application embodiment acquires data from both a third-party monitoring platform and a designated log system, fusing them into a unified structured context dataset. This automatically aligns and links data previously scattered across multiple heterogeneous systems, eliminating information silos and providing a complete fault scenario for subsequent diagnosis, including user operation paths and network request links. By anonymizing and simplifying the stack traces of abnormal context data locally, privacy filtering and token consumption optimization can be completed before uploading to the large language model, addressing the privacy compliance risks and excessive computing costs associated with directly uploading raw logs to the public cloud large language model. Simultaneously, by retrieving similar historical cases from a pre-defined knowledge base using anomaly fingerprints as reference context, the targeting and accuracy of the large language model's reasoning are enhanced, overcoming the problems of generalized large models lacking enterprise historical repair knowledge and inaccurate generalization of diagnostic conclusions. Based on a symbolic mapping table, the obfuscated stack is automatically restored to its source code location, and the code modifier information is identified. Finally, based on the diagnostic results and responsible party information, an anomaly work order is automatically generated and pushed. Compared to traditional methods requiring hours or even days of manual investigation, this reduces time, improves efficiency, and eliminates delays caused by manual data transfer and flow between different stages due to system fragmentation. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a software exception handling method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating an automatic collaborative analysis and report generation method for software crash logs based on a large language model, provided in an embodiment of this application. Figure 3 This is a schematic diagram of the overall architecture of an automatic collaborative analysis and report generation system for software crash logs based on a large language model, provided in an embodiment of this application. Figure 4 This is a schematic diagram of the heterogeneous data acquisition and alignment process based on a dual-mode mechanism provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a software exception handling device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0014] In the daily operation and maintenance of internet products such as mobile internet applications, web applications, and desktop clients, it is necessary to capture, locate, and repair software anomalies such as crashes to ensure user experience and business continuity. Currently, third-party crash monitoring platforms, such as Firebase Crashlytics, Sentry, and Bugsnag, are commonly used to collect and alert on online crashes. These platforms can typically record basic information such as the exception type, obfuscated stack trace, device metadata (operating system version, CPU architecture, memory usage, etc.), and the timestamp of the crash occurrence.

[0015] In recent years, some monitoring platforms have begun to provide crash summaries or root cause guessing capabilities based on Large Language Models (LLMs). However, their analysis input is usually limited to a single stack trace, without integrating multi-source business contexts such as user behavior trajectories and network request links. They also do not link with the enterprise's internal historical repair knowledge base and version control system to achieve automatic source tracing and collaborative assignment of responsibilities, and cannot yet form a complete automated processing flow from fault perception to work order push.

[0016] Specifically, existing technical solutions generally suffer from the following technical defects in actual production environments: Log information is isolated and lacks the ability to correlate with business context. Crash logs collected by third-party monitoring platforms are mainly code stacks, which usually do not include the specific operation path of the user before the crash (such as click flow, page jump sequence, etc.), changes in network request links, local cache status, or business session context. Developers cannot reconstruct the real failure scenario based solely on stack information, resulting in high reproduction costs and long localization cycles.

[0017] Code obfuscation leads to poor stack trace readability and low efficiency in manual troubleshooting. Client code in production environments is typically obfuscated using tools like ProGuard and R8, replacing class and method names with meaningless short identifiers. Even after symbolic deobfuscation, the massive stack traces still contain a large amount of redundant call information from system frameworks and third-party SDKs. Relying on extensive manual reading and cross-referencing of source code can take hours or even days on average.

[0018] The lack of an intelligent closed-loop system for repair response means that collaborative assignment relies on manual intervention. Traditional crash monitoring systems only provide "alarm notification" capabilities and cannot automatically provide accurate diagnostic conclusions and repair suggestions based on the severity of the crash, the scale of affected users, or historical repair experience. Furthermore, they cannot automatically link the responsible code owners in the version control system. The complete time-to-repair (MTTR) cycle for software defects (bugs) from discovery to assignment to repair is generally long, severely impacting online stability.

[0019] Applying large-scale models directly to crash analysis raises concerns about privacy breaches and computational costs. Uploading raw crash logs containing sensitive fields such as user identifiers, access tokens, and phone numbers directly to public cloud large language model services poses data compliance risks. Furthermore, the complete stack trace and lengthy context result in enormous token consumption, making economically feasible deployment in large-scale crash scenarios difficult.

[0020] Furthermore, enterprises often have multiple heterogeneous systems operating simultaneously, such as crash monitoring platforms, behavior logging systems, version control systems (e.g., GitLab / GitHub), and collaborative communication tools (e.g., WeChat Work, DingTalk, Slack). These systems often have inconsistent data formats, interface protocols, and time precision, lacking a unified data alignment and automated collaboration mechanism. Therefore, existing technologies struggle to achieve end-to-end automated processing, from real-time fault detection and multi-source context reconstruction to intelligent diagnosis, repair suggestion generation, and precise assignment of responsibility.

[0021] Against this backdrop, there is an urgent need for a software anomaly handling method that, while ensuring data privacy, integrates multi-source heterogeneous contextual information, combines the enterprise's internal historical fault knowledge base with the reasoning capabilities of a large language model, and enables automatic collaborative analysis of crash logs, generation of multi-role reports, and precise assignment of responsibility, thereby significantly shortening the average repair time for software crashes.

[0022] To overcome the shortcomings of the existing technologies, this application provides a method and system for automatic collaborative analysis and report generation of software crash logs based on a large language model. By constructing a dual-mode data acquisition mechanism, combining local privacy-de-identified feature engineering, retrieval-augmented generation (RAG) technology, and the multi-round reasoning capabilities of the large language model, it achieves a fully automated closed loop from real-time fault perception, heterogeneous context reconstruction, AI intelligent diagnosis, repair code suggestion generation to precise assignment of responsibility, which can shorten the mean time to repair (MTTR) of Internet software.

[0023] The following is in conjunction with the appendix Figures 1 to 6 The present application provides a detailed description of a software exception handling method, apparatus, electronic device, and computer program product through specific embodiments and application scenarios.

[0024] Figure 1 This application illustrates a software exception handling method according to an embodiment of the present application. This method can be executed by an electronic device, which may include a server and / or terminal device, etc. In other words, the method can be executed by software or hardware installed on the server and / or terminal device, and the method includes the following steps: Step 110: In response to an abnormal event notification sent by a third-party monitoring platform in the form of real-time event push, obtain abnormal event data from the third-party monitoring platform, and obtain user behavior trajectory and network request data within a preset time window before the occurrence of the abnormal event from a designated log system; generate an abnormal context dataset based on the abnormal event data, user behavior trajectory and network request data.

[0025] The third-party monitoring platform can refer to an anomaly collection and alerting service system independent of the application developer, such as Firebase Crashlytics, Sentry, and Bugsnag. It collects and reports anomaly events occurring during application execution and provides query interfaces for external systems to obtain anomaly details. Anomaly event data can refer to a set of data obtained from the third-party monitoring platform that characterizes the program execution state and environment at the time of the anomaly. In one specific implementation, after receiving an anomaly event notification pushed by the third-party monitoring platform, the system actively pulls the anomaly event data by calling the platform's data acquisition interface. This anomaly event data includes at least obfuscated stack traces, thread information, and device operating environment data. The obfuscated stack trace records the information of each frame of the program's call stack at the time of the anomaly; the thread information records the state of each thread at the time of the anomaly, used to help determine whether the anomaly is caused by a multi-threading problem; the device operating environment data includes the operating system version, CPU architecture, available memory, device model, network connection type, etc., used to help reproduce the fault scenario. It should be noted that the above three types of data are standard data fields typically provided by third-party monitoring platforms when actually collecting anomalies. The technical solution of this application does not depend on the data format of a specific monitoring platform. As long as abnormal event data, including obfuscated stacks, thread information and device operating environment data, can be obtained, the subsequent processing flow of the embodiments of this application can be applied.

[0026] The designated log system can refer to a pre-specified log storage system used to collect and store user behavior traces and network request data generated during application operation. For example, the designated log system could be an internal enterprise log server, from which context data prior to the occurrence of the anomaly is retrieved during implementation.

[0027] The anomaly context dataset can be a structured dataset obtained by fusing anomaly event data, user behavior trajectories, and network request data along a unified timeline, used to characterize the complete fault scenario when the anomaly occurs. The preset time window can refer to a pre-defined traceability duration, the value of which can be adjusted according to the application type and user operation method.

[0028] In one implementation, an abnormal event push endpoint is pre-registered with a third-party monitoring platform. When an abnormal event occurs on an online user device, the monitoring platform proactively sends an abnormal event notification to this endpoint. The notification includes at least the event identifier, abnormal timestamp, and user identifier. Upon receiving the abnormal event notification, the monitoring platform's data acquisition interface is automatically invoked to retrieve the complete obfuscated stack trace, thread information, and device operating environment data for that abnormal event. Simultaneously, according to a preset user identifier mapping rule, the user identifier from the monitoring platform is associated and matched with the user identifier from a designated log system. Using the abnormal timestamp and the matched internal user identifier as search criteria, the user's behavior trajectory and network request data within a preset time window before the abnormality occurred are retrieved from the designated log system. The above three types of data are aligned and fused along a unified timeline to generate an abnormal context dataset.

[0029] Step 120: Preprocess the abnormal context dataset, extract key abnormal feature information from the preprocessed data and generate an abnormal fingerprint.

[0030] The preprocessing may include privacy desensitization and stack simplification. Desensitization is used to ensure the privacy compliance of data before it is transmitted to the large language model service, and simplification is used to reduce the token consumption of large language model inference.

[0031] Anonymization refers to the detection and masking of sensitive fields in abnormal context datasets to prevent the leakage of personal privacy information. Sensitive fields include, but are not limited to, user access tokens, mobile phone numbers, email addresses, plaintext passwords, real names, and ID card numbers. There are various methods for anonymization, such as using named entity recognition algorithms and regular expression rules to identify sensitive fields and replace them with uniform placeholders, using rule tree field-level anonymization to perform hierarchical anonymization of structured fields, or using differential privacy methods to add noise perturbation to numerical sensitive fields.

[0032] Stack simplification can refer to filtering redundant information from obfuscated stacks, removing intermediate layer calls from system framework calls and third-party software development kits, and retaining error lines directly related to abnormal business logic and their preset number of frames above and below them, such as 2 to 5 frames.

[0033] The anomaly fingerprint can be a fixed-format string extracted from the simplified stack, which can be used as the primary key for subsequent knowledge base retrieval and anomaly deduplication aggregation.

[0034] In one implementation, before submitting the abnormal context dataset to the large language model inference service, sensitive fields in the dataset are first anonymized, and the identified sensitive information is replaced with uniform placeholders. After anonymization, the obfuscated stack is simplified, removing system-level and third-party library call frames according to preset framework filtering rules, retaining only the core stack information related to the business.

[0035] In some implementations, the exception type, core exception line, and error message summary can be extracted from the simplified stack trace, and these three can be combined into a fixed-format string as an exception fingerprint. In other implementations, the exception fingerprint can further incorporate dimensional information such as application version number, device model, or operating system version to improve retrieval accuracy.

[0036] Step 130: Obtain candidate cases from the preset knowledge base based on the abnormal fingerprint, input the candidate cases and abnormal context dataset into the large language model, and obtain the abnormal diagnosis result.

[0037] The preset knowledge base can refer to a pre-built internal historical fault and repair knowledge base of the enterprise, which stores anomaly cases that have been repaired in the past. Each case includes at least the fault fingerprint, root cause description, involved source files and line numbers, repair code differences, and repair personnel. The fault fingerprint and root cause description text are vectorized for semantic retrieval. Candidate cases can refer to historical repair cases that are semantically similar to the current anomaly fingerprint and retrieved from the preset knowledge base, which are used as reference context for reasoning in the large language model.

[0038] In one implementation, previously repaired anomaly cases are pre-structured, stored in a database, and quantified. During this step, the anomaly fingerprint generated in step 120 is input into a pre-defined knowledge base for vector semantic similarity matching. A pre-defined number of similar historical repair cases are obtained as candidate cases, for example, 3 to 10. Subsequently, the retrieved candidate cases are combined with the simplified obfuscated stack trace from step 120, the user behavior trajectory obtained from the designated log system in step 110, and the device operating environment information obtained from the third-party monitoring platform in step 110. This results in a multi-segment input prompt containing system role settings, candidate case examples, the current anomaly context, and output format constraints. This prompt can serve as an enhanced prompt. This enhanced prompt is input into a large language model, which performs inference based on the candidate case references and the current anomaly context, outputting an anomaly diagnosis result. This anomaly diagnosis result includes at least an anomaly root cause localization conclusion and remediation suggestions. The root cause localization conclusion indicates the specific business logic defect that caused the anomaly, and the remediation suggestions guide developers in code repair.

[0039] In other implementations, the large language model can also perform multi-round inference, such as first locating the root cause, then generating remediation suggestions based on the root cause, and finally self-assessing the confidence level of the diagnostic conclusion. When the confidence level is lower than a preset threshold, it is marked as requiring manual review. The large language model can be a privately deployed open-source model or a cloud-based commercial model proxied by an enterprise security gateway. After the anomaly is repaired, the confirmed diagnostic results and the differences between the repair code can be written back to a preset knowledge base to achieve continuous updates to the knowledge base.

[0040] Step 140: Restore the obfuscated stack in the abnormal event data to the source code location through a symbolic mapping table, and determine the code modifier information of the source code location; generate an abnormal work order based on the abnormal diagnosis result and the code modifier information, and push the abnormal work order through a preset message interface.

[0041] The symbolic mapping table refers to a data file used to restore obfuscated code symbols to their original source code locations. Its specific form varies by platform; for example, on Android, it's a mapping file generated by tools like ProGuard or R8; on iOS, it's a dSYM symbol table; and in JavaScript front-end applications, it's a sourcemap file. The source code location refers to the specific line number in the source code file, which is the basis for locating abnormal code and tracing responsibility. The code modifier information refers to the committer information for the most recent modifications to a certain section of source code, obtained through a version control system query. The exception ticket refers to a fault handling task ticket containing exception diagnosis results and responsible person information, used to notify the relevant responsible person to handle the issue. The preset message interface refers to a pre-configured notification interface for pushing messages to external systems, such as the message push interface of an enterprise collaboration tool.

[0042] In one implementation, the corresponding symbolic mapping table is first searched based on the application version corresponding to the current anomaly. The class names and method names contained in the obfuscated stack trace of the anomaly event data obtained from the third-party monitoring platform in step 110 are then restored to the actual source code file paths and line numbers. After the stack trace restoration is completed, the commit record query interface of the version control system is called to query the commit record of the most recent modification at this source code location and extract the commit author information. In one implementation, if the source code location has been modified multiple times within a preset time, a weighted calculation is performed based on the modification frequency and the most recent modification time. This can be combined with file owner rules, organizational structure address books, or historical fault repair records for multi-factor weighted matching to determine the primary responsible party. Subsequently, an anomaly work order is generated based on the anomaly diagnosis results obtained in step 130 and the aforementioned code modifier information. The anomaly work order is pushed and assigned to the corresponding responsible party through a preset message interface. The work order content can include an anomaly summary and diagnosis results, realizing an automated processing flow from anomaly occurrence to the responsible party being aware of it.

[0043] In this embodiment, by simultaneously acquiring data from a third-party monitoring platform and a designated log system and merging them into a unified structured context dataset, data originally scattered across multiple heterogeneous systems is automatically associated and aligned, eliminating information silos and providing a complete fault scenario including user operation paths and network request links for subsequent diagnosis. By performing anonymization and stack simplification processing on the abnormal context data locally, privacy filtering and token consumption optimization can be completed before uploading to the large language model, solving the privacy compliance risks and excessive computing costs associated with directly uploading raw logs to the public cloud large language model. Simultaneously, by retrieving similar historical cases from a preset knowledge base using abnormal fingerprints as reference context, the targeting and accuracy of the large language model's reasoning are enhanced, overcoming the problems of generalized large models lacking enterprise historical repair knowledge and inaccurate generalization of diagnostic conclusions. Based on a symbolic mapping table, the obfuscated stack is automatically restored to its source code location and the code modifier information is determined. Finally, based on the diagnostic results and responsible person information, an abnormal work order is automatically generated and pushed. Compared to the traditional method requiring hours or even days of manual investigation, this reduces time, improves efficiency, and eliminates the delays caused by manual data transfer and flow between different stages due to system fragmentation.

[0044] In yet another exemplary embodiment, the real-time push method is a Webhook callback or a message queue subscription; based on step 110 of the above embodiment, the method of obtaining abnormal event data from the third-party monitoring platform may further include the following specific steps: The abnormal event data is retrieved from the third-party monitoring platform by calling the RESTful API interface, GraphQL interface, or platform SDK direct connection interface. The abnormal event data includes obfuscated stack traces, thread information, and device operating environment data.

[0045] For example, the system can pre-deploy an asynchronous Webhook callback listening module at the access layer and register an exception event push endpoint with a third-party monitoring platform (such as Firebase Crashlytics, Sentry, Bugsnag, etc.). When a new exception event occurs on any online user device, the third-party monitoring platform sends a JSON payload containing fields such as event identifier, exception timestamp, application version number, and user anonymity identifier to the Webhook endpoint within seconds. The monitoring platform proactively pushes the exception event notification, eliminating the need for the system to poll for exception status, thus ensuring real-time performance while avoiding the resource consumption caused by polling. After the Webhook callback is triggered, the system uses a pre-configured security authentication token to automatically call the data acquisition interface of the third-party monitoring platform, such as a RESTful API interface, or a GraphQL interface or a direct connection interface of the platform SDK, to deeply retrieve the complete obfuscated stack trace, thread information, and device operating environment data of the exception. Device operating environment data can be used as device metadata, which may include operating system version, CPU architecture, available memory, device model, network connection type, etc. The above-mentioned dual-mode acquisition mechanism combining push reception and proactive retrieval ensures the real-time performance of exception detection and the integrity of the acquired data.

[0046] The system can also retrieve business context data prior to the anomaly from a designated log system. Since user identifiers on the third-party monitoring platform and those on the designated log system often use different encoding rules, the two types of identifiers can be associated and matched according to pre-configured user identifier mapping rules. Mapping criteria can include unified anonymous IDs, device ID hashes, login session token hashes, or user identifiers assigned by the attribution platform. After identifier mapping is completed, the system automatically calls the query interface of the designated log system, using the anomaly timestamp and the matched internal user identifier as the association key, to trace back and retrieve the user's behavior trajectory and network request data within a preset time window before the anomaly occurred. User behavior trajectory includes, but is not limited to, page browsing events, button click events, and page jump sequences. Network request data includes, but is not limited to, HTTP methods, URL paths, response status codes, and latency.

[0047] The three types of heterogeneous data obtained above—abnormal event data (including obfuscated stack traces, thread information, and device operating environment data), user behavior trajectories, and network request data—are aligned and fused along a unified timeline. Using the abnormal timestamp as the anchor point, the relative time offset is calculated for each behavioral event and network request. Finally, a complete abnormal context dataset containing abnormal information, device information, user operation sequences, and network request links is generated, providing business context support for subsequent intelligent diagnosis.

[0048] In this embodiment, real-time push notifications via Webhook callbacks or message queue subscriptions enable immediate notification upon an anomaly, eliminating the need for polling the monitoring platform and avoiding resource consumption and time delays associated with polling. Furthermore, upon receiving the notification, proactively calling RESTful API interfaces, GraphQL interfaces, or platform SDK direct connection interfaces to retrieve complete anomaly event data compensates for the limited data content in push notifications. Through the collaborative operation of these push and pull modes, real-time anomaly detection and complete data acquisition are achieved. The anomaly event data explicitly includes obfuscated stack traces, enabling stack simplification in step 120 and symbolic mapping restoration in step 140, ensuring complete data input throughout the entire data processing chain from anomaly data acquisition to intelligent diagnosis and accountability. The thread information contained in the anomaly event data can be used in the stack simplification process of step 120 to determine the thread context to which the call frame belongs, more accurately identifying which stack frames belong to business threads and which belong to system threads, thus retaining more accurate business-related error lines when removing system framework calls. The equipment operating environment data enables the reasoning of the large language model in step 130 to combine the specific operating environment when the anomaly occurred, thereby improving the accuracy of diagnosis and providing a basis for testers to reproduce the fault in the future.

[0049] In yet another exemplary embodiment, based on step 110 of the above embodiment, the method of obtaining user behavior trajectory and network request data within a preset time window before the occurrence of the abnormal event from a designated log system may further include the following specific steps: Obtain the monitoring platform user identifier and abnormal timestamp from the abnormal event notification; associate and match the monitoring platform user identifier with the specified log system user identifier according to the preset user identifier mapping rules; query the specified log system using the abnormal timestamp and the specified log system user identifier as search conditions; extract the user behavior trajectory and network request data corresponding to the specified log system user identifier within a preset time window before the abnormal timestamp from the query results.

[0050] For example, the designated logging system can be an internal enterprise log server. User identifiers on the third-party monitoring platform and the designated logging system often use different encoding rules. For instance, the monitoring platform might use anonymized identifiers, while the designated logging system might use internally unified user IDs; there is no direct correspondence between the two. Therefore, before querying data from the designated logging system, cross-system association and matching of user identifiers is necessary.

[0051] In one implementation, the monitoring platform user identifier and the anomaly timestamp are first extracted from the received anomaly event notification. This notification, proactively pushed by the third-party monitoring platform when an anomaly occurs, carries the user's identifier on the monitoring platform side and the precise time of the anomaly. Subsequently, the monitoring platform user identifier is matched with a specified log system user identifier according to a preset user identifier mapping rule. This mapping rule pre-configures the correspondence between user identifiers in the monitoring platform and the specified log system, and the mapping basis may include a unified anonymous identifier, device identifier hash, login session token hash, or user identifier assigned by the attribution platform. After the identifier mapping is completed, the specified log system is queried using the anomaly timestamp and the matched specified log system user identifier as search criteria. During the query, the anomaly timestamp is used as the time anchor, and the matched specified log system user identifier is used as the user-level filter condition to retrieve all log records of the user before the anomaly timestamp from the specified log system. Finally, the user behavior trajectory and network request data within a preset time window before the anomaly timestamp, corresponding to the specified log system user identifier, are extracted from the query results. For example, the preset time window is set to 15 to 120 seconds, which can be configured according to the application type and user operation method.

[0052] In this embodiment, the above steps can accurately obtain user behavior trajectories and network request data within a preset time window before the anomaly occurs from the specified log system, providing business-level context information for subsequent anomaly context dataset construction and intelligent diagnosis.

[0053] In yet another exemplary embodiment, based on step 120 of the above embodiment, the method for preprocessing the abnormal context dataset may further include the following specific steps: Sensitive fields in the abnormal context dataset are de-identified using at least one of the following methods: sensitive fields are identified and replaced with uniform placeholders using named entity recognition algorithms and regular expression rules; a rule tree-based field-level de-identification method is used; and a differential privacy method is used to perturb numerical sensitive fields. The obfuscated stack in the desensitized exception context dataset is simplified as follows: system framework calls and third-party SDK intermediate layer calls are removed from the obfuscated stack, and error lines directly related to the exception business logic and their preset frame numbers above and below are retained.

[0054] The de-identification process involves detecting and masking sensitive fields in abnormal context datasets to prevent the leakage of personal privacy information. Sensitive fields include, but are not limited to, user access tokens, mobile phone numbers, email addresses, plaintext passwords, real names, and ID card numbers.

[0055] The simplification process can involve filtering redundant information from the obfuscated stack, removing intermediate layer calls from system framework calls and third-party software development kits, and retaining error lines directly related to the abnormal business logic and their preset frame numbers above and below.

[0056] In one implementation, sensitive fields in the abnormal context dataset are first anonymized. Specific anonymization methods may include: for unstructured text logs, sensitive fields can be identified and replaced with uniform placeholders using named entity recognition algorithms and regular expression rules; for structured field data, a rule-tree-level anonymization method can be used, where the field to be anonymized is matched layer by layer with a preset rule tree, and the corresponding level of masking or truncation is performed on the field according to the anonymization rules corresponding to the matched nodes; for fields containing numerical sensitive information, differential privacy methods can be used to add Laplace or Gaussian noise for perturbation.

[0057] The three anonymization methods described above can be used individually or in combination as needed. Anonymization ensures that the data uploaded to the large language model service does not contain personally identifiable information.

[0058] After the anonymization process is completed, the obfuscated stack traces in the anonymized exception context dataset are further simplified. Following predefined framework filtering rules, system framework calls in the stack trace are automatically removed, such as android.os.Handler and java.lang.Thread in the Android operating system, as well as calls to third-party software development kits (SDKs) middleware layers that are known to have no business value. Only error lines directly related to the exception's business logic and their preset number of frames above and below them are retained, such as 2 to 5 frames above and below.

[0059] Through the above simplification process, the original stack can be compressed from an average of 50 to 200 lines to 10 to 20 lines, which can reduce the token consumption of subsequent large language model inference and reduce inference costs while ensuring the integrity of diagnostic information.

[0060] In yet another exemplary embodiment, the anomaly key feature information includes an anomaly type, an anomaly core line, and an error message summary extracted from a simplified obfuscated stack, for use in generating the anomaly fingerprint.

[0061] In one implementation, three key feature information types are extracted from the simplified obfuscated stack trace. The first type is the exception type, i.e., the exception type name corresponding to the exception event, such as null pointer exception, array out-of-bounds exception, null pointer dereference, etc. This information reflects the program-level nature of the exception. The second type is the exception core line, i.e., the core error line extracted from the top frame of the obfuscated stack. This line points to the innermost call location of the program execution at the time the exception occurred, and is a key clue for locating the exception code. The third type is the error message summary, i.e., the error description information carried by the exception object, used to assist in understanding the specific cause of the exception. These three types of information are combined into a fixed-format string to generate an exception fingerprint. This exception fingerprint serves as the primary key for subsequent knowledge base retrieval and exception deduplication aggregation.

[0062] The following example illustrates a NullPointerException. Assume an Android application experiences a NullPointerException. The monitoring platform collects an obfuscated stack trace, and the error line corresponding to the top frame points to the coupon application method in the settlement module. After simplification, the exception type is identified as a NullPointerException, the core exception line is the line containing the coupon application method in the settlement manager, and the error message summary is "attempted to call a virtual method on a null object reference." These three types of information are combined into an exception fingerprint in the following format: NullPointerException, Settlement Manager, Coupon Application Method, Line xxx, Attempted to call a virtual method on a null object reference.

[0063] In another implementation, to further improve the accuracy of knowledge base retrieval, anomaly fingerprints can be extended to include dimensions such as application version number, device model, or operating system version, forming a multi-dimensional fingerprint. For example, the same anomaly type and core line may correspond to different source code implementations in different application versions. Adding the version number dimension ensures a better match between retrieved historical cases and the current anomaly in terms of code version, thereby improving the accuracy of diagnostic conclusions generated by the large language model based on candidate cases. The anomaly fingerprint is then used in subsequent steps for vector semantic similarity matching within a pre-defined knowledge base.

[0064] In yet another exemplary embodiment, based on step 130 of the above embodiment, the method of obtaining candidate cases from a preset knowledge base according to the abnormal fingerprint may further include the following specific steps: The abnormal fingerprint is input into the preset knowledge base, and vector semantic similarity matching is performed with the historical repair cases in the preset knowledge base to obtain a preset number of similar historical repair cases, and the similar historical repair cases are used as candidate cases.

[0065] The preset knowledge base can be a pre-built internal historical fault and repair knowledge base used to store anomaly cases that have been repaired in the company's history. During the knowledge base construction phase, the fault fingerprint and root cause description text of each historical case are vectorized and encoded to generate corresponding feature vectors, which are then stored in a vector database for efficient semantic similarity retrieval. The preset quantity refers to the pre-set number of candidate cases to be acquired, for example, 3 to 10.

[0066] In one implementation, the abnormal fingerprint generated in step 120 is used as query input and input into a preset knowledge base. Upon receiving the abnormal fingerprint, the preset knowledge base first vectorizes it to generate a query feature vector. Then, it calculates the semantic similarity between the query feature vector and the feature vectors of each historical repair case in the preset knowledge base, for example, using cosine similarity as a metric to calculate a similarity score between the query vector and each historical case vector. Next, the system sorts the historical repair cases according to their similarity scores from highest to lowest, selecting a preset number of historical repair cases as candidate cases. For example, when the preset number is 5, the system returns the 5 historical repair cases with the highest similarity to the current abnormal fingerprint.

[0067] In one implementation, if the number of similar historical repair cases matched is less than a preset number, the actual number of matched cases is used as candidate cases. In another implementation, a similarity threshold can be set, and only historical repair cases with similarity scores higher than the threshold are included in the candidate cases, avoiding the introduction of irrelevant historical cases into subsequent large language model inference, thereby affecting the diagnostic accuracy.

[0068] In this embodiment, the aforementioned candidate cases are combined with the current anomaly context to form enhanced prompts, which are then input into the large language model for intelligent diagnosis. By introducing historical repair cases with semantic similarity to the current anomaly as references, the large language model can make inferences based on the enterprise's actual and verified repair experience, rather than relying solely on the generalization ability of the general model itself, thereby improving the accuracy of root cause localization and repair suggestion generation.

[0069] In yet another exemplary embodiment, based on step 140 of the above embodiment, the method for determining the code modifier information of the source code location may further include the following specific steps: The code modifier information for the specified source code location can be obtained by calling the commit history query interface of the version control system; or, the code modifier information for the specified source code location can be determined by weighting the modification frequency and the most recent modification time of the specified source code location within a preset time period, and combining this with file owner rules, organizational structure address book and / or historical repair records for multi-factor weighted matching.

[0070] The version control system can refer to a system used to manage the history of source code changes, such as Git or SVN. It records the modification history of each line of code in each file, including information such as the modifier, modification time, and modification content. The commit history query interface can be an application programming interface provided by the version control system for querying code commit history, such as the Blame interface in Git, which can return the most recent modification commit record for each line of code at a specified source code location. Code modifier information refers to the identity information of the committer who modified a section of source code. File owner rules can be predefined rules used to identify the owner of source code files, such as the rules defined in the CODEOWNERS file in the root directory of the version control system repository. The organizational structure directory refers to the internal organizational structure information of the enterprise, used to identify the responsible team or person for each business module or source code directory. Historical repair records refer to a record of anomaly cases that have been repaired in the enterprise's history, recording the responsible person information for each anomaly repair.

[0071] In one implementation, the first method is used to determine the code modifier information. After restoring the obfuscated stack to the source code location using a symbolic mapping table, the commit history query interface of the version control system is invoked, sending a query request to the version control system with the file path and line number of the source code location as input parameters. The version control system locates the line of code based on the file path and line number, traces the modification history of that line of code, and finds the commit record of the most recent modification of that line of code. The committer's identity information is extracted from the commit record as the code modifier information for that source code location. This method is suitable for scenarios where the code modification history is clear and the responsible party can be identified for a single modification, and it features high query efficiency.

[0072] In another implementation, a second method is used to determine the code modifier information. When a source code location has been modified multiple times within a preset time period, a single query for the most recent modifier may not accurately reflect the actual person responsible for that code segment. In this case, all modification records for that source code location within the preset time period can be obtained, the modification frequency of each committer can be counted, and the commit time of each modification can be obtained. A weighted calculation is performed based on the modification frequency and the most recent modification time to obtain the preliminary weight of each candidate. On this basis, multiple factors are further introduced for weighted matching: combining the file owner rules, it is determined whether the source code file has a clearly defined responsible person in the file owner rules; querying the organizational structure address book, it is determined to determine the responsible team or person corresponding to the source code module; querying historical repair records, it is determined whether the source code location has been involved in historical anomaly repairs, and the participation of each candidate in historical repairs. The matching results of the above multiple dimensions are comprehensively weighted to calculate the final weight score of each candidate, and the one with the highest weight is taken as the primary responsible person for that source code location.

[0073] In this embodiment, the two methods described above allow for flexible selection of the most suitable method for determining the responsible party based on the complexity of the source code modification history, providing reliable information on the responsible party for the accurate assignment of subsequent abnormal work orders.

[0074] The following explanation uses a mobile application crash scenario as an example. It is understood that the methods described in this application are also applicable to other types of software exceptions such as application unresponsiveness (ANR) and memory overflow (OOM).

[0075] In one implementation, an automated collaborative analysis and report generation system for software crash logs based on a large language model is provided, which may include, but is not limited to, the following functional modules: The dual-mode data acquisition and alignment module is used to obtain crash events and complete stack information from third-party crash monitoring platforms by combining Webhook streaming triggering and RESTful API deep retrieval. Based on the crash timestamp and user identifier, it traces and extracts user behavior trajectories and network request links within a preset time window before the crash from the internal log server, and merges heterogeneous data into a structured fault context dataset.

[0076] The local privacy desensitization and feature engineering module is used to mask sensitive fields using Named Entity Recognition (NER) algorithms and regular expression rules before data is uploaded to the large model service. It also simplifies crash stacks and extracts crash fingerprints, thereby reducing the consumption of large model tokens while ensuring data privacy.

[0077] The RAG-enhanced large-scale intelligent diagnostic module is used to input the fault fingerprint into the enterprise's internal historical fault and repair knowledge base for vector semantic retrieval. The retrieved similar historical repair cases are used as few-shot prompts and input together with the current crash context into the large language model to perform multi-round cross-context reasoning, and output the root cause localization conclusion and repair code suggestions.

[0078] The multi-role report rendering and automatic assignment module is used to dynamically generate differentiated analysis reports based on the needs of different roles within the enterprise (management, development, and testing). It also links with the Git Blame interface of the version control system to identify the code responsible party and automatically creates fault tickets through the Webhook interface of the enterprise collaboration tool, and completes accurate push and group assignment.

[0079] In this embodiment, key technologies such as dual-mode heterogeneous data acquisition and alignment, local desensitization and stack fingerprint extraction, RAG-enhanced LLM intelligent diagnosis, and Git Blame-linked automatic collaborative assignment are introduced to connect the crash monitoring platform, behavior log system, AI inference engine, version control system and collaboration tools across platforms, so as to realize an unattended fully automated process for bug investigation and assignment.

[0080] In one implementation, see Figure 2 This paper presents an automated collaborative analysis and report generation method for software crash logs based on a large language model, including the following steps: Step 201: Receive crash event push notifications from a third-party monitoring platform via Webhook.

[0081] Step 202: Call the monitoring platform API to retrieve the complete crash stack and device metadata.

[0082] Step 203: Trace internal behavior logs and network requests according to the crash timestamp and user identifier mapping rules.

[0083] Step 204: Align and merge the heterogeneous data into a structured fault context.

[0084] Step 205: Perform local privacy desensitization and stack simplification.

[0085] Step 206: Extract the fault fingerprint.

[0086] Step 207: Retrieve historical fault knowledge base based on fault fingerprint vector.

[0087] Step 208: Assemble the RAG enhanced hints and input them into the large language model for multi-round reasoning.

[0088] Step 209: Output the root cause diagnosis conclusion and repair code suggestions.

[0089] Step 210: Dynamically render the differential analysis report according to different roles.

[0090] Step 211: After restoring the source code path and line number through symbolic mapping, execute Git Blame to trace the source and determine the responsible party.

[0091] Step 212: Automatically create work orders and push assignments through the enterprise collaboration tool Webhook.

[0092] Traditional data processing workflows typically include the following steps: a third-party monitoring platform collects crash data, sends alerts (email / SMS), developers manually log in to the platform to view the stack trace, manually search for related logs, manually read the source code to locate the problem, manually confirm the responsible party, and manually create a work order in the collaboration tool.

[0093] In contrast, the data processing flow of this application differs from existing methods in that existing methods rely on human intervention, requiring manual data transfer and correlation between systems. This application, however, uses an automated pipeline as its processing hub. Through structured data alignment, local preprocessing, and AI-enhanced inference, it can compress manual investigations that would otherwise take hours to minutes or even seconds. In this application's embodiment, after a crash event is triggered, the system can sequentially complete data collection, preprocessing, intelligent diagnosis, report generation, and collaborative assignment, ultimately forming a complete automated process from fault discovery to awareness of responsibility.

[0094] In one implementation, see Figure 3 A software crash log automated collaborative analysis and report generation system based on a large language model can be deployed in enterprise private cloud or hybrid cloud environments, employing an event-driven microservice architecture. The overall architecture of this system may include the following: Access layer: Deploy Webhook listening service, subscribe to real-time event push from third-party crash monitoring platforms (such as FirebaseCrashlytics); and maintain secure authentication channels with the RESTful APIs of various platforms.

[0095] Data fusion layer: includes crash data retrieval submodule, internal log tracing submodule and heterogeneous data alignment submodule, responsible for associating and fusion crash stack, device metadata, user behavior trajectory and network request link with user identifier according to a unified timeline.

[0096] Preprocessing layer: Deploy a lightweight privacy desensitization engine and a stack simplification engine to complete sensitive information filtering and fault fingerprint extraction locally or within the enterprise intranet, preventing the leakage of raw data.

[0097] Intelligent Analysis Layer: Includes vector retrieval service (connecting to the enterprise's internal fault knowledge base), large language model inference service (which can use a privately deployed LLM or a cloud-based LLM forwarded through a security gateway), and prompt word arrangement engine.

[0098] Collaborative output layer: includes a multi-role report rendering engine, Git Blame source tracing service, and a Webhook integration module for enterprise collaboration tools (WeChat Work / DingTalk / Slack).

[0099] Data storage layer: Stores historical fault knowledge base (including vector index), intermediate results of crash analysis, report template configuration, and work order status, etc.

[0100] In this embodiment, compared to the isolated architecture of existing monitoring platforms that rely on independent alarms and manual investigation, this application uses a layered design for the overall architecture to connect data and capabilities that were originally scattered across multiple heterogeneous systems into a unified automated processing pipeline.

[0101] In one implementation, an online crash of a mobile internet application on the Firebase Crashlytics platform is used as an example for illustration.

[0102] Step 301: Heterogeneous data acquisition and alignment based on a dual-mode mechanism. (See also...) Figure 4 This step is executed in the following time sequence: trigger first, then pull, then align. (1) Streaming Trigger Mode (Mode A): The system deploys an asynchronous Webhook callback listening module at the access layer and registers a crash event push endpoint with Firebase Crashlytics. When a new fatal crash occurs on any user device online, the monitoring platform sends a JSON payload containing fields such as event identifier (event_id), crash timestamp (crash_timestamp), application version number (app_version), and user anonymity identifier (user_id) to the Webhook endpoint within seconds, achieving zero-polling fault detection within seconds.

[0103] (2) Deep fetch modality (modality B): After the Webhook callback is triggered, the system uses the pre-configured Service Account Token to automatically call the Firebase Crashlytics RESTful API interface to deeply slice and fetch the complete obfuscated stack trace, thread information, device metadata (CPU model, available memory, operating system version, network type) and custom key-value pairs of the crash.

[0104] (3) User ID Mapping and Context Reconstruction: The user_id on the monitoring platform and the user ID in the internal log system often use different encoding rules. The system associates and matches the two types of IDs through pre-configured user ID mapping rules. The mapping basis may include: unified anonymous ID, device ID hash, login session token hash, or user ID assigned by the attribution platform. After the mapping is completed, the system uses crash_timestamp and the mapped internal user ID as the association key to automatically call the query interface of the enterprise internal log server to trace back and extract the user's behavior trajectory (User Action Tracks) within T seconds (T can be 15 to 60 seconds, with a typical value of 30 seconds) before the crash occurred. This includes, but is not limited to: page view events (page_view), button click events (button_click), page navigation sequence (navigation_path), and concurrent network request records (HTTP method, URL path, response status code, and time consumption).

[0105] (4) Data alignment rules: The above heterogeneous data are sorted according to a unified time axis. Using crash_timestamp as the anchor point, the relative time offset Δt (unit: milliseconds) is calculated for each behavioral event. The potential relationship between each network request and the relevant code module in the crash stack is marked. Finally, they are merged into a structured fault context dataset containing four top-level fields: crash_info, device_meta, user_actions, and network_traces.

[0106] Step 302, Local Privacy De-identification and Feature Engineering for Large Models. Before submitting the fault context dataset to the large model inference service, the preprocessing layer performs the following operations: (1) Privacy Sanitization: Using a pre-trained Named Entity Recognition (NER) model and a configurable regular expression rule library, sensitive fields in log text are automatically scanned, including but not limited to: user access token, mobile phone number, email address, plaintext password, real name, ID card number, precise geographical coordinates, etc.

[0107] The matched sensitive segments are replaced with uniform placeholders, such as [PLACEHOLDER_UID], [PLACEHOLDER_PHONE], and [PLACEHOLDER_TOKEN], to ensure that the data uploaded to the large model service does not contain personally identifiable information (PII).

[0108] (2) Stack Trimming: The tokenizer automatically removes system-level framework calls (such as android.os.Handler, java.lang.Thread, etc.) and third-party SDK intermediate layer calls with no known business value from the stack trace according to the predefined framework filtering rules, and only retains the error line and the N frames above and below it (N can be 2 to 5, with a typical value of 3) that are directly related to the application business logic, compressing the original stack from an average of 50 to 200 lines to 10 to 20 lines.

[0109] (3) Crash Fingerprint Extraction: A fixed-format string consisting of "Exception Type + Top Frame of Crash Line + Error Message Summary" is extracted from the simplified stack trace as the crash fingerprint. For example, NullPointerException | com.example.payment.CheckoutManager.processPayment:142 | Attempt to invoke virtual method on a nullobject reference. This fingerprint serves as the primary key for subsequent knowledge base retrieval and deduplication aggregation.

[0110] (4) Token cost control: After the above processing, the number of input tokens for a single crash analysis can be reduced by more than 60% compared with the original complete log, which significantly reduces the inference cost of large models while ensuring the integrity of diagnostic information.

[0111] Step 303: Intelligent diagnosis using a large model combined with Retrieval Augmentation (RAG). This step does not blindly rely on the generalization capabilities of a generic large model, but instead introduces an internal enterprise historical fault knowledge base, executing a three-stage process of retrieval, augmentation, and inference: (1) Knowledge Base Construction (Offline Stage): Structured storage of historically repaired crash cases is performed. Each record includes fields such as: fault fingerprint, root cause description, involved source files and line numbers, repair code diff, repair personnel, repair time, and associated business module tags. The fault fingerprint and root cause description text are vectorized and stored in a vector database to construct a "historical fault and repair knowledge base". After the crash is repaired manually or automatically, the system can write the new diagnostic conclusions and repair diffs back to the knowledge base, forming a continuously updated closed loop.

[0112] (2) Vector semantic retrieval: Input the current fault fingerprint extracted in step 302 into the vector retrieval engine, and use cosine similarity as the metric to retrieve Top-K (K can be 3 to 10, with a typical value of 5) historical similar bug fix cases as candidate references.

[0113] (3) Prompt Engineering: The prompt engine assembles the search results, current simplified stack, user operation path summary and device environment information into a multi-section prompt according to a predefined template. The structure includes: system role setting, historical similar cases (Few-Shot Examples), current crash full context, and output format constraints (requiring the output of three parts: root cause location, impact assessment and repair code suggestions).

[0114] (4) Multi-round reasoning and code-level diagnosis: The large language model performs multi-round cross-context reasoning based on the above-mentioned enhanced prompts. The first round focuses on root cause localization and identifies the specific business logic defects that cause the bug; the second round generates code suggestions / patches and outputs the code comparison before and after the modification in Unified Diff format; the third round performs confidence self-evaluation. When the model's confidence in the diagnostic conclusion is lower than the preset threshold (e.g., 0.7), it is automatically marked as "requires manual review" and an uncertainty explanation is added.

[0115] Step 304: Dynamic Rendering and Precise Collaborative Assignment of Multi-Role Reports. In this step, the AI ​​diagnostic results are transformed into customized outputs for different roles within the enterprise, and automated collaborative assignment is completed. (1) Management Report (Dimension A): The report rendering engine automatically generates a summary of macro indicators, including the cumulative number of occurrences of the fault fingerprint in the past 24 hours, the number of independent users affected, the proportion of affected users to total active users, the potential risk level of related business modules, the frequency of the fingerprint in the historical knowledge base, and the average repair time, based on the predefined management report template. This summary is used for fault classification and accountability.

[0116] (2) Development layer report (dimension B): For R&D personnel, the report highlights the core lines of the crash stack, visualizes the user's operation path before the crash in the form of a timeline, and includes an AI-generated Diff view of the fix code, supporting one-click jump to the corresponding source file in the IDE deep link.

[0117] (3) Test layer report (dimensional C, optional): Generate a draft test case containing suggested reproduction steps, prerequisites (device model, network environment, application version) and regression test checkpoints to assist the QA team in verifying the repair effect.

[0118] (4) Symbolic mapping and Git Blame linkage: Class names and method names identified in AI diagnostic results or crash stacks may still be obfuscated symbols. Before calling Git Blame, the system first restores the obfuscated stack to the source code file path and line number based on the symbolic mapping table bound to the application version (e.g., ProGuard / R8 mapping file for Android, dSYM symbol table for iOS). Subsequently, it automatically calls the GitBlame API interface of the enterprise's internal version control system (GitLab or GitHub) to query the commit record of the most recent modification of the line of code, and extracts the author and commit time. If the line has been modified multiple times recently (e.g., within 30 days), a candidate list of responsible persons is calculated by weighting the modification frequency and the most recent modification time, and the one with the highest weight is selected as the primary responsible person.

[0119] (5) Automatic Work Order Creation and Push: The system automatically creates fault work order messages containing fault summaries and development layer report links through the Webhook interface of enterprise collaboration tools (WeChat Work, DingTalk, etc.), and marks the responsible person as the notification recipient in the message to send reminder notifications to the responsible person. Fault work order messages can be pushed to the corresponding R&D group or the responsible person's personal conversation, realizing unattended automation of the entire process from the occurrence of the crash to the responsible person's awareness.

[0120] In other implementations, the behavior tracing time window T in dual-mode data acquisition can be adjusted to 15 seconds, 45 seconds, 60 seconds, or 120 seconds to adapt to the user operation rhythm density of different applications.

[0121] In other implementations, in addition to Webhook, the streaming trigger modality can also be implemented by subscribing to the event stream of the monitoring platform using message queues (such as Kafka, RabbitMQ, etc.).

[0122] In other implementations, in addition to RESTful APIs, the deep pull modality can also use GraphQL interfaces or direct connection to the platform SDK to obtain crash details.

[0123] In other implementations, in addition to Firebase Crashlytics, third-party crash monitoring platforms can also replace or be used in conjunction with Sentry, Bugsnag, self-built APM platforms, etc. The system's platform adaptation layer abstracts and shields the underlying differences through plug-in interfaces.

[0124] In other implementations, in addition to NER and regular expressions, the privacy desensitization module can also introduce a field-level desensitization strategy based on rule trees, or use differential privacy technology to perturb numerical sensitive fields.

[0125] In other implementations, the large language model can be an open-source model deployed in a private location, or a commercial cloud model proxied by an enterprise security gateway.

[0126] In other implementations, the vector model and generative model for RAG retrieval can be selected independently.

[0127] In other implementations, the components of the fault fingerprint can be expanded to include dimensions such as application version number, device model, and operating system version to form a multi-dimensional fingerprint to improve retrieval accuracy.

[0128] In other implementations, in addition to Git Blame, the person in charge can also be assigned a multi-factor weighted match by combining CODEOWNERS file rules, organizational address book, and historical bug fix records.

[0129] In other implementations, the report rendering template can be customized according to business lines and product lines, and supports dynamic addition and deletion of report dimensions.

[0130] The following example illustrates a fatal software crash that occurred on a certain e-commerce app at 14:32:05 on March 15, 2026.

[0131] Firebase Crashlytics pushed an event notification via Webhook at 14:32:06, with the event identifier evt_8f3a2b1c. At 14:32:07, the system called the Firebase API to retrieve the full stack trace, with the core error being: java.lang.NullPointerException at abc(Unknown Source). Device information: Android 14, Pixel 7, Wi-Fi network, App version 3.2.1.

[0132] The system uses user identifier mapping rules to map Firebase user_id=anon_u_92847 to the internal log user identifier uid_7281904, and uses crash_timestamp as the key to trace the behavior in the 30 seconds before the crash from the internal log server: 14:31:50 Entered the product details page 14:31:58 Click "Add to Cart" 14:32:02 Entered the settlement page 14:32:04 Click "Use Coupon" 14:32:05 Crash.

[0133] Simultaneous network requests show that at 14:32:04, an HTTP 200 response was returned to / api / v2 / coupon / validate, but the coupon field in the response body was null.

[0134] After local anonymization and stack trace simplification, the fault fingerprint was extracted as: NullPointerException | abc | null object reference in coupon validation. Vector search found 3 similar historical cases in the knowledge base, with the case with the highest similarity of 0.92 being: "The checkout page failed to validate the coupon API, returning an empty object, causing an NPE. The solution was to add a null check at the entry point of the applyCoupon method."

[0135] The large model, based on RAG-enhanced output, concluded that the root cause was the lack of defensive programming when the coupon verification interface returned null. The recommended fix was to add an `if (coupon == null)` check before line 142 in `CheckoutManager.java` and implement fallback processing. The system, based on the R8 mapping file corresponding to App version 3.2.1, restored the obfuscated stack trace abc to `CheckoutManager.java:142`. Git Blame showed that this line was recently modified by developer Zhang San in Commita1b2c3d three days prior. The system pushed a work order to the "E-commerce R&D Group" via WeChat Webhook, tagging Zhang San and attaching a link to the complete development report. From the crash occurrence (14:32:05) to the responsible party receiving the work order (14:32:45), the entire process took approximately 40 seconds, significantly shorter than the traditional manual investigation method (usually 2-8 hours).

[0136] Corresponding to the software exception handling method provided in the above embodiments, based on the same technical concept, this application also provides a software exception handling apparatus. See also Figure 5 The device 400 includes a data acquisition module 410, a context construction module 420, a fingerprint extraction module 430, an intelligent diagnosis module 440, a traceability module 450, and a work order management module 460.

[0137] The data acquisition module 410, in response to an anomaly event notification sent by a third-party monitoring platform via real-time event push, acquires anomaly event data from the third-party monitoring platform and acquires user behavior trajectory and network request data within a preset time window before the anomaly event occurs from a designated log system; the context construction module 420 is used to generate an anomaly context dataset based on the anomaly event data, user behavior trajectory, and network request data; the fingerprint extraction module 430 is used to preprocess the anomaly context dataset, extract key anomaly feature information from the preprocessed data, and generate an anomaly fingerprint; the intelligent diagnosis module 440 is used to obtain candidate cases from a preset knowledge base based on the anomaly fingerprint, input the candidate cases and the anomaly context dataset into a large language model, and obtain an anomaly diagnosis result; the source tracing module 450 is used to restore the obfuscated stack in the anomaly event data to the source code location through a symbolic mapping table, and determine the code modifier information of the source code location; and the work order management module 460 generates an anomaly work order based on the anomaly diagnosis result and the code modifier information, and pushes the anomaly work order through a preset message interface.

[0138] It should be noted that the software exception handling device and the software exception handling method provided in this application are based on the same application concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned software exception handling method, and the repeated parts will not be described again.

[0139] The software exception handling method and apparatus provided in this application are based on dual-mode heterogeneous data collection and alignment that combines Webhook streaming triggering with deep RESTful API retrieval. After the second-level perception of the crash event, the user behavior trajectory and network request link within a preset time window before the crash are traced and extracted from the internal log server according to the timestamp through user identifier mapping rules. The crash stack, device metadata, and user operation path are then integrated into a structured fault context dataset.

[0140] This application provides a local privacy desensitization and fault fingerprint extraction method for large model inference. Before the data is uploaded to the large model service, sensitive fields are masked using NER and regular expression rules, the crash stack is simplified at the framework level, and a fixed-format fault fingerprint composed of exception type, core crash line and error information is extracted, thereby reducing token consumption while ensuring privacy.

[0141] The software anomaly handling method and apparatus provided in this application embodiment combine large model crash intelligent diagnosis with vector retrieval enhancement (RAG). The fault fingerprint is input into the enterprise's internal historical fault knowledge base for semantic similarity matching. The retrieved historical repair cases are used as few-sample prompts and input together with the current crash context into the large language model. Multi-round inference is performed and the root cause localization conclusion and repair code suggestions (Diff format) are output.

[0142] The software anomaly handling method and apparatus provided in this application embodiment offer dynamic rendering of multi-role differentiated reports. Based on the information needs of different roles such as management, development, and testing, different dimensions of report content are dynamically extracted and rendered from the same diagnostic result according to a predefined template, including impact statistics, operation reproduction path visualization, and repair code comparison view.

[0143] The software exception handling method and apparatus provided in this application are based on automatic source tracing and collaborative assignment of crash responsibility through symbolic mapping and Git Blame linkage. First, the obfuscated stack is restored to the source code file and line number through mapping / dSYM mapping. Then, the version control system API is called to query the most recent code modifier. Finally, the fault work order is automatically created, accurately pushed and assigned to the corresponding responsible person through the Webhook interface of the enterprise collaboration tool, so as to realize cross-platform unattended collaboration.

[0144] The software exception handling method and apparatus provided in this application provide a fully automated closed-loop system architecture from fault perception to assignment of responsibility, which connects the crash monitoring platform, internal log system, local preprocessing engine, RAG knowledge base, large language model inference service, version control system and enterprise collaboration tools into a unified event-driven processing pipeline.

[0145] Corresponding to the software exception handling method provided in the above embodiments, based on the same technical concept, this application also provides an electronic device for executing the above method. Figure 6 To illustrate the structure of an electronic device according to various embodiments of this application, as shown in the following diagrams... Figure 6 As shown. Electronic device 500 can vary considerably due to differences in configuration or performance, and may include one or more processors 510 and memory 520. Memory 520 may store one or more application programs or data. Memory 520 may be temporary or persistent storage. The application programs stored in memory 520 may include one or more modules (not shown), each module may include a series of computer-executable instructions for the electronic device. Furthermore, processor 510 may be configured to communicate with memory 520 and execute the series of computer-executable instructions stored in memory 520 on the electronic device.

[0146] This application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, implement the steps of the software exception handling method described above.

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

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

[0149] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0150] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

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

[0153] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

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

[0156] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

[0157] It should be understood that the training and prediction processes of the AI ​​models involved in the various embodiments of this specification all adhere to multiple legal and compliant principles, including legal data sources, compliant data content, compliant data governance, compliant training objectives and schemes, compliant training processes, compliant training environments and tools, and compliant ethical verification of training results, and comply with the requirements of Article 5 of the Patent Law. Among them: Data source legitimacy: All datasets used for AI model training were obtained through legal means, covering three categories: publicly authorized data, data authorized by partners, and self-collected compliant data. Publicly authorized data originates from compliant data sources that comply with relevant open-source agreements, with complete copyright attribution and authorization scope clearly marked, and no unauthorized open-source code or data reuse. Data authorized by partners has been subject to formal data usage agreements, clearly defining the scope, duration, and confidentiality obligations, and possessing a complete authorization chain. For self-collected data involving personal information, strict informed consent procedures have been followed, and anonymization processes (including but not limited to field masking, feature anonymization, and differential privacy technology) have been implemented to remove personally identifiable information, fully complying with relevant laws and regulations.

[0158] Data content compliance: The AI ​​model's dataset undergoes multiple screenings and cleaning processes to remove all non-compliant information and ensures that there is no illegal acquisition or use of genetic resources. For data in sensitive fields (such as healthcare and finance), an additional privacy-preserving computation module (including federated learning and secure multi-party computation technologies) is used to ensure that the data is "usable but not visible," avoiding compliance risks during the original data transmission process and ensuring that the data application scenarios and uses comply with public order and good morals and industry regulatory requirements.

[0159] Data governance norms: A complete data traceability system is established during the AI ​​model training process to automatically record the source, collection time, annotation process, cleaning rules, and permission allocation of training data, generating traceable compliance reports to ensure that the data is verifiable throughout its entire lifecycle. The dataset annotation process for AI models is completed by a professional human R&D team, clearly defining the proportion of human creative contributions and avoiding reliance on AI-generated data that has not undergone substantial human modification, thus meeting the examination requirements for "human main contributions" in AI patent applications.

[0160] Training objectives and plans are compliant: The training objectives, training schemes, and final output results of the AI ​​model do not violate any mandatory provisions of laws or administrative regulations, do not harm the public interest or the legitimate rights and interests of others, and do not pose any potential risks of being used for illegal or criminal activities, infringing on privacy, or disrupting public safety. They strictly adhere to the ethical principle of "intelligent for good".

[0161] Training process compliance: A closed-loop training framework is adopted to ensure compliance and controllability of the training process. The specific process is as follows: First, training samples are obtained through compliant data sources. After the aforementioned data cleaning and desensitization, they are input into the neural network model to generate preliminary training results. Second, an expert system is introduced to verify the preliminary results. Based on preset rules and human expert experience, the feasibility of the results is evaluated, and outputs that may pose ethical risks or compliance hazards are corrected (such as removing decision-making logic that violates public order and good morals, and adjusting model parameters that do not comply with safety regulations). Finally, the loss function weights are dynamically optimized based on expert system feedback to strengthen the model's learning of compliant results, avoid overfitting errors or non-compliant labels, and form a closed-loop control of "data input - model training - expert verification - parameter optimization - result feedback" to ensure that the entire training process complies with the ethical review requirements of relevant laws.

[0162] Training environment and tool compliance: AI model training is implemented using nationally licensed chips and a compliant training platform. All open-source frameworks and components used in the training process have obtained their corresponding licenses, and copyright statements and patent citation information are fully retained, with no instances of infringement or reuse. The training environment is built using virtual devices (containers / virtual machines) with fixed random seeds and initial parameter configurations to ensure the reproducibility of the training process. Furthermore, through access control and operation log recording, risks such as data leakage and parameter tampering during training are prevented, ensuring the security and compliance of the training process.

[0163] Training results ethical verification compliance: After the model is trained, it undergoes additional third-party ethical compliance assessment and algorithm filing review to verify that the model output does not violate social morality or harm public interests. For potentially sensitive scenarios, a dedicated result verification mechanism is established to ensure that the model always complies with relevant laws and regulations in practical applications.

[0164] In summary, the data and training process used in the AI ​​model in this specification strictly comply with relevant regulations and do not violate any laws, social ethics, public interests, or regulations on the use of genetic resources. Therefore, it fully meets the compliance requirements for patent authorization.

Claims

1. A software exception handling method, characterized in that, The method includes the following steps: In response to an abnormal event notification sent by a third-party monitoring platform in the form of real-time event push, abnormal event data is obtained from the third-party monitoring platform, and user behavior trajectory and network request data within a preset time window before the occurrence of the abnormal event are obtained from a designated log system. An abnormal context dataset is generated based on the abnormal event data, user behavior trajectory, and network request data. The abnormal context dataset is preprocessed, and key abnormal feature information is extracted from the preprocessed data to generate an abnormal fingerprint. Candidate cases are obtained from a preset knowledge base based on the abnormal fingerprints, and the candidate cases and abnormal context dataset are input into a large language model to obtain abnormal diagnosis results. The obfuscated stack in the abnormal event data is restored to the source code location by using a symbolic mapping table, and the code modifier information of that source code location is determined. An exception work order is generated based on the anomaly diagnosis results and the code modifier information, and the exception work order is pushed through a preset message interface.

2. The method according to claim 1, characterized in that, The real-time push method is either a Webhook callback or a message queue subscription; The process of obtaining abnormal event data from the third-party monitoring platform includes the following steps: The abnormal event data is retrieved from the third-party monitoring platform by calling the RESTful API interface, GraphQL interface, or platform SDK direct connection interface. The abnormal event data includes obfuscated stack traces, thread information, and device operating environment data.

3. The method according to claim 1, characterized in that, The step of retrieving user behavior trajectories and network request data within a preset time window prior to the occurrence of the abnormal event from a designated log system includes the following steps: Obtain the monitoring platform user identifier and the abnormal timestamp from the abnormal event notification; According to the preset user identifier mapping rules, the user identifier of the monitoring platform is associated and matched with the user identifier of the specified log system; Using the abnormal timestamp and the specified log system user identifier as search criteria, query the specified log system; Extract user behavior trajectory and network request data corresponding to the specified log system user identifier within a preset time window before the abnormal timestamp from the query results.

4. The method according to claim 1, characterized in that, The preprocessing of the abnormal context dataset includes the following steps: Sensitive fields in the abnormal context dataset are de-identified using at least one of the following methods: sensitive fields are identified and replaced with uniform placeholders using named entity recognition algorithms and regular expression rules; a rule tree-based field-level de-identification method is used; and a differential privacy method is used to perturb numerical sensitive fields. The obfuscated stack in the desensitized exception context dataset is simplified as follows: system framework calls and third-party SDK intermediate layer calls are removed from the obfuscated stack, and error lines directly related to the exception business logic and their preset frame numbers above and below are retained.

5. The method according to claim 4, characterized in that, The key anomaly features include the anomaly type, core anomaly line, and error message summary extracted from the simplified obfuscated stack, used to generate the anomaly fingerprint.

6. The method according to claim 1, characterized in that, The step of obtaining candidate cases from a preset knowledge base based on the abnormal fingerprint includes the following steps: The abnormal fingerprint is input into the preset knowledge base, and vector semantic similarity matching is performed with the historical repair cases in the preset knowledge base to obtain a preset number of similar historical repair cases, and the similar historical repair cases are used as candidate cases.

7. The method according to claim 1, characterized in that, The process of determining the code modifier information for this source code location includes the following steps: The code modifier information for the specified source code location can be obtained by calling the commit history query interface of the version control system; or, the code modifier information for the specified source code location can be determined by weighting the modification frequency and the most recent modification time of the specified source code location within a preset time period, and combining this with file owner rules, organizational structure address book and / or historical repair records for multi-factor weighted matching.

8. A software exception handling device, characterized in that, Including the following: The data acquisition module responds to abnormal event notifications sent by a third-party monitoring platform in a real-time event push manner, acquires abnormal event data from the third-party monitoring platform, and acquires user behavior trajectories and network request data within a preset time window before the occurrence of the abnormal event from a designated log system. The context building module is used to generate an abnormal context dataset based on the abnormal event data, user behavior trajectory, and network request data. The fingerprint extraction module is used to preprocess the abnormal context dataset, extract key abnormal feature information from the preprocessed data, and generate abnormal fingerprints. The intelligent diagnosis module is used to obtain candidate cases from a preset knowledge base based on the abnormal fingerprint, input the candidate cases and abnormal context dataset into a large language model, and obtain the abnormal diagnosis result. The source tracing module is used to restore the obfuscated stack in the abnormal event data to the source code location through a symbolic mapping table, and determine the code modifier information of the source code location. as well as The work order management module generates abnormal work orders based on the abnormal diagnosis results and code modifier information, and pushes the abnormal work orders through a preset message interface.

9. An electronic device, characterized in that, It includes a processor, a memory, a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, implement the steps of the method as described in any one of claims 1 to 7.

Images