Method, device and equipment for positioning flow problem of network client of Netcom equipment

Abstract

The invention provides a netcom equipment network client flow problem positioning method, which comprises the following steps: collecting log information of netcom equipment, and sending the log information to a cloud; on the basis of the log information, the running state of the specific program is tracked and analyzed, and tracking information is obtained; according to the log information and the tracking information, restoring a specific program execution process and memory mapping in the cloud; and when the execution process and the memory mapping of the program are restored, comparing the system call log in the log information of the normal process with the system call log in the log information of the abnormal process in the cloud, and positioning the process problem through a pattern recognition algorithm and a process branch prediction algorithm. And the process problem can be quickly positioned.

Description

Technical Field

[0001] The present invention relates to the technical field of network client process problem positioning of a Netcom device, and in particular to a method, device and equipment for positioning a network client process problem of a Netcom device. Background Art

[0002] In recent years, wireless and wired broadband services such as optical communications have developed rapidly, and the software function requirements of existing network communication equipment have become increasingly complex. Various complex client programs have been built inside the equipment. Limited by hardware costs and development cycles, a more complete diagnostic system cannot be deployed. It is necessary to rely on a complete debugging process and the environment in which the fault occurred to reproduce and locate the fault. This has brought serious challenges, especially to small and medium-sized companies in terms of personnel, labor intensity, and environment construction. The best thing is to be able to use on-site faults, collect comprehensive information, and quickly locate them.

[0003] In order to locate embedded devices, its operating system can be a Linux system. In order to locate the crash problem, the common instruction architectures of the Core file generated are ARM and MIPS. The Coredump file is organized in the ELF format. When an exception occurs, Linux saves the contents of the memory segment of the crashed process in the form of Segment to the Coredump file (including the data area, stack area, allocated heap content, and frame structure data at the time of crash, etc.). For the code segment, Linux does not save its content, but only saves the address information of the code segment; other auxiliary information such as thread information and register information is saved in the Segment segment of type PT_NOTE. Therefore, when using the GDB tool to view, the original executable file is required to restore the contents of the code area. The stack frame structure at runtime is as follows: Figure 3 , the operating system saves memory map and core dump files according to the settings.

[0004] Unlike existing Internet technologies, the server will have clear connection logs for terminal devices. The number of devices connected to the network is huge, and the update status is complicated. Generally, the network protocol bottom layer rarely records complete information, and regular diagnosis may also lose the details of the main process when the fault occurs. Correspondingly, since the traditional method requires waiting, manually confirming the location of the source code and the calling relationship of the function symbol, and repeatedly doing experiments to confirm, it is not conducive to quickly locating process anomalies. It is increasingly necessary to put manual workload on communication and collaboration that machines are not easy to do. It will require manual reading and analysis of the occurrence of system calls and the intermediate library encapsulation and the current location of the executable program.

[0005] The traditional debugging process is different from the development of networks around the world. The efficiency of cooperation is limited by objective conditions. It is still necessary to equip additional steps to complete the construction and observation of the test environment, especially when on-site assistance is required. Netcom equipment has more physical limitations than other Internet terminal equipment. Often, environmental exploration itself is cumbersome and highly professional. When maintenance is required, professional technicians are needed, leaving more time for real debugging and experiments, which affects the user experience. For some trivial operations, experienced people are needed to change the relevant manual diagnosis command template parameters to customize some additional remote commands, which is not conducive to reducing the difficulty of diagnosing problems. Summary of the invention

[0006] The present invention aims to solve at least one of the technical problems existing in the prior art. To this end, the present invention proposes a method, device and equipment for locating process problems of a network client of a network communication device, which can quickly locate process problems and reduce the internal collaboration cost of developers.

[0007] In a first aspect, an embodiment of the present invention provides a method for locating a problem in a network client process of a Netcom device, comprising:

[0008] Collect log information of Netcom devices and send it to the cloud;

[0009] Based on the log information, the running status of the specific program is tracked and analyzed to obtain tracking information;

[0010] Restore the specific process and memory mapping of program execution in the cloud according to the log information and the tracking information;

[0011] When the execution process and memory mapping of the program are restored, the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located through pattern recognition algorithm and process branch prediction algorithm.

[0012] In some embodiments of the present invention, when there are at least two network communication devices, collecting log information of the network communication devices and sending it to the cloud includes:

[0013] Placing all of the network communication devices in the same environment;

[0014] Configuring all of the network communication devices to have the same program running conditions;

[0015] Model the flow chart of the source code, and generate judgment conditions for the variables and exception types that the abnormal process branches depend on for monitoring when the device tracks the process;

[0016] During compilation, the debugging symbol versions of all binary execution files and function module files that the network communication device firmware depends on are saved as backups, corresponding one to one with the binary execution files and function module files of the network communication device firmware after the debugging symbols are stripped.

[0017] In some embodiments of the present invention, the network communication device includes a first network communication device and a second network communication device, and the collecting log information of the network communication devices and sending it to the cloud includes:

[0018] Get the exception type of the process;

[0019] Collect the log information of each of the exception types;

[0020] Collect the variables and functions of the process that triggers the judgment condition as key logs;

[0021] Based on the log information and the key log, at least one judgment condition instruction and an adjustment memory mapping instruction are generated, so that the cloud sends the judgment condition instruction and the adjustment memory mapping instruction to the first network communication device and / or the second network communication device for reproducing the problem to confirm all conditions for reproducing the problem.

[0022] In some embodiments of the present invention, the collecting the log information of each of the exception types includes:

[0023] When the abnormality type is a system crash, information on the operation of system resources is collected;

[0024] When the abnormality type is network interruption, information on the interruption of basic services is collected;

[0025] When the abnormal type is the interruption of basic services, the additional network is connected to the network communication equipment to collect manual input information;

[0026] When the abnormal type is a client device service interruption, information is collected from internal record information of the user state process.

