DE102009038177A1 - Tracing in a running computer system - Google Patents

Abstract

The present invention relates to a method for dynamically activating a trace with respect to a subroutine running on a computer system which is operated by an operating system kernel, the subroutine comprising a multiplicity of instructions and being located in machine code in a working memory of the computer system, and one of these instructions or a sequence of these instructions represents an idle instruction having a size in machine code that is at least equal to the size of the machine code of a jump instruction, the method comprising: loading the machine code of a trace module into the memory of the computer system; Replacing the machine code of the empty instruction of the subroutine in the working memory with the machine code of a jump instruction which enables a program control flow to be redirected to the tracing module in the working memory; Redirecting, after calling the subroutine by a calling program, the program control flow to the trace module by the jump instruction; Registering entry into the subroutine by the trace module and returning the program control flow to the subroutine.

Description

The present invention relates to a dynamically activatable trace of a subroutine in a running computer system.

Subprograms, sometimes referred to as functions, procedures, routines, or subroutines, represent self-contained sets of instructions of a program which can be called from the running program and, after execution of the instructions in the respective subroutine, return to the calling location in the program Return program. The program may represent the operating system operating the computer, a specific module of this operating system, an application program running on the computer with the aid of the operating system or a specific module of this application program.

If errors occur during the execution of such programs, it is necessary to find out the cause of this error. This applies in particular to the development phase of a program or program module, in order to recognize and eliminate as many sources of error as possible in good time, before the program or program module is completed and delivered. However, it is also necessary for the later application phase of a program or program module to detect error causes occurring in a specific environment and possibly be able to clean them up. For this purpose, the so-called tracing is used, which registers the entry into a specific subroutine and the exit from this subroutine, so that when an error occurs in the course of a program or program module can determine which subroutine the error has occurred. The entry or exit can be registered by a chronological logging or recording, counting up or down a counter or another measure that allows an assignment to the respective subroutine.

In order to enable the tracing of a subroutine, it is necessary to instrument this subroutine. This can be achieved by introducing special instructions into the program code already during the program creation which later enable the trace. However, a trace is only possible for such subroutines of a program for which this was already provided during the programming and in which thus the instructions necessary for the trace are already in the program code at compile time.

It is also possible to instrument a subroutine after compilation of the corresponding program or program module for a trace. For such dynamic instrumentation, it is necessary to manipulate the machine code of the program already resident in the main memory of the computer system. It should be noted that the machine code of a compiled program or program module represents a coherent bit sequence and therefore additional instructions can not be easily inserted into the machine code without damaging its integrity.

To prevent such damage, proposes the US 7,047,521 B2 It is known in the prior art to overwrite the initial instructions of a subroutine in machine code which is to be dynamically instrumented for a trace with a jump instruction and to copy the initial instructions displaced by the jump instruction into a buffer memory. Upon invocation of the subroutine, the control flow through the jump instruction is directed to a trace program that logs entry into the subroutine and then redirects the control flow to the buffer containing the instructions displaced by the jump instruction. After execution of these instructions, the instruction of the subprogram which follows the displaced instructions is jumped back to. After inserting the jump instruction and storing the displaced instructions in a buffer memory, the functional integrity of the subroutine is restored.

A disadvantage of this method, however, is that for the period in which the instructions to be displaced are written into the buffer memory and instead of the jump command is inserted, the functional integrity of the subroutine is not given. Since after completion of the trace program all changes made in the machine code must be reversed, ie in particular the instructions contained in the buffer memory must be written back, the functional integrity of the subroutine is not given for this period. However, such temporary damage to the functional integrity may lead to the abort of the subroutine and also of the calling program. In addition, the actual execution behavior of the subroutine can be impaired by the necessary switching back and forth of the displaced instructions in the main memory, whereby the significance of the data obtained by the trace is questioned. Another disadvantage of this method is that in the case of an exception occurring at the end of the subroutine, which is not within the scope of the invention Subroutine can not be handled, the subroutine will not shut down normally without this completion being recorded. This complicates the error analysis that is actually intended by the trace. The object of the present invention is to enable an improved dynamically activatable trace of a subroutine running on a computer system.

This object is solved by the subject of the main claim.

Preferred embodiments of the present invention are subject matters of the subclaims.

The invention is based on the observation that many subroutines contain empty instructions consisting of an empty instruction or a sequence of empty instructions which do not affect the actual function of a subroutine but have been inserted into the subroutine for other reasons. One reason for inserting empty statements is z. Example, to influence the timing of a subroutine so that it is ensured that certain time requirements are met to and by the subroutine, the program and / or the operating system. The insertion of empty instructions is a common measure, as it affects the timing behavior of the subroutine, but not the registers and memory values managed by the subroutine. Another reason for inserting empty instructions is z. Example is to align the machine code in memory so that the subsequent access is optimized. In addition, by inserting an empty instruction, the respective subprogram can be prepared for later dynamic updating. So z. B. for operating system components, ie subroutines of Windows NT ^® , which are assumed from the beginning that they must be updated later by a corrected subroutine, a so-called patch, already inserted in the programming at the beginning of such a subroutine an empty statement which corresponds to the size of a jump instruction. If a patch is available later, it can be loaded into the main memory and the program control flow can be dynamically redirected by overwriting the empty instruction with a jump instruction to this patch (so-called "hot-patching").

The present invention is based on the idea to exploit the presence of such empty statements in the code of a subroutine for the purpose of tracing. For this purpose, in a subroutine contained in a main memory of a computer system in machine code and containing an idle instruction consisting of a dummy instruction or a sequence of dummy instructions, the dummy instruction is replaced by a jump instruction which, upon invocation of the subroutine, redirects the program control flow to a trace module which has been previously placed in the main memory. The trace module registers entry to the subroutine and then returns the program control flow to the instruction of the subroutine following the replaced empty instruction.

Preferably, before overwriting the dummy instruction, it is ensured that it is not a jump target of a jump instruction contained in the subroutine. This will generally not be the case with subroutines that have been programmed for the later dynamic update, but may well be the case if the dummy instruction has been inserted for timing reasons. Therefore, preferably, a management application identifies the subprograms residing in the main memory of the computer system which contain an idle instruction having a length in the machine code which corresponds to at least a length of the machine code of a jar instruction and which is not the target of a jar instruction located in the subroutine. The management applications can such subroutines z. B. by comparing the in-memory subroutines with a list of subroutines that are known to contain a suitable empty statement and also where they contain them. The management application can such subroutines z. B. but also by analyzing their memory in machine memory code. If an empty instruction of sufficient length is not at the beginning but rather at a later point in a subprogram, then the instructions occurring before the empty instruction must not be the target of a jump instruction. In this regard, it should be noted that in a subroutine having a suitable empty instruction at the beginning, entry into this subroutine can be accurately registered, whereas in a subroutine where a suitable empty instruction is later in the code, the entry into the subroutine is delayed registered. Nevertheless, the information gained thereby can provide valuable services in fault analysis.

According to a preferred embodiment of the present invention, the machine code of an already in-memory subroutine at runtime of the associated program by replacing a subroutine in the empty instruction by a jump instruction that refers directly or indirectly to a trace module, which is also in the machine code in Memory is instrumented for a dynamic trace by the trace engine. The trace module registers entry into the subroutine and manipulates the entry associated with the subroutine in a call stack such that the associated return address is replaced with an address of an exit routine provided by the trace module. In addition, an auxiliary stack is generated, which receives the displaced from the call stack memory original return address and allows the exit routine after the completion of the correct return to the program calling the subroutine.

