A method of locating dynamic runtime library loading exceptions

Abstract

The application discloses a method for positioning dynamic runtime library loading exception, which comprises the following steps: initializing and starting monitoring the loading library process in a program, setting the monitoring search dynamic runtime library DLL process, and setting the monitoring process of loading the dynamic runtime library DLL library, in the monitoring loading process, according to different user environment conditions, the search dynamic library process and the dynamic library real-time loading process conditions are recorded in real time, because of the dynamic monitoring, the method is fully compatible with the complex conditions under different user environments, does not need to traverse all environment variable paths, is compatible with dynamically changing environment variables, is not affected by program or system environment changes, can analyze the infinite level of call relationship, has higher compatibility and stability, does not need to analyze the user environment separately, does not need remote, and is more beneficial for developers to analyze the abnormal problems under the user environment.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method for locating dynamic runtime library loading anomalies. Background Technology

[0002] Currently, the common practice in the software industry is to use Microsoft's dumpbin and depends tools to add DLLs to the program directory. This approach works by analyzing the import table of each DLL and identifying the libraries it depends on. While dumpbin and depends can view the dependencies of dependent DLL files and place all dependent DLLs in the same directory as the program, this approach is unsustainable in multi-user development or when using different third-party libraries. It makes it impossible to control when each DLL is loaded, thus hindering the analysis of loading failures in complex environments.

[0003] Furthermore, the dynamic library loading process is affected by the user's computer environment variable directories and files in the system directory. This static analysis cannot determine the loading failure problem in a real-world scenario. This situation typically occurs when loading A.dll, which depends on B.dll, which in turn depends on C.dll, and C.dll depends on D.dll, creating a multi-level dependency relationship. Because Windows loads DLLs that depend on other DLLs, it searches multiple directories in the Path environment variable. When multiple directories contain DLL files with the same filename, it loads the directory whose filename appears first in the search path. If the DLL version in this directory is inconsistent with the expected version, loading will fail. For developers, the only error they receive is the one returned by loading the first A.dll, indicating a failure to load the entire process that includes A.dll imports. Such error messages cannot pinpoint the specific problem, the environment path situation, or library conflicts.

[0004] In addition, the search directory is also affected by the developer's current environment variable directory. However, the current working directory and the environment variable directory are not fixed and can change with the program. This makes things more complicated in a real user's environment, and error logs cannot accurately locate the problem.

[0005] Therefore, how to help developers analyze abnormal issues in the user environment has become a technical problem that urgently needs to be solved.

[0006] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0007] The main objective of this invention is to provide a method for locating dynamic runtime library loading exceptions, aiming to help developers analyze exception problems in the user environment.

[0008] To achieve the above objectives, the present invention provides a method for locating dynamic runtime library loading exceptions, the method comprising the following steps:

[0009] Perform the operation of initializing the monitoring loading library in the program;

[0010] Create a procedure function to monitor the search path for dynamic runtime library (DLL) and a procedure function to monitor the path where dynamic runtime library (DLL) is being loaded.

[0011] The process function that monitors and searches for the path of the dynamic runtime library (DLL) and the process function that monitors the loading of the path of the dynamic runtime library (DLL) pushes the information stack data of the absolute path of the global runtime library file.

[0012] Iterate through the data in the information stack of the absolute paths of the global runtime library files mentioned above, and read the absolute paths of the DLLs in order;

[0013] Get the version information of the dynamic runtime library (DLL) file, and read the version number corresponding to the version information of the dynamic runtime library (DLL) file based on the file version information function;

[0014] Compare the preset library versions and paths to determine any abnormal runtime library loading conditions.

[0015] Preferably, the operation of initializing the monitoring loading library in the program includes:

[0016] Obtain the module handle address of Ntdll.dll, wherein the module handle address of Ntdll.dll is obtained in the process function of loading dynamic libraries during initialization monitoring;

[0017] The procedure function that exports the address of a specified function is obtained through the Ntdll.dll module handle. The procedure function that exports the address of a specified function includes the procedure function that queries file attributes and the procedure function that opens the file.

[0018] Read the address of the original NT kernel procedure function, and save the procedure function with the exported function address into the global address variable of the NT kernel procedure function address;

[0019] By reading the process memory function, the header 8 bytes of the global address variable of the NT kernel process function address are read, and the 8 bytes are saved into the original NT kernel process function's global byte array variable.

[0020] Preferably, the process function for creating a monitoring and searching dynamic runtime library (DLL) path includes:

[0021] Create a function flow that captures information about the path of a dynamically linked runtime library (DLL), where the information function includes a structure containing object attributes and basic file information;

[0022] Replace the created procedure function that monitors and searches for the path of a dynamic runtime library (DLL) with a procedure function in the process space that queries the properties of a specified file object.

[0023] Determine whether a signal for obtaining file object attributes has been triggered. If the signal for obtaining file object attributes has been triggered, capture and extract the complete path information of the searched dynamic runtime library (DLL) file.

[0024] Preferably, the process function for creating a monitoring and searching dynamic runtime library (DLL) path further includes:

[0025] Get the length of the object's attribute information, check if it is empty, and if not empty, extract the complete path;

[0026] Retrieves a string pointer to the handle object name from an object property;

[0027] Read the contents from the string buffer, where the contents are the path the program is currently searching for in the dynamic runtime library (DLL);

[0028] Concatenate the full path of the currently searched dynamic runtime library (DLL);

[0029] The retrieved content is pushed onto the stack and written to the information stack of the absolute path of the global runtime library file.

[0030] Preferably, the process function for creating a monitoring and searching dynamic runtime library (DLL) path further includes:

[0031] Read the function address that was already stored in the global address variable of the procedure function for querying file attributes in the NT kernel during the initialization of the monitoring and loading library in the program, and the 8-byte array of the global byte array variable of the original procedure function for querying file attributes in the NT kernel;