[0027] In some embodiments of the present invention, the tracing information includes a stack frame log, and the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located by a pattern recognition algorithm, including:

[0028] Obtain the stack frame log and memory map when the program is running;

[0029] Map the stack frame log to the source code to obtain the corresponding statement call structure;

[0030] The abnormalities of different processes in the network communication device during the program execution process are monitored and located through a pattern recognition algorithm and a process branch prediction algorithm.

[0031] In some embodiments of the present invention, the comparing the system call log in the log information of the normal process with the system call log in the log information of the abnormal process in the cloud, and locating the process problem by pattern recognition algorithm, includes:

[0032] Obtain the log information at the location as an error log;

[0033] According to the error code in the error log, locate the corresponding code position in the source code, perform code inspection on the code at the code position, and obtain code summary information;

[0034] Flow problem information of the flow problem is obtained, and an error report is generated according to the code summary information and the flow problem information.

[0035] In some embodiments of the present invention, the comparing the system call log in the log information of the normal process with the system call log in the log information of the abnormal process in the cloud, and locating the process problem by using a pattern recognition algorithm, includes:

[0036] Obtaining a source code stack snapshot in the tracking information in the cloud;

[0037] The binary address information in the source code stack snapshot is removed.

[0038] In the second aspect, an embodiment of the present invention provides a device for locating a process problem of a network client of a Netcom device, comprising at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor so that the at least one control processor can execute the method for locating a process problem of a network client of a Netcom device as described in the first aspect above.

[0039] In a third aspect, an embodiment of the present invention provides an electronic device, comprising the apparatus for locating a process problem of a network client of a Netcom device as described in the second aspect above.

[0040] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the method for locating a problem in a network client process of a Netcom device as described in the first aspect above.

[0041] According to the method for locating the process problem of the network client of the network communication device of the embodiment of the present invention, there are at least the following beneficial effects: collecting the log information of the network communication device and sending it to the cloud; based on the log information, tracking and analyzing the running status of the specific program to obtain the tracking information; based on the log information and the tracking information, restoring the specific process and memory mapping of the program execution in the cloud; when the execution process and memory mapping of the program are restored, the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located by the pattern recognition algorithm. The log information of the network communication device is obtained, and the specific program is quickly and deeply related to find the recurrence conditions. After the recurrence is realized, the recurred program flow can be quickly located, which is convenient for subsequent problem solving, reduces the workload of setting up the environment and a large amount of repeated diagnostic work. This method can greatly improve automation, shorten the time to locate problems, and reduce the internal collaboration cost of developers. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings constituting a part of the present invention are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the accompanying drawings:

[0043] Figure 1 It is a flow chart of a method for locating a problem in a network client process of a Netcom device provided by an embodiment of the present invention;

[0044] Figure 2 It is a structural diagram of a device for locating a process problem of a network client of a Netcom device provided by another embodiment of the present invention.

[0045] Figure 3 It is a stack frame structure diagram of an operating system running a program of a network client device of a network communication device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0046] The present invention will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that the embodiments and features in the embodiments of the present invention can be combined with each other without conflict.

[0047] The following detailed description is an exemplary description, which is intended to provide further detailed description of the present invention. Unless otherwise specified, all technical terms used in the present invention have the same meaning as those generally understood by those skilled in the art to which the present invention belongs. The terms used in the present invention are only for describing specific embodiments, and are not intended to limit the exemplary embodiments according to the present invention.

[0048] The control method of the embodiment of the present invention is further described below based on the accompanying drawings.

[0049] Reference Figure 1 , Figure 1 A flowchart of a method for locating a problem in a network client process of a Netcom device provided by an embodiment of the present invention includes but is not limited to the following steps:

[0050] Step S110, collecting log information of Netcom devices and sending it to the cloud;

[0051] Step S120, based on the log information, tracking and analyzing the running status of the specific program to obtain tracking information;

[0052] Step S130, restoring the specific process and memory mapping of program execution in the cloud according to the log information and tracking information;

[0053] Step S140, when the execution process and memory mapping of the program are restored, the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located through the pattern recognition algorithm and the process branch prediction algorithm.

[0054] It should be noted that multiple modules may be provided, each module corresponding to executing a step. For example, a built-in log service module is provided to collect log information, including logs of program operation output, and logs of the call flow or system status of a single process and program core dump files collected according to remote instructions, and sent to the cloud;

[0055] The program tracking module performs tracking and analysis on a preset specific program according to remote instructions. The tracking and analysis can be real-time scanning of the memory map and system calls of the specific program. The tracking information includes the output stack and the actual content of the memory map.

[0056] The cloud restore execution module is used to restore the executable file. The restoration process includes expanding the executable file, core dump file, and program execution stack frame, separating files with debugging symbols, and restoring the specific process and memory mapping of the executable file at that time through the cross-compilation tool chain;

[0057] The above is suitable for the situation of known recurring problem conditions, and the part that can be repeatedly reproduced; the cloud program diagnosis module, according to the system call log of the execution file in the normal running state, especially the stack frame expansion process log, and the stack frame expansion log of the system call log of the abnormal process, performs pattern recognition to locate the place where the process is blocked. In this way, it can be collected without time and space restrictions, because the complete expansion and collection of the stack frame will consume a lot of resources and preparation. Generally, the search matching space can be greatly reduced through qualitative analysis. Combined with the qualitative analysis of different devices under the same network environment and the accurate expansion of the program stack frame analysis, the exact variable values ​​and some unknown factors when the process abnormal problem class occurs can be more clearly known. For some network applications, the deep network call encapsulation level is very deep, and it is necessary to expand the stack, because not all takeover personnel have the experience and ability to read so much source code to determine the process location where the problem occurs. The present invention especially automatically obtains these stack records for pattern recognition, which can locate the problem at the system level when the process is abnormal. If it is finally found that there is no obvious variable abnormality or null pointer at the program level that causes system call blocking, etc., it can be manually confirmed near the corresponding source code for re-examination.

