A processing method and an electronic device

Abstract

This application discloses a processing method and an electronic device. When loading a driver for a first external device into the memory of an electronic device, the method obtains and stores the first memory address corresponding to the driver's entry point in the electronic device's memory, determines whether an abnormality has occurred during driver operation, and if so, determines and stores the second memory address corresponding to the current running progress of the driver in the electronic device's memory. Based on the first and second memory addresses, the method obtains and stores the corresponding driver code from the electronic device's memory. Therefore, this application detects and responds to driver operation abnormalities when loading and running an external device driver. By locating the relevant driver code at the time of the abnormality through the corresponding memory address, the application can subsequently analyze the captured driver code to locate the problem and analyze its cause. This facilitates rapid analysis and location of the cause of UEFI startup abnormalities and reduces the manual cost of root cause analysis.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a processing method and an electronic device. Background Technology

[0002] In applications where electronic devices load external devices, system crashes and other operational anomalies may occur during UEFI (Unified Extensible Firmware Interface) boot. However, current methods struggle to pinpoint the cause of these problems during UEFI boot, and the analysis process requires significant manual effort. Summary of the Invention

[0003] Therefore, this application discloses the following technical solution:

[0004] A processing method includes:

[0005] When loading the driver of the first external device into the memory of the electronic device, obtain and store the first memory address corresponding to the driver entry point in the memory of the electronic device;

[0006] Determine whether the electronic device is malfunctioning in response to the drive.

[0007] If so, determine and store the second memory address corresponding to the current running progress of the driver in the memory of the electronic device;

[0008] Based on the first memory address and the second memory address, the corresponding driver code of the driver is obtained from the memory of the electronic device and stored to obtain the target driver code, which is used to determine the cause of the abnormality.

[0009] Optionally, when loading the driver of the first external device into the memory of the electronic device, obtaining and storing the first memory address corresponding to the driver entry point in the memory of the electronic device includes:

[0010] When loading the driver for the first external device, the stored memory pointer information is obtained from the preset pointer register of the electronic device, and the memory address corresponding to the obtained memory pointer information is used as the first memory address.

[0011] The first memory address is stored in the storage component on the electronic device board management controller.

[0012] Optionally, determining whether an abnormality has occurred in the operation of the electronic device in response to the drive includes:

[0013] Determine whether the driving process of the first external device has been completed within a preset time period;

[0014] If not, then it is determined that the operation of the driver has malfunctioned;

[0015] If so, then it is determined that the operation of the driver has not encountered any abnormalities.

[0016] Optionally, determining and storing the second memory address corresponding to the current running progress of the driver in the memory of the electronic device includes:

[0017] When the above-mentioned abnormality occurs, the stored memory pointer information is obtained from the preset pointer register, and the memory address corresponding to the obtained memory pointer information is used as the second memory address;

[0018] The second memory address is stored in the storage component on the electronic device board management controller.

[0019] Optionally, the step of retrieving and storing the corresponding driver code of the driver from the memory of the electronic device based on the first memory address and the second memory address includes:

[0020] The target memory region is determined based on the first memory address and the second memory address;

[0021] Obtain the driver code of the first external device in the target memory region, and use it as the target driver code;

[0022] The target driver code is stored in the storage component on the electronic device board management controller.

[0023] Optionally, determining the target memory region based on the first memory address and the second memory address includes:

[0024] The memory region starting at the first memory address and ending at the second memory address is determined as the target memory region;

[0025] Alternatively, a memory region is determined with the first memory address as the starting address and the address obtained by offsetting the second memory address by a preset offset as the ending address, and this region is taken as the target memory region.

[0026] Optionally, the storage component is a first failure data capture (FFDC), which stores at least some information from the first memory address, the second memory address, and the target driver code.

[0027] Optionally, the above method also includes:

[0028] After the anomaly is determined to have occurred, a stop command is sent to the preset processor of the electronic device to cause the preset processor to stop the operation of the driver for the first external device.

[0029] And / or,