[0032] The 8-byte array, which is backed up in the global byte array variable, is written to the function address in the global address variable for restoration.

[0033] Calling the NT kernel's function to query file attributes;

[0034] Continue executing the function flow that monitors and searches for information about the paths of dynamic runtime libraries (DLLs).

[0035] Preferably, the process of starting the monitoring and searching for dynamic runtime libraries (DLLs) includes: assigning and replacing the newly created process function for monitoring and searching for DLL paths to the address of the original process function for checking NT kernel file attribute queries. This assignment and replacement process includes:

[0036] Set an 8-byte jump instruction buffer array;

[0037] Fill the address of the procedure function created for monitoring and searching the path of the dynamic runtime library (DLL) into the jump instruction buffer after the first byte.

[0038] The address of the process function that monitors and searches for the path of the dynamic runtime library (DLL) is assigned to the register;

[0039] The jump instruction jumps to the address of the procedure function that searches the register for the path of the dynamic runtime library (DLL);

[0040] The process involves monitoring and traversing the path of dynamic runtime libraries (DLLs) and recording related information.

[0041] Preferably, the process function for creating a monitoring tool that is loading a dynamic runtime library (DLL) includes:

[0042] Create a function flow that captures and monitors the full path of a dynamically loaded DLL. This information function includes a pointer to a structure containing information such as the file operation handle, file access type, object attributes, file operation and completion status, file shared access type, and operation options when opening the file.

[0043] Replace the newly created process function that is monitoring the path of the dynamic runtime library DLL with the address of the original NT kernel process function that opens a file in the process space.

[0044] Determine whether the signal for opening a dynamic runtime library (DLL) file object handle operation is triggered. If the signal for opening a dynamic runtime library (DLL) file object handle operation is triggered, capture and extract the full path information of the currently loading dynamic runtime library (DLL).

[0045] Preferably, the process function for creating a monitoring tool that is loading a dynamic runtime library DLL further includes:

[0046] Get the length of the object information, check if it is empty, and if not empty, extract the complete path;

[0047] Retrieve a string pointer to the handle object name from the object information;

[0048] Read content from the buffer of the character string, where the content of the buffer of the character string includes the program directory, the system directory, the system directory system32, or the path under the environment variable Path;

[0049] Concatenate the full path to the name of the currently loaded dynamic runtime library (DLL);

[0050] The retrieved content is pushed onto the stack and written to the information stack of the absolute path of the global runtime library file.

[0051] Preferably, the process function for creating a monitoring tool that is loading a dynamic runtime library DLL further includes:

[0052] Read the function address that was already saved in the global address variable of the NT kernel file opening procedure function during the initialization of the monitoring loading library in the program, and the 8-byte array of the global byte array variable of the original NT kernel file opening procedure function;

[0053] Write the 8 bytes stored in the global address variable backup to the global address variable for restoration;

[0054] Calling the NT kernel's function to open a file;

[0055] Continue executing the function flow that monitors the full path of the runtime DLL being loaded.

[0056] Preferred options also include:

[0057] Read the function address in the global address variable of the procedure function for querying file attributes and opening files in the NT kernel, which was already saved in the operation of initializing the monitoring and loading library in the program, and the 8-byte array of the global byte array variable of the original NT kernel procedure function for opening files;

[0058] The function that writes to the process's memory region writes the 8 bytes stored in the backup of the global address variable to the function address of the global byte array variable.

[0059] Restore the original NT kernel's function flow for querying and opening file attributes.

[0060] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a program for dynamically detecting and quickly locating runtime library loading anomalies. When the program for dynamically detecting and quickly locating runtime library loading anomalies is executed by a processor, it implements the steps of the method for dynamically detecting and quickly locating dynamic runtime library loading anomalies as described above.

[0061] Compared with existing technologies, the present invention provides a method for locating dynamic runtime library loading anomalies. By setting up monitoring of the dynamic runtime library (DLL) search process and the process of loading the DLL, it can dynamically acquire the real-time loading process, unaffected by the environment. Through data analysis, it can accurately see the dynamic library search and loading process, compare and identify information on unloaded DLLs, problems where the DLL location cannot be found due to environmental variables, and complex situations such as inconsistent DLL versions. It can print prompts or report, accurately reflecting the cause of the error and the user's environment.

[0062] This approach avoids traversing all files under every environment variable path, resulting in higher performance. It is also compatible with dynamically changing environment variables, unaffected by changes in the program or system environment. It can analyze complex dynamic library call relationships, offering stronger compatibility and higher stability. Furthermore, it eliminates the need for separate user environment analysis and remote access, making it easier for developers to analyze anomalies in user environments.

[0063] Obviously, the above description of the advantages of the present invention is general, and more advantages will be described in the following disclosure of embodiments. In addition, those skilled in the art can reasonably invent other many advantages of the present invention based on the content disclosed herein.

[0064] Additional aspects and advantages of the invention will be set forth in the description which follows, and the advantages of the invention will become apparent from the description or be learned by practice of the invention. Attached Figure Description

[0065] Figure 1 This is a flowchart illustrating the first embodiment of a method for locating dynamic runtime library loading exceptions according to the present invention. Detailed Implementation

[0066] Reference will now be made in detail to the present embodiments of this disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same element symbols are used in the drawings and description to denote the same or similar parts.

[0067] Reference Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for dynamically detecting and quickly locating dynamic runtime library loading anomalies according to the present invention. In this embodiment, the method for dynamically detecting and quickly locating dynamic runtime library loading anomalies includes the following steps:

[0068] S100: Perform the operation of initializing the monitoring loading library in the program.