[0058] Furthermore, compared to traditional horizontal comparisons, such as using passively collected API execution trajectories and then restoring them, the present invention adds real-time probes, which can reverse debug and jump back to the previous observation point in situ. It is controlled by cloud instructions in real time, and the stack of the source code running process is visualized in advance according to the normal process. The complete normal process data is collected, and the binary address information dehydration steps are used to reserve more complete observation points.

[0059] Furthermore, according to remote instructions, the preset specific program is tracked and analyzed: the system bottom-level record information is collected, and a panoramic process restoration is performed to determine whether a fixed process exception of the client process causes blockage or service interruption.

[0060] For network communication devices, due to the limited space of ROM and RAM, debugging services cannot be placed inside the device. An intermediary probe is needed to place remote commands and complex logical judgments in the cloud. This part uses a large model to summarize the preset pattern recognition knowledge base in natural language and try to classify it into known problems in the existing knowledge base. If it exceeds the range, an early warning is issued, requiring refined analysis or manual intervention analysis. This probe must be lightweight and collect relatively limited information.

[0061] In another embodiment, when there are at least two network communication devices, collecting log information of the network communication devices and sending it to the cloud includes:

[0062] Place all Netcom devices in the same environment;

[0063] Configure all Netcom devices with the same program running conditions;

[0064] Model the flow chart of the source code, and generate judgment conditions for the variables and exception types that the abnormal process branches depend on for monitoring when the device tracks the process;

[0065] During compilation, the debugging symbol versions of all binary execution files and function module files that the Netcom device firmware depends on are saved as backups, corresponding one to one with the binary execution files and function module files of the Netcom device firmware after the debugging symbols are stripped.

[0066] For the process branch prediction algorithm, through normal log information and abnormal log information, the normal flow chart parses out the basic hit control conditions of a normal flow, such as the return value of a function Function_a in the condition, the variable value of the abnormal state captured by the abnormal process, and the specified variable does not meet the expected conditions; through the calling sequence of the functions successively experienced in the log, the present invention backtracks the content of the memory dump corresponding to the function, and infers the situation of each variable on which the source code statement where the exception type is located depends, and the values ​​of these variables are stored in the stack frame at runtime. For example, by uniquely numbering the stack frame, the call stack can be located. For ARM architecture chips, the stack frames saved by the pc register and the LR register ensure that the memory mapping corresponding to the source code will not be confused in different call paths. Through the training of key logs of source code, the judgment conditions of a certain function or variable can be determined, so that when the location of the First Netcom device can meet the necessary and sufficient conditions for reproducing the problem, it can be paused without waiting for the final abnormal code process to appear, which greatly improves the speed of locating the problem; collecting on-site abnormalities and memory dump files is to provide enough constraints to avoid searching too many processes and call stacks, and avoid being unable to deduce the function name of the abnormality that appears only at runtime;

[0067] Due to the particularity of embedded devices, the life cycle of variables may be recovered before being popped off the stack at an earlier time. Therefore, when multiple variables are executed continuously and the judgment conditions need to be confirmed, there is a certain uncertainty in a single condition, and backtracking cannot be efficient and successful immediately. It is necessary to use the first Netcom device (the device at the first scene where the problem occurred) and the second Netcom device (the device used for backup verification) to breakpoint and pause to the same process where the same function is located, send the modification memory mapping instruction, simulate and reproduce the environment before the specific log record time point where the problem occurred with the first Netcom device, and the status of all variables and registers in the same function to see whether it will go to an abnormal process, and gradually eliminate the uncertain variables, that is, whether it has an impact on the IO or network environment, or whether there is a loophole in the internal processing logic that produces an unexpected exception. This process can also be used for pre-training of the log process for a single application, so that the work process in the daily debugging environment can provide the necessary log data and judgment conditions required for monitoring to manually supplement the production environment for locating problems.

[0068] When establishing problem archives and manual retrieval, you can build word vectors through a series of functions involved in the call stack when locating the problem later, and quickly locate the stack frames of a series of related functions. A single word vector can uniquely define the specific problem record scenario of a process branch. When outputting the report, bring this word vector and the summary description of the problem in the corresponding call process to archive;

[0069] It should be noted that for a group of network communication devices within the same network region, the hardware is often the same, the code segments of the program files preset in the binary firmware are mapped to the same address, and the probability of problems is also the same. Therefore, after fixing the environment and program running conditions, and determining the logs of system resources, you can use the method of automatically obtaining logs to compare different devices. In this way, you can find many related clues without too much human intervention. After obtaining the operating authority provided by the operator or user, you can quickly collaborate with the diagnostic tool and the portable and deployable cloud to complete the analysis. Furthermore, because some complex client programs call many dynamic library files and have their own stack limitations for sub-processes, it is impossible to output complete information when tracking program execution. For example, the number of levels of output stack frames and log information summaries are limited by default.

[0070] Preferably, in the firmware release stage, the initial environment is used to coordinate the joint debugging of the cloud and Netcom equipment, collect the initial stack of a round of key business processes, and when an exception occurs, batch remote debugging is adopted to debug Netcom devices with unified inducement conditions in the same region and the same batch, and the operation logs of Netcom devices with preset debugging symbols and the status logs of specific processes and the system calls of the process expansion flow stack are collected in parallel; this step enables the memory address identified by the machine code instructions in the execution file to be decompiled back to the actual location of the source code according to the symbol table generated by the compilation process. The address of the process, thread, and each register can be clearly presented in the stack frame, and summarized and prompted according to the pre-trained model, and similarity matching is performed with various preset problems in the knowledge base to inspire R&D personnel to think deeply.