In a preferred embodiment of the present invention, not only the entry into a subroutine is registered by the trace module, but also the exit from it. For this purpose, the return address stored in a call stack when the subprogram is called up is replaced by an address which allows the program control flow to be redirected to an exit routine of the trace module. As a result, after execution of the instructions located in the subroutine, the program control flow is diverted to the exit routine, which registers the exit from the subroutine and then forwards the program control flow to the original return address stored in an auxiliary stack.

In a preferred embodiment of the present invention, the trace module also takes into account the occurrence of exceptions and their treatment. For this purpose, when a subroutine is called, an exception handling function provided by the trace module is registered. Register means in this context that information regarding the exception handling function is stored in a known location. If a non-regular termination of the subroutine is necessary due to an exception that has occurred, this is registered by the exception handling function of the trace module.

Preferably, for this purpose, a stored address in a top entry in an exception handler registration chain containing addresses or pointers to exception handling functions registered in connection with called subroutines is replaced with the address of the exception handler provided by the trace module and stored instead in an auxiliary stack. When an exception occurs, the exception handling function of the trace module is called by the address stored in the exception handler registration chain entry, which in turn calls the originally registered exception handler function using the address stored in the helper stack. The exception handling function of the trace module ensures that in the case of a handling of the call stack caused by the exception that has occurred, no entries no longer required remain in the auxiliary stack.

Preferably, the exception handler function of the trace module, after being called, causes a temporary registration of another exception handler that acts as a cleanup and logger. If the occurrence of the exception causes the call stack to be processed, this additional exception handling function is accessed, which carries out the handling of the auxiliary stack and, if necessary, registers it.

Further advantages and preferred embodiments of the present invention will become apparent hereinafter with reference to the accompanying drawings. The drawings as well as the following detailed description are not intended to limit the scope of the invention defined in the claims but to facilitate an understanding of the features and advantages of the invention.

The drawings show in detail:

1 a schematic representation of a generation of machine code from a source code of a program;

2a a schematic representation of a program control flow between a program and two subroutines according to the prior art;

2 B a schematic representation of the contents of a call stack storage during the in 2a illustrated program control flow according to the prior art;

3a a schematic representation of a subroutine and a call stack storage at runtime according to the prior art;

3b a schematic representation of a subroutine, a trace module, a call stack and an auxiliary stack at run time according to a preferred embodiment of the present invention;

4a a schematic representation of a program control flow between a program, two subroutines and a Trace module according to a preferred embodiment of the present invention;

4b a schematic representation of the contents of a call stack storage during the in 4a illustrated program control flow according to a preferred embodiment of the present invention;

5 a schematic representation of an exception treatment according to a preferred embodiment of the present invention;

6 a schematic representation of a registration of an exception handling function of a trace module according to a preferred embodiment of the present invention;

7 a schematic representation of an exception treatment using a transaction flag according to a preferred embodiment of the present invention;

8th a schematic representation of a trace module according to a preferred embodiment of the present invention;

9 a schematic representation of a trace in the user mode according to a preferred embodiment of the present invention; and

10 a schematic representation of a trace in operating system kernel mode according to a preferred embodiment of the present invention.

1 schematically illustrates how machine code is generated from the source code of a program. Programs are typically written by a programmer in a high level language, e.g. Fortran, C, C ++ or Java, which allow the programmer to understand and processor architecture-independent programming. In order to run a high-level language program on a particular computer, it is necessary to translate that program into a machine language corresponding to the processor architecture, ie, the machine instruction set and the addressing modes of the underlying microprocessor, among other things.

1 shows the source code 100 a program. The source code usually consists of a main program part 102 and various subroutine parts 104 . 106 and 108 , A compiler 120 translates the various program parts of the source code into different object code modules 142 . 144 . 146 and 148 , wherein the object code corresponds to the machine language of the underlying microprocessor. A binder 160 , also called linker, connects the various object code modules 142 . 144 . 146 and 148 and possibly needed additional library modules from a library 170 such that a machine program executable by the microprocessor 180 created in machine code. The machine code of the machine program 180 represents a related binary sequence, which is loaded into the memory of the computer system. Accordingly, the machine code is located 180 at runtime of the program in the main memory of the computer system and is processed by the processor of the computer system according to the present binary sequence.

The binary sequence of the machine code 180 corresponds to a sequence of instructions executable directly by the processor, which are executed by the processor one after the other. However, by jump instructions the program control flow can be between different parts of the machine code 180 be turned back and forth. In addition, the machine program contains 180 several sequences of instructions that are a main program 182 and several subroutines 184 correspond. A subprogram can be called from the main program or another subroutine. In addition, the machine program contains 180 additional Information 186 which are required by the main program and / or subroutines when exceptions occur during program execution.

2a shows an exemplary program control flow between a main program HP 200 and two subprograms UPX 220 and UPY 240 , The processor works at first all Instructions of the main program HP 200 one after the other. By a call instruction 202 to the subroutine UPX 220 the program control flow becomes the first instruction 222 subprogram UPX 220 redirected (S1). The instructions of subroutine UPX 220 are processed consecutively until a call instruction 224 the program control flow to the first instruction 242 of the subroutine UPY 240 redirects (S2). The instructions of subroutine UPY 240 are processed one after the other. At the end 248 of the subroutine UPY 240 a return S3 to the calling subprogram UPX 220 causes. At the same time the instruction becomes 226 subprogram UPX 220 jumped back, the call instruction 224 follows. The further instructions of subroutine UPX 220 are then processed sequentially. At the end 228 subprogram UPX 220 a return S4 to the instruction 204 of the main program HP 200 causes the call instruction 202 follows. Subsequently, the further instructions of the main program HP 200 processed one after the other.

In order to allow a called subroutine to return to the calling program, a call stack is usually used. A call stack represents a dynamic data structure that stores information about active subroutines of a running computer program. If a subprogram is called, a suitable return address is placed on the call stack. Upon completion of the subroutine, the return address is again removed from the call stack and used for a return. 2 B shows the example of in 2a program control flow segments shown how the call stack changes during the course of a computer program.

segment 200A of in 2a shown program control flow of 2a extends to the call instruction 202 of the main program part HP 200 , There are no subroutines active. The call stack 280 is therefore free from entries related to subroutine calls. By the call 202 becomes a redirection S1 of the control flow to the instruction 222 subprogram UPX 220 causes. The address of the call 202 following instruction 204 in the main program HP 200 gets into the call stack 280 placed. In segment 200B the program control flow containing the instructions 222 to 224 Therefore, it is located in the call stack 280 the entry 282 which returns the return address RSA_HP for instruction 204 of the main program HP 200 contains. By the call 224 becomes the subroutine UPY 240 from the subroutine UPX 220 called. The program control flow is the instruction S2 through the reversal S2 242 of the subroutine UPY 240 redirected and the address of the call 224 following instruction 226 of the subroutine UPY 240 into the call stack 280 in a new entry 284 placed. In segment 200C the program control flow containing the instructions of the subroutine UPY 240 Therefore, it is located in the call stack 220 An entry 282 with the previously stored therein return address RSA_HP to the main program HP 200 and then a new entry 284 with the newly stored return address RSA_UPX to the subprogram UPX 220 , At the end of the subroutine UPY 240 a return S3 is made to the address in the currently highest entry of the call stack 280 is stored, so in the entry 284 stored address RSA_UPX, and the top entry 284 removed from the call stack. In segment 200D the program control flow containing the instructions 226 to 228 subprogram UPX 220 Therefore, there is only the entry 282 in the call stack 280 , Upon completion of subroutine UPX, a return is also made to the address in the currently top entry of the call stack 280 is stored, so in the entry 282 stored return address RSA_HP for instruction 204 of the HP 200 , The return S4 to the instruction 204 of the main program HP 200 is done and the entry 282 from the call stack 280 away. Thus, the call stack includes memory 280 in segment 200E the program control flow, that with instruction 204 of the main program HP 200 starts, no entries related to active subprograms.