[0069] It should be noted that, in this embodiment, the specific operations of initializing the monitoring loading library include: obtaining the module handle address of Ntdll.dll using the process function for loading dynamic libraries; reading the address of the original NT kernel query file attribute process function using the process function for retrieving and exporting the specified function address through the Ntdll.dll module handle; saving the retrieved and exported function address to the global address variable of the NT kernel query file attribute process function address; reading the header 8 bytes of the global address variable of the NT kernel query file attribute process function address through the process memory reading function; saving the 8 bytes to the global byte array variable of the original NT kernel query file attribute process function, which is used to restore the flow state of the original NT kernel query file attribute process function when the monitoring search path is stopped.

[0070] Using the Ntdll.dll module handle, the process function that retrieves and exports the address of a specified function is used to read the address of the original NT kernel's file-opening process function. The retrieved and exported function address is saved to the global address variable of the NT kernel's file-opening process function. By reading the process memory function, the header 8 bytes of the global address variable of the NT kernel's file-opening process are read and saved to the global byte array variable of the original NT kernel's file-opening process. This is used to restore the flow state of the original NT kernel's file-opening process function when monitoring the path of the dynamically loaded library stops.

[0071] S200: Sets the process function for monitoring the search path of dynamic runtime libraries (DLLs) and sets the process for monitoring the loading of dynamic runtime libraries (DLLs).

[0072] It should be noted that the process of setting up the monitoring and searching for dynamic runtime libraries (DLLs) includes: a procedure function that creates the path to the monitoring and searching for dynamic runtime libraries (DLLs) and a procedure that starts executing the monitoring and searching for dynamic runtime libraries (DLLs).

[0073] In practice, the process of creating a function to monitor and search for dynamic runtime library (DLL) paths includes the following steps:

[0074] Create a function flow that captures and searches for information about the path of a dynamic runtime library (DLL). This function has two parameters. The first is an object attribute, which describes the information content of the file object attributes. The second parameter is a structure of basic file information, which contains file-related timestamp information and file attributes, such as whether the file is encrypted, read-only, or compressed.

[0075] When the monitoring and search for dynamic runtime libraries (DLLs) are set up, the function that queries the attributes of a specified file object in the process space is replaced with the function that monitors and searches the DLL path. That is, the original NT kernel function that queries file attributes is replaced. When the execution loads other DLL files that the runtime depends on, it will search different environment variables or system directories. When searching for a specified DLL, it will obtain the file object attributes. At this time, the created function to capture the information of the DLL path will be triggered. During this function, the complete path information of the searched DLL file will be captured and extracted.

[0076] The specific data resides in the structure of the object property variable, which is a structure for obtaining properties that can be applied to an object or object handle by a routine that can create an object and / or return an object handle.

[0077] First, obtain the length of the object's attribute information and check if it is empty. If it is not empty, extract the complete path.

[0078] Retrieve a string data pointer to the handle object name from the object property. This value is a pointer to a wide character string. Read the contents from the character string buffer. This contents are the path to the dynamic runtime library (DLL) that the program is currently searching for.

[0079] The content in the buffer of this string is the program directory, system directory, system32 directory, or the path under the environment variable Path, concatenated with the complete path of the currently searched dynamic runtime library (DLL) name. The retrieved content is pushed onto the stack and written to the information stack of the absolute path of the global runtime library file for subsequent data analysis and printing.

[0080] The program reads the function address (which was already saved in the global address variable of the NT kernel file attribute query procedure function during the initialization and library loading process of S100) and the 8-byte array (which was also saved in the global byte array variable of the original NT kernel file attribute query procedure function). It then writes the 8 bytes saved in the global byte array variable backed up to the function address in the global address variable for restoration. This is used to subsequently restore the original NT kernel file attribute query procedure function flow.

[0081] The function that executes the call to the NT kernel to query file attributes sets two parameters, which are the parameters of the function currently passed in to capture and search for dynamic runtime library (DLL) path information. Specifically, the first parameter is the object attributes, and the second parameter is a structure containing basic file information. This ensures that the original logical order and complete call process of the program are maintained without affecting the flow.

[0082] After calling the original NT kernel function to query file attributes, the process continues to execute the function to monitor and search for dynamic runtime library (DLL) path information, ensuring continuous monitoring of every process searching for dynamic libraries until the S40 process is executed to stop monitoring.

[0083] In practice, creating the procedure function to start monitoring and searching for dynamic runtime library (DLL) paths involves replacing the newly created procedure function with the address of the existing procedure function that checks NT kernel file attributes. The specific process includes the following steps:

[0084] An 8-byte jump instruction buffer array is set up, specifically containing {0xB8, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xE0, 0x00}. The address of the procedure function for monitoring and searching the dynamic runtime library (DLL) path is filled into the first byte of the jump instruction buffer. When this jump instruction is executed, it is converted into a machine instruction. By assigning the address of the procedure function for monitoring and searching the DLL path to the register (EAX), and then using the jump instruction (JMP), the jump is executed to the address of the procedure function for monitoring and searching the DLL path in the register EAX, thus executing the information recording process of monitoring, traversing and searching the DLL path.

[0085] During the program's library loading search process, each time a path is traversed, the program enters the information flow of the function that monitors the search path of the dynamic runtime library (DLL) once, and the currently searched path is recorded in the information stack of the absolute path of the global runtime library file.

[0086] Additionally, the procedures for setting up monitoring of the path where dynamic runtime library (DLL) files are being loaded include:

[0087] The process flow includes creating a procedure function to monitor the loading of a dynamic runtime library (DLL) and starting execution of a function that monitors the full path of the DLL being loaded.

[0088] Specifically, creating a process function to monitor the loading of a dynamic runtime library DLL includes the following steps:

[0089] Step 1: Create a function flow that captures the information of the full path of the dynamic runtime library DLL being loaded. This function has 6 parameters: the first is the file operation handle, the second is the file access type, the third is the object attribute, the fourth is the pointer to a structure containing information about the file operation and completion status, the fifth is the file's shared access type, and the sixth is the operation options when opening the file.