[0071] Preferably, the program tracking module in the network communication device is directly issued with instructions to output the stack, output the executed function name symbol and address, and when the function name and symbol are unclear, they can be parsed according to the memory address and the memory mapping address of the symbol file stored in the cloud; by reserving the debugging symbol file of the binary file in the firmware, it is not necessary to repeatedly compile and confirm whether there are errors in the fixed process and the inducement of the on-site environment that cause the process abnormality, such as deadlock, business process blocking caused by network interruption or program crash, etc.;

[0072] In another embodiment, the network communication device includes a first network communication device and a second network communication device, and collecting log information of the network communication device and sending it to the cloud includes:

[0073] Get the exception type of the process;

[0074] Collect log information of each exception type;

[0075] Collect the variables and functions of the process that triggers the judgment conditions as key logs;

[0076] Based on the log information and key logs, at least one judgment condition instruction and an adjustment memory mapping instruction are generated, so that the cloud sends the judgment condition instruction and the adjustment memory mapping instruction to the first Netcom device and / or the second Netcom device for reproducing the problem to confirm all conditions for reproducing the problem.

[0077] Furthermore, the step of collecting log information of each exception type includes:

[0078] When the exception type is system crash, information on the operation of system resources is collected;

[0079] When the abnormality type is network interruption, information on the interruption of basic services is collected;

[0080] When the exception type is basic service interruption, additional networks are connected to the Netcom equipment to collect manual input information;

[0081] When the exception type is client device service interruption, information is collected from the internal record information of the user state process.

[0082] It should be noted that conventional exception types can collect corresponding logs at different levels. The most serious, such as system crashes, can be discovered by monitoring the operation of system resources, CPU and memory usage in a reproducible type. The next level is network interruption, which can be viewed by looking at the network link status. Basic service interruptions, such as DNS services and DHCP services, have built-in diagnostic tools that are triggered according to the number of retries, which can cause some of the most basic remote diagnostic services to fail. At this time, the present invention is required to utilize additional network connection deployment and connect the Netcom device to diagnose problems with basic services. It is necessary to perform maintenance on-site at home users, so as to collect relevant information input manually. The next level is the common main service interruptions of CPE, which can be refined to a specific process, such as Wi-Fi, OMCI (ONT management and control interface), TR069 (a communication protocol between CPE and ACS), VoIP (Voice over Internet Protocol) key subsystem, etc., to collect relevant user-mode process internal record information. At the next level, the corresponding user-mode process records information internally; if the system and network are not crashed, the remote control system can still be enabled, and some operations can be performed on the device in the remote diagnosis service area such as ACS. When it is not affected by the firewall policy, it can be authorized to perform remote diagnosis and deploy diagnostic tools, which can greatly increase the scope of collaboration without geographical restrictions. Different layers of exception handling and log collection are performed for different exception types, and what kind of log information is collected is determined according to the degree and type of exception, such as the level and method of the log.

[0083] Step 1, process internal information, link information includes some basic status records in the anomaly detection log used by the corresponding business program according to the OSI seven-layer model. For example, TR069 business is a business process of CPE and ACS based on http connection. Its http protocol-based layer has data records, and each interaction has a status code, such as 401 to maintain authentication. Whether the interaction specified in the protocol is completed, the relevant status code is set. When creating a tcp connection in the http outer layer, there will also be status records, such as the port number, which can correspond to the file descriptor inside the process.

[0084] Step 2 also includes network information detected by the system; recording the process status information of the TR069 service, such as how many sites, which network ports are occupied, and what changes will occur at different times;

[0085] Step 3: Find out whether the current network step has changed through the network link tracking step;

[0086] For example, if the server connection of the TR069 network is disconnected, the main phenomenon is related to the accident of the intermediate router being closed. The client can perceive obvious link changes. If the link is suddenly disconnected, the diagnosis process will have some basic status information, which can be followed up quickly;

[0087] Step 4, preferably, based on the remote instruction template of the specific service and the preliminary obtained diagnostic summary, continue to modify the instruction generation model to be applicable to the observation parameters under the current network topology;

[0088] These embedded devices have many basic gadgets to support them; quickly scan the processes and interfaces of related services. For example, TR069 service problems are often related to port problems, data flow problems, and DNS problems. Quickly scan the connections of DNS servers on different WAN ports, and perform topology discovery and diagnosis through traceroute / ping the servers on the link. Record this part of the system log and transmit it to the cloud.

[0089] If the internal log output by the process does not match the external log, for example, after a certain interface receives a remote command, manually executing some commands can show that the server connection is normal, but the diagnosis-related service still has not restored the connection with the server (this part of information often needs to be manually confirmed with the customer complaint report when the fault occurs), you can quickly diagnose based on pattern recognition to see if there is an internal situation of the Netcom device that caused the direct connection to the server to be interrupted. This can be manually triggered to make a preliminary response to such problems quickly.

[0090] Including collecting the corresponding DNS, http, ICMP, and arp messages, and calculating them according to the reference attributes; the implementation example is that the ACS server cannot distinguish how a CPE (a form of expression of Netcom equipment, Customer Premise (s) Equipment) that has established a multi-process and multi-process duplex link is interrupted, and can only manually or initiate the diagnosis of the connectivity and quality of the specific business link on the server again to determine the last time of loss of connection, and cannot test some occasional factors and complex inducement conditions that cannot be simply controlled. Through external factors, the qualitative situation of the current fault can be understood.

[0091] In another embodiment, the tracing information includes a stack frame log, and the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located by a pattern recognition algorithm, including:

[0092] Get the stack frame log and memory map of the program when it is running;

[0093] Map the stack frame log to the source code to get the corresponding statement call structure;

[0094] The pattern recognition algorithm and process branch prediction algorithm are used to locate the anomalies of different processes in the program execution process of Netcom devices.

[0095] It should be noted that the present invention mainly builds a test environment based on the same topological environment to collect the normal running instruction flow, observes an observation main flow defined by the process source code, and makes reliability marking based on the main flow.