[0030] The target driver code is output to a second external device, so that the second external device can convert the target driver code into a preset readable program code and locate the cause of the exception based on the preset readable program code;

[0031] The identified cause of the anomaly includes: device information of the external device that caused the anomaly, and / or at least part of the problem code and problem type in the target driver code that caused the anomaly.

[0032] Optionally, the baseboard management controller of the electronic device obtains the corresponding memory pointer information or driver code through a preset interface, and / or sends a stop command to the preset processor of the electronic device through the preset interface.

[0033] An electronic device, comprising:

[0034] Memory, used to store at least one set of computer instructions;

[0035] A controller is configured to invoke and execute the instruction set stored in the memory, thereby implementing the processing method described in any of the preceding items.

[0036] A storage medium having stored thereon at least one set of computer instructions, which, when invoked and executed, are used to implement any of the processing methods disclosed above.

[0037] In summary, the processing method and electronic device disclosed in this application, when loading the driver of the first external device into the memory of the electronic device, obtains and stores the first memory address corresponding to the driver entry point in the memory of the electronic device, determines whether an abnormality has occurred during the driver's operation, and if so, determines and stores the second memory address corresponding to the current running progress of the driver in the memory of the electronic device, and obtains and stores the corresponding driver code of the driver from the memory of the electronic device based on the first and second memory addresses. Therefore, this application detects and responds to driver operation abnormalities when loading and running the external device driver, locates the relevant driver code at the time of the abnormality by using the corresponding memory address, and subsequently analyzes the captured driver code at the time of the abnormality for problem localization and root cause analysis. This facilitates rapid analysis and localization of the cause of UEFI startup abnormalities and reduces the manual cost of root cause analysis. Attached Figure Description

[0038] 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 embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0039] Figure 1 This is a flowchart illustrating one of the processing methods provided in this application;

[0040] Figure 2 This is a flowchart of the process of obtaining and storing target driver code from the memory of an electronic device, as provided in this application;

[0041] Figure 3 This is another flowchart illustrating the processing method provided in this application;

[0042] Figure 4 This is another flowchart illustrating the processing method provided in this application;

[0043] Figure 5 This is a schematic diagram illustrating the connection between the electronic device provided in this application and the second external device;

[0044] Figure 6 This is a structural diagram of the electronic device provided in this application. Detailed Implementation

[0045] The technical solutions of 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 are within the scope of protection of this application.

[0046] During startup, the system BIOS (Basic Input Output System) loads the UEFI (Unified Extensible Firmware Interface) driver for external devices such as expansion cards. When the UEFI driver of an external card malfunctions, resulting in device crashes or other issues, it's necessary to pinpoint the cause of the problem / abnormality. Current solutions typically involve manually inserting an ITP (a hardware device responsible for copying data related to the abnormal phenomenon) into the problematic machine to replicate the data. After copying, the cause of the problem is analyzed based on the copied data. This process is extremely time-consuming and labor-intensive, and it doesn't guarantee 100% reproducibility. Furthermore, if the problem occurs on the client side, it's difficult to reproduce using ITP (because it requires dedicated service personnel to the client to use ITP, and it interrupts services used by the client).

[0047] To address the aforementioned problems, this application discloses a processing method and an electronic device. The processing method can be applied to an electronic device, and the electronic device to which the method of this application is applied can be, but is not limited to, devices in a variety of general or special computing environments or configurations, such as: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, etc.

[0048] See Figure 1 The provided flowchart illustrates the processing method of this application, which includes the following processing steps:

[0049] Step 101: When loading the driver of the first external device into the memory of the electronic device, obtain and store the first memory address corresponding to the driver entry point in the memory of the electronic device.

[0050] Optionally, the first external device is an external device that the system BIOS needs to load during the boot process, which may be, but is not limited to, external cards such as graphics cards and network cards.

[0051] During the boot process, the system BIOS loads drivers for external devices, such as expansion cards or UEFI drivers, via the CPU (Central Processing Unit). If these drivers malfunction, it will manifest as a device crash at the UEFI boot node. To facilitate rapid and efficient troubleshooting when a malfunction in the driver causes a device crash at the UEFI boot node, this embodiment first obtains and stores the first memory address corresponding to the driver's entry point in the electronic device's memory at the point when the driver is loaded into the electronic device's memory.