[0090] It should be noted that the creation process captures the full path information of the dynamically loaded DLL during the process.

[0091] Step 2: When setting up monitoring of dynamic runtime libraries (DLLs), replace the original NT kernel file opening procedure address in the process space with the newly created procedure function for monitoring the loading of dynamic runtime libraries (DLLs). When other dependent DLLs are found in the runtime library, the loading process of that DLL will be executed. When the operation of opening the handle of the DLL file object is executed during the loading process, it will trigger the entry into the newly created procedure function for monitoring the loading of dynamic runtime libraries (DLLs). During this process, the complete path information of the DLL being loaded will be captured and extracted.

[0092] In one embodiment, the specific data also resides in a variable structure that retrieves properties that can be applied to an object or object handle by a routine that can create an object and / or return an object handle.

[0093] First, obtain the length of the object information and check if it is empty. If it is not empty, extract the complete path.

[0094] The string data pointer to the handle object name is obtained from the object information length. This value is a pointer to a string. The content is read from the string buffer, which is the path to the dynamic runtime library DLL that the program is currently loading.

[0095] The content in the buffer of this string is the program directory, system directory, system32 directory, or the path under the environment variable Path, concatenated with the complete path of the currently loaded dynamic runtime library DLL name; the obtained content is pushed onto the stack and written to the information stack of the absolute path of the global runtime library file for subsequent data analysis and printing.

[0096] The function address and the original NT kernel file opening procedure's global byte array variable, which were already saved in the global address variable of the S100 program during the initialization and monitoring of the library loading process, are read. The 8 bytes saved in the variable backup are written to the function address for restoration; this is used to restore the original NT kernel file opening procedure flow later.

[0097] The function that calls the NT kernel to open a file takes six parameters, which are the parameters passed to the function currently loading a dynamically loaded DLL. These parameters are: the first is the file handle, the second is the file access type, the third is an object attribute, the fourth is a pointer to a structure containing file operation and completion status information, the fifth is the file's shared access type, and the sixth is the operation options when opening the file. This ensures the original logical order of the program and the complete calling process.

[0098] After calling the original NT kernel's file opening process function, the process continues to execute the function that starts monitoring the full path of the dynamically loaded DLL, ensuring continuous monitoring of each dynamic library loading process until the subsequent process of stopping monitoring is executed.

[0099] Specifically, the process of executing the function that monitors the full path of the dynamically loaded DLL involves replacing the previously created function for monitoring the loading of the DLL with the address of the existing NT kernel's function for opening files. The specific process includes:

[0100] An 8-byte jump instruction buffer array is set up, specifically {0xB8,0x00,0x00,0x00,0x00,0xFF,0xE0,0x00}. The address of the process function monitoring the loading of the dynamic runtime library DLL is filled after the first byte of the jump instruction buffer. A function that writes to the process's memory region replaces the 8 bytes of the jump instruction buffer array with the function address. After replacement, the jump instruction is converted into a machine instruction during execution. By assigning the address of the process function monitoring the loading of the dynamic runtime library DLL to the register (EAX), and then using a jump instruction (JMP) to jump to the address of the process function monitoring the loading of the dynamic runtime library DLL in the EAX register, the process of recording the complete path information of the DLL being loaded is executed.

[0101] During the program's library search process, each time a dynamic runtime library (DLL) is found, it will be loaded. During each loading process, the program will enter a function flow that monitors the path of the currently loading DLL and record the path of the currently loading DLL in the information stack of the absolute path of the global runtime library file.

[0102] After monitoring is complete, the process also includes stopping and closing the monitoring of dynamic library search and loading processes.

[0103] The specific steps to stop monitoring and searching for dynamic runtime library (DLL) libraries include:

[0104] The reading step S100 initializes the function address in the global address variable of the process function for querying file attributes in the NT kernel, which was already saved during the initialization of the library loading process, and the 8-byte array of the global byte array variable of the original NT kernel process function for querying file attributes.

[0105] The function that writes to the process's memory region writes the 8 bytes backed up in the global byte array variable to the global address variable function for restoration. This is used to restore the original NT kernel's function flow for querying file attributes, and the subsequent monitoring and dynamic library search process is not executed, ensuring the smooth execution of subsequent logical calls in the program.

[0106] The specific steps to stop monitoring the process of loading dynamic runtime DLL libraries include:

[0107] In step S100, the program initializes and starts monitoring the loading of the library, which has already been saved in the global address variable of the NT kernel's file opening process function and the original NT kernel's file opening process global byte array variable, which are 8 bytes in the global address variable.

[0108] The function that writes to the process's memory region writes the 8 bytes backed up in the global byte array variable to the function address in the global address variable for restoration. This is used to restore the original NT kernel's file opening process flow. The process of loading dynamic libraries is not monitored during execution, ensuring the smooth execution of subsequent logical calls in the program.

[0109] S300: Obtains stack data of information about the absolute path of the global runtime library file pushed into the process function that monitors the search for the path of the dynamic runtime library (DLL) and the process function that monitors the loading of the path of the dynamic runtime library (DLL).

[0110] Because the stack structure preserves the order and complete path of library searching and loading, this example reads the data from the stack containing information about the absolute path of the global runtime library file pushed onto the stack in the process function that is monitoring the search for dynamic runtime library DLLs and the process function that is monitoring the loading of dynamic runtime library DLLs, queries it in order, and writes it to the log record.

[0111] S400: Traverse the data in the information stack of the absolute paths of the global runtime library files mentioned above, and read the absolute paths of the DLLs in order.

[0112] S500: Get the version information of the dynamic runtime library (DLL) file. Based on the file version information, read the version number corresponding to the DLL file version information.

[0113] In this embodiment, the version information of the dynamic runtime library (DLL) file is obtained, the corresponding storage space is created by using the function to obtain the size of the dynamic runtime library version information, and the 4-digit complete version number corresponding to the version information of the dynamic runtime library (DLL) file is read by using the function to obtain the file version information.