[0096] The first small step is to accumulate training data and establish a complete process flow that directly replicates the API and stack frames used in the source code: specifically, in the visualized process, it is used to collect the main sequence of the API that can be inserted into the observation point, and the function name stored in the $pc register in the collection stack frame when it just enters. According to the depth of the call stack in the process source code content, the test coverage of the exceptions in the running process and whether there are any places where the running risks need to be considered are marked according to the process. Therefore, an appropriate number of stack frame dumps are set, and a core dump file of appropriate granularity is saved while outputting the summary to meet the hardware performance limitations. The main API main sequence belonging to the observation point (mostly the source code directory to which the current process belongs, and a few questionable library APIs can also be set) can be based on the environment built during the docking process before production, completely controlled by probes, collect various branch processes that can run normally, and draw a world map (refer to the branch design of git hash values, and establish a sequence for the processes inside the current process and called external dynamic libraries for each function statement). The real low-probability difficult problems are some external factors involving external dynamic libraries and system calls (some non-open source call dependency libraries may be encountered), inter-process, and inter-host communications, and establish branch prediction warning conditions. By setting up observation points, the huge amount of calculations and file generation in the existing technology of process monitoring and system monitoring can be avoided.

[0097] After that, trace back each API and variable, and set the risk probability mark and the count of the position of the dependent mark for the branch condition: including, if an exception is encountered during multiple actual measurements and white-box tests of various conditions, mark the direct risk probability A of the corresponding test. When a field problem occurs, find out the dependent conditions and dependent variables, whether they are local variables, and whether they have been used up. If the values of the direct risk probability (P_direct) of both the called variable and the content pointed to by the address are very low in past tests, the current risk probability is set to 0 as the corrected posterior probability, which is used to greatly compress the transmission volume of the core dump file in the actual environment. If the storage domain of its function is outside the process source code directory, then a stack frame that references this function can be marked as not uploaded to the cloud; the present invention restores according to the address in the cloud based on the register information, variables, and a small amount of function information of the stack frame. And according to the test process of the library file, mark the coverage of the white-box test for these external API functions, which is used to set the risk probability of the API referenced by the current process. According to the parameters and the number of times of the currently incoming API, count whether the test result is abnormal, and draw the hit rate P_hit of the white-box test cases included in the main branch drawn according to the current API white-box test process. In this step, in order to exclude the processes and APIs that are normally running from the ones that ultimately cause problems and put them into the prior probability, P_unknown = (1 - P_hit). Therefore, it is necessary to mark whether it belongs to the hit range or the non-hit range (there may be exceptions) during the training process. If no white-box test has been performed, the prior probability of (P_unknown) can be set to 1 to warn the user to first check the comprehensive test situation of this API. This condition will be used in the next step for a strictly restricted device to command the probe tool located in the embedded device to decide whether to discard the sequence of the dump API of the secondary and used-up stack frames. According to the normal process of the present invention, a single function executed multiple times will also have a unique hash value for positioning the timing diagram. Since problems such as crashes, memory issues, or idling issues have a certain latency, the core dump file should be appropriately set with a delay time before deciding whether to delete (transfer) it. If there is an obvious accident, regardless of whether it is marked as not uploaded, reset it to upload all, so that there can still be a trigger signal such as a crash for emergency transmission when the problem occurs, avoiding missing the last time and the last relevant evidence. If it is a non-crash signal, these files marked as not uploaded are files of APIs that have been through a closed-loop and are almost impossible to make mistakes, and there will be subsequent core files of API dumps as evidence, and there is no need to upload from beginning to end, which greatly improves the debugging performance. According to the risks of each API that have been initially output, when any relatively hard-to-understand problem occurs, the position where the problem is reported can be quickly found by combining the timing diagram.Based on (P_unknown) or posterior probability (P_direct), when a real problem occurs, some core information can be discarded based on the risk according to the observation point of the API that is prone to problems. The parts that are confirmed not to cause problems can also be classified. It is not necessary to dump all stack frames, which reduces the transmission load and can quickly locate the problem while ensuring performance. Modifying some metadata information of memory dumps and enriching the content of traditional core dump files can make it easier to automatically perform pattern recognition in the cloud, and the probability of manual confirmation can complement the differences in some tags learned by machine learning.

[0098] Step 1: Perform pattern recognition based on system logs and corresponding messages, and qualitatively analyze the types of network problems. Based on the qualitative analysis report, humans can determine which services have problems. If certain specific TCP and UDP ports are found to be in an abnormal state, such as being unable to switch as expected in a short period of time or being always open or closed, the port does not exist, or the process does not exist. In addition, the DNS domain names or DNS servers that have not responded for many times are counted, and the messages and preliminary analysis results of the messages are sent to the cloud to find out whether the DNS-related business problems are in the system state or in the abnormal process state.

[0099] Step 2: Pattern recognition diagnoses the running status of different threads and subprocesses of a single process. The pattern calculation is directly performed through the logs of stack frame expansion of different devices to restore the source code statement call structure and determine the type of execution process problem. Because the binary execution file in the Netcom device may only read the address but not understand the actual meaning after the stack is expanded at runtime, it is necessary to restore the source code statement according to the address; and the existing description of the type of source code and running errors and business processes has a relatively mature knowledge base that can be used for summary. When the preliminary execution statement and execution environment are obtained through binary file address conversion, the current state log content is manually cut and marked, and handed over to the large model interface for brief summary, limiting the context window and simple logic derived by the large model, and based on the stack situation of a single statement, especially the system call situation that can be adversarially marked in accordance with the normal process, basic business anomaly judgment is performed, that is, whether the next executable statement can be entered and the normal value range judgment can be made. Therefore, manual intervention and correction process can be reduced, and a comparison summary with less noise can be output to avoid hallucinations and reduce the burden of human memory. Some necessary process problem information can be intelligently prompted on the log or source code interface to calculate possible code risks.

[0100] Furthermore, in step 3, a backup of the executable program with debugging symbols in the cloud needs to be prepared at the stage of generating the firmware, which is used to restore all log files of the program execution in the Netcom device;

