JP4125053B2 - Log acquisition method - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a technique for acquiring a processing log of software divided into a plurality of modules.
[0002]
[Prior art]
In the past, for software failures with low recall, the cause of the failure has been identified by taking a software processing log and analyzing the processing log, and countermeasures have been taken.
[0003]
[Problems to be solved by the invention]
However, the acquisition of the conventional processing log has the following problems.
(1) In order to continue to acquire logs even in the user's operating environment, the software module itself has to be modified and a processing log acquisition routine has to be added, resulting in a heavy workload for acquiring the processing logs.
(2) Since processing log acquisition is performed for each module, the generated log is for each module, and it is difficult to acquire the entire software processing as a log in time order. For this reason, the prospect as the whole processing log was bad, and it took man-hours to analyze the log and discover the cause of the failure.
[0004]
The present invention has been made in view of the above problems, and can easily acquire a software processing log divided into a plurality of modules, and can reduce the number of steps for analyzing the cause of a software failure. An object of the present invention is to provide a simple log acquisition method, a program for realizing the method by a computer, and a storage medium storing the program.
[0005]
[Means for Solving the Problems]
In order to achieve the above object, a log acquisition method according to the present invention has the following configuration. That is,
A dynamic link library storing functions, an import function address table storing addresses of the functions, and a target program that calls and executes the functions in the dynamic link library; The Program storage means for storing; A storage medium for storing the program; Log recording means for recording a log; and execution means for executing a program, wherein the execution means Storage media A log acquisition method for acquiring a log during execution of the target program in an information processing apparatus comprising a rewriting means implemented by executing a program stored in the memory and a calling means,
The rewriting means loads a log acquisition function corresponding to each function in the dynamic link library into the dynamic link library and stores it in the import function address table before executing the target program. Rewriting the address of each function to the address of the corresponding function for log acquisition;
The call means is configured to acquire the log based on the address of the corresponding function for log acquisition after rewriting on the import function address table for the function to be called that the target program is to call. Starting a log acquisition means realized by calling a function and causing the execution means to execute;
The log acquisition unit records a log related to a call by the calling unit in the log recording unit, calls the function to be called corresponding to the function for log acquisition called by the calling unit, and Causing the execution means to execute a function to be called;
The log acquisition unit includes a step of receiving an execution result of the function to be called, recording a log related to the execution result in the log recording unit, and passing the execution result to the target program.
[0006]
DETAILED DESCRIPTION OF THE INVENTION
[First Embodiment]
In this embodiment, an import function address stored in a memory or a virtual function address table (Virtual Address Table), which is a mechanism when a function existing in another module is called from one module, is used. By hooking function calls between modules and recording them in the log, it is possible to acquire the entire software process as a log in time order without modifying the software module itself. . This will be specifically described below.
[0007]
<System configuration>
FIG. 1 is a diagram showing the configuration of a computer (software evaluation system) that implements a log acquisition method according to each embodiment of the present invention. In order to simplify the explanation, in this embodiment, it is assumed that the software evaluation system is built inside one PC, but the feature of the log acquisition method of the present invention is built inside one PC. It is effective regardless of whether it is constructed as a network system on a plurality of PCs.
[0008]
A computer on which this software evaluation system is mounted includes a CPU 1, a chip set 2, a RAM 3, a hard disk controller 4, a display controller 5, a hard disk drive 6, a CD-ROM drive 7, and a display 8. Further, a signal line 11 connecting the CPU and the chip set, a signal line 12 connecting the chip set 2 and the RAM 3, a peripheral device bus 13 connecting the chip set 2 and various peripheral devices, and a signal connecting the hard disk controller 4 and the hard disk drive 6. Line 14, signal line 15 connecting hard disk controller 4 and CD-ROM drive 7, and signal line 16 connecting display controller 5 and display 8 are mounted.
[0009]
<Acquire processing log for function processing>
In order to explain the software evaluation system for realizing the log acquisition method according to the first embodiment of the present invention, first, how the software divided into a plurality of modules is loaded into the memory in a normal state according to FIG. Explain how.
[0010]
Usually, the software divided into a plurality of modules is divided into an executable file EXE (23) that performs overall control and a dynamic link library DLL (27) that exists as a module and plays a complementary role of EXE. Is loaded with both EXE and DLL. EXE consists of a code segment (28), a data segment (29), and an import function address table (22). Furthermore, the import function address table is divided by the DLL to which the function belongs (21, 24), and the address at which each function is loaded is written for each DLL (30-35). The entity of the DLL function is loaded separately for each DLL (25, 26), and each function is loaded as a part of the corresponding DLL (36-41). This figure shows an example in which one EXE uses functions in two dynamic link libraries of A.DLL and B.DLL, and the functions actually used are Func AA, Func AB, and Func. AC, Func BA, Func BB, and Func BC.
[0011]
When the code in the EXE code segment calls the function Func AA, the Func AA address (30) written in the import function address table is first read. Here, the address of the Func AA code (36) actually read as part of A.DLL is written, and by calling that address, the EXE code calls Func AA of A.DLL. be able to.
[0012]
FIG. 3 is a diagram showing a memory configuration of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention. FIG. 2 is different from FIG. 2 in terms of IAT Patch (Import Address) for the log acquisition code. It is different in that the function call is redirected using a technique called “Table Patch”.
[0013]
When log acquisition is started, C.DLL (58), which is a DLL for IAT Patch, is loaded into the memory. C.DLL is the address of the function written in the import function address table (52), and the address of the log acquisition code in C.DLL is Func CAA, Func CAB, Func CAC, Func CBA, Func CBB, Func CBC (61-66). Func CAA, Func CAB, Func CAC, Func CBA, Func CBB, and Func CBC code (73-78) in C. DLL are logged and loaded into memory to receive the original function call The corresponding functions Func AA, Func AB, Func AC, Func BA, Func BB, and Func BC (67 to 72) are called.
[0014]
4A is a diagram showing the processing of the IAT Patch in FIG. 3, and FIG. 4B is a flowchart showing the flow of the log acquisition processing. In order to simplify the explanation, this figure shows an example of how the log acquisition code by IAT Patch operates when EXE calls Fun AA in A.DLL.
[0015]
When EXE (91 in FIG. 4A) calls Func AA (94 in FIG. 4A), the log acquisition code in C.DLL saves the DLL name / function name in memory (step S402 in FIG. 4B), and the call time Is stored in the memory, the parameter at the time of calling is stored in the memory, and the memory content pointed to by the pointer parameter at the time of calling is stored in another memory (95 in FIG. 4A, step S403 in FIG. 4B). After that, C.DLL calls Func AA in A.DLL (93 in FIG. 4A), which was supposed to be called (96 in FIG. 4A, step S404 in FIG. 4B). When the A.DLL Func AA process (97 in FIG. 4A) ends and control returns to C.DLL (98 in FIG. 4A), C.DLL stores the return time in memory and stores the return value in memory. The memory contents pointed to by the pointer parameter at the time of return are stored in another memory (99 in FIG. 4A). Thereafter, C.DLL writes the saved log information to a file (100 in FIG. 4A, step S405 in FIG. 4B), and returns to EXE as if A.DLL Func AA ended normally ( 101).
[0016]
FIG. 5 is a diagram showing the internal configuration of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention. Normally, the executable EXE (113) calls a function in the DLL-1 (116) or DLL-2 (117). Here, a log acquisition code called an API tracer is embedded (114) to generate a processing log. (115). The API tracer is based on a file (111) describing function definitions of DLL-1 and DLL-2, and a setting scenario (trace scenario 112) of rewriting the import function table of which function of which DLL and acquiring the log. To work.
[0017]
<Acquire process log for method process>
Next, in the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention, when an instance of an interface in which the execution file EXE (118) is exported by a COM (Component Object Model) server is created, In order to explain how the data is loaded into the memory, first, how it is loaded into the memory in a normal state will be described with reference to FIG.
[0018]
Normally, when an instance of an interface is created, the requested interface (121, 122) and its method (: a program describing a procedure executed by an object in object-oriented programming, 130 to 135) in the COM server are displayed. They are both loaded into memory. Here, a virtual address table (virtual address table) is created for each created interface (118, 120), and passed to the EXE that made the creation request. In this virtual address table, addresses where each method is created are written (124 to 129). EXE uses these information to make a call to each interface. In this figure, one EXE creates instances of two interfaces, Interface A and Interface B, and shows an example of using the methods inside that interface. , Method AA, Method AB, Method AC, Method BA, Method BB, Method BC.
[0019]
When the EXE code calls the function Method AA, the address (124) of the Method AA written in the virtual address table is first read. Here, the address of the Method AA code (130) created as part of Interface A of the COM server is actually written, and by calling this address, the code of EXE executes Method AA of Interface A. Can be called.
[0020]
FIG. 7 is a diagram showing a memory configuration of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention. FIG. 6 is different from FIG. 6 in terms of VTable Patch (virtual address) for the log acquisition code. This method is different in that the method call is redirected using a method called “table Patch”.
[0021]
When log acquisition is started, a DLL (143) for VTable Patch is loaded in the memory. This DLL uses the address of the method written in the virtual address table (136, 138) as the method A'A, Method A'B, Method A'C, Method B'A, Method B, which is the log acquisition code in the DLL. Rewrite to the address of 'B, Method B'C (145-150). Method A'A, Method A'B, Method A'C, Method B'A, Method B'B, Method B'C code (157-162) in the DLL records the log and the original method Method AA, Method AB, Method AC, Method BA, Method BB, MethodBC (157 to 162), which are the corresponding methods loaded in the memory to receive the call, are called.
[0022]
8A is a diagram showing the processing of the VTable Patch in FIG. 7, and FIG. 8B is a flowchart showing the flow of the log acquisition processing. In order to simplify the explanation, this figure shows an example of how the log acquisition code by VTable Patch operates when EXE calls MethodAA of Interface A in the COM server.
[0023]
When EXE (163 in FIG. 8A) calls Method AA (166 in FIG. 8A), the log acquisition code in the DLL stores the module name / interface name / method name in memory (step S802 in FIG. 8B) and calls The time is saved in the memory, the parameter at the time of calling is saved in the memory, and the memory content pointed to by the pointer parameter at the time of calling is saved in another memory (167 in FIG. 8A, step S803 in FIG. 8B). Thereafter, the DLL calls Method AA in the COM server (165 in FIG. 8A), which was supposed to be called (168 in FIG. 8A, step S804 in FIG. 8B)). When the Method AA process (169 in FIG. 8A) of the COM server ends and control returns to the DLL (170 in FIG. 8A), the DLL stores the return time in the memory, stores the return value in the memory, and returns. The memory content pointed to by the pointer parameter is saved in another memory (171 in FIG. 8A). Thereafter, the DLL writes the saved log information to the file (172 in FIG. 8A, step S805 in FIG. 8B), and returns to EXE as if Method AA of the COM server was terminated normally (in FIG. 8A). 173).
[0024]
FIG. 9 is a diagram showing the internal configuration of the software evaluation system according to the first embodiment of the present invention. Normally, the execution format EXE (176) calls a method in the COM server 1 (179) or the COM server 2 (180). Here, a log acquisition code called an API tracer is embedded (177) to generate a processing log. (178). The API tracer sets a file (174) in which the function definitions of the COM server 1 (179) and the COM server 2 are described, and a virtual address table for which method of which interface of which COM server to acquire a log. Operates based on (175).
[0025]
<Example>
FIG. 10 is a diagram of a function definition file for instructing the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention, the format of each function and method parameter, and the format of the return value. It is a figure which shows an example. Describes the DLL / interface name and function / method name ("function / method" means "function or method", the same applies hereinafter), and indicates the parameter and return type for that function / method. . The software evaluation system that implements the log acquisition method according to the present embodiment determines what parameters / return values each function / method has based on the contents instructed by the function definition file. , Get the contents as a log.
[0026]
FIG. 11 is a diagram showing an example of a log acquired by the software evaluation system according to the embodiment of the present invention using the function definition file shown in FIG. For each call, the time when the function / method is called and the parameters / return values at that time are generated as a log.
[0027]
As is clear from the above description, according to the log acquisition method according to the present embodiment, the acquisition of the processing log of the software divided into a plurality of modules is prepared in the module without changing the module itself. The function / method calls can be recorded as a log, and the work load for acquiring the processing log can be reduced. In addition, the generated log can be acquired as a chronological log and the log can be easily analyzed. Therefore, the number of steps for analyzing the cause of the software failure can be reduced.
[0028]
[Second Embodiment]
In the present embodiment, a process when a place gap (Place Gap) exists in the virtual address table will be described.
[0029]
FIG. 12 shows how a memory is created when an interface instance is created when a place gap exists in the virtual address table for the software evaluation system that implements the log acquisition method according to the second embodiment of the present invention. Is an example of what is loaded. FIG. 12 is described in association with FIG. What is different from the example of FIG. 6 is a portion related to Method BB and Method BC. In the VTable (203) for Interface B, an address (211) to a dummy routine called a place gap is placed in the portion where Method BB should be placed, and Method BB is implemented by deriving Interface B. In this case, the offset of the address (212) to the Method BC on the VTable is not changed. That is, the place gap refers to an area on the VTable reserved for a derived class with respect to an interface having a virtual function. In the interface B before the derivation, the Method BB is not implemented, so that there is no gap between the Method BA and the Method BC in the actual code (216, 217).
[0030]
FIG. 13 shows what kind of memory arrangement the log acquisition code has when a place gap exists in the virtual address table for the software evaluation system that implements the log acquisition method according to the second embodiment of the present invention. It is a figure showing whether it is placed, and this embodiment is best shown. FIG. 13 is described in association with FIG.
[0031]
When log acquisition is started, a DLL (228) for VTable Patch is loaded in the memory. This DLL uses the address of the method written in the virtual address table (221, 223) as the method A'A, Method A'B, Method A'C, Method B'A, Method which is the log acquisition code in the DLL. Rewrite to the address of B′C (230 to 233, 235). The difference from FIG. 7 is that the place gap (234) is automatically detected and rewriting is not performed for that portion, and the code of Method B′B is not arranged in the memory. Method A'A, Method A'B, Method A'C, Method B'A, Method B'C code (241-245) in the DLL records the log and also stores the original method call. Method AA, Method AB, Method AC, Method BA, and Method BC (236 to 240), which are the corresponding methods loaded in (1), are called.
[0032]
FIG. 14 is a diagram showing a flow of processing at the time of memory loading in the software evaluation system that implements the log acquisition method according to the second embodiment of the present invention, and together with FIG. It is what you represent.
[0033]
When the process is started (step S1), a memory area that is referred to as an index is initialized to zero (step S2). This Index represents the order of methods described in the function definition file. Next, the attribute of the Index n method written in the function definition file is read from the operating system (step S3), and it is determined from the attribute information whether the function is a virtual function (step S4). If the function is a virtual function, the offset p of the place gap for the method of Index n is read from the operating system (OS) (step S5), and it is determined whether p is a true value, that is, whether it is not a null pointer ( Step S6). Here, whether or not a place gap exists is determined based on whether or not p is a true value. However, for an operating system in which a defined value such as 0xFFFFFFFF is defined as meaning that there is no place gap, for example. Similarly, it is determined whether it is 0xFFFFFFFF.
[0034]
If there is no place gap, or if it is determined in step S4 that it is not a virtual function, a log acquisition code is generated as shown in FIG. Specifically, the log acquisition code is placed in the memory (step S7), the offset m on the VTable for the Index n method is read from the operating system (step S8), and the address of the offset m is acquired in step S9 as the log acquisition code. Rewrite to the address.
[0035]
When step S9 is completed, Index n is incremented (step S10). If it is determined in step S6 that there is a place gap, Index n is incremented (step S10). That is, in this case, the place gap area in the memory cannot be rewritten to the address of the method for log acquisition. This process is continued until the memory load process is completed (step S11).
[0036]
FIG. 15 is a diagram of a function definition file for instructing the software evaluation system that implements the log acquisition method according to the second embodiment of the present invention, the format of each function and method parameter, and the format of the return value. It is an example. The DLL / interface name and function / method name are described, and the parameter and return type for the function / method are shown. The software evaluation system that implements the log acquisition method according to the present embodiment determines what parameters / return values each function / method has based on the contents instructed by the function definition file. , Get the contents as a log.
[0037]
Note that definitions regarding place gaps are not provided in this function definition file because they are functions normally provided by the operating system. Therefore, FIG. 15 is similar to FIG.
[0038]
FIG. 16 is a software evaluation system that implements the log acquisition method according to the second embodiment of the present invention for the interface having the place gap shown in FIG. 12 using the function definition file shown in FIG. It is an example of the acquired log. For each call, the time when the function / method is called and the parameters / return values at that time are generated as a log. It should be noted that the log for the method BC call placed after the place gap can be acquired even though there is a place gap on the VTable, that is, the flow shown in FIG. As long as the place gap is not detected, it is usually impossible to obtain a log for a method arranged after the place gap, such as Method BC.
[0039]
As is clear from the above description, according to the present embodiment, by automatically determining the place gap of the virtual address table from the information returned from the operating system, even if there is a place gap in the virtual address table, Log acquisition is possible.
[0040]
[Third Embodiment]
Normally, the place gap is used for resolving a virtual function accompanying the derivation of a class as in the second embodiment, but there are cases where it is used other than that.
[0041]
FIG. 17 is a diagram showing a processing flow at the time of memory loading in the software evaluation system that implements the log acquisition method according to the third embodiment of the present invention, which is an example different from FIG.
[0042]
When the process is started (step S21), the memory area referred to by itself as an index is initialized to zero (step S22). This Index represents the order of methods described in the function definition file. Next, the offset p of the place gap for the Index n method is read from the operating system (step S23), and it is determined whether or not p is a true value, that is, whether it is not a null pointer (step S24). Here, whether or not a place gap exists is determined based on whether or not p is a true value. However, for an operating system in which a defined value such as 0xFFFFFFFF is defined as meaning that there is no place gap, for example. Similarly, it is determined whether it is 0xFFFFFFFF.
[0043]
If there is no place gap, or if it is determined in step S24 that it is not a virtual function, a log acquisition code is generated as shown in FIG. Specifically, the log acquisition code is placed in the memory (step S25), the offset m on the VTable for the Index n method is read from the operating system (step S26), and the address of the offset m is rewritten to the address of the log acquisition code. (Step S27).
[0044]
When step S27 is completed, Index n is incremented (step S10). If it is determined in step S24 that there is a place gap, Index n is incremented (step S28). That is, in this case, the place gap area in the memory cannot be rewritten to the address of the method that is the log acquisition code. This process is continued until the memory load process ends (step S29).
[0045]
By this processing, even when the place gap is for a function other than a virtual function, it is possible to obtain a log for a method call placed after the place gap as shown in FIG.
[0046]
[Fourth Embodiment]
In the present embodiment, processing when an instance of an interface is generated inside a method will be described.
[0047]
In the present embodiment, it is determined whether the parameters and return values in all method calls are the parameters or return values of the log acquisition target interface. Even if an interface instance is generated inside a method by loading the acquisition code into memory, rewriting the parameter or return value to the address of the log acquisition code and returning the function, the method inside the instance Enable automatic logging of calls to. Details are described below.
[0048]
FIG. 18 is a diagram of a function definition file for instructing the software evaluation system that implements the log acquisition method according to the fourth embodiment of the present invention, the format of each function and method parameter, and the format of a return value. It is an example. The DLL name and the function / method name are described, and the parameter and return type for the function / method are shown. The software evaluation system according to the embodiment of the present invention determines what parameters / return values each function / method has based on the contents instructed by the function definition file, and determines the contents. Get as a log. In the present embodiment, Method AB of Interface A returns a pointer to an instance of Interface B generated inside Method AB as an output parameter. Also, Method A Method AC of Interface A returns a pointer to an instance of Interface B generated inside Method AB as a return value. In order for EXE to call a method in Interface B described as a code in DLL, first create an instance of Interface B using Method AB to Method AC, and know the memory address of the instance There is a need.
[0049]
FIG. 19 is an example of a log acquired by the software evaluation system according to the embodiment of the present invention using the function definition file shown in FIG. For each call, the time when the function / method is called and the parameters / return values at that time are generated as a log.
[0050]
FIG. 20 is a diagram showing the flow of processing in the software evaluation system that implements the log acquisition method according to the embodiment of the present invention.
[0051]
When processing is started (step S2001), each time a set function / method is called, the DLL name / interface name / method name / call time is stored in the HDD (step S2002). All parameters are stored in the HDD (step S2003). A method of the main body is called (step S2004).
[0052]
When the processing inside the method ends, the DLL name / interface name / method name / end time is stored in the HDD (step S2005), and the parameters and return values for the call are stored in the HDD (step S2006). .
[0053]
Next, it is determined whether or not the parameter is defined as a pointer to the interface based on the function definition file shown in FIG. 18 (step S2007). If the parameter is defined, a log for the pointer is acquired on the memory. A code is generated (step S2008), and the corresponding parameter or return value is rewritten to the memory address of the log acquisition code (step S2009). If it is determined that the process of step S2009 is completed or not defined as an interface pointer in step S2007, a function return process is performed (step S2010).
[0054]
This process is continued until the program to be evaluated ends (step S2011).
[0055]
By redirecting the pointer to the interface instance returned to EXE as a parameter or return value by the method, the method is called by using the pointer, for example, Method of Interface B in FIG. Also for a BA call, parameters / return values / time and the like can be recorded as shown in FIG.
[0056]
[Fifth Embodiment]
FIG. 21 is a diagram showing a flow of processing in the software evaluation system according to the embodiment of the present invention, which is an example different from FIG.
[0057]
When the processing is started (step S2121), each time the set function / method is called, the DLL name / interface name / method name / calling time is stored in the HDD (step S2122). All parameters are stored in the HDD (step S2123). A method of the main body is called (step S2124).
[0058]
When the processing inside the method ends, the DLL name / interface name / method name / end time is stored in the HDD (step S2125), and the parameters and return value for the call are stored in the HDD (step S2126). . Next, it is determined whether or not the parameter is defined as a pointer to the interface based on the function definition file shown in FIG. 18 (step S2127). If defined, the interface is written in the trace scenario. .
[0059]
It is determined whether it is a trace target (log acquisition target) (step S2128, step S2129). If it is determined that it is a trace target, a log acquisition code for the pointer is generated on the memory (step S2130), and the corresponding parameter or return value is rewritten to the memory address of the log acquisition code (step S2131). When the process of step S2131 ends, or when it is determined that it is not defined as an interface pointer in step S2127, or when it is determined that it is not a trace target in step S2129, a function return process is performed (step S2132). ).
[0060]
This process is continued until the program to be evaluated ends (step S2133).
[0061]
Unlike the fourth embodiment, in the fifth embodiment, the log acquisition code is generated and the address is redirected only when the parameter or the return value is to be traced. It is effective in preventing a decrease in processing speed of EXE and DLL.
[0062]
[Other Embodiments]
Note that the present invention can be applied to a system including a plurality of devices (for example, a host computer, an interface device, a reader, and a printer), and a device (for example, a copying machine and a facsimile device) including a single device. You may apply to.
[0063]
Another object of the present invention is to supply a storage medium storing software program codes for implementing the functions of the above-described embodiments to a system or apparatus, and the computer (or CPU or MPU) of the system or apparatus stores the storage medium. Needless to say, this can also be achieved by reading and executing the program code stored in the.
[0064]
In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiment, and the storage medium storing the program code constitutes the present invention.
[0065]
As a storage medium for supplying the program code, for example, a floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, magnetic tape, nonvolatile memory card, ROM, or the like is used. be able to.
[0066]
Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) operating on the computer based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.
[0067]
Further, after the program code read from the storage medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing.
[0068]
【The invention's effect】
As described above, according to the present invention, it is possible to easily obtain a processing log of software divided into a plurality of modules, and to reduce the man-hours for analyzing the cause of software failure.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of a computer (software evaluation system) that implements a log acquisition method according to a first embodiment of the present invention.
FIG. 2 is a diagram showing a normal memory configuration at the time of loading a function, for explaining a log acquisition method according to the first embodiment of the present invention;
FIG. 3 is a diagram showing a memory configuration when using the IAT Patch of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention;
FIG. 4A is a diagram showing a state when using the IAT Patch of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention;
FIG. 4B is a diagram showing a flow of log acquisition processing of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention;
FIG. 5 is a diagram showing an internal configuration when using the IAT Patch of the software evaluation system according to the first embodiment of the present invention.
FIG. 6 is a diagram showing a normal memory configuration at the time of creating an instance of a COM server interface, for explaining a log acquisition method according to the first embodiment of the present invention;
FIG. 7 is a diagram showing a memory configuration when using the VTable Patch of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention;
FIG. 8A is a diagram showing a state when using the VTable Patch of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention;
FIG. 8B is a diagram showing a flow of log acquisition processing of the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention;
FIG. 9 is a diagram showing an internal configuration of a software evaluation system that implements a log acquisition method according to the first embodiment of the present invention;
FIG. 10 is a diagram of a function definition file for instructing the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention, the format of each function and method parameter, and the format of a return value; It is a figure which shows an example.
FIG. 11 is a diagram showing an example of a log acquired by the software evaluation system that implements the log acquisition method according to the first embodiment of the present invention.
FIG. 12 shows how a memory is created when an interface instance is created when a place gap exists in the virtual address table for the software evaluation system that implements the log acquisition method according to the second embodiment of the present invention; It is a figure which shows the example of whether it is loaded.
FIG. 13 is a diagram illustrating a memory evaluation configuration of a log acquisition code when a place gap exists in a virtual address table for a software evaluation system that implements a log acquisition method according to a second embodiment of the present invention; It is a figure showing how to be placed.
FIG. 14 is a diagram showing a flow of processing in a software evaluation system that implements a log acquisition method according to a second embodiment of the present invention;
FIG. 15 is a diagram of a function definition file for instructing the software evaluation system that implements the log acquisition method according to the second embodiment of the present invention, the parameter format of each function and method, and the format of a return value; It is a figure which shows an example.
FIG. 16 is a diagram illustrating an example of a log acquired by a software evaluation system that implements a log acquisition method according to the second embodiment of the present invention;
FIG. 17 is a flowchart of processing when loading a memory in a software evaluation system that implements a log acquisition method according to a third embodiment of the present invention;
FIG. 18 is a diagram of a function definition file for instructing the software evaluation system that implements the log acquisition method according to the fourth embodiment of the present invention, the format of each function and method parameter, and the format of a return value; It is a figure which shows an example.
FIG. 19 is a diagram illustrating an example of a log acquired by a software evaluation system that implements a log acquisition method according to the fourth embodiment of the present invention;
FIG. 20 is a diagram showing a flow of processing in a software evaluation system that implements a log acquisition method according to a fourth embodiment of the present invention;
FIG. 21 is a diagram showing a flow of processing in a software evaluation system that implements a log acquisition method according to a fifth embodiment of the present invention;
[Explanation of symbols]
1: CPU
2: Chipset
3: RAM
4: Hard disk controller
5: Display controller
6: Hard disk drive
7: CD-ROM drive
8: Display
11: Signal line connecting CPU and chipset
12: Signal line connecting chipset and RAM
13: Peripheral device bus connecting chipset and various peripheral devices
14: Signal line connecting hard disk controller and hard disk drive
15: Signal line connecting hard disk controller and CD-ROM drive
16: Signal line connecting display controller and display