At this point it is noted that 2 B contains simplified representations of a call stack. Thus, an entry associated with an active subroutine in the call stack may not only contain the return address to the particular calling program, but may also contain other information such as: For example, parameter values passed by the calling program or information about exception handling. An entry in a call stack associated with a subroutine is therefore also referred to as the call frame of this subroutine. In addition, the call stack memory can be generated dynamically at the start of the main program and also information for the main program z. With respect to basic exception handling.

3a schematically shows a subroutine UPX 300 and a call stack 330 at runtime of a program containing the subprogram UPX.

In the call stack 330 There are already several entries 332 . 334 and 336 , The lowest entry 332 contains a return address RSA_HP to the main program and was stored in connection with the oldest active subroutine. entry 336 includes the return address RSA_UPX-1 to a subroutine UPX-1, from which the subroutine UPX 300 was called, and was associated with the call of the subprogram UPX 300 stored. The subprogram UPX 300 represents the most recent active subroutine. A subroutine is called active if it has been called but has not yet ended.

The subprogram UPX 300 of the 3a was called by subroutine UPX-1, which is why the associated call batch entry 336 contains the return address RSA_UPX-1. Between the top entry 336 , which corresponds to the most recent active subroutine and the lowest entry 332 , which corresponds to the oldest active subroutine, can have additional entries 334 which correspond to further active subroutines. It is known to the person skilled in the art that two different entries on the call stack are quite similar to the same subroutine of the machine program 180 which has been called at different times at runtime of the machine program and therefore different runtime subprograms UPX, UPY, ... corresponds.

The subprogram UPX 300 designated in 3a the most recent active, ie last called and not finished subroutine. As soon as the instructions of the subprogram UPX 300 The program control flow returns to the address RSA_UPX-1 of subprogram UPX-1 stored in the call stack, which contains the subroutine UPX 300 has called. The subprogram UPX 300 associated entry 336 the call stack 330 is removed from the call stack, as already in connection with the 2a and 2 B was described in more detail.