[0101] Furthermore, step 4 converts to binary files and source code files with debugging symbols and process annotations of R&D personnel through the interface of the debugging tool, and splits the stack log information corresponding to a readable source code statement and sends it to the large model for analysis: Compared with traditional horizontal comparison, such as using passively collected API execution traces and then restoring them, the present invention is also a real-time probe, which can reverse debug in situ and jump to the previous observation point again, and is controlled by cloud instructions in real time. It visualizes the stack of the source code running process in advance according to the normal process, collects complete normal process data, and uses binary address information to dehydrate the steps, and more completely reserve observation points. The process annotations of R&D personnel include setting a binary observation point (breakpoint) for a certain source code statement to globally uniquely mark the entire source code project, and describing the basic process of calling the function through language organization based on the globally unique mark description, and establishing a preset instruction requirement prompt for generating judgments and summary processes based on the core dump file and log content of the executable file. The large model outputs language and text that humans can understand according to the preset instruction requirements of the prompt. It is different from traditional function descriptions and comments because some deep calls have subtle normal value states, which lead to problems. This is unexpected, so it is necessary to quickly find the problem and see if it meets the expected effect stated in the notes; since the expected process is set, the expected can be generated and found faster according to the prompt, which reduces the amount of comparison calculations, which has certain advantages over the existing technology of collecting the complete sequence before diagnosis.

[0102] The present invention is mainly aimed at embedded devices, which have small capacity and low CPU performance. A large number of plug-ins cannot be executed for tracking. It can only obtain the system's scheduling of process resources based on the kernel level with little damage to the environment. Through ftrace and process attachment debugging, the relevant information of ptrace is obtained in real time, and the various registers, variables, and address states during the program operation are monitored. The information obtained is relatively limited. Through cloud device simulation, there are more read and write observation permissions, and with the pre-trained process branch data, the capture and restoration of the abnormal branch process with a small probability is quickly increased. The prior art considers the situation that can be completely copied. Due to the limitations of equipment and security policies, the environment of embedded devices is much more complicated in terms of observation environment, and it is impossible to fully reproduce the external and upstream and downstream environments of the device. Therefore, the device itself can only be detected from the support of the device load. When encountering an observation point, this step can be manually suspended, similar to breakpoint debugging, sending instructions to the embedded device, accessing the values ​​of all registers and variables of the memory mapping situation recorded by the checkpoint, and avoiding the confusion problem caused by the large model accepting a large amount of input, because the existing large model is easy to produce hallucinations for such random strings.

[0103] If it is a specific process problem according to the message and system log, such as the query that the process no longer exists, the same sentence and thread position, memory mapping address, and variable value that appear repeatedly in the log cannot be updated, it can be determined that the executed system call has been blocked; if it is a crash problem, it will not easily delete the memory mapping file that has been dumped nearby. The function name, hashid, risk point and probability value (identification condition) saved in the file name can be quickly mapped to the position corresponding to the source code, reducing the steps of manual confirmation. The present invention requires basic reasoning of the word vectorized sentences and knowledge graphs corresponding to the general reasoning knowledge base, and fine-tuning the accuracy of the pattern recognition customized by the aforementioned process annotations, so that a flow chart and prompt can be set by a mentor-level person, giving a clearer prompt to the later person, playing a coaching role, plus the process of debugging by oneself, can more fully understand the state machine required by the program and business process, and fully combine the specific operation process with the large model prompt warning, reduce the attention requirements of R&D personnel, and shorten the time from studying the source code to locating the problem and doing experiments. This improvement reduces the lack of summary and prompts when reading logs manually, allowing more energy to be spent on comparing and confirming the logical process of the problem itself. When necessary, simulation debugging can be performed based on the core dump file to supplement the chain of evidence at the fault site. Reducing the reliance on experienced developers when summarizing complex phenomena can better serve junior R&D personnel in analyzing problems, and in-depth research on problems caused by logical anomalies or unreasonableness behind the process. It also provides semi-automatic to fully automated assistance for some complex problems that require parallel analysis and relay collaboration. Through the previous steps, R&D personnel can be assisted in discovering fixed process problems at the source code level.

[0104] In another embodiment, the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and after the process problem is located by a pattern recognition algorithm, the following steps are included:

[0105] Get the log information at the location as the error log;

[0106] According to the error code in the error log, locate the corresponding code position in the source code, perform code inspection on the code position, and obtain code summary information;

[0107] Obtain process problem information of process problems, and generate an error report based on the code summary information and process problem information.

[0108] It should be noted that report summaries and unit test suggestions are generated for fixed process exceptions and causes:

[0109] For example, based on pattern recognition of some blockages and obvious error logs that appear in a certain place, a source code summary is given in the final complete debugging report. The source code summary can help developers quickly locate problems: analyze the source code through manual review or automated tools to determine the code segment where the problem occurs, and then identify potential problems in the code, such as syntax errors, bad coding practices, or possible bugs, obtain code summary information, implement semi-automatic and automatic report assistance, and try to use core process information to generate complete tests, including automatic output of problems that meet the test and R&D summary specifications, including process problem information, such as the flowchart where the process problem is located, external stack, inducement conditions, and preliminary solutions, especially a test case designed with existing inducements and processes after the solution, and environment construction suggestions. In this way, some reasonable reports can be given for different places where problems may occur, which is convenient for R&D personnel to confirm again and conduct in-depth debugging. To avoid the difficulties caused by the existing technology that only pre-configures the most basic code display and has no way to go deep into the actual situation at runtime, solve the debugging difficulties of embedded devices, and input too much information, which has exceeded the summary and reasoning capabilities of the existing large model. Therefore, according to the reasonable trajectory slicing and process branch matching check of key observation points, the exact link and context can be locked from two aspects to reduce the computational burden. For example, when connecting to the operator's network, the device often has a WAN port and a LAN port connected to the optical network, and then automatically obtains upstream information, convenient default WAN configuration, or multiple DNS servers and multiple voice servers. The situation is often more complicated. Sometimes a single person needs to operate different devices clearly to reduce the reporting process outside the core debugging process, and find some relatively simple errors. There is also a clear record of the deep encapsulation process; for example, network congestion may occasionally cause the connection to fail. The corresponding source code may only have a problem with the SOCKET. It is necessary to determine the incidence of the problem and whether it is a weak link or a random process problem that has not been handled properly to increase robustness. Necessary network monitoring can narrow the scope of locating the link where the problem occurs, so as to further use the observation method of the present invention to lock the evidence and causes and consequences of where a process may have an interaction problem, which constitutes a part of the commissioning report.