[0114] S600: Compare the preset library version and path to determine runtime library loading exceptions.

[0115] By comparing the preset library versions and paths, information on any missing dynamic runtime libraries (DLLs) is identified, and prompts are printed or reported accordingly. Similarly, if the DLL versions or paths are inconsistent, prompts are printed or reported.

[0116] Before step S400, this embodiment also includes obtaining the directory of the program's path by obtaining the current process module name function, setting the log writing path by concatenation, creating read / write and shared read / write / delete permissions for the Logs file under the current program directory to ensure that the file is not locked; setting the file pointer to the end of the file to record and print logs sequentially.

[0117] This invention monitors the library loading process during program initialization, including monitoring the search for and loading of dynamic runtime libraries (DLLs). During this monitoring, it records and provides real-time feedback on the DLL search and loading process based on different user environments. Because it's dynamic monitoring, it's fully compatible with complex situations in various user environments, eliminating the need to traverse all environment variable paths. It's also compatible with dynamically changing environment variables and unaffected by program or system environment changes. It can analyze unlimited levels of call relationships, offering stronger compatibility and higher stability. Furthermore, it eliminates the need for separate user environment analysis and remote access, making it easier for developers to analyze anomalies in user environments.

[0118] For example, the complete process of the method for locating dynamic runtime library loading exceptions according to the present invention is as follows:

[0119] (1): Initialize the monitoring of the library loading process in the program.

[0120] Initialize monitoring by using the LoadLibrary function to obtain the module handle address of Ntdll.dll. Using the Ntdll.dll module handle, use the GetProcAddress function to retrieve and export the address of a specified function, then read the address of the original NT kernel function for querying file attributes (NtQueryAttributesFile). Save the retrieved function address to the global address variable (g_lpfnAddrNtQueryAttributesFile) of the NT kernel function for querying file attributes. Then, use the ReadProcessMemory function to read the first 8 bytes of the global address variable (g_lpfnAddrNtQueryAttributesFile) of the NT kernel function for querying file attributes, and save these 8 bytes to the global byte array variable (g_szNtQueryAttributesFileOldBytes) of the original NT kernel function for querying file attributes. This is used to restore the flow state of the original NT kernel function for querying file attributes (NtQueryAttributesFile) when monitoring and path searching are stopped.

[0121] Using the Ntdll.dll module handle, the process function GetProcAddress is used to retrieve and export the address of the specified function. The address of the original NT kernel file opening process function NtOpenFile is then read. The retrieved and exported function address is saved to the global address variable g_lpfnAddrNtOpenFile of the NT kernel file opening process function. The process memory is read using the ReadProcessMemory function. The header 8 bytes of the global address variable g_lpfnAddrNtOpenFile of the NT kernel file opening process are then read. These 8 bytes are saved to the global byte array variable g_szNtOpenFileOldBytes of the original NT kernel file opening process function. This is used to restore the flow state of the original NT kernel file opening process function NtOpenFile when monitoring the path of the dynamically loaded library is stopped.

[0122] This sets up a stack containing information about the absolute paths of global dynamic runtime library (DLL) files. This stack sequentially stores the complete path information of the DLLs being searched during the search process, as well as the complete path information of the DLLs being loaded, and stores them in order.

[0123] (2): Configure the monitoring and search process for dynamic runtime libraries (DLLs).

[0124] 1. Create a procedure function to monitor and search for dynamic runtime library (DLL) paths.

[0125] Create a function flow that captures and searches for dynamic runtime library (DLL) paths. This function has two parameters. The first is the object attributes (OBJECT_ATTRIBUTES), which describes the information content of the file object attributes. The second parameter is a structure of file basic information (PFILE_BASIC_INFORMATION), which contains file-related timestamp information and file attributes. The attributes describe information such as whether the file is encrypted, read-only, or compressed.

[0126] When setting up monitoring and searching for dynamic runtime libraries (DLLs), we replace the NtQueryAttributesFile function in the process space that queries the attributes of a specified file object with the function we created to monitor and search for DLL paths. In other words, we replace the original NT kernel function that queries file attributes. When the execution loads runtime libraries that depend on other DLL files, it will search different environment variables or system directories. When searching for a specified DLL, it will obtain the file object attributes. At this time, it will trigger the function we created to capture the information of the DLL path search. During this function, the complete path information of the searched DLL files will be captured and extracted.

[0127] The specific data resides in the structure of the object attribute variable OBJECT_ATTRIBUTES, which is used to retrieve the attributes that can be applied to an object or object handle by a routine that can be used to create an object and / or return an object handle.

[0128] First, obtain the length of the ObjectAttributes object's attribute information, and check if it is empty. If it is not empty, extract the complete path.

[0129] Retrieve the string data pointer ObjectName of the handle object name from the ObjectAttributes property. This value is a pointer to a wide character (Unicode) string. Read the content from the string buffer. This content is the path of the dynamic runtime library DLL that the program is currently searching for. The content in the string buffer is the path under the program directory, system directory, system32 directory, or environment variable Path. Concatenate the complete path of the currently searched dynamic runtime library DLL name. Push the retrieved content onto the stack and write it to the information stack of the absolute path of the global runtime library file for subsequent data analysis and printing in S50.

[0130] The program reads the function address from the global address variable (g_lpfnAddrNtQueryAttributesFile) stored during the initialization and library loading process of the NT kernel file attribute query procedure function, and extracts the 8-byte array from the global byte array variable (g_szNtQueryAttributesFileOldBytes) of the original NT kernel file attribute query procedure function. The 8 bytes backed up in g_szNtQueryAttributesFileOldBytes are then written to the function address of g_lpfnAddrNtQueryAttributesFile for restoration. This is used to restore the original NT kernel file attribute query procedure function flow. The two parameters set for this function are the two parameters of the currently passed-in function flow for capturing and searching dynamic runtime library (DLL) path information: the first is object attributes (OBJECT_ATTRIBUTES), and the second is a structure of file basic information (PFILE_BASIC_INFORMATION). This ensures the original logical order and complete calling process of the program without affecting the flow.