The first instructions 302 to 304 subprogram UPX 300 make an idle statement 310 through the instructions 302 to 304 It is illustrated that the empty instruction is either that from an instruction 302 or several instructions 302 to 304 can exist. In the former case would thus be the empty instruction 310 the first instruction 302 correspond and the instruction 304 eliminated. Empty instructions correspond to instructions which, when executed, do not change any processor registers or memory values and thus have no influence on the instructions provided by the UPX subprogram 300 have provided functionality. However, they consume a certain number of processor cycles for their processing, which is why they are often used for timing reasons. In addition, they may be included for memory alignment purposes or may serve as placeholders for a later jump instruction to a patch, if already during the programming of the UPX subprogram 300 was provided. The exact configuration of such an empty instruction depends on the instruction set of the respective underlying processor architecture. An empty instruction can already be provided as an empty instruction in one instruction set, be simulated by another instruction by means of a suitable choice of its operands, or be implemented by a suitable concatenation of instructions which correspond in total to an empty instruction. In the case of the operating system Windows NT in the version for the Intel x86 architecture (32 bit, IA-32) is z. For example, in subroutines that are provided for a later hot-patching, usually at the beginning of an instruction "MOV edi, edi", which represents an empty instruction and in the case of hot-patching by a short jump instruction ("in the case from IA-32 2 bytes) can be replaced; both commands have the same memory size. The short jump instruction does not direct the control flow directly to the corrected subprogram, but instead means "jump near", which in the case of IA-32 comprises 5 bytes, by means of a long jump instruction placed in a buffer program preceding the hot patching. Since the long jump instruction is immediately preceded by the subroutine, the address of the first instruction of the subroutine is placed on the call stack, from which the address of the second instruction of the subroutine and thus the return address can be easily derived.

3b schematically shows how the subroutine UPX 300 and the call stack 330 In accordance with a preferred embodiment of the present invention, a trace of subroutine UPX is changed 300 to enable.

In order to track the program flow of a subroutine which has already been loaded into a working memory of a running computer system in machine code, an empty instruction in the machine code of the subroutine to be tracked is replaced by a jump instruction which, upon invocation of the subroutine, places the program control flow into a memory inserted into the main memory Trace module redirects. This redirection can be done directly by defining the trace module as the jump destination of the jump instruction, or indirectly via another instruction, as shown above with reference to the short jump / long jump combination. For the sake of a simple presentation of the facts, the following is usually referred to as a jump instruction which redirects the program control flow without distinguishing between direct and indirect diversion. However, it will be apparent to those skilled in the art that both direct and indirect deflection are in accordance with the present invention.

In 3b is the jump instruction JMP_AVM 325 shown in the subprogram UPX 300 the from the instructions 302 to 304 existing original empty instruction 310 repressed. The empty instruction 310 and the jump instruction 325 have the same length in machine code. The jump instruction 325 directs the program control flow to an entry routine ER 360 um, by a trace module AVM 350 is provided, which has been introduced into the main memory of a computer system. The jump instruction can be directly to the entry routine ER 360 refer as in 3a represented, or on a central module ZM 355 within the trace module AVM 350 that the Program control flow between components of the trace module AVM 350 controls.

The entry routine ER 360 registers the entry into subprogram UPX 300 and then directs the program control flow to the instruction 312 subprogram UPX 300 um, the jump statement JMP_AVM 325 and thus the displaced empty instruction 310 follows. In this case, the admission can be registered by chronologically logging or recording, incrementing a counter or another measure which allows an assignment to the respective subprogram.

In addition, the trace module AVM provides 350 for the fact that also the exit from the subprogram UPX 300 can be logged. To do this, the trace module replaces AVM 350 the ones in the call stack 330 stored return address RSA_UPX-1 for subprogram UPX 300 in the entry 336 with an address RSA_AR indicating the control flow after the completion of subroutine UPX 300 not to the subprogram UPX 300 but to one of the trace module AVM 350 provided exit routine AR 370 , The by the return address RSA_AR in the entry 336 the call stack 330 displaced return address RSA_UPX-1 is in a top entry 394 in a utility stack 390 stored. The auxiliary stack can contain additional entries 392 which refer to further run-off, still active subprograms. The exit routine AR 370 the trace module AVM 350 registers the exit from the subroutine UPX 300 and then redirects the control flow to the address in the top entry 394 the auxiliary stack 390 is stored, that is to the address RSA_UPX-1. As in connection with the entry routine ER 360 described this address RSA_AR directly to the exit routine AR 370 refer or to a central module ZM 355 the trace module AVM 350 , In this case, the exit can be registered by chronological logging or recording, counting down of a counter or another measure which allows an assignment to the respective subprogram.

It should be noted at this point that the techniques described herein in connection with the present invention are also suitable for a multithreaded environment. In such an environment, it is preferred that only a single empty instruction be displaced by the jump instruction, which redirects the control flow to the trace module, in order to avoid problems associated with so-called "preempted threads". In this case, the short jump / long jump combination illustrated above is preferably used since the length of a single instruction is usually not sufficient to jump to the trace module. In 3 would this have z. B. result in that the empty instruction 310 only the first instruction 302 subprogram UPX 300 and by the jump instruction JMP_AVM 325 is displaced, but not directly, but indirectly on the entry routine ER 360 the trace module AVM 350 points.

In 4a a control flow diagram is shown schematically, which when calling a subroutine UPX 420 from a main program HP 410 and a call to a subroutine UPY 430 from the subroutine UPX 420 occurs when subroutines UPX and UPY are executed in accordance with the present invention.

4b illustrates the states of the call stack and the help stack for individual segments 400A to 400H the program control flow according to 4a ,

The instructions 412 a major program HP 410 are processed one after the other. There are no subprograms active, therefore they are in the call stack 480 no entries for active subroutines ( 400A ). In instruction 413 of the main program HP 410 a call is made to a subroutine UPX 420 , As a result of this call is placed in the call stack 480 an entry or frame 482 for the called subroutine UPX 420 created ( 400B ) by calling the return address RSA_HP as the address of the call 413 following instruction 414 of the main program HP 410 is located, and to the beginning 422 subprogram UPX 420 jumped (S1). Subprogram UPX 420 was related to the earlier 3b instrumented for tracing and thus includes as a first instruction 422 a jump instruction JMP_AVM to one of the trace module AVM 440 provided entrance routine ER 450 , The address of the jump instruction 422 following instruction RSA_UPX_ 423 subprogram UPX 420 is preferably stored in a register, but may also be on the call stack of the call stack 480 get saved. After the jump (S2), the entry routine replaces ER 450 the address RSA_HP in the subroutine UPX 420 associated entry 482 the call stack 480 by an address RSA_AR, which is at the beginning of one of the trace module AVM 440 provided exit routine AR 460 points. The return address RSA_HP is instead in an entry 492 in a utility stack 490 filed ( 400C ). The entry routine ER 450 reads the address RSA_UPX_ 423 from the register or the call stack and in the latter case removes the address RSA_UPX_ 423 again from the call stack. The admission routine 450 registers the entry into subprogram UPX 420 and jumps with the help of the read address RSA_UPX_ 423 to instruction 423 subprogram UPX 420 (S3).

Thereupon the instructions become 424 subprogram UPX 420 executed until instruction 425 a subroutine UPY 430 is called. The address of the call 425 following instruction 426 of the subroutine UPY 430 is in the call stack 480 in a called subroutine UPY 430 associated entry or frame 484 stored as a return address RSA_UPX ( 400D ) and it gets to the beginning 432 of the subroutine UPY 430 jumped (S4). Subroutine UPY has been developed in accordance with the 3b instrumented for tracing. That's why it's at the beginning 432 of the subroutine UPY 430 a jump instruction to the entry routine ER 450 the trace module AVM 440 , The jump instruction 432 following instruction RSA_UPY_ 433 of the subroutine UPY 430 is preferably stored in a register, but may also be on the call stack of the call stack 480 get saved. After the jump (S5) to the entry routine ER 450 this reads the return address RSA_UPY_ 433 from the register or the call stack, in the latter case the return address RSA_UPY_ 433 is removed from the call stack. The return address RSA_UPX in the subprogram UPY 430 associated entry 484 in the call stack 480 is determined by the address RSA_AR, which indicates the beginning of the exit routine AR 460 the trace module AVM 440 refers, replaces, and the return address is RSA_UPX in the auxiliary stack 490 in a new entry 494 saved ( 400E ). The entry routine ER 450 registers the entry into the subroutine UPY 430 , After completion of the entry routine ER 450 is sent to the previously read address RSA_UPY_ 433 of the subroutine UPY 430 jumped back (S6).

Thereupon the instructions become 434 of the subroutine UPY 430 processed sequentially. At the end 435 of the subroutine UPY 430 is jumped to the address in the top entry of the call stack 480 is stored (S7). This is the address RSA_AR in the entry 484 the call stack is stored. Therefore, as usual, the control flow to the subprogram UPX is not 420 which is the subprogram UPY 430 but returned to one of the trace module AVM 440 provided exit routine AR 460 , The top entry 484 becomes from the call stack memory 480 away ( 400F ). The exit routine 460 registers the exit from the subroutine UPY 430 and then jump back to the address (S8) in the top entry 494 the auxiliary stack 490 is stored, that is, to the address RSA_UPX, that of the instruction 426 subprogram UPX 420 equivalent. The top entry 494 becomes from the auxiliary stack 490 away ( 400G ).

The instructions 427 subprogram UPX 420 are then executed sequentially and at the end 428 subprogram UPX 420 is then jumped to the address in the top entry of the call stack 480 is stored (S9). This, in turn, is the address RSA_AR which is the beginning of the exit routine AR 460 the trace module AVM 440 equivalent. The top entry will be from the call stack 480 removed so that there are no more active subprograms in the call stack memory at this time ( 400H ). The exit routine AR 460 registers the exit from the subroutine UPX 420 and then returns the control flow to the address in the top entry of the auxiliary stack 490 is stored (S10). This is the address RSA_HP, that of the instruction 414 of the main program part corresponds to the entry 492 the auxiliary stack 490 , This will be the entry 492 from the auxiliary stack 490 removed, which is empty at this time. Thereupon the further instructions become 415 of the main program part HP 410 processed sequentially. As related to 3 the control flow can be described directly or via a central module ZM 445 to and from the entry routine ER 450 or the exit routine AR 460 be steered.

It is again pointed out that the subprograms UPX 420 and UPY 430 introduced jump instruction JMP_AVM direct or indirect diversion to the entry routine ER 450 of the trace module 440 represents. In the case of an indirect diversion by means of a short jump / long jump combination, the addresses RSA_UPX_ would be used as return addresses. 422 and RSA_UPY_ 432 instead of the correct addresses RSA_UPX_ 423 and RSA_UPX_ 433 as a result of the jumps S2 and S5 to the entry routine ER 450 which in turn stores the correct return addresses RSA_UPX_ 423 and RSA_UPX_ 433 derives.

In connection with the 3 and 4 It was shown how a subroutine can be instrumented at runtime and how to register for such subroutine and exit from such subroutine. In 5 Now a mechanism is presented, with which also the occurrence of an exception can be considered.

Exceptions indicate problems that occur during the execution of a program or Subprogram can occur. Typical exceptions show z. Example, the attempt to divide by zero, to access a non-existent memory address or other problem situations that occur during the execution of the program or subroutine. Exceptions can be handled by special exception handling functions. Upon successful handling of an exception, the interrupted program execution may be taken either at a location within the subroutine in which the exception occurred, or at some other stable location in the program code, resulting in a controlled, non-regular termination of the subroutine. If no exception handling function can handle the exception that has occurred, it is usually followed by a crash of the program.

Each subprogram of a program can define a special exception handler that contains instructions on how to proceed when certain exceptions occur. Not every subroutine must necessarily have such an exception handling function, and not every exception handling function usually contains instructions for every conceivable exception.

When a subroutine is called, the corresponding exception handling function of the subroutine is registered, if any, d. H. their address stored in a known, designated place. The registrations of exception handling functions of various subroutines may be stored at this location as a chain of exception handling registrations. If an exception occurs during the execution of this subroutine, the associated registered exception handling function is accessed by means of the stored address. However, if the exception handler fails to successfully handle the exception that has occurred, it checks to see if another exception handler previously registered by another subprogram can handle this exception.

In principle, after a successful exception handling, either the execution of the program can be continued within the subprogram in which the exception occurred, or at another location determined by the successful exception handling function. In the latter case, the call stack is usually handled up to the entry corresponding to the subroutine that registered the successful exception handling function. This form of exception handling via a chain of registered exception handling functions is also referred to as structured exception handling.

In the case of the dynamically activated tracing of subroutines, such a structured exception handling when processing one or more entries or call frames of the call stack of run-tracked subroutines could result in the coherency between call stack and auxiliary stack no longer being present, since entries or subframes become subroutines in the auxiliary stack could remain standing, which are no longer active after processing the call stack. The following with reference to 5 The preferred embodiment of the present invention contemplates the occurrence of exceptions and allows both the occurrence of exceptions that result in call stack handling and / or the call stack handlers caused by them to be maintained, as well as maintaining coherency between the call stack and auxiliary stack.

For this purpose, according to a preferred embodiment of the present invention, the trace module provides its own exception handling function, which is registered in each case before entry of a subroutine to be tracked and deregistered after regular termination thereof. In order to avoid registration by means of its own call frame for the trace module in the call stack, and thus its negative consequence for accesses to parameters addressed by call stack pointer relative offsets by the subroutine to be followed, an existing registration of an exception handling function is adapted. This existing registration corresponds to the exception handling function that would be accessed next in the event of an exception that is not within the tracked subroutine or exception handling function. Accordingly, if an exception handling registration chain is used, this existing registration corresponds to the topmost member or entry in the exception handling registration chain. The adaptation consists of replacing the address of the exception handling function of this existing registration with the address of the exception handling function provided by the trace module. The address of the original exception handling function is stored in an auxiliary stack in an entry or subframe associated with the subroutine to be followed, along with the address of the changed registry.

5 illustrates the consideration of exceptions according to a preferred embodiment of the present invention. In step 510 For example, a subroutine UPX for which a trace has been dynamically activated as shown above is called from a running program. Due to the instrumentation, the program control flow in step 515 redirected to the trace module AVM. The trace module AVM provides its own exception handling function EXC_AVM, which in step 520 registered, ie their address is stored in a designated for this purpose by the operating system in the working memory. 6 shows the flow of such a registration according to a preferred embodiment of the present invention. After registration, entry into the UPX subroutine will be in step 525 registered. This can be accomplished by an entry protocol routine ER within the trace module AVM. The steps performed by the trace module to register the exception handling function EXC_AVM 520 and entry registration 525 can also be reversed in their order. Thereafter, the program control flow to the subroutine UPX in step 530 are returned and the individual instructions of the UPX subroutine are processed. If the subroutine UPX has its own exception handling function EXC_UPX, the execution of the subroutine UPX also includes the registration of the exception handling function EXC_UPX. During the execution of the subroutine UPX, it is monitored whether an exception occurs that can not be successfully handled within the subroutine UPX or by its exception handling function EXC_UPX; this is by step 535 symbolizes. If no such exception occurs up to the end of the subroutine UPX, the exception handling function EXC_UPX registered by the subroutine UPX, if any, is deregistered and the program control flow due to the instrumentation of UPX in step 540 returned to the trace module AVM. The trace module AVM registers the exit from the subroutine UPX in step 545 , This can be z. B. be made by a provided by the trace module exit log routine AR. Then in step 550 the registered exception handling function EXC_AVM deregistered, ie the previously stored at the intended location in the working memory address EXC_AVM removed again. Similar to the steps of registering the exception handling function EXC_AVM 520 and entry registration 525 can also follow the steps of exit registration 545 and deregistration of exception handling function EXC_AVM 550 be reversed in their order. Then in step 555 the program control flow is returned in accordance with the return address ADR_UPX provided for the subroutine UPX, as explained in greater detail above.

However, step in 535 an exception during the execution of the subroutine UPX, which can not be successfully handled within the subroutine UPX or by its exception handling function EXC_UPX, the registered exception handling function EXC_AVM of the trace module AVM in step 560 called. The exception handling function EXC_AVM serves to call the actual exception handling function EXC_UPV of an active subprogram UPV displaced during the registration of the exception handling function EXC_AVM and to ensure that in the case of a necessary handling of the call frame of the subfunction UPX of the call stack memory no entries associated with the subroutine UPX are in an auxiliary stack stay. Therefore, if a call frame assigned to the subroutine UPX is handled, an auxiliary frame assigned to the subroutine UPX is also handled. In addition, the exception handling function EXC_AVM may cause the occurrence of the exception logging, the successful or unsuccessful exception handling by the exception handling function EXC_UPV, and / or the handling of the call frame and the subframe. This will be in 5 by step 565 symbolizes. A detailed example of the interaction of exception handling functions EXC_AVM and EXC_UPV will be discussed below 7 described.

6 shows an example of a registration process for an exception handling function EXC_AVM when the operating system is intended to register exception handling functions as linked entries. This is z. For example, in Windows NT or OS / 2 on Intel 32-bit / IA-32 systems in the context of structured exception handling the case. In this case, after calling a subroutine, the address belonging to the exception handling function provided by this subroutine is stored as the top entry in a chain of exception handling registration entries. In addition, this entry also stores an address or a pointer to the previous top entry of the exception handling registration chain. If, on the occurrence of an exception during a subroutine operation, this exception can not be handled by the exception handling function registered by this subroutine, the previous entry in the exception handling registration chain is skipped and a check is made as to whether the exception handling function registered therein can handle the exception that has occurred. In this way, the exception handling registration chain can be examined from top to bottom until a suitable exception handling function is found.

In this procedure, an address or pointer to the entry in the exception handling registration chain which registers the exception handling function of a subroutine and thus contains its address is stored in the call frame of this subroutine. However, the trace module preferably does not create its own call frame, so that the behavior of the subroutine to be tracked and the runtime environment of the program are as little affected by the dynamically activated trace as possible. In addition, it is preferable to avoid problems in accessing parameters addressed by call stack pointer relative offsets. Therefore, in a preferred embodiment of the present invention, the exception handling function EXC_AVM of the trace module AVM is registered by replacing the address in an already existing top entry in the exception handling registration chain with the address of EXC_AVM. The address of the exception handling function originally registered in the top entry is instead stored in a subframe.

In the in 6 illustrated preferred embodiment of the present invention is in step 610 first checked if the exception handling registration chain is empty. If this is the case, no registration is made ( 630 ), since it is assumed that no call stack transactions occur. However, if the exception handler registration chain is not empty, then in step 615 checks whether the address of the exception handling function EXC_AVM provided by the trace module AVM has already been entered in the top entry of the exception handling registration chain. This can be z. For example, if the top entry in the exception handling registration string corresponds to a previously invoked, still active subroutine that has also been instrumented for tracing by the trace module AVM.

If the address of the exception handling function EXC_AVM has not yet been entered in the top entry of the exception handling registration chain, then in step 620 the address ADR_EXC_UPV stored in the top entry of the exception handling registration string replaces the exception handling function EXC_UPV provided by the subroutine UPV with the address ADR_EXC_AVM of the exception handling function EXC_AVM provided by the trace module AVM, and in step 625 the replaced address ADR_EXC_UPV in the subframe of the subroutine UPX is stored together with an address or a pointer to this entry of the exception handling registration chain. The steps of replacing 620 and saving 625 can be reversed in their order.

Will in step 615 however, it is determined that the address of EXC_AVM is already in the top entry of the exception handler registration chain 635 identifies the subroutine that caused the replacement of the originally registered exception handling function. This identification can z. By the determination of the subframe in which an address or a pointer to this entry is stored in the exception handling registration chain. Then in step 640 stored the address of the identified subframe in the subframe of the subprogram UPX. If an exception occurs during the execution of the subroutine UPX, the exception handling function EXC_AVM is called on the basis of the top entry of the exception handling registration chain. The auxiliary subframe address stored in the subframe of the subroutine UPX, which has made the replacement of the original exception handling function, can be localized and the original exception handling function suppressed by EXC_AVM can be called via the address stored therein.

An exception handling function generally has the following capabilities to deal with an exception that has occurred: (a) successfully handle the exception and return to the subroutine in which the exception occurred; (b) successful handling of the exception, with at least the call-frame of the sub-program in which the exception occurred; and (c) no treatment of the exception. Of particular interest in the context of the trace presented here is how cases (a) to (c) affect the coherence between the call stack and the auxiliary stack.

Case (a) has no effect on the call stack and the auxiliary stack; H. the coherence between the two is guaranteed. In case (c), the exception handler registration chain continues to search for an appropriate exception handling function, i. H. The coherence between the call stack and the auxiliary stack is also not endangered at this time. If a suitable exception handling function is subsequently found which causes the call stack to be processed, the exception handling function EXC_AVM registered in the exception handling registration chain is automatically called again and can thus carry out a corresponding handling of the auxiliary stack, so that the coherency between call stack and auxiliary stack is also preserved.

The situation is different in case (b) when an original exception handler function is invoked indirectly via the exception handling function EXC_AVM registered in the exception handling enrollment chain. If this original exception handling function causes the call stack to be handled, the EXC_AVM exception handling function registered in the exception handler registration chain is not called again because the original exception handler assumes that it is itself registered in the corresponding entry in the exception handling enrollment chain and is not aware of the registration of the EXC_AVM exception handling function this entry has. Therefore, in case (b), the call stack would be handled and the execution of the program resumed at a location provided by the original exception handling function without the auxiliary stack being appropriately handled. To prevent this, a preferred embodiment of the present invention provides for registering another exception handling function EXC_AVM2 provided by the trace module AVM in the exception handling registration chain by the trace module AVM before calling the original exception handling function. As a result, in a transaction initiated by the original exception handling function, the exception handling function EXC_AVM2 is called, which effects a corresponding execution of the auxiliary stack.

7 11 illustrates an example of handling exceptions that occur during the course of a subroutine dynamically instrumented for tracing by the trace module AVM, in accordance with a preferred embodiment of the present invention.

step 710 denotes the execution of a subroutine UPX that has been dynamically instrumented for tracing by the trace module AVM. In addition, according to the above description, an exception handling function EXC_AVM of the trace module AVM was registered. In step 715 it is determined that there is an exception that can not be successfully handled within the subroutine UPX or by an exception handling function EXC_UPX provided by the subroutine UPX. In step 720 Thereafter, the exception handling function EXC_AVM registered by the trace module AVM is called. The exception handling function EXC_AVM in turn causes in step 725 registration of another exception handling function EXC_AVM2 provided by the trace module AVM, and in step 730 the call of the original exception handling function EXC_UPV provided by the active subroutine UPV. In step 735 it is determined whether and with what consequence the exception handling function EXC_UPV can handle the present exception.

If the exception handling function EXC_UPV is able to handle the exception that has occurred in such a way that a return to the subprogram UPX is possible, then the exception handling function EXC_UPV treats the exception accordingly in step 740 , Then in step 745 the exception handling function EXC_AVM2 is deregistered and in step 750 the processing of the UPX subroutine is resumed at the point at which the exception occurred.

If the exception handling function EXC_UPV is able to handle the occurred exception in such a way that a processing of the call stack becomes necessary, then in step 755 the settlement is initiated by the exception handling function EXC_UPV. As a result, in step 760 exception handling function EXC_AVM2 is called because it corresponds to the top entry in the exception handling registration chain. The exception handling function EXC_AVM2 becomes in step 765 the entries made in the auxiliary stack in connection with the subroutine UPX and optionally further active subprograms affected by the execution are deleted and thus the auxiliary frame assigned to the subprogram UPX is processed in the auxiliary stack. The exception handling function EXC_AVM2 can also cause the processing to be registered or logged. In step 770 The call frame of the UPX subroutine is also handled. In step 780 the program execution is resumed at one point in the UPV subroutine.

If the EXC_UPV exception handling function fails to handle the exception that has occurred successfully, it returns to the EXC_AVM exception handling function, which causes deregistration of the EXC_AVM2 exception handler function and returns control to the system. It then calls the next exception handler according to the next entry in the exception handling registration chain and checks if it can handle the error that has occurred.

The exception handling functions can be informed by setting a handling flag AW that it is no longer the phase of searching for a suitable exception handling function but a handling the respective call frame and subframe.

8th shows the various components of a trace module AVM according to a preferred embodiment of the present invention. The trace module AVM 800 has an instrumentation module 810 on that related to 3b detailed instrumentation of a sub-program to be followed. The other modules 820 . 830 . 840 . 850 do the actual tracing associated with the 3b to 7 has been described in detail. module 820 provides the entry protocol function ER described above. module 830 provides the exit log function AR described above. module 840 provides the exception handling function EXC_AVM described above. module 850 provides the further exception handling function EXC_AVM2 described above.

Preferably, the trace module comprises 800 also a central module 890 that the use of the modules 820 . 830 . 840 and 850 controls. In this preferred embodiment, a jump instruction introduced by the instrumentation directs the control flow first to the central module 890 before this in the 3 to 4 described replacement of the return address of the instrumented subfunction and then the entry protocol function ER of the module 820 calls. In addition, the central module 890 also the registration of the module 850 cause the exception handling function EXC_AVM to be provided. After completion of the subroutine to be followed, the control flow through the return address becomes the central module again 890 then the logging of the exit from the subroutine by the module 830 provided exit log function AR. In addition, the above-described interaction of the exception handling function EXC_AVM in module 840 with the exception handling function EXC_AVM2 in module 850 through the central module 890 be controlled.

The present invention may be implemented in both user mode and kernel operating mode. In 9 For example, tracing is shown for user mode processes in accordance with a preferred embodiment of the present invention. With the help of a management application 910 , which is loaded into the main memory of the computer system, are a user applications or sub-programs such. B. EXE or DLL modules 930 currently running on the computer system using the kernel and are suitable for dynamic activation of a trace. The user then selects one or more applications or subroutines for tracing. The management application 910 this communicates to the trace module AVM 920 , which then instrumented the applications or subroutines to be followed as described above. The management application 910 communicates with the trace module AVM 920 which z. B. has been introduced by means of a library injection technique in the main memory, using a corresponding inter-process communication mechanism IPC. When calling an instrumented application or instrumented subroutine 930 its flow through the trace module AVM 920 tracked as described above.

To enable working with function names (rather than addresses), the management application can 910 preferably to a database 940 which contains debug symbol information allowing translation between names and addresses.

10 schematically shows the trace in operating system kernel mode according to a preferred embodiment of the present invention. In the case of tracing in the kernel, the management application communicates 1010 by means of an IOCTL interface with the trace module AVM 1020 which is loaded as a special device driver when needed and runs in kernel mode. The management application shows operating system kernel modules to a user 1030 such as For example, device drivers are required for dynamic activation of a trace by the trace module AVM 1020 are suitable. The user can then one or more subroutines, ie operating system kernel modules 1030 to trace. The trace module 1010 then orchestrates the selected operating system kernel modules 1030 with the help of the operating system kernel and follows their procedure as described above. To enable working with function names (rather than addresses), the management application can 1010 preferably to a database 1040 which contains debug symbol information allowing translation between names and addresses.

If a dynamically activated trace as described above is to be ended, all changes made with the aid of the trace module AVM must be reversed. In addition, if the trace module AVM as a whole is to be safely removed, it must be ensured that all run-track subroutines have been terminated and no longer jump to the trace module AVM pending. For this it may be necessary to examine all created auxiliary stacks. A safe removal of the trace module AVM is only possible when all memory is empty, ie no longer contain entries and thus no more jumps to the trace module AVM longer.

The present invention enables dynamic activation of a trace of subroutines already residing in the main memory of a computer system. Preferred embodiments of the present invention allow the registration of the entry into a subroutine, the exit from this subroutine as well as the handling of a call frame associated with the subroutine in the event of a non-regular termination of the subroutine due to the occurrence of an unhandleable exception.

• (a) Auf einem Multi-User-System (bspw. Microsoft Windows Terminal Server) dauert der Aufruf von Webseiten ungewöhnlich lange: Es verstreichen mehrere Sekunden, bevor der Aufbau der jeweiligen Webseite im Browser beginnt. Da mehrere Benutzer auf dem System arbeiten, sollte die Analyse des Fehlers keine Unterbrechung des Betriebs (etwa durch Systemneustart) erfordern. Die Analyse eines derartigen Fehlverhaltens könnte wie folgt ablaufen: Zunächst wird mithilfe einer erfindungsgemäßen dynamisch aktivierbaren Ablaufverfolgung der Browser so instrumentiert, dass alle Systemaufrufe (inklusive deren Ausführungszeiten) protokolliert werden. Die Analyse des Protokolls ergibt, dass ein bestimmter Systemaufruf überdurchschnittlich lange dauert – wobei es sich um einen IOCTL (NtDeviceloControlFile) handelt. Die Betrachtung des Aufrufstapels, welcher zu diesem Aufruf führte, ergibt, dass der IOCTL von der DNS-Bibliothek initiiert wurde. Ausgehend von dieser Information werden nun die DNS-Einstellungen und die Verfügbarkeit der DNS-Servers geprüft, was zu der Erkenntnis führt, das der sekundäre DNS-Server zwar erreichbar ist, ein Verbindungsversuch zum primären DNS-Server jedoch stets zu einem Timeout führt. Ein Tausch von primärem und sekundärem DNS-Server behebt das ursprüngliche Problem.
• (b) Ein System wurde von einer neuartigen Schadware befallen, deren Funktionsweise noch unbekannt ist. Um ein entsprechendes Erkennungs- oder Beseitigungs-Werkzeug erstellen zu können, gilt es daher zunächst, das Verhalten der Schadware zu analysieren. Hierzu kann ein Vergleich zwischen einem unbefallenem und einem befallenem System vorgenommen werden: Zwei identische Computersysteme, wovon eines der Systeme mit der Schadware infiziert worden ist, werden mithilfe einer erfindungsgemäßen dynamisch aktivierbaren Ablaufverfolgung derart instrumentiert, dass die Abläufe im System detailliert protokolliert werden. Nachdem auf beiden Systemen die gleichen Aktionen durchgeführt worden sind, kann durch Vergleich der Protokolle ermittelt werden, wie und in welchem Ausmaß die Schadware das Verhalten beeinflusst hat.
• (c) Um automatisch Schadware erkennen zu können, muss eine Sicherheitssoftware bestimmte Vorgänge im Betriebssystem auf verdächtige Aktionen hin überwachen: Werden bspw. kritische Systemeinstellungen geändert, so kann die Sicherheitssoftware zunächst überprüfen, ob es sich bei dem durchführenden Programm um Schadware oder unverdächtige Software handelt. Mithilfe einer erfindungsgemäßen dynamisch aktivierbaren Ablaufverfolgung kann eine Sicherheitssoftware beispielsweise den Aufruf bestimmter Funktionen in Bibliotheken oder im Betriebssystemkern überwachen und ggf. protokollieren, um eine solche Überprüfung durchzuführen. Sobald ein Verdacht vorliegt, dass es sich bei einem Programm um Schadware handelt, kann der Benutzer gewarnt werden oder es können konkrete Aktionen – beispielsweise das Terminieren des verdächtigten Programms – veranlasst werden.
• (d) Ein Entwickler eines Programms, etwa einer Anwendung oder eines Gerätetreibers, möchte den Code auf Ressourcen-Lecks (z. B. Speicher und Handles) überprüfen. Statt der manuellen Instrumentierung des Codes kann hierzu eine erfindungsgemäße dynamisch aktivierbare Ablaufverfolgung eingesetzt werden, um alle Aufrufe von Ressourcen-Akquisitions- sowie Freigabe-Funktionen zu protokollieren. Nach erfolgter Ausführung der zu untersuchenden Anwendung kann somit auf Basis des Protokolls ermittelt werden, welche Ressourcen akquiriert, jedoch nicht freigegeben wurden, also ein Leck darstellen. Statt den gesamten Code auf Lecks zu untersuchen, kann der Entwickler ausgehend von diesem Ergebnis die Analyse so auf jene Code-Stellen beschränken, welche sich mit den betroffenen Ressourcen befassen.
• (e) Um ein Verständnis für ein System oder eine bestimmte Funktion eines Systems aufzubauen, kann eine visuelle Darstellung des Verhaltens – etwa in Form von UML Sequenz-Diagrammen oder Aufruf-Graphen – dienlich sein. Eine erfindungsgemäße dynamisch aktivierbare Ablaufverfolgung kann genutzt werden, um die zu einer derartigen Visualisierung benötigten Daten zu gewinnen. Typischerweise möchte man zu einem Zeitpunkt nur bestimmte Aspekte eines Systems untersuchen, nicht das Gesamtsystem. Eine erfindungsgemäße Ablaufverfolgung ermöglicht genau diesen Sachverhalt durch die Fähigkeit zur Laufzeit die Ablaufverfolgung für ausgewählte Bereiche des Systems an- bzw. abzuschalten. Als Beispiel sei ein Web-Browser als System gegeben, von dem man wissen möchte, welche Funktionen daran beteiligt sind, eine Web-Seite zu laden und anzuzeigen. Um das herauszufinden, wird die Ablaufverfolgung für alle Funktionen des Browsers aktiviert, eine Web-Seite geladen und die Ablaufverfolgung wieder deaktiviert. Die aufgezeichneten Daten beschreiben nun den Kontrollfluss durch das System, der notwendig war, um die Web-Seite zu laden und anzuzeigen. Im Weiteren kann die Ablaufverfolgung nun so eingegrenzt werden, dass nur diejenigen Funktionen instrumentiert werden, die beispielsweise für die Netzwerkkommunikation notwendig sind.

Such a dynamically activatable trace according to the invention offers numerous advantages. The following are just a few application examples:

• (a) On a multi-user system (for example, Microsoft Windows Terminal Server), it takes an unusually long time to access web pages: several seconds elapse before the web page starts to build in the browser. Because multiple users are working on the system, the analysis of the error should not require any interruption of operation (such as system reboot). The analysis of such a misconduct could proceed as follows: First, the browser is instrumented using a dynamically activatable trace according to the invention so that all system calls (including their execution times) are logged. The analysis of the log shows that a particular system call takes a longer than average time - which is an IOCTL (NtDeviceloControlFile). Considering the call stack that resulted in this call indicates that the IOCTL was initiated by the DNS library. Based on this information, the DNS settings and the availability of the DNS servers are now checked, which leads to the realization that the secondary DNS server is reachable, but a connection attempt to the primary DNS server always results in a timeout. An exchange of primary and secondary DNS server fixes the original problem.
• (b) A system has been attacked by a novel malware whose operation is still unknown. In order to be able to create a corresponding detection or removal tool, it is therefore necessary first to analyze the behavior of the damaged product. For this purpose, a comparison can be made between an untrained and an infested system: Two identical computer systems, of which one of the systems has been infected with the damaged goods, are instrumented by means of a dynamically activatable trace according to the invention in such a way that the processes in the system are logged in detail. After the same actions have been taken on both systems, it can be determined by comparing the logs how and to what extent the malware affected the behavior.
• (c) To automatically detect malware, security software must monitor certain operations in the operating system for suspicious actions: For example, if critical system settings are changed, the security software can first verify that the executing program is malware or unsuspected software , By means of a dynamically activatable trace according to the invention, a security software can monitor, for example, the call of certain functions in libraries or in the operating system kernel and, if necessary, log to carry out such a check. Once suspected that a program is malware, the user can be warned or specific actions can be taken, such as scheduling the suspected program.
• (d) A developer of a program, such as an application or device driver, wants to check the code for resource leaks (eg, memory and handles). Instead of the manual instrumentation of the code, a dynamically activatable trace according to the invention can be used for this purpose in order to log all calls of resource acquisition and release functions. After the execution of the application to be examined can thus be determined on the basis of the protocol, which resources were acquired, but were not released, so represent a leak. Instead of examining the entire code for leaks, based on this result, the developer can limit the analysis to those code locations that deal with the resources involved.
• (e) To build an understanding of a system or a particular function of a system, a visual representation of the behavior, such as UML sequence diagrams or invocation graphs, may be useful. A dynamically activatable trace according to the invention can be used to obtain the data required for such a visualization. Typically, one would like to examine only certain aspects of a system at a time, not the entire system. A tracing according to the invention enables precisely this state of affairs through the ability to Run time to turn tracing on or off for selected areas of the system. As an example, consider a web browser as a system that you want to know about which functions are involved in loading and displaying a web page. To find out, the trace is enabled for all features of the browser, a web page is loaded and the trace is disabled again. The recorded data now describes the control flow through the system that was necessary to load and display the web page. Furthermore, the trace can now be limited so that only those functions are instrumented that are necessary, for example, for network communication.

The present invention has been described with reference to preferred technical embodiments consistent therewith. It will be apparent to those skilled in the art that various modifications, variations and improvements of the present invention may be made in light of the above teachings within the scope of the appended claims without departing from the spirit and intended scope of the invention. Accordingly, it is to be understood that the invention is not limited by any particular illustrative embodiments, but only by the scope of the claims.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 7047521 B2 [0006]

Claims (18)

A method of dynamically activating a trace with respect to a subroutine running on a computer system operated by an operating system kernel, the subroutine comprising a plurality of instructions and being located in machine code in a working memory of the computer system and wherein one of these instructions or a sequence of these instructions represents an idle instruction having in machine code a size at least equal to the size of the machine code of a jump instruction, and wherein the method comprises: Loading the machine code of a trace module into the memory of the computer system; Replacing the machine code of the idle instruction of the subroutine in the working memory with the machine code of a jump instruction which enables a redirection of a program control flow to the trace module in the main memory; Upon invoking the subroutine by a calling program, redirecting the program control flow to the trace module by the jump instruction; Registering an entry in the subroutine by the trace module; and Return the program control flow to the subroutine. The method of claim 1, wherein the jump instruction indirectly enables the program control flow to be indirectly redirected to the trace module, in which the jump instruction defines as a jump target a further jump instruction which is in a buffer area immediately preceding the subroutine and defines the trace module in memory as a jump target. The method of claim 2, wherein the operating system kernel corresponds to a Windows NT kernel for IA-32, the jump instruction of a 2 byte short jump instruction and the further jump instruction of a 5 byte long jump instruction. The method of claim 1, wherein the jump instruction enables a direct redirection of the program control flow to the trace module, in which the jump instruction defines the trace module as a jump target. The method of one of claims 1 to 4, wherein the idle instruction corresponds to the first instruction of the subroutine. Method according to one of claims 1 to 5, which further comprises after returning the program control flow to the subroutine: Processing the instructions of the subroutine until the end of the subroutine; Redirecting the program control flow to the trace module; Registering an exit from the subroutine by the trace module; and Returning the program control flow to the calling program. The method of claim 6, wherein the trace module, upon invoking the subroutine, replaces a return address stored in a call stack call frame associated with the subroutine to the calling program by a return address to the trace module, and the program control flow, after executing the instructions of the subroutine, by the return address stored in the call frame is redirected to the trace module. Method according to claim 7, wherein the return address replaced in the call frame is stored in an auxiliary frame assigned to the subroutine of an auxiliary stack and after recording the exit from the subroutine the program control flow is returned to the calling program by the return address stored in the auxiliary stack. The method of claim 7 or 8, wherein the trace module registers an exception handling function of the trace module upon invocation of the subroutine and further comprises the method: Occurrence of an exception that can not be handled within the subroutine or by a registered exception handling function of the subroutine while processing the instructions of the subroutine or other subroutines called by the subroutine; Calling the registered exception handling function of the trace module; Calling an exception handling function registered by another running subroutine; and Registering a handling of the call frame of the subroutine by means of the exception handling function of the trace module, if the handling of the exception occurred by the exception handling function registered by the further running subroutine causes call stack handling relating to a call stack associated with the subroutine. The method of claim 9, wherein the trace module, upon invoking the subroutine, registers the exception handling function of the trace module by the steps of: replacing the topmost address of an exception handling function stored in an exception handler registration chain with the address of the exception handling function of the trace module; and storing the replaced address in the subframe associated subframe. The method of claim 10, further comprising: Check, before replacing the top address stored in the exception handling registration chain, if the address of the address matches the exception handling function of the trace module, and if so: Identifying the subroutine that has stored the address of the exception handling function address of the trace module in the top entry of the exception handling registration chain by analyzing the auxiliary stack; and Storing an address of a subframe corresponding to the identified subroutine in the subframe of the subroutine in which the exception occurred. A method according to claim 10 or 11, wherein, by the registered exception handler function of the trace module, prior to invoking the exception handler registered by the further running subprogram, a further exception handler function of the trace module is registered as a new top entry in the exception handler register, and the step of registering comprises: Causing the call stack handling by the exception handling function registered by the other running subroutine; Calling the further exception handling function of the trace module registered in the top entry of the exception handling registration chain; Unwinding the sub-program associated sub-frame of the auxiliary stack and possibly further according to claim 11 associated with the sub-sub-frame by the further exception handling function of the trace module; Unwinding the call stack of the call stack associated with the subroutine by the exception handling function registered by the further running subroutine; wherein the unwinding is registered by the further exception handling function of the trace module. The method of any one of claims 10 to 12, wherein the operating system kernel corresponds to a Windows NT kernel for IA-32 and the exception handler registration chain is implemented according to the structured exception handler provided by Windows NT. Method according to one of claims 1 to 13, wherein an entry into the subroutine or an exit from the subroutine by counting up or down a counter or a time recording or logging is registered. Method according to one of claims 1 to 14, wherein upon deactivation of the dynamically activated trace of the subroutine, all changes made by the trace module with respect to this subroutine are undone. Method according to one of Claims 1 to 14, in which, before the removal of the trace module from the main memory, all changes made by the trace module are reversed and it is ensured that no more jumps to the trace module are outstanding The method of any one of claims 1 to 16, wherein a management application using the operating system kernel identifies subprograms running on the computer system that include a void instruction having a size in machine code that is at least the size of a machine code of the vault instruction, and wherein the management application comprises the identifies subroutines to a user of the system for selection and, in response to a selection of the user, instructs the trace module to replace the respective empty instruction in the selected subroutine (s) with the jump instruction. The method of claim 17, wherein the management application identifies the subroutines by analyzing their machine codes or by comparing them with a list of known subroutines containing a corresponding empty instruction.

Images