[0110] The following is an example of external operation to locate the problem in cooperation with the process. As a system network problem, the problem scenario can be further locked after the external factors are collected and determined, providing corpus for the final problem description and cause summary. If the downstream device is an OTT box, an IPTV WAN or an Internet WAN interface is required to obtain DNS. The data flow of the final IPTV service is not in the same WAN. If it is an Internet-based VOIP server, the DNS of a specific WAN should be requested to obtain the IP corresponding to the domain name of the voice server. The first part is to achieve rapid diagnosis by detecting the forwarding status of multiple DNS and the direct connection status of the downstream device. The first step is to collect DNS, ICMP, and ARP messages. ARP failure is not necessarily a problem, because there may be a security policy that causes the upstream server to not respond. If there is no ICMP response, traceroute is executed to see if there is a response, but there may not be a response. If it can be connected at the beginning, then according to whether the affected service needs to detect the DNS service and system process monitoring, the necessary external information can be gradually collected.

[0111] In another embodiment, in the cloud, the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared, and before the process problem is located by using a pattern recognition algorithm, the following steps are included:

[0112] Get source code stack snapshots from trace information in the cloud;

[0113] Remove binary address information from source code stack snapshots.

[0114] It should be noted that a backup of the executable program with debugging symbols in the cloud is required during the firmware generation stage, which is used to restore all log files of the program execution in the Netcom device;

[0115] A source code stack snapshot is also generated, which removes the binary address information of the executable file's running log and only retains the mapping relationship between human-readable symbolic tags and the call stack frame position of the source code; it is convenient for pattern recognition to compare the running logs generated by different versions of program files. In this case, the large model does not need to understand the full picture of a section of program source code, but only needs to know the source code process reasoning notes of normal input and normal output that the developer further marks near the source code. The source code stack snapshot can be generated and managed accordingly according to the version update of the source code, so that the official version can regenerate a comparison relationship diagram, quickly find similar stack records based on a certain running situation, and can be used for comparison between the large model and manual operations without paying attention to the interference of binary information; the source code stack snapshot can be used to import IDE tools to view the source code and stack at the same time, without having to connect to the Netcom device again for real-time viewing, ensuring that a certain statement at each version moment can accurately query the corresponding core dump file and stack record content. In the Netcom device, the target executable program file being run may be the executable program file with debugging symbols stripped from the backup program file, or it may be an identical binary file; for program files that are not stripped of symbols, when outputting logs, the source code of the execution process can be restored in one step. If there are no symbols, it is necessary to combine the stack log and core dump coredump file and system log of the Netcom device for the running status of a single process, and combine the source code execution for visualization; combined with the symbols of the executable file in the cloud, and the dumped executable program core file, checkpoint memory mapping image file or stack log and system log of the system call sent to the cloud by the Netcom device according to the running status of the device, the stack state and variable value of a certain call of the process can be easily restored, and the manual confirmation of whether there is a process abnormality can be made based on the prompt of such restoration to the source code; the innovation of the present invention is to perform pattern recognition based on the log, find out the problem, and synchronously obtain the core dump file, and the manual reproduction of the execution process based on the core dump file can be used for secondary confirmation to avoid misjudgment.

[0116] The present invention uses reserved firmware to compile intermediate files in the cloud, and combines them with the process log and memory log of the running execution file to accelerate the positioning of problems in the process corresponding to the source code, so that the rich data can help junior and intermediate R&D personnel to quickly find process blocking points and log abnormal points, reduce the dependence on senior R&D personnel, shorten the time to locate problems, enrich the means beyond complete reproduction of complex environment detection, use log records and core dump files to reproduce the problem process, reduce the burden of human analysis, and reduce the travel costs when network products are deployed around the world.

[0117] Improves the efficiency of locating occasional problems, iteratively upgrades network quality, and improves robustness. In order to reduce the time loss caused by step-by-step debugging, repeated experimental comparison debugging, and refined learning for developers, the present invention needs to perform a panoramic and rapid scan of core issues and an in-depth scan of core processes to find recurrence conditions or quickly locate them. It can quickly adapt the firmware and directly solve the problem with the on-site environment, reducing the workload of setting up the environment and a large amount of repeated diagnostic work, and try to allow gateway devices such as ONT to quickly intervene in the diagnostic process, and the log information is clearly summarized and prompted.

[0118] The location process of complex programs is shortened, especially for some relatively old equipment, which can only use external analysis methods. Then the manual labor according to the traditional method will be very heavy and more dependent on experience and memory, which is disadvantageous to the increasing network problems and collaboration cycle restrictions. The present invention uses a large model to communicate the information of the internal knowledge base, source code library and the environment in which the firmware is released to provide assistance for debugging and locating process problems. The application of this method can greatly improve automation, shorten the time to locate problems, fully understand the process defined by the source code at runtime, and reduce the internal collaboration cost of developers for situations where more equipment is required for large-scale diagnosis. Improve the parallel multi-party comparison discovery model of the source code and the actual operation of the field equipment, combined with the natural language large model, for some fixed processes and deep encapsulation of multi-process, multi-threaded type of program problems, provide an efficient system and an effective automation method to assist developers in locating problems more flexibly and efficiently. The present invention has clearly seen the statement positions of the dynamic library called in the stack and the execution program by directly outputting debugging symbols or according to the function name address mapped in the memory in the log of the mapped source code position, or when the debugging symbols of the execution file are missing, the real source code execution process can be restored according to the symbol address specified by the binary code and the symbol file and core dump file stored in the cloud, and the manual workload is put on communication and collaboration that some machines are not good at, reducing some unnecessary communication, and outputting the place where the system call occurs, the intermediate library encapsulation, and the current position of the executable program.