[0131] After calling the original NT kernel function to query file attributes, the following function to start monitoring and searching for dynamic runtime library (DLL) path information is executed to ensure continuous monitoring of each process searching for dynamic libraries until the S40 process stops monitoring.

[0132] 2. Begin the process of monitoring and searching for dynamic runtime libraries (DLLs).

[0133] The process function for monitoring and searching the dynamic runtime library DLL path created in the previous step is assigned to replace the original process function for retrieving and querying file attributes (NtQueryAttributesFile) of the NT kernel. Specifically, an 8-byte jump instruction buffer array (BYTEg_szNtQueryAttributesFileNewBytes[8]) is set, with the specific content being {0xB8,0x00,0x00,0x00,0x00,0xFF,0xE0,0x00}. The address of the process function for monitoring and searching the dynamic runtime library DLL path is filled into the first byte of the jump instruction buffer. When the jump instruction is executed, it will be converted into a machine instruction. The address of the process function for monitoring and searching the dynamic runtime library DLL path is assigned to the register (EAX). The jump instruction (JMP) is used to jump to the address of the process function for monitoring and searching the dynamic runtime library DLL path in the register EAX to execute the information recording process of monitoring and searching the dynamic runtime library DLL path.

[0134] During the program's library loading search process, each time a path is traversed, the program enters the information flow of the function that monitors the search path of the dynamic runtime library (DLL) once, and the currently searched path is recorded in the information stack of the absolute path of the global runtime library file.

[0135] (3): Configure monitoring to monitor the process of loading dynamic runtime library DLLs.

[0136] 1. Create a procedure function to monitor the loading of a dynamic runtime library (DLL).

[0137] The function flow that creates the capture controller is loading the full path of the dynamic runtime library DLL has 6 parameters: the first is the file operation handle (FileHandle), the second is the file access type (DesiredAccess), the third is the object attributes (OBJECT_ATTRIBUTES), the fourth is the pointer to the structure containing file operation and completion status information (PIO_STATUS_BLOCK), the fifth is the file's shared access type (ShareAccess), and the sixth is the operation options when opening the file (OpenOptions).

[0138] During the creation of the function, the full path information of the dynamically loaded DLL is captured. When the monitoring of the dynamically loaded DLL is set up, the address of the original NT kernel file opening procedure function (NtOpenFile) in the process space is replaced with the procedure function we created to monitor the loading of the dynamically loaded DLL. When other dependent DLL libraries are found in the runtime library, the loading process of the DLL is executed. When the operation of opening the handle of the DLL file object is executed during the loading process, it will trigger the entry into the procedure function we created to monitor the loading of the dynamically loaded DLL. During this procedure, the full path information of the dynamically loaded DLL is captured and extracted.

[0139] The specific data also exists in the variable OBJECT_ATTRIBUTES structure, which is used to obtain the properties that can be applied to an object or object handle by a routine that can create an object and / or return an object handle.

[0140] First, obtain the length of the ObjectAttributes object information, check if it is empty, and if not empty, extract the complete path;

[0141] Get the string data pointer ObjectName of the handle object name from ObjectAttributes. This value is a pointer to a Unicode string. Read the content from the character string buffer. This content is the path of the dynamic runtime library DLL that the program is currently loading. The content in the character string buffer is the path under the program directory, system directory, system32, or environment variable Path. Concatenate the complete path of the name of the currently loading dynamic runtime library DLL. Push the obtained content onto the stack and write it into the information stack of the absolute path of the global runtime library file for subsequent data analysis and printing in S50.

[0142] The program reads the S10 code during the initialization and library loading process. It extracts the function address from the global address variable (g_lpfnAddrNtOpenFile) of the NT kernel's file opening procedure function and the 8-byte array from the original NT kernel's file opening procedure's global byte array variable (g_szNtOpenFileOldBytes). The 8 bytes backed up in the variable g_szNtOpenFileOldBytes are then written to the address of the g_lpfnAddrNtOpenFile function for restoration. This is used to subsequently restore the original NT kernel's file opening procedure flow.

[0143] The execution of the function that calls the NT kernel to open a file sets six parameters, which are the six parameters of the process function currently being monitored as it loads the dynamic runtime library DLL. Specifically, the first is the file handle (FileHandle), the second is the file access type (DesiredAccess), the third is the object attributes (OBJECT_ATTRIBUTES), the fourth is a pointer to a structure containing file operation and completion status information (PIO_STATUS_BLOCK), the fifth is the file's shared access type (ShareAccess), and the sixth is the operation options when opening the file (OpenOptions). This ensures the original logical order of the program and the complete calling process.

[0144] After calling the existing NT kernel function to open a file, the process continues with the following function to monitor the full path of dynamically loaded DLLs, ensuring continuous monitoring of each DLL loading process until the S40 process stops monitoring.

[0145] 2. Begin executing the function process that monitors the loading of the full path to the dynamic runtime library DLL.

[0146] The process function that was created in the previous step to monitor the loading of the dynamic runtime library DLL is assigned and replaced in the address of the original NT kernel file opening process function (NtOpenFile). Specifically, an 8-byte jump instruction buffer array (BYTE g_szNtOpenFileNewBytes[8]) is set with the content {0xB8,0x00,0x00,0x00,0x00,0xFF,0xE0,0x00}. The address of the process function that was created to monitor the loading of the dynamic runtime library DLL is filled after the first byte of the jump instruction buffer. Using the function (WriteProcessMemory) to write the memory region of the process, 8 bytes of the jump instruction buffer array (BYTE g_szNtOpenFileNewBytes[8]) are written to the address of the function g_lpfnAddrNtOpenFile for replacement. After replacement, the jump instruction will be converted into a machine instruction when executed. By assigning the address of the process function that is monitoring the loading of the dynamic runtime library DLL to the register (EAX), and then jumping to the address of the process function that is monitoring the loading of the dynamic runtime library DLL in the register EAX by the jump instruction (JMP), the process of recording the information of the complete path of the dynamic runtime library DLL being monitored is executed.