[0052] Specifically, when loading the driver for the first external device, the stored memory pointer information can be obtained from the preset pointer register of the electronic device, the memory address corresponding to the obtained memory pointer information can be used as the first memory address, and the first memory address can be stored in the storage component on the BMC (Baseboard Management Controller) of the electronic device.

[0053] Optionally, the default pointer register is the instruction pointer register IP in the CPU, i.e., CPU IP, and the storage unit on the BMC can be an FFDC (First Failure Data Capture) device set on the BMC.

[0054] Step 102: Determine whether there is any abnormality in the operation of the electronic device with the loaded driver.

[0055] After loading the driver of the first external device into memory, the CPU further runs the driver of the first external device based on the driver code loaded into memory. If the driver of the first external device has software problems, such as Dead Loop or Hang, it will cause the driver to run abnormally. This step determines whether the driver's running process has run abnormally.

[0056] Specifically, this step determines whether the electronic device's operation of the loaded driver has encountered any abnormalities by determining whether the driver operation process of the first external device has been completed within a preset time period.

[0057] Specifically, the system checks whether the driver for the first external device has completed its operation within a preset time period. If so, it returns to the main process of the electronic device, such as the system BIOS. If so, it is determined that the driver for the first external device has not encountered any abnormalities. Otherwise, if not, it is determined that the driver for the first external device has encountered any abnormalities.

[0058] The aforementioned preset duration is at least as long as the overall operation time required for the driver of the first external device to run without any abnormalities. Preferably, the preset duration is a certain value higher than the overall operation time required for the driver of the first external device to run without any abnormalities.

[0059] In practice, when the driver for the first external device is loaded, a timer can be started and triggered to count down for a preset duration, such as 30 to 60 seconds. The timer can then determine whether the driver for the first external device has finished running and whether the system BIOS has returned to normal when the timer ends. If so, the driver for the first external device has not run abnormally; otherwise, an abnormality has occurred.

[0060] Optionally, the timer can be set and managed by the BMC of the electronic device.

[0061] Step 103: If yes, determine and store the second memory address corresponding to the current running progress of the above driver in the memory of the electronic device.

[0062] If an abnormality occurs during the operation of the driver of the first external device, the current running progress of the driver of the first external device is further determined and stored in the second memory address corresponding to the electronic device's memory. Specifically, at the moment when an abnormality is detected, the memory pointer information currently stored in the aforementioned preset pointer register, such as CPU IP, is obtained, and the memory address corresponding to the obtained memory pointer information is used as the second memory address.

[0063] Alternatively, the obtained second memory address can also be stored in the FFDC on the BMC.

[0064] Conversely, if the driver of the first external device does not encounter any abnormalities during operation, there is no need to perform corresponding abnormality analysis and processing. Instead, the stored first memory address can be cleared, and the timer can also be cleared.

[0065] Furthermore, optionally, the system BIOS can notify the BMC to clear the first memory address stored in the FFDC, as well as the clear timer.

[0066] Step 104: Based on the first memory address and the second memory address mentioned above, retrieve and store the corresponding driver code of the above driver from the memory of the electronic device to obtain the target driver code. The target driver code is used to determine the cause of the abnormality that occurred.

[0067] In the event of an anomaly during the operation of the driver for the first external device, after obtaining and storing the first and second memory addresses, the relevant driver code at the time of the anomaly is further retrieved based on the first and second memory addresses, serving as the data basis for subsequent anomaly cause analysis. See also... Figure 2 This process can be specifically implemented as follows:

[0068] Step 201: Determine the target memory region based on the first memory address and the second memory address.

[0069] The identified target memory region is used to locate the driver code when capturing the relevant driver code when the driver of the first external device experiences an operational error.

[0070] Optionally, in one embodiment, a memory region starting at a first memory address and ending at a second memory address can be directly determined as the target memory region.