[0119] like Figure 2 As shown, Figure 2 The present invention also provides a device for locating a process problem of a network client of a network communication device, including:

[0120] The processor 201 may be implemented by a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0121] The memory 202 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 202 can store an operating system and other application programs. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 202, and the processor 201 calls and executes the method for locating the problem of the network client process of the network communication device in the embodiment of this application;

[0122] Input / output interface 203, used to implement information input and output;

[0123] Communication interface 204, used to realize communication interaction between the present apparatus and other devices, which can be realized by wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.);

[0124] Bus 205 , which transmits information between various components of the device (e.g., processor 201 , memory 202 , input / output interface 203 , and communication interface 204 );

[0125] The processor 201 , the memory 202 , the input / output interface 203 and the communication interface 204 are connected to each other in communication within the device via the bus 205 .

[0126] An embodiment of the present application also provides an electronic device, including the apparatus for locating a problem in a network client process of a Netcom device as described above.

[0127] The embodiment of the present application also provides a storage medium, which is a computer-readable storage medium. The storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned method for locating problems in the network client process of a Netcom device is implemented.

[0128] It is known from common technical knowledge that the present invention can be implemented by other embodiments that do not deviate from its spirit or essential features. Therefore, the above disclosed embodiments are only illustrative in all respects and are not exclusive. All changes within the scope of the present invention or within the scope equivalent to the present invention are included in the present invention.

[0129] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may 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.

[0130] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

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

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

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for locating a problem in a network client process of a Netcom device, characterized in that: include: Collect log information of Netcom devices and send it to the cloud; Based on the log information, the running status of the specific program is tracked and analyzed to obtain tracking information; Restore the specific process and memory mapping of program execution in the cloud according to the log information and the tracking information; When the execution process and memory mapping of the program are restored, the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located through pattern recognition algorithm and process branch prediction algorithm.

2. The method for locating a problem in a network client process of a network communication device according to claim 1, characterized in that: When there are at least two network communication devices, the step of collecting log information of the network communication devices and sending the log information to the cloud comprises: Placing all of the network communication devices in the same environment; Configuring all of the network communication devices to have the same program running conditions; Model the flow chart of the source code, and generate judgment conditions for the variables and exception types that the abnormal process branches depend on for monitoring when the device tracks the process; During compilation, the debugging symbol versions of all binary execution files and function module files that the network communication device firmware depends on are saved as backups, corresponding one to one with the binary execution files and function module files of the network communication device firmware after the debugging symbols are stripped.

3. The method for locating a problem in a network client process of a network communication device according to claim 2, characterized in that: The network communication device includes a first network communication device and a second network communication device, and the collecting log information of the network communication device and sending it to the cloud includes: Get the exception type of the process; Collect the log information of each of the exception types; Collect the variables and functions of the process that triggers the judgment condition as key logs; Based on the log information and the key log, at least one judgment condition instruction and an adjustment memory mapping instruction are generated, so that the cloud sends the judgment condition instruction and the adjustment memory mapping instruction to the first network communication device and / or the second network communication device for reproducing the problem to confirm all conditions for reproducing the problem.

4. The method for locating a problem in a network client process of a network communication device according to claim 3, characterized in that: The collecting of the log information of each of the exception types includes: When the abnormality type is a system crash, information on the operation of system resources is collected; When the abnormality type is network interruption, information on the interruption of basic services is collected; When the abnormal type is the interruption of basic services, the additional network is connected to the network communication equipment to collect manual input information; When the abnormal type is a client device service interruption, information is collected from internal record information of the user state process.

5. The method for locating a problem in a network client process of a network communication device according to claim 1, characterized in that: The tracking information includes a stack frame log, and the system call log in the log information of the normal process and the system call log in the log information of the abnormal process are compared in the cloud, and the process problem is located by a pattern recognition algorithm, including: Obtain the stack frame log and memory map when the program is running; Map the stack frame log to the source code to obtain the corresponding statement call structure; The abnormalities of different processes in the network communication device during the program execution process are monitored and located through a pattern recognition algorithm and a process branch prediction algorithm.

6. The method for locating a problem in a network client process of a network communication device according to claim 1, characterized in that: The step of comparing the system call log in the log information of the normal process with the system call log in the log information of the abnormal process in the cloud, and locating the process problem by using a pattern recognition algorithm, includes: Obtain the log information at the location as an error log; According to the error code in the error log, locate the corresponding code position in the source code, perform code inspection on the code at the code position, and obtain code summary information; Flow problem information of the flow problem is obtained, and an error report is generated according to the code summary information and the flow problem information.

7. The method for locating a problem in a network client process of a network communication device according to claim 1, characterized in that: The step of comparing the system call log in the log information of the normal process with the system call log in the log information of the abnormal process in the cloud, and locating the process problem by using a pattern recognition algorithm, includes: Obtaining a source code stack snapshot in the tracking information in the cloud; The binary address information in the source code stack snapshot is removed.

8. A device for locating problems in a network client process of a Netcom device, characterized in that: comprising at least one control processor and a memory for communicatively coupling with the at least one control processor; The memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor so that the at least one control processor can execute the method for locating network client process problems of Netcom devices as described in any one of claims 1 to 7.

9. An electronic device, characterized in that: It includes the Netcom equipment network client process problem locating device as described in claim 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method for locating a problem in a network client process of a Netcom device as described in any one of claims 1 to 7.

Images