Information recording method and apparatus, electronic device, storage medium, program product
By configuring an information logging module in the graphics device driver to replace and simulate function call information, the problem of third-party software being blocked from running is solved, achieving the effect of efficiently obtaining function execution information.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- MOORE THREADS TECH CO LTD
- Filing Date
- 2026-05-11
- Publication Date
- 2026-07-10
AI Technical Summary
In existing technologies, obtaining function execution information through third-party software is inefficient because the third-party software may be blocked from running by security detection mechanisms, resulting in failure to obtain function execution information.
Configure an information logging module in the graphics device driver to replace the function call information in the graphics device management module with simulated function call information, and simulate the execution of function call instructions through the information logging module to record function execution information.
It enables efficient acquisition of function execution information without being blocked by security detection mechanisms, improving the reliability and success rate of API tracing and avoiding the obstacles of traditional DLL injection methods.
Smart Images

Figure CN122363683A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and in particular to an information recording method and apparatus, electronic equipment, computer-readable storage medium, and computer program product. Background Technology
[0002] With the development of computer technology and graphics processing technology, graphics applications running on computers can perform various graphics processing tasks using image devices through function calls. In scenarios such as graphics development, debugging, or performance analysis testing, it is necessary to obtain the function execution information of the graphics application during function calls to facilitate the execution of graphics development, debugging, or performance analysis testing tasks targeting the graphics application.
[0003] Related technologies typically use third-party software to obtain function execution information, but because third-party software may be blocked from running by security detection mechanisms, the efficiency of obtaining function execution information is low. Summary of the Invention
[0004] This disclosure provides an information recording method and apparatus, an electronic device, a computer-readable storage medium, and a computer program product.
[0005] In a first aspect, this disclosure provides an information recording method applied to a terminal. The information recording method includes: when a graphics device driver running on the terminal receives a module creation instruction sent by a graphics application running on the terminal, the graphics device driver creates a graphics device management module for the graphics application; the function call information of the graphics device management module is replaced with simulated function call information obtained from an information recording module; and the simulated function call information is sent to the graphics application. The information recording module is configured in the graphics device driver. When the graphics application generates a function call instruction, the graphics application sends the function call instruction to the information recording module according to the simulated function call information. The information recording module simulates the graphics device management module executing the function call instruction and records function execution information during the execution of the function call instruction.
[0006] Secondly, this disclosure provides an information recording device applied to a terminal, the information recording device comprising: a graphics application running on the terminal, a graphics device driver running on the terminal, and an information recording module configured in the graphics device driver.
[0007] The graphics device driver is configured to, upon receiving a module creation instruction sent by the graphics application, create a graphics device management module for the graphics application, replace the function call information of the graphics device management module with simulated function call information obtained from the information recording module, and send the simulated function call information to the graphics application.
[0008] The graphical application is configured to send the generated function call instruction to the information recording module based on the simulated function call information.
[0009] The information recording module is configured to simulate the graphics device management module executing the function call instruction and record the function execution information during the execution of the function call instruction.
[0010] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to perform the above-described information recording method.
[0011] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described information recording method.
[0012] Fifthly, this disclosure provides a computer program product that includes computer-readable code or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described information recording method.
[0013] The information recording method provided in this disclosure can configure the information recording module in the graphics device driver, avoiding the problem of the information recording module being blocked from running by the application's security detection mechanism, thus enabling the information recording module to load and execute normally. Based on this, when a graphics device management module is created for a graphics application through the graphics device driver running in the terminal, the function call information in the graphics device management module is replaced with simulated function call information obtained from the information recording module, and this simulated function call information is sent to the graphics application, achieving seamless redirection of subsequent function call instructions from the graphics application. The graphics application then sends function call instructions to the information recording module based on the simulated function call information. Finally, through the information recording module running successfully in the graphics device driver, the graphics device management module is simulated to execute the function call instructions, and the function execution information during the execution of the function call instructions is recorded. Therefore, this disclosure overcomes the technical obstacle of traditional DLL (Dynamic Link Library) injection methods failing to capture information due to detection, ensuring the reliability and success rate of API (Application Programming Interface) tracking and recording processes, thereby achieving efficient acquisition of function execution information.
[0014] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0015] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:
[0016] Figure 1 A flowchart of an information recording method provided in an embodiment of this disclosure.
[0017] Figure 2 This is a schematic diagram of the system architecture in an information recording method provided in an embodiment of the present disclosure.
[0018] Figure 3 This is a schematic diagram illustrating the application of an information recording method provided in an embodiment of this disclosure.
[0019] Figure 4 This is a block diagram of an information recording device provided in an embodiment of the present disclosure.
[0020] Figure 5 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation
[0021] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.
[0022] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.
[0023] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.
[0024] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.
[0025] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.
[0026] The information recording method according to embodiments of this disclosure can be executed by an electronic device such as a terminal device or a server. The terminal device can be an in-vehicle device, user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.
[0027] The technical terms used in the embodiments of this disclosure are explained below.
[0028] Windows DirectX 11 applications refer to software developed based on the DirectX 11 graphics interface. These applications optimize performance and graphics by calling the DirectX 11 API (Application Programming Interface). Windows DirectX 11 is primarily used for 3D graphics rendering, multimedia processing, and game development on the Windows platform.
[0029] API Trace: This is detailed information about the DirectX 11 graphics API functions called by the application during runtime, including: the name of the API function being called, the parameters passed in when it is called, the return value, the call timestamp, etc.
[0030] API Hook: refers to intercepting an application's calls to the DirectX 11 runtime API. In the following examples, it can be simply referred to as a hook.
[0031] Warp (Windows Advanced Rasterization Platform) is a high-performance CPU software rasterization driver used to implement full Direct3D functionality on the CPU when a compatible GPU is unavailable or hardware acceleration is disabled.
[0032] D3D11 (Display Driver for Direct3D 11): is a driver component in the Windows Graphics Subsystem that supports the Direct3D 11 API.
[0033] Runtime: refers to the runtime library.
[0034] d3d11.dll is a core dynamic link library file in the Windows operating system. It belongs to the Direct3D 11 runtime component of DirectX 11 and is responsible for handling 3D graphics rendering and multimedia tasks.
[0035] UMD (User-Mode Driver): refers to a driver program that runs in user space and is used to implement the specific execution logic and instruction conversion of the graphics API.
[0036] KMD (Kernel-Mode Driver): refers to a driver program that runs in kernel space and is used to manage GPU hardware resources, manage GPU tasks, and perform other operations.
[0037] User space: This is where ordinary applications run, with limited permissions, and crashes there will not cause a blue screen.
[0038] Kernel space: This is where the operating system kernel runs. It has the highest privileges, and code errors there may cause system crashes (BSOD).
[0039] UMD DDI: is a set of function calling specifications and interface conventions used for communication between the DirectX Runtime and UMD. When an application calls a UMD, UMD DDI specifies how the DirectX runtime (such as d3d11.dll) should call the corresponding function in the UMD.
[0040] DXG Kernel (DirectX Graphics Kernel): This refers to the kernel module, which acts as a bridge between UMD and KMD. It is the core scheduler and resource manager running in kernel space.
[0041] KMD DDI: is a set of callback function tables used to make the DXG Kernel call KMD.
[0042] Dynamic polymorphism refers to the process of determining which function version to call at runtime (rather than at compile time) based on the actual type of the object.
[0043] COM (Component Object Model) refers to a component object model; COM is a cross-language, cross-process, binary-level software component reuse architecture. Its purpose is to enable software modules written in different programming languages to call and collaborate with each other in a standard way, without needing to know each other's internal implementation details.
[0044] D3D11CreateDevice is a function used to initialize the Direct3D 11 runtime environment and create two core objects required for communication with the GPU: Device: an object representing the logical GPU device, responsible for resource creation (such as textures, buffers, and shaders); DeviceContext: a rendering context, responsible for submitting rendering commands (such as drawing and setting states).
[0045] With the development of computer technology and graphics processing technology, graphics applications running on computers can perform various graphics processing tasks using image devices through function calls. In scenarios such as graphics development, debugging, or performance analysis testing, it is necessary to obtain the function execution information of the graphics application during function calls to facilitate graphics development, debugging, or performance analysis testing tasks. Related technologies typically use third-party software to obtain function execution information; however, because third-party software may be blocked by security detection mechanisms, the efficiency of obtaining function execution information is relatively low.
[0046] For capturing API traces (such as function execution information) in Windows DirectX 11 applications (e.g., graphics applications), DLL (Dynamic Link Library) injection technology is generally used. This technology injects a DLL into the target application; the runtime API is then hooked within this DLL. In other words, API tracing is performed at the runtime level. Specifically, the addresses of exported functions are redirected to the Warp function in the DLL. The Warp function then captures the parameters of the Graphics API and serializes them into a trace file. After obtaining the trace file, the parameters of each Graphics API can be recovered through deserialization, allowing for playback.
[0047] With the widespread use of anti-cheat engines, DLL injection may be blocked by these engines. Anti-cheat engines are designed to prevent third-party software from maliciously modifying game data, but many games check for DLL injection. Once an anti-cheat engine detects an unknown DLL attempting to inject into the game, it will prevent it from loading or exit the game directly. Furthermore, most of these anti-cheat engines operate in kernel mode and cannot be easily bypassed. Therefore, in these games, DLLs will not be able to capture the D3D11 API Trace.
[0048] In other words, API trace capture schemes based on DLL injection generally require injecting the DLL used for hooking into the target application; however, DLL injection is easily detected by the target application; at the same time, there are also some methods to detect the hooking of Runtime API; whether the injection fails or the hook fails, the trace cannot be captured.
[0049] Based on this, the present disclosure provides an information recording method and apparatus, an electronic device, a computer-readable storage medium, and a computer program product, as detailed in the following embodiments.
[0050] Figure 1 A flowchart illustrating an information recording method provided in an embodiment of this disclosure. (Refer to...) Figure 1 The method is applied to a terminal and includes steps S11 to S13.
[0051] Step S11: When the graphics device driver running on the terminal receives a module creation instruction sent by the graphics application running on the terminal, the graphics device driver creates a graphics device management module for the graphics application, replaces the function call information of the graphics device management module with simulated function call information obtained from the information recording module, and sends the simulated function call information to the graphics application; the information recording module is configured in the graphics device driver.
[0052] The graphics application can be understood as an application that needs to use a graphics device to draw or generate graphics data (such as screens, images, or image frames); the graphics application can be software developed using the DirectX 11 graphics interface, such as Windows DirectX 11 applications, and the graphics application includes, but is not limited to, game applications, drawing applications, etc.
[0053] A graphics device can be understood as a hardware device used to draw or generate graphics data. For example, a graphics device can be a GPU (graphics processing unit), a CPU, etc.
[0054] A graphics device driver can be understood as a driver program corresponding to a graphics device, such as a GPU driver. The graphics device management module can be understood as a software module within the graphics device driver used to call the graphics device to perform graphics processing. This graphics device management module can be a subroutine, process, class, object, or instance. For example, taking the DirectX series graphics interface as an example, the graphics device management module can include a device object (Device) and a device context object (DeviceContext); taking the OpenGL graphics interface as an example, the graphics device management module can include a rendering context object; taking the Vulkan (a low-overhead, cross-platform graphics and computing application programming interface) graphics interface as an example, the graphics device management module can include a device object (Device) and a command buffer object. Those skilled in the art will understand that different types of graphics interfaces can use different objects as graphics device management modules, and this disclosure does not limit this.
[0055] It should be noted that the graphics application and the graphics device management module running on the terminal can be closely collaborative and interdependent. The graphics device management module can be used for communication and collaboration between the graphics application and the graphics device. Since the graphics device cannot directly understand and process the instructions issued by the graphics application, the graphics application will send the instructions to the graphics device management module. The graphics device management module can receive high-level instructions issued by the graphics application through the interface and "translate" or "convert" these instructions into low-level hardware instructions that the graphics device can understand and execute.
[0056] The module creation command can be understood as an instruction that instructs the graphics device driver to create a graphics device management module; when the graphics device management module is Device and DeviceContext, the module creation command can be the D3D11CreateDevice command.
[0057] The information recording module can be understood as a module used to record function execution information during the execution of function call instructions. This information recording module can be a software module, such as a link library or an application program.
[0058] Function call information can be understood as information used to call functions in the graphics device management module. For example, this function call information can be a pointer, function address, or function identifier. Simulated function call information can be understood as information generated by simulating functions in the graphics device management module, used to forward function call instructions to the information recording module for execution. For example, this simulated function call information can be a pointer (including but not limited to function pointers, object pointers, etc.), function address, or function identifier. Taking the DirectX series graphics interface as an example, this function call information can be a function pointer corresponding to a device object (Device) or device context object (DeviceContext) and recorded in the virtual function table. Taking the OpenGL graphics interface as an example, this function call information can be a function pointer generated or loaded through a loading library.
[0059] It should be noted that in this disclosure, the function call information of the graphics device management module is replaced with simulated function call information obtained from the information recording module of the graphics device driver, so that function calls initiated by the graphics application can be processed by the information recording module. This can be achieved by modifying existing function call information or by directly setting up a new information table containing simulated function call information for the graphics device management module. For example, the function call information is a function pointer, and the simulated function call information is a simulated function pointer corresponding to the function call information; this disclosure can use the simulated function pointer to modify the function pointer and send the modified function pointer to the graphics application; alternatively, it can generate a function pointer array containing simulated function pointers and send the function pointer array to the graphics application.
[0060] In one or more embodiments provided in this disclosure, the graphics device driver can send simulated function call information to the graphics application through a runtime component running in the terminal.
[0061] It should be noted that the graphics device driver provided in this disclosure can be understood as a legitimate running driver, such as a digitally signed driver in an operating system. The signing mechanism confirms that the graphics device driver is released by a trusted manufacturer, rather than a third-party disguised official driver. This graphics device driver will not be blocked from running by security detection mechanisms (such as anti-cheat mechanisms); by configuring the information recording module in the graphics device driver, the information recording module will also not be blocked from running during operation.
[0062] In one or more embodiments provided in this disclosure, the function call information includes a function table, which includes function pointers of functions in the graphics device management module; the simulated function call information includes a simulated function table, which includes function pointers of simulated functions in the information recording module; the functions correspond one-to-one with the simulated functions; the function pointers of the simulated functions are used to forward the function call instructions of the graphics application to the information recording module.
[0063] The function table can be understood as a table used to record function pointers corresponding to functions, and this function table can be an array. The simulated function table can be a table generated by simulating the function table, and this simulated function table includes function pointers of simulated functions. The simulated function is generated by simulating functions (e.g., virtual functions) in the graphics device management module; the simulated function can implement the functionality or operation of the functions in the graphics device management module.
[0064] A function pointer can be understood as a pointer to a function or a simulated function, used to call that function or simulated function.
[0065] In some embodiments, the function may be a virtual function, and the function table may be a virtual function table. A virtual function is a mechanism in object-oriented programming languages (C++) to achieve so-called dynamic polymorphism. The virtual function table is an array of function pointers automatically maintained by the compiler, used to dynamically determine which function implementation to call at runtime. When a class has virtual functions, the compiler hides a pointer (called a virtual table pointer, vptr) in each object of that class, which points to the virtual function table of the corresponding class. Whenever the program calls a virtual function, it actually looks up the corresponding function pointer (i.e., object pointer) in the virtual table through the vptr, and then indirectly jumps to that function for execution. Each object of a class actually shares the same virtual function table (vtable).
[0066] In this scenario, a virtual table hook directly modifies a function pointer in the virtual function table of the target object during the runtime of the graphics application, causing it to point to a developer-defined function (i.e., a simulated function). This way, when the graphics application subsequently calls the virtual function through that object, the control flow is redirected to the custom function, thereby intercepting, monitoring, or extending the original function call behavior and increasing the probability of successful API trace capture.
[0067] Furthermore, DirectX's graphics API is implemented based on COM (Component Object Model) technology, and COM interfaces organize their method calls through virtual function tables. The D3D Runtime communicates with user-mode drivers via DDI (Device Driver Interface). The Windows driver specification stipulates that user-mode drivers must implement a series of DDI function tables so that when an app calls a function provided by the D3D11 Runtime, the code will be executed in the implementation of the respective GPU vendor's driver. This DDI function table is returned to the Runtime by the GPU vendor's driver when the app calls D3D11CreateDevice. At the application layer, these functions are methods of the Device and DeviceContext classes.
[0068] Therefore, the information recording method proposed in this disclosure is a Windows system D3D11 APITrace capture method based on user-mode driver; the D3D11 core object is hooked in the D3D11 user-mode driver (i.e., graphics device driver), which does not require DLL injection and avoids being detected by the application, thereby increasing the probability of successful APITrace capture of Windows DirectX11 applications.
[0069] Step S12: When the graphical application generates a function call instruction, the graphical application sends the function call instruction to the information recording module according to the simulated function call information.
[0070] The function call instruction can be understood as an instruction to call a function in the graphics device management module. In the context of applying this disclosure to an image rendering scenario, the function call instruction can be an image rendering instruction.
[0071] In one or more embodiments provided in this disclosure, the function table is a virtual function table, the function is a virtual function, the simulated function table is a simulated virtual function table, the simulated function is a simulated virtual function, and the simulated virtual function is obtained by simulating the virtual function; the step of sending the function call instruction to the information recording module through the graphics application according to the simulated function call information includes: determining the function pointer of the simulated virtual function corresponding to the function call instruction from the simulated virtual function table through the graphics application, and forwarding the function call instruction to the information recording module according to the function pointer.
[0072] Taking the application of the information recording method provided in this disclosure in the scenario of capturing API traces as an example, this information recording method will be explained. The information recording module can be a Trace Layer library; the graphics application is an APP; the graphics device driver is a GPU vendor driver. Based on this, the GPU vendor driver in this disclosure can load function pointers (i.e., simulated function call information) for capturing traces and perform virtual table hooking on Device and DeviceContext. For the methods of Device and DeviceContext that need to be captured, the function pointer of the method is replaced with the function pointer for capturing traces provided by the Trace Layer library, and then the function pointer for capturing traces is returned to the APP as the function pointer of Device and DeviceContext.
[0073] When an app makes a function call, it generates a corresponding function call instruction, determines the function pointer of the virtual function corresponding to the instruction from the virtual function table, and sends the instruction to the Trace Layer library (the information recording module) based on this pointer. The Trace Layer library can then record API call parameters, achieving efficient API trace capture.
[0074] Step S13: Through the information recording module, simulate the graphics device management module to execute the function call instruction, and record the function execution information during the execution of the function call instruction.
[0075] The function execution information can be understood as the information generated during the execution of a function call instruction. This information includes, but is not limited to, the information carried by the function call instruction, the function name corresponding to the function call instruction, and the function execution result (i.e., return value) corresponding to the function call instruction. For example, the function execution information could be an API Trace.
[0076] In the embodiments provided in this disclosure, the information recording module includes a simulation submodule and an information recording submodule. The simulation submodule is used to simulate the graphics device management module executing the function call instruction. The step of simulating the graphics device management module executing the function call instruction through the information recording module and recording function execution information during the execution of the function call instruction includes: executing the function call instruction according to a simulated function through the simulation submodule, wherein the simulated function is obtained by simulating a function in the graphics device management module; and recording the function execution information during the execution of the function call instruction by the simulation submodule through the information recording submodule and outputting the function execution information.
[0077] The simulation submodule can be understood as a module used to simulate the graphics device management module; the simulation submodule can be a program or process configured in the information recording module.
[0078] The graphics device management module contains multiple functions, objects, or classes. In this case, to capture accurate function execution information, this disclosure uses a simulation submodule to simulate all the multiple functions, objects, or classes implemented by the graphics device management module. For example, this disclosure can write a Trace Layer library that needs to implement all methods of Device and DeviceContext in D3D11, including but not limited to multiple functions, objects, or classes.
[0079] The information logging submodule can be understood as a module used to record function execution information. This information logging submodule can be a program or process configured within the information logging module. For example, during the execution of API calls (i.e., function call instructions) using the simulation submodule, the information logging submodule can record the API trace of the API call in each method.
[0080] Specifically, after the graphics application sends the function call instruction to the information recording module based on the simulated function call information, the simulation submodule in the information recording module can execute the function call instruction sent by the graphics application through the simulated function. During the operation of the simulation submodule, the information recording submodule in the information recording module can record the function execution information during the execution of the function call instruction; that is to say, the simulation submodule and the information recording submodule can run in parallel.
[0081] After recording the function execution information, this information recording submodule also outputs the function execution information.
[0082] In the embodiments provided in this disclosure, after recording the function execution information, the information recording submodule can directly send the function execution information to the information acquisition module; or, upon receiving an information acquisition request from the information acquisition module, it can send the function execution information to the information acquisition module.
[0083] This information acquisition module can be understood as a module in the terminal used to acquire function execution information. For example, this information acquisition module can be a hardware module such as a database, memory, or display device, or a software module such as an information analysis application (used to analyze function execution information) running in the terminal.
[0084] As can be seen from the above embodiments, this disclosure achieves non-intrusive monitoring and recording of function call behavior in graphics applications. Graphical applications do not need to modify existing code or embed additional third-party logic; they can trigger the information recording module and record data simply by "simulating function call information," improving the completeness and accuracy of function execution information collection. Furthermore, by using a simulation submodule to replace real function execution, interference with the original system operation is avoided, while preserving the complete call context.
[0085] In the embodiments provided in this disclosure, the information recording module is a static link library, the function call instruction is an image rendering instruction, and the simulation function is a simulated image rendering function. The step of simulating the graphics device management module's execution of the function call instruction through the information recording module, and recording function execution information during the execution of the function call instruction, includes: executing the image rendering instruction according to the simulated image rendering function through the simulation submodule; and recording function execution information during the execution of the image rendering instruction by the simulation submodule through the information recording submodule.
[0086] Using the previous example, the APP can receive function pointers to Device and DeviceContext returned by Runtime (i.e., runtime component); when image rendering is required, the APP will generate an API call to perform image rendering, and use the function pointer returned by Runtime to forward the API call to the Trace Layer library, thereby entering the implementation of TraceLayer.
[0087] The Trace Layer library can implement all rendering methods of the graphics device management module. In this case, after receiving an API call, the Trace Layer library can execute the API call through the functions in the Trace Layer library; and record the API Trace during the execution of the API call.
[0088] As can be seen from the above embodiments, this disclosure does not require modification of the original rendering logic of the graphics application. It can automatically route all graphics API calls to the Trace Layer simply by using the function pointer returned by the Runtime (which actually points to the object encapsulated by the Trace Layer). Since the Trace Layer fully implements all rendering methods of the graphics device management module, it can accurately understand and process various API calls (such as creating textures, binding framebuffers, drawing commands, etc.), thereby capturing complete function execution information such as call chains, parameters, resource status, and execution sequence during execution.
[0089] In the embodiments provided in this disclosure, the method further includes: when the information recording module completes the execution of the function call instruction, sending the function call instruction to the graphics device driver through the information recording module; and through the graphics device driver, executing the function call instruction according to the graphics device management module to obtain the function execution result, and sending the function execution result to the graphics application.
[0090] The execution result of the function can be understood as the result obtained after executing the function call instruction. The execution result of the function can be a rendered image, a drawn graphic, etc., and this disclosure does not impose any specific limitations. In some embodiments, the execution result of the function can be the return value corresponding to the function call instruction.
[0091] In some embodiments, when the information recording module completes the execution of the function call instruction, the information recording module sends the function call instruction to a runtime component running in the terminal; the runtime component then sends the function call instruction to the graphics device driver.
[0092] As can be seen from the above embodiments, this disclosure can achieve complete recording of graphics rendering behavior without modifying the source code of the graphics application, significantly reducing integration costs and system coupling. After the information recording module completes the information recording, it will send the function call instruction to the graphics device driver for execution, thereby avoiding interference with the original system operation and ensuring the smooth execution of the function call.
[0093] In some embodiments, the graphics device driver is a user-mode graphics device driver, and the terminal also runs a kernel-mode graphics device driver and a runtime component. The step of executing the function call instruction according to the graphics device management module via the graphics device driver, obtaining the function execution result, and sending the function execution result to the graphics application includes: generating a command to be executed based on the function call instruction and the function corresponding to the function call instruction through the graphics device management module in the user-mode graphics device driver, and submitting the command to be executed to the kernel-mode graphics device driver through a system call interface; calling the graphics device to execute the command to be executed through the kernel-mode graphics device driver, obtaining the function execution result corresponding to the function call instruction, and returning the function execution result to the user-mode graphics device driver; and returning the function execution result to the graphics application through the user-mode graphics device driver and the runtime component.
[0094] User-mode graphics device drivers can be understood as graphics device drivers configured in the user space of the system, such as vendor GPU drivers; kernel-mode graphics devices can be understood as graphics device drivers configured in the kernel space of the system, such as KMD (kernel-mode driver); runtime components can be understood as runtime libraries configured in the system, such as WindowsRuntime (d3d11.dll).
[0095] Following the example above, Figure 2 This is a schematic diagram of the system architecture in an information recording method provided in an embodiment of this disclosure, based on Figure 2 It is known that for DirectX applications on the Windows operating system (such as...) Figure 2 AppA and AppB in the document were both developed using the DirectX API. DirectX can be a collection of multimedia application programming interfaces (APIs) used to handle tasks related to data such as graphics.
[0096] When an application needs to make API calls during runtime, the API call instructions first enter the implementation of the Trace Layer library. Then, the Trace Layer library calls the Windows Runtime (such as d3d11.dll) to enter the Runtime implementation. Figure 2The D3D Runtime (i.e., Direct3D Runtime) in this context can be a Direct3D software layer running in user space, implemented by DLLs (such as d3d11.dll and d3d12.dll). d3d11.dll is a runtime library file that provides the implementation of the graphics API to support GPU graphics rendering; d3d12.dll is another runtime library file that also provides the implementation of the graphics API. Figure 2 In the context of dxgi.dll, it is the DirectX graphics infrastructure, responsible for managing the underlying graphics devices.
[0097] Then, d3d11.dll responds to the API call instruction by calling UMD (user-mode driver), thereby entering the GPU manufacturer's user-mode driver. UMD converts the API call instruction and the corresponding function into commands that the GPU can execute (i.e., commands to be executed), and provides the commands to KMD through the system call interface, thereby calling KMD (kernel-mode driver) for processing. Finally, KMD calls the hardware device (i.e., the GPU) to perform rendering and obtain the rendering result (i.e., the function execution result).
[0098] KMD provides the rendering results to UMD, which in turn calls d3d11.dll to return the rendering results to the application, thus completing an API call for image rendering.
[0099] in, Figure 2 UMD DDI, DXG Kernel, and KMD DDI are tools used to transmit data or instructions in the above call chain.
[0100] As can be seen from the above embodiments, after the information recording module completes the information recording, the present disclosure can send the function call instruction to the user-mode graphics device driver for execution. The user-mode graphics device driver can realize the rendering call of the graphics application by calling the kernel-mode graphics device driver and the graphics device hardware, thereby achieving the goal of avoiding interference with the original system operation while recording function execution information and ensuring the smooth execution of function calls.
[0101] The information recording method provided in this disclosure can configure the information recording module in the graphics device driver, avoiding the problem of the information recording module being blocked from running by the application's security detection mechanism, thus enabling the information recording module to load and execute normally. Based on this, when a graphics device management module is created for a graphics application through the graphics device driver running in the terminal, the function call information in the graphics device management module is replaced with simulated function call information obtained from the information recording module, and this simulated function call information is sent to the graphics application, achieving seamless redirection of subsequent function call instructions from the graphics application. The graphics application then sends function call instructions to the information recording module based on the simulated function call information. Finally, through the information recording module running successfully in the graphics device driver, the graphics device management module is simulated to execute the function call instructions, and the function execution information during the execution of the function call instructions is recorded. Therefore, this disclosure overcomes the technical obstacle of traditional DLL (Dynamic Link Library) injection methods failing to capture information due to detection, ensuring the reliability and success rate of API (Application Programming Interface) tracking and recording processes, thereby achieving efficient acquisition of function execution information.
[0102] Taking the application of the information recording method provided in this disclosure in the scenario of capturing API traces as an example, this information recording method is explained and illustrated. Figure 3 This is a schematic diagram illustrating the application of an information recording method provided in an embodiment of this disclosure.
[0103] based on Figure 3 As can be seen from the content, the information recording method provided in this disclosure is in Figure 3 After the APP calls D3D11CreateDevice for the first time, and before the user-mode driver returns the pointers to Device and DeviceContext, the virtual table Hook is performed on Device and DeviceContext in the user-mode driver (UMD). The overall process steps include steps 1 to 8.
[0104] Step 1: After the graphics application (APP) starts, it sends the D3D11CreateDevice command to the UMD.
[0105] Step 2: When the graphics application (APP) initiates D3D11CreateDevice, the D3D11CreateDevice instruction first enters the Runtime implementation; the Runtime adjusts the D3D11CreateDevice to the D3D11CreateDevice_rt instruction, and sends the D3D11CreateDevice_rt instruction to the UMD through the OpenAdapter interface, thus entering the GPU manufacturer's implementation.
[0106] Step 3: The GPU vendor driver performs virtual table hooking on the created Device and DeviceContext.
[0107] The specific implementation steps include:
[0108] 1. Based on the D3D11CreateDevice instruction, create a Device and a DeviceContext. The Device and DeviceContext have corresponding pointers that point to the functions in the Device and DeviceContext.
[0109] 2. Load the function pointers used to capture traces before the GPU vendor driver returns pointers to Runtime Device and DeviceContext.
[0110] Specifically, the GPU manufacturer's driver links and loads TraceLayer.lib, and obtains the function address (i.e., function pointer) used to capture traces by calling the GetDispatchTable function.
[0111] It should be noted that in the process of capturing API traces of Windows D3D11 applications, the first step is to write a Trace Layer library. This Trace Layer library needs to implement all methods of Device and DeviceContext in D3D11. In other words, this Trace Layer library needs to simulate all functions in Device and DeviceContext so that it can execute the captured API calls and record the corresponding API traces.
[0112] The Trace Layer library needs to provide a GetDispatchTable function for user-space drivers to call function pointers to capture traces. To avoid being detected by loading dynamic link libraries, Trace Layer can be compiled into a static library (.lib). That is to say, Trace Layer can be provided as a static link library (lib).
[0113] 3. The GPU vendor driver will hijack the required Device and DeviceContext methods (corresponding to multiple functions), and replace the function pointers of the functions included in the virtual table (VTable) of the method with the function pointers of the Trace capture, thereby facilitating the subsequent implementation of pointing to the Trace Layer.
[0114] 4. After completing the pointer replacement, the GPU vendor driver will use the function pointers of the captured Trace as function pointers for objects such as Device and DeviceContext, and return them to the Runtime.
[0115] The above steps can be understood as Figure 3 The VTableHook in the code is for Device / DeviceContext. This means that after the application calls D3D11CreateDevice, it enters the UMD, and the UMD uses a virtual table hook to intercept the implementations of the methods in the Device and Context classes and redirect them to the function implementations in Trace Layer.lib. This operation replaces the original method (that is, sending unreplaced function pointers to the Runtime).
[0116] Step 4: When rendering is required, the APP generates an API call instruction and uses the function pointers of the Device and DeviceContext objects returned by the Runtime to send the API call instruction to the Trace Layer library.
[0117] Specifically, after performing virtual table hooking in the user-space driver, all methods of Device and DeviceContext can be pointed to the implementation (i.e., functions) in Trace Layer; therefore, the API used for rendering in the application will first enter Trace Layer.lib.
[0118] Among them, based on Figure 3 It is understood that the APP disclosed herein can be a D3D11 graphics application running in the terminal, which includes CreateTexture2D_app (a function call for creating a 2D texture in the application layer), CreateBuffer_app (a function call for creating a buffer in the application layer), and Draw_app (a function call for drawing in the application layer).
[0119] Step 5: After receiving the API call instruction sent by the APP, the Trace Layer will execute the API call instruction through the function corresponding to the method configured by itself, and record the API call information during the execution of the API call instruction, thereby obtaining the API Trace file.
[0120] In other words, the implementation of the Trace Layer can record API call parameters, thereby achieving the purpose of capturing API traces.
[0121] based on Figure 3It can be seen that the API Trace includes CreateTexture2D_trace (the trace corresponding to the application of creating 2D textures), CreateBuffer_trace (the trace corresponding to the application of creating buffers), and draw_trace (the trace corresponding to the application of drawing).
[0122] Step 6: The Trace Layer library sends the API call instructions to the Runtime.
[0123] It should be noted that the purpose of the Trace Layer in executing API call instructions is to simulate the behavior of the original function to trigger information recording, but it does not possess complete graphics rendering capabilities itself. To ensure that the graphics application can render correctly and obtain the correct execution results, after executing and recording, the Trace Layer needs to forward the same API call instructions to the Runtime to enter the standard graphics processing flow.
[0124] Specifically, to ensure that the application can render correctly, after capturing the API Trace, the Trace Layer library's implementation still needs to call the Runtime implementation.
[0125] By calling the Runtime function of the same name, the API call instruction is sent to the Runtime, thereby entering the Runtime implementation.
[0126] Step 7: After receiving the API call instruction, the runtime will adjust the API call instruction and send it to the GPU vendor driver, thereby calling the GPU vendor driver's implementation to execute the API call instruction.
[0127] based on Figure 3 It is known that the API call instructions sent by the Runtime to the GPU manufacturer's driver include: CreateTexture2D_rt (API call instruction corresponding to the application of creating 2D textures), CreateBuffer_rt (API call instruction corresponding to the application of creating buffers), and Draw_rt (API call instruction corresponding to the application of drawing).
[0128] Step 8: After receiving the API call instruction, the GPU vendor driver will execute the API call instruction through the kernel-mode driver and the GPU, obtain the execution result corresponding to the API call instruction, and return the execution result to the APP.
[0129] in, Figure 3The CreateTexture2D_ddi, CreateBuffer_ddi, and Draw_ddi functions are the interface functions for the API call instructions implemented by the GPU manufacturer's driver for creating 2D textures (corresponding to CreateTexture2D_ddi), creating buffers (corresponding to CreateBuffer_ddi), and drawing (corresponding to Draw_ddi).
[0130] Based on the above steps, it can be seen that the information recording method disclosed herein is a user-mode driver-based method for capturing DirectX 11 application API traces. This method does not use traditional DLL injection techniques, but captures the API traces of Windows D3D11 applications based on user-mode drivers, avoiding application detection of DLL injection and greatly improving the success rate of capturing Windows D3D11 API traces. In other words, based on user-mode drivers, it can avoid being detected as malware by anti-cheat engines during the loading of dynamic link libraries, thereby enabling safe and reliable capture of API trace information.
[0131] In other words, this disclosure proposes a Windows system D3D11 API Trace capture method based on user-mode driver. It performs virtual table hooking on D3D11 core objects in the D3D11 user-mode driver, without the need for DLL injection, thus avoiding detection by the application and increasing the probability of successful API Trace capture for Windows DirectX11 applications.
[0132] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.
[0133] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.
[0134] In addition, this disclosure also provides information recording devices, electronic devices, and computer-readable storage media, all of which can be used to implement any of the information recording methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding section of the method, and will not be repeated here.
[0135] Figure 4 This is a block diagram of an information recording device provided in an embodiment of the present disclosure.
[0136] Reference Figure 4 This disclosure provides an information recording device applied to a terminal. The information recording device includes: a graphics application 401 running on the terminal, a graphics device driver 402 running on the terminal, and an information recording module 403 configured in the graphics device driver 402.
[0137] The graphics device driver 402 is configured to, upon receiving a module creation instruction sent by the graphics application 401, create a graphics device management module for the graphics application 401, replace the function call information of the graphics device management module with simulated function call information obtained from the information recording module 403, and send the simulated function call information to the graphics application 401.
[0138] The graphics application 401 is configured to send the generated function call instruction to the information recording module 403 based on the simulated function call information.
[0139] The information recording module 403 is configured to simulate the graphics device management module executing the function call instruction and record the function execution information during the execution of the function call instruction.
[0140] In some embodiments, the information recording module 403 is further configured to send the function call instruction to the graphics device driver 402 after the function call instruction has been executed; the graphics device driver 402 is further configured to execute the function call instruction through the graphics device management module, obtain the function execution result, and send the function execution result to the graphics application 401.
[0141] In some embodiments, the function call information is a function table, which includes function pointers of functions in the graphics device management module; the simulated function call information is a simulated function table, which includes function pointers of simulated functions in the information recording module 403; the functions correspond one-to-one with the simulated functions; the function pointers of the simulated functions are used to forward the function call instructions of the graphics application 401 to the information recording module 403.
[0142] In some embodiments, the function table is a virtual function table, the function is a virtual function, the simulated function table is a simulated virtual function table, the simulated function is a simulated virtual function, and the simulated virtual function is obtained by simulating the virtual function; the graphics application 401 is also configured to generate the function call instruction, determine the function pointer of the simulated virtual function corresponding to the function call instruction from the simulated virtual function table, and forward the function call instruction to the information recording module 403 according to the function pointer.
[0143] In some embodiments, the graphics device driver 402 is a user-mode graphics device driver 402, and the system further includes a kernel-mode graphics device driver and a runtime component; the user-mode graphics device driver 402 is further configured to generate an executable command based on the function call instruction and the function corresponding to the function call instruction through the graphics device management module in the user-mode graphics device driver 402, and submit the executable command to the kernel-mode graphics device driver through a system call interface; the kernel-mode graphics device driver is configured to call the graphics device to execute the executable command, obtain the function execution result corresponding to the function call instruction, and return the function execution result to the user-mode graphics device driver 402; the user-mode graphics device driver 402 is further configured to return the function execution result to the graphics application 401 according to the runtime component.
[0144] In some embodiments, the information recording module 403 includes a simulation submodule and an information recording submodule. The simulation submodule is configured to simulate the graphics device management module executing the function call instruction. The simulation submodule is configured to execute the function call instruction by simulating a function, wherein the simulated function is obtained by simulating a function in the graphics device management module. The information recording submodule is configured to record function execution information during the process of the simulation submodule executing the function call instruction and output the function execution information.
[0145] In some embodiments, the information recording module 403 is a static link library, the function call instruction is an image rendering instruction, and the simulation function is a simulated image rendering function; the simulation submodule is configured to execute the image rendering instruction through the simulated image rendering function; the information recording submodule is configured to record function execution information during the process of the simulation submodule executing the image rendering instruction.
[0146] The information recording device provided in this embodiment can configure the information recording module 403 in the graphics device driver 402, avoiding the problem that the information recording module 403 is blocked from running by the application's security detection mechanism, thus enabling the information recording module 403 to load and execute normally. Based on this, when a graphics device management module is created for a graphics application 401 through the graphics device driver 402 running in the terminal, the function call information in the graphics device management module is replaced with simulated function call information obtained from the information recording module 403, and this simulated function call information is sent to the graphics application 401, achieving seamless redirection of subsequent function call instructions from the graphics application 401. The graphics application 401 then sends function call instructions to the information recording module 403 according to the simulated function call information. Finally, through the information recording module 403 running smoothly in the graphics device driver 402, the graphics device management module is simulated to execute the function call instructions, and the function execution information during the execution of the function call instructions is recorded. Therefore, this disclosure overcomes the technical obstacle of traditional DLL (Dynamic Link Library) injection methods failing to capture data due to detection, ensuring the reliability and success rate of API (Application Programming Interface) tracking and recording process, thereby achieving efficient acquisition of function execution information.
[0147] The above is an illustrative scheme of an information recording device according to this embodiment. It should be noted that the technical solution of this information recording device and the technical solution of the information recording method described above belong to the same concept. For details not described in detail in the technical solution of the information recording device, please refer to the description of the technical solution of the information recording method described above.
[0148] Figure 5 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.
[0149] Reference Figure 5 This disclosure provides an electronic device, which includes: at least one processor 501; at least one memory 502; and one or more I / O interfaces 503 connected between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs that can be executed by the at least one processor 501, and the one or more computer programs are executed by the at least one processor 501 to enable the at least one processor 501 to perform the above-described information recording method.
[0150] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the information recording method described above. The computer-readable storage medium may be volatile or non-volatile.
[0151] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described information recording method.
[0152] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).
[0153] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0154] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.
[0155] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.
[0156] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.
[0157] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0158] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0159] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0160] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0161] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.
Claims
1. An information recording method, characterized in that, Applied to a terminal, the method includes: When the graphics device driver running on the terminal receives a module creation instruction sent by the graphics application running on the terminal, it creates a graphics device management module for the graphics application through the graphics device driver, replaces the function call information of the graphics device management module with simulated function call information obtained from the information recording module, and sends the simulated function call information to the graphics application. The information recording module is configured in the graphics device driver. When the graphical application generates a function call instruction, the graphical application sends the function call instruction to the information recording module according to the simulated function call information. The information recording module simulates the graphics device management module executing the function call instruction and records the function execution information during the execution of the function call instruction.
2. The method according to claim 1, characterized in that, The method further includes: When the information recording module completes the execution of the function call instruction, the function call instruction is sent to the graphics device driver through the information recording module. The graphics device driver executes the function call instruction according to the graphics device management module, obtains the function execution result, and sends the function execution result to the graphics application.
3. The method according to claim 1, characterized in that, The function call information includes a function table, which includes function pointers to functions in the graphics device management module. The simulated function call information includes a simulated function table, which includes function pointers to simulated functions in the information recording module. Each function corresponds one-to-one with the simulated function. The function pointer of the simulation function is used to forward the function call instruction of the graphics application to the information recording module.
4. The method according to claim 3, characterized in that, The function table is a virtual function table, the function is a virtual function, the simulated function table is a simulated virtual function table, the simulated function is a simulated virtual function, and the simulated virtual function is obtained by simulating the virtual function; The step of sending function call instructions to the information recording module based on the simulated function call information through the graphical application includes: The graphical application determines the function pointer of the simulated virtual function corresponding to the function call instruction from the simulated virtual function table, and forwards the function call instruction to the information recording module according to the function pointer.
5. The method according to claim 2, characterized in that, The graphics device driver is a user-mode graphics device driver, and the terminal also runs a kernel-mode graphics device driver and runtime components. The step of executing the function call instruction according to the graphics device management module through the graphics device driver, obtaining the function execution result, and sending the function execution result to the graphics application includes: The graphics device management module in the user-mode graphics device driver generates a command to be executed based on the function call instruction and the function corresponding to the function call instruction, and submits the command to be executed to the kernel-mode graphics device driver through the system call interface; The kernel-mode graphics device driver invokes the graphics device to execute the command to be executed, obtains the function execution result corresponding to the function call instruction, and returns the function execution result to the user-mode graphics device driver. The user-mode graphics device driver returns the function execution result to the graphics application based on the runtime component.
6. The method according to claim 1, characterized in that, The information recording module includes a simulation submodule and an information recording submodule. The simulation submodule is used to simulate the graphics device management module executing the function call instruction. The step of simulating the graphics device management module executing the function call instruction through the information recording module and recording function execution information during the execution of the function call instruction includes: The simulation submodule executes the function call instruction according to the simulation function, wherein the simulation function is obtained by simulating the function in the graphics device management module; The information recording submodule records the function execution information during the execution of the function call instruction by the simulation submodule, and outputs the function execution information.
7. The method according to claim 6, characterized in that, The information recording module is a static link library, the function call instruction is an image rendering instruction, and the simulation function is a simulated image rendering function; The step of simulating the graphics device management module executing the function call instruction through the information recording module and recording function execution information during the execution of the function call instruction includes: The simulation submodule executes the image rendering instructions according to the simulated image rendering function. The information recording submodule records function execution information during the process of the simulation submodule executing the image rendering instructions.
8. An information recording device, characterized in that, The device, applied to a terminal, includes: a graphics application running on the terminal, a graphics device driver running on the terminal, and an information recording module configured in the graphics device driver; The graphics device driver is configured to, upon receiving a module creation instruction sent by the graphics application, create a graphics device management module for the graphics application, replace the function call information of the graphics device management module with simulated function call information obtained from the information recording module, and send the simulated function call information to the graphics application. The graphics application is configured to send the generated function call instruction to the information recording module based on the simulated function call information; The information recording module is configured to simulate the graphics device management module executing the function call instruction and record the function execution information during the execution of the function call instruction.
9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program, when executed by a processor, implements the method as described in any one of claims 1-7.
11. A computer program product, characterized in that, Includes computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the method as described in any one of claims 1-7.