[0071] However, this is not the only approach. In other embodiments, a certain offset can be made based on the second memory address. That is, the second memory address is offset backward by a preset offset amount, and a memory region with the first memory address as the starting address and the address obtained after the preset offset based on the second memory address as the ending address is determined as the target memory region. In this embodiment, by offsetting the second memory address backward by a preset offset amount and determining the target memory region with the address obtained after the offset based on the second memory address as the ending address, the purpose is to ensure that the driver code located and captured based on the target memory region has a certain degree of redundancy compared to the already running driver code corresponding to the current running progress. Consequently, the captured driver code related to the abnormal operation of the first external device driver is more comprehensive.

[0072] The offset used when offsetting the second memory address can be set based on experience, or adapted to the amount of driver code data of the first external device and the current running progress, so as to ensure that the address obtained after offsetting the second memory address by this offset does not exceed the address corresponding to the end of the driver code.

[0073] Step 202: Obtain the driver code of the first external device in the target memory area, and use it as the target driver code.

[0074] After determining the target memory region, the relevant driver code for runtime exceptions is located based on the target memory region, and the driver code of the first external device in the target memory region is captured as the target driver code.

[0075] Step 203: Store the target driver code to the storage component on the electronic device board management controller.

[0076] The obtained target driver code is then stored in the corresponding storage component of the electronic device's BMC, optionally in the FFDC located on the BMC. That is, in this embodiment, the obtained first memory address, second memory address, and at least a portion of the target driver code are stored in the FFDC located on the BMC.

[0077] The target driver code is the driver code related to the first external device driver when it malfunctions, and it is used for subsequent analysis of the cause of the malfunction.

[0078] In practical applications of this application, the BMC of the electronic device can capture the corresponding memory pointer information and / or driver code through a preset interface. Optionally, the BMC can capture the first memory address, the second memory address, and the relevant driver code (i.e., the target driver code) when the driver of the first external device is abnormal through the JTAG (Joint Test Action Group) interface, and store the captured address information or driver code information in FFDC so that the cause of the abnormality can be located by parsing FFDC and analyzing the target driver code stored therein.

[0079] In summary, the method of this embodiment detects and responds to driver operation abnormal events when loading and running the external device driver. It locates the relevant driver code at the time of the abnormal operation by using the corresponding memory address. Subsequently, the captured driver code at the time of the abnormal operation can be analyzed to locate the problem and analyze the cause of the problem. This facilitates the rapid analysis and location of the cause of the problem when UEFI startup is abnormal, and reduces the manual cost of root cause analysis.

[0080] In one embodiment, see Figure 3 The provided flowchart illustrates the processing method. After determining that an abnormality has occurred during the operation of the driver for the first external device, the processing method disclosed in this application may further include the following steps:

[0081] Step 105: Send a stop command to the preset processor of the electronic device to stop the preset processor from driving the first external device.

[0082] Optionally, the default processor is the CPU of the electronic device.

[0083] When an abnormality is detected in the operation of the driver of the first external device, it indicates that the driver of the first external device, such as the UEFI driver of the external card, has a software problem such as Dead Loop or Hang. In response to this situation, the BMC sends a stop command to the CPU through the aforementioned preset interface, such as the JTAG interface, to indicate that the operation of the driver of the first external device should be stopped.

[0084] The CPU receives and responds to the stop command, stopping the operation of the driver for the first external device, thereby reducing the performance consumption of the device.

[0085] In one embodiment, see Figure 4 The provided processing flowchart indicates that, after obtaining the target driver code, the processing method disclosed in this application may further include the following processing:

[0086] Step 106: Output the target driver code to the second external device so that the second external device can convert the target driver code into preset readable program code and locate the cause of the exception based on the converted preset readable program code.