[0147] During the program's library search process, each time a dynamic runtime library (DLL) is found, it will be loaded. During each loading process, the program will enter a function flow that monitors the path of the currently loading DLL and record the path of the currently loading DLL in the information stack of the absolute path of the global runtime library file.

[0148] (4): Monitoring complete, stop monitoring and close the dynamic library search and loading process.

[0149] 1. Stop monitoring the process of searching for dynamic runtime libraries (DLLs).

[0150] The function address already stored in the global address variable (g_lpfnAddrNtQueryAttributesFile) of the NT kernel's file attribute query procedure function address and the original NT kernel's file attribute query procedure function's global byte array variable (g_szNtQueryAttributesFileOldBytes) are extracted during the S10 initialization and monitoring of the library loading process.

[0151] The function `WriteProcessMemory` is used to write the 8 bytes backed up in the array variable `g_szNtQueryAttributesFileOldBytes` to the address of the function `g_lpfnAddrNtQueryAttributesFile` for restoration. This is used to restore the original NT kernel's function flow for querying file attributes, preventing the execution of subsequent monitoring and dynamic library searches, and ensuring the smooth operation of subsequent program logic calls.

[0152] 2. Stop monitoring the process of loading dynamic runtime DLL libraries.

[0153] The program reads the S10 and starts monitoring the library loading process during initialization. It extracts the function address from the global address variable (g_lpfnAddrNtOpenFile) of the NT kernel's file opening procedure function and the 8-byte array of the original NT kernel's file opening procedure's global byte array variable (g_szNtOpenFileOldBytes).

[0154] The function `WriteProcessMemory` is used to write the 8 bytes backed up in the variable `g_szNtOpenFileOldBytes` to the address of the function `g_lpfnAddrNtOpenFile` for restoration. This is used to restore the original NT kernel's file opening process flow. Monitoring of subsequent dynamic library loading processes is not performed, ensuring the smooth execution of subsequent program logic calls.

[0155] (5): Automatically analyze the information stack content of the absolute path of the global runtime library file, analyze and compare, locate the problem, print prompts or report errors.

[0156] We read the data from the stack of information pushed onto the absolute path of the global runtime library file in the process function that is monitoring the search for dynamic runtime library (DLL) and the process function that is loading the DLL. Because the stack structure preserves the order and complete path of the search and loading of libraries, we query them in order and write them to the log.

[0157] The directory of the program's path is obtained by using the function GetModuleFileName to get the current process module name. The log writing path is set by concatenating the path. Read, write, and shared read, write, and delete permissions are created for the Logs file in the current program directory to ensure that the file is not locked.

[0158] Set the file pointer to the end of the file to record the print log sequentially;

[0159] Iterate through the data in the information stack of the absolute paths of global runtime library files, and read the absolute paths of DLLs in order;

[0160] Get the version information of the dynamic runtime library (DLL) file, create the corresponding storage space by using the function to get the size of the dynamic runtime library version information (GetFileVersionInfoSize), and read the 4-digit complete version number corresponding to the version information of the dynamic runtime library (DLL) file by using the function to get the file version information (GetFileVersionInfo).

[0161] Compare and determine the preset library version and path;

[0162] Compare and identify any missing dynamic runtime DLLs, then print a notification or report the issue.

[0163] If there are inconsistencies in the versions of dynamic runtime libraries (DLLs), print a notification or report the issue.

[0164] If the paths to the dynamic runtime library (DLL) are inconsistent, print a message or report the issue.

[0165] The purpose of this invention is to propose a method for dynamically detecting, rapidly detecting, and quickly locating dynamic runtime library loading anomalies. This invention can handle complex user computer environment variables, is not limited by changing environment variables, dynamically monitors and tracks the dynamic runtime library search and loading process, and deduces the specific conflict problem by analyzing the search order and recording the corresponding version information. It does not require remote analysis of the user's computer environment or traversing all environment folders and files. This makes analyzing loading problems simpler and more convenient for developers. Furthermore, it does not require changing the original runtime code logic and does not affect program stability.

[0166] The direct solution described in this invention monitors the library loading process during program initialization, including monitoring the search for and loading of dynamic runtime libraries (DLLs). During this monitoring, the system records and provides real-time feedback on the DLL search and loading process, adapting to different user environments. Because it's dynamic monitoring, it's fully compatible with complex situations in various user environments, eliminating the need to traverse all environment variable paths. It's also compatible with dynamically changing environment variables and unaffected by program or system environment changes. It can analyze unlimited levels of call relationships, offering stronger compatibility and higher stability. Furthermore, it eliminates the need for separate user environment analysis and remote access, making it easier for developers to analyze anomalies in user environments.