Claims (8)

A dynamic link library that stores functions, an import function address table that stores addresses of the functions, a program storage unit that stores a target program that calls and executes functions in the dynamic link library, and a memory that stores programs a medium, and logging means logs are recorded, and a means for executing the program, and rewriting means for the execution unit is realized by executing a program stored in the storage medium, calling means A log acquisition method for acquiring a log during execution of the target program,
The rewriting means loads a log acquisition function corresponding to each function in the dynamic link library into the dynamic link library and stores it in the import function address table before executing the target program. Rewriting the address of each function to the address of the corresponding function for log acquisition;
The call means is configured to acquire the log based on the address of the corresponding function for log acquisition after rewriting on the import function address table for the function to be called that the target program is to call. Starting a log acquisition means realized by calling a function and causing the execution means to execute;
The log acquisition unit records a log related to a call by the calling unit in the log recording unit, calls the function to be called corresponding to the function for log acquisition called by the calling unit, and Causing the execution means to execute a function to be called;
The log acquisition unit includes a step of receiving an execution result of the function to be called, recording a log related to the execution result in the log recording unit, and passing the execution result to the target program. Log acquisition method.   The log acquisition method according to claim 1, wherein the log related to the call includes at least one of a function name of the function to be called, a call time, and a call parameter.   The log acquisition according to claim 1, wherein the log related to the execution result includes at least one of a time when the execution result is received, a parameter when the execution result is received, and a return value when the execution result is received. Method.   The information processing apparatus further includes scenario storage means for storing a setting scenario. In the rewriting step, among the addresses of the functions stored on the import function address table, the setting scenario is set as the log acquisition target. The log acquisition method according to claim 1, wherein the address of the function that has been set is rewritten. An interface that stores methods, the virtual address table storing an address of the method, a program storage means for storing a target program to be executed by calling a method in the interface, and a storage medium for storing a program, logs Information comprising: a log recording means to be recorded; an execution means for executing a program; the rewriting means realized by the execution means executing a program stored in the storage medium; and a calling means In a processing apparatus, a log acquisition method for acquiring a log during execution of the target program,
Before executing the target program, the rewriting means loads a method for log acquisition corresponding to each method in the interface into the interface , and stores the address of each method stored in the virtual address table, Rewriting the address of the corresponding method for acquiring the log;
The calling unit calls the method for acquiring the log and causes the execution unit to execute based on the rewritten address on the virtual address table for the method to be called that the target program is to call. Starting the log acquisition means realized by
The log acquisition unit records a log related to a call by the calling unit in the log recording unit, calls the method to be called corresponding to the method for log acquisition called by the calling unit, and Causing the execution means to execute a method to be called;
The log acquisition unit includes a step of receiving an execution result of the method to be called, recording a log related to the execution result in the log recording unit, and passing the execution result to the target program. Log acquisition method.   The log acquisition method according to claim 5, wherein the log related to the call includes at least one of a method name of the called method, a call time, and a call parameter.   The log acquisition according to claim 5, wherein the log related to the execution result includes at least one of a time when the execution result is received, a parameter when the execution result is received, and a return value when the execution result is received. Method.   The information processing apparatus further includes scenario storage means for storing a setting scenario. In the rewriting step, among the method addresses stored on the virtual address table, the setting scenario is set as the log acquisition target. 6. The log acquisition method according to claim 5, wherein a method address is rewritten.

Images