[0087] See Figure 5 ( Figure 5 The diagram shows the connection between the electronic device and the second external device (NVD represents memory). The second external device is used as a debugging host to provide functions such as exporting, converting, debugging, and analyzing and locating the cause of the abnormality based on the target driver code captured by the BMC of the electronic device (the relevant driver code when the driver of the first external device is running abnormally). The second external device can be, but is not limited to, a personal computer or server computer with a display device, a portable mobile terminal, etc. Optionally, the second external device can be remotely connected to the abnormal electronic device through the network via the network management port (Mgmt).

[0088] Specifically, such as Figure 5 As shown, the second external device can send an export command to the BMC of the electronic device through a plug-in. The BMC of the electronic device receives and responds to the export command, retrieves the target driver code from the FFDC, and outputs it to the second external device. Alternatively, the BMC of the electronic device can also automatically trigger the output of the target driver code to the second external device in response to the capture of the relevant driver code (i.e., the target driver code) in the case of an abnormal operation of the first external device driver. In any of the above methods, the target driver code captured by the BMC of the electronic device in the case of an abnormal operation of the first external device driver can be exported to the second external device.

[0089] Optionally, after obtaining the exported target driver code, the second external device converts it into preset readable program code, such as converting the target driver code in machine code form into assembly code, and at the same time, visualizes and outputs the converted assembly code and other readable program code so that relevant personnel can locate the cause of the abnormality that occurs during the operation of the first external device driver by analyzing and debugging the output readable program code.

[0090] The identified causes of the anomaly include, but are not limited to: device information of the external device that caused the anomaly, and / or at least part of the problem code and problem type in the target driver code that caused the anomaly.

[0091] The device information of the external device may include, but is not limited to, any one or more of the following: device name, device ID, device number, etc. By analyzing the target driver code in the form of readable program code, the name, ID, and other information of the external device that caused the above-mentioned anomaly can be identified. This allows us to pinpoint which specific external device (such as a graphics card or a network card) is experiencing a software anomaly. In addition, by debugging and analyzing the target driver code in the form of readable program code, we can determine the specific problematic code in the target driver code that caused the anomaly and the specific anomaly type corresponding to the problematic code, such as Dead Loop or Hang. This enables us to locate the cause of the anomaly, facilitating subsequent repair of the existing software anomaly. The problem point can be identified without copying the phenomenon, and it is convenient to obtain the specific source code level problem point.

[0092] In other embodiments, optionally, when the BMC of the electronic device captures and stores the first memory address corresponding to the driver entry of the first external device in the electronic device's memory via the JTAG interface, it can also capture and store the slot information of the first external device, such as the slot ID and slot number, in the slot of the electronic device. This is to facilitate the subsequent location of which first external device has a software problem (i.e., driver abnormality) based on the correspondence between the slot and the first external device (e.g., graphics card or network card). This can effectively avoid the situation where the specific external device that has an abnormality cannot be effectively analyzed due to insufficient target driver code data information captured.

[0093] This application also discloses an electronic device, which may be, but is not limited to, a device in a variety of general or special computing device environments or configurations, such as: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, etc.

[0094] The composition and structure of electronic devices, such as Figure 6 As shown, it includes at least:

[0095] Memory 10 is used to store the computer instruction set;

[0096] Computer instruction sets can be implemented in the form of computer programs.

[0097] Processor 20 is configured to implement the processing method disclosed in any of the above method embodiments by executing a computer instruction set.

[0098] The processor 20 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices.

[0099] Electronic devices have a display device and / or have a display interface and can connect to an external display device.

[0100] Optionally, the electronic device may also include a camera assembly, and / or be connected to an external camera assembly.

[0101] In addition to these components, electronic devices may also include communication interfaces, communication buses, and other parts. Memory, processor, and communication interface communicate with each other through the communication bus.

[0102] Communication interfaces are used for communication between electronic devices and other devices. Communication buses can be Peripheral Component Interconnect (PCI) buses or Extended Industry Standard Architecture (EISA) buses, and can be categorized into address buses, data buses, control buses, etc.

[0103] In addition, this application also discloses a storage medium storing at least one set of computer instructions, which, when invoked and executed, are used to implement the processing methods disclosed in any of the above embodiments.

[0104] In summary, the processing method, electronic device, and storage medium disclosed in this application have at least the following technical advantages compared to traditional technologies:

[0105] a. By using BMC to capture CPU IP machine code information when an external device driver malfunctions via the JTAG interface, the relevant driver code when the external device driver malfunctions is obtained and stored in storage components such as FFDC. This allows for subsequent location of the abnormal cause by parsing the captured driver code in FFDC. The problem point can be determined without copying the phenomenon, which facilitates quick and efficient location of the problem cause and reduces the manual cost of root cause analysis.

[0106] b. Since the relevant driver code captured by BMC when the external device driver runs abnormally can be exported via remote connection, it can be applied to both the development process and the client.

[0107] c. By capturing and exporting the relevant driver code when the external device driver malfunctions, source-level debugging and analysis of software problems in the external device driver can be performed, which facilitates more accurate location of the cause of the exception and makes it easier to find the specific source code level problem points.

[0108] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referenced to each other.

[0109] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0110] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0111] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 limitations, 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.