[0167] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for locating dynamic runtime library loading exceptions, characterized in that, Dynamic detection and rapid location of runtime library loading anomalies include: Perform the operation of initializing the monitoring loading library in the program; Create a procedure function to monitor the search path for dynamic runtime library (DLL) and a procedure function to monitor the path where dynamic runtime library (DLL) is being loaded. The process function that monitors and searches for the path of the dynamic runtime library (DLL) and the process function that monitors the loading of the path of the dynamic runtime library (DLL) pushes the information stack data of the absolute path of the global runtime library file. Iterate through the data in the information stack of the absolute paths of the global runtime library files mentioned above, and read the absolute paths of the DLLs in order; Get the version information of the dynamic runtime library (DLL) file, and read the version number corresponding to the version information of the dynamic runtime library (DLL) file based on the file version information function; Compare the preset library versions and paths to determine runtime library loading anomalies; The operation of initializing the monitoring loading library in the program includes: Obtain the module handle address of Ntdll.dll, wherein the module handle address of Ntdll.dll is obtained in the process function of loading dynamic libraries during initialization monitoring; The procedure function that exports the address of a specified function is obtained through the Ntdll.dll module handle. The procedure function that exports the address of a specified function includes the procedure function that queries file attributes and the procedure function that opens the file. Read the address of the original NT kernel procedure function, and save the procedure function with the exported function address into the global address variable of the NT kernel procedure function address; By reading the process memory function, the header 8 bytes of the global address variable of the NT kernel process function address are read, and the 8 bytes are saved into the original NT kernel process function's global byte array variable.

2. The method for locating dynamic runtime library loading anomalies according to claim 1, characterized in that, The process function for creating a monitoring and searching dynamic runtime library (DLL) path includes: Create a function flow that captures information about the path of a dynamically linked runtime library (DLL), where the information function includes a structure containing object attributes and basic file information; Replace the created procedure function that monitors and searches for the path of a dynamic runtime library (DLL) with a procedure function in the process space that queries the properties of a specified file object. Determine whether a signal for obtaining file object attributes has been triggered. If the signal for obtaining file object attributes has been triggered, capture and extract the complete path information of the searched dynamic runtime library (DLL) file.

3. The method for locating dynamic runtime library loading anomalies according to claim 2, characterized in that, The process function for creating a monitoring and searching dynamic runtime library (DLL) path also includes: Get the length of the object's attribute information, check if it is empty, and if not empty, extract the complete path; Retrieves a string pointer to the handle object name from an object property; Read the contents from the string buffer, where the contents are the path the program is currently searching for in the dynamic runtime library (DLL); Concatenate the full path of the currently searched dynamic runtime library (DLL); The retrieved content is pushed onto the stack and written to the information stack of the absolute path of the global runtime library file.

4. The method for locating dynamic runtime library loading anomalies according to claim 2, characterized in that, The process function for creating a monitoring and searching dynamic runtime library (DLL) path also includes: Read the function address that was already stored in the global address variable of the procedure function for querying file attributes in the NT kernel during the initialization of the monitoring and loading library in the program, and the 8-byte array of the global byte array variable of the original procedure function for querying file attributes in the NT kernel; The 8-byte array, which is backed up in the global byte array variable, is written to the function address in the global address variable for restoration. Calling the NT kernel's function to query file attributes; Continue executing the function flow that monitors and searches for information about the paths of dynamic runtime libraries (DLLs).

5. The method for locating dynamic runtime library loading exceptions according to claim 1, characterized in that, The process of monitoring and searching for dynamic runtime libraries (DLLs) includes: assigning and replacing the newly created process function for monitoring and searching for DLL paths with the address of the existing process function for checking NT kernel file attributes. This assignment and replacement process includes: Set an 8-byte jump instruction buffer array; Fill the address of the procedure function created for monitoring and searching the path of the dynamic runtime library (DLL) into the jump instruction buffer after the first byte. The address of the process function that monitors and searches for the path of the dynamic runtime library (DLL) is assigned to the register; The jump instruction jumps to the address of the procedure function that searches the register for the path of the dynamic runtime library (DLL); The process involves monitoring and traversing the path of dynamic runtime libraries (DLLs) and recording related information.

6. The method for locating dynamic runtime library loading exceptions according to claim 1, characterized in that, The process function for creating a monitor that is loading a dynamic runtime library DLL includes: Create a function flow that captures and monitors the full path of a dynamically loaded DLL. This information function includes a pointer to a structure containing information such as the file operation handle, file access type, object attributes, file operation and completion status, file shared access type, and operation options when opening the file. Replace the newly created process function that is monitoring the path of the dynamic runtime library DLL with the address of the original NT kernel process function that opens a file in the process space. Determine whether the signal for opening a dynamic runtime library (DLL) file object handle operation is triggered. If the signal for opening a dynamic runtime library (DLL) file object handle operation is triggered, capture and extract the full path information of the currently loading dynamic runtime library (DLL).

7. The method for locating dynamic runtime library loading exceptions according to claim 6, characterized in that, The process function for creating a monitor that is loading a dynamic runtime library DLL also includes: Get the length of the object information, check if it is empty, and if not empty, extract the complete path; Retrieve a string pointer to the handle object name from the object information; Read content from the buffer of the character string, where the content of the buffer of the character string includes the program directory, the system directory, the system directory system32, or the path under the environment variable Path; Concatenate the full path to the name of the currently loaded dynamic runtime library (DLL); The retrieved content is pushed onto the stack and written to the information stack of the absolute path of the global runtime library file.

8. The method for locating dynamic runtime library loading anomalies according to claim 6, characterized in that, The process function for creating a monitor that is loading a dynamic runtime library DLL also includes: Read the function address that was already saved in the global address variable of the NT kernel file opening procedure function during the initialization of the monitoring loading library in the program, and the 8-byte array of the global byte array variable of the original NT kernel file opening procedure function; Write the 8 bytes stored in the global address variable backup to the global address variable for restoration; Calling the NT kernel's function to open a file; Continue executing the function flow that monitors the full path of the runtime DLL being loaded.

9. The method for locating dynamic runtime library loading exceptions according to claim 1, characterized in that, Also includes: Read the function address in the global address variable of the procedure function for querying file attributes and opening files in the NT kernel, which was already saved in the operation of initializing the monitoring and loading library in the program, and the 8-byte array of the global byte array variable of the original NT kernel procedure function for opening files; The function that writes to the process's memory region writes the 8 bytes stored in the backup of the global address variable to the function address of the global byte array variable. Restore the original NT kernel's function flow for querying and opening file attributes.

Images