[0112] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A processing method, comprising: When loading the driver of the first external device into the memory of the electronic device, obtain and store the first memory address corresponding to the driver entry point in the memory of the electronic device; Determine whether the electronic device is malfunctioning in response to the drive. If so, determine and store the second memory address corresponding to the current running progress of the driver in the memory of the electronic device; The target memory region is determined based on the first memory address and the second memory address; The driver code of the first external device in the target memory region is obtained as the target driver code, which is used to determine the cause of the exception.

2. The method according to claim 1, wherein when loading the driver of the first external device into the memory of the electronic device, obtaining and storing the first memory address corresponding to the driver entry point in the memory of the electronic device includes: When loading the driver for the first external device, the stored memory pointer information is obtained from the preset pointer register of the electronic device, and the memory address corresponding to the obtained memory pointer information is used as the first memory address. The first memory address is stored in the storage component on the electronic device board management controller.

3. The method according to claim 1, wherein determining whether an abnormality occurs in the operation of the electronic device in response to the drive includes: Determine whether the driving process of the first external device has been completed within a preset time period; If not, then it is determined that the operation of the driver has malfunctioned; If so, then it is determined that the operation of the driver has not encountered any abnormalities.

4. The method according to claim 2, wherein determining and storing the second memory address corresponding to the current running progress of the driver in the memory of the electronic device comprises: When the above-mentioned abnormality occurs, the stored memory pointer information is obtained from the preset pointer register, and the memory address corresponding to the obtained memory pointer information is used as the second memory address; The second memory address is stored in the storage component on the electronic device board management controller.

5. The method according to claim 2, further comprising: The target driver code is stored in the storage component on the electronic device board management controller.

6. The method according to claim 1, wherein determining the target memory region based on the first memory address and the second memory address comprises: The memory region starting at the first memory address and ending at the second memory address is determined as the target memory region; Alternatively, a memory region with the first memory address as the starting address and the address obtained by offsetting the second memory address by a preset offset amount as the ending address is determined as the target memory region.

7. The method according to claim 5, wherein the storage component is a first failure data capture FFDC, and the FFDC stores at least a portion of the information in the first memory address, the second memory address, and the target driver code.

8. The method according to claim 1, further comprising: After the anomaly is determined to have occurred, a stop command is sent to the preset processor of the electronic device to cause the preset processor to stop the operation of the driver for the first external device. And / or, The target driver code is output to a second external device, so that the second external device can convert the target driver code into a preset readable program code and locate the cause of the exception based on the preset readable program code; The identified cause of the anomaly includes: device information of the external device that caused the anomaly, and / or at least part of the problem code and problem type in the target driver code that caused the anomaly.

9. The method according to claim 8, wherein, The baseboard management controller of the electronic device obtains the corresponding memory pointer information or driver code through a preset interface, and / or sends a stop command to the preset processor of the electronic device through the preset interface.

10. An electronic device, comprising: Memory, used to store at least one set of computer instructions; A controller is configured to invoke and execute the instruction set stored in the memory, and to implement the processing method as described in any one of claims 1-9 by executing the instruction set.

Images