JP4125169B2 - ログ取得方法 - Google Patents
ログ取得方法 Download PDFInfo
- Publication number
- JP4125169B2 JP4125169B2 JP2003099465A JP2003099465A JP4125169B2 JP 4125169 B2 JP4125169 B2 JP 4125169B2 JP 2003099465 A JP2003099465 A JP 2003099465A JP 2003099465 A JP2003099465 A JP 2003099465A JP 4125169 B2 JP4125169 B2 JP 4125169B2
- Authority
- JP
- Japan
- Prior art keywords
- log
- function
- log acquisition
- module
- calling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数にモジュール分けされたソフトウェアの処理ログを取得するための技術に関するものである。
【０００２】
【従来の技術】
従来より、再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得し、当該処理ログを解析することによって、障害の原因をつきとめ、その対策を講じてきた（例えば、特許文献１を参照）。
【０００３】
【特許文献１】
特開平１１−２９６４１５号公報
【０００４】
【発明が解決しようとする課題】
しかし、上記従来の処理ログの取得には以下のような問題点がある。
（１）ユーザの動作環境でも処理ログを取得しつづけるためには、ソフトウェアのモジュール自体に手を加え、処理ログ取得ルーチンを追加しなければならず、処理ログ取得のための作業負荷が大きかった。
（２）処理ログ取得はモジュール毎に行うため、生成された処理ログはモジュール単位のものとなってしまい、ソフトウェア全体の処理を、完全に時間順の処理ログとして取得するのが困難である。このため、全体の処理ログとしての見通しが悪く、処理ログを解析して障害の原因を発見するまでのプロセスに工数がかかっていた。
【０００５】
本発明は、上記課題を鑑みてなされたものであり、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法、ならびに該方法をコンピュータによって実現させるためのプログラム、および該プログラムを格納した記憶媒体を提供することを目的とする。
【０００６】
【課題を解決するための手段】
上記の目的を達成するために本発明に係るログ取得方法は以下のような構成を備える。即ち、
関数を記憶したダイナミックリンクライブラリと、該関数のアドレスを記憶したインポート関数アドレステーブルと、該ダイナミックリンクライブラリ内の関数を呼び出して実行する対象プログラムとを記憶するプログラム記憶手段と、プログラムを記憶する記憶媒体と、ログが記録されるログ記録手段と、特定のモジュールのリストを記憶したリスト記憶手段と、プログラムを実行する実行手段とを有し、前記実行手段が前記記憶媒体に記憶されたプログラムを実行することにより実現される書き換え手段と、呼び出し手段とを備えた情報処理装置において、前記対象プログラムの実行中のログを取得するログ取得方法であって、
前記書き換え手段が、前記対象プログラムの実行前に、前記ダイナミックリンクライブラリ内の各関数に対応するログ取得のための関数を当該ダイナミックリンクライブラリ内にロードし、前記インポート関数アドレステーブル上に記憶された各関数のアドレスを、対応する前記ログ取得のための関数のアドレスに書き換える工程と、
前記呼び出し手段が、前記対象プログラムが呼び出そうとする呼び出し対象の関数に対する前記インポート関数アドレステーブル上の書き換え後の前記対応するログ取得のための関数のアドレスに基づいて、前記ログ取得のための関数を呼び出して前記実行手段に実行させることで実現されるログ取得手段を起動する工程と、
前記ログ取得手段が、呼び出し元のモジュールが前記特定のモジュールのリストに含まれているか否かを判断する工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記呼び出し手段による呼び出しに関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記呼び出し手段により呼び出された前記ログ取得のための関数に対応する前記呼び出し対象の関数を呼び出して、該呼び出し対象の関数を前記実行手段に実行させ、実行結果を受け取る工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記実行結果に関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記実行結果を前記対象プログラムに渡す工程とを備える。
【０００７】
【発明の実施の形態】
【第１の実施形態】
本実施形態は、あるモジュールから別のモジュール内に存在する関数の呼び出しが行われる際の仕組みである、メモリに保持されたインポート関数アドレス、または仮想関数アドレステーブル（Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ Ｔａｂｌｅ）を利用して、モジュール間の関数呼び出しをフックして処理ログに記録することで、ソフトウェアのモジュール自体に手を加えることなく、ソフトウエア全体の処理を、時間順の処理ログとして取得することを可能にするものである。以下に具体的に説明する。
【０００８】
＜システム構成＞
図１は、本発明の各実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。説明を簡略化するために、本実施形態では、本ソフトウェア評価システムが１台のＰＣ内部に構築されるものとするが、本発明にかかるログ取得方法は１台のＰＣ内部に構築されるか、あるいは複数のＰＣにネットワークシステムとして構築されるかによらず有効である。
【０００９】
本ログ取得方法を実現するソフトウェア評価システムには、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵ１とチップセット２とを繋ぐ信号線１１、チップセット２とＲＡＭ３とを繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とハードディスクドライブ６とを繋ぐ信号線１４、ハードディスクコントローラ４とＣＤ−ＲＯＭドライブ７とを繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８とを繋ぐ信号線１６が搭載されている。
【００１０】
＜関数処理に対する処理ログ取得＞
本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理を説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。
【００１１】
通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行う実行ファイルＥＸＥ（２３）と、モジュールとして存在しＥＸＥの補完的な役割を担うダイナミックリンクライブラリＤＬＬ（２７）とに分かれており、メモリにはＥＸＥとＤＬＬの両方がロードされる。ＥＸＥはコードセグメント（２８）とデータセグメント（２９）、そしてインポート関数アドレステーブル（２２）とから成っている。更に、インポート関数アドレステーブル（２２）は、関数の所属するＤＬＬによって分かれており（２１，２４）、ＤＬＬごとにそれぞれの関数がロードされたアドレスが書かれている（３０〜３５）。ＤＬＬの関数の実体は、ＤＬＬごとに分かれて（２５，２６）ロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。この図では、１本のＥＸＥがＡ．ＤＬＬ及びＢ．ＤＬＬの２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ ＡＡ, ＦｕｎｃＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣの６個となっている。
【００１２】
ＥＸＥのコードセグメント内にあるコードが関数Ｆｕｎｃ ＡＡを呼び出す場合には、まずインポート関数アドレステーブル（２２）内に書かれたＦｕｎｃ ＡＡのアドレス（３０）が読み込まれる。ここには実際にはＡ．ＤＬＬの一部として読み込まれたＦｕｎｃ ＡＡコード（３６）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＡ．ＤＬＬのＦｕｎｃ
ＡＡを呼び出すことができる。
【００１３】
図３は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してＩＡＴ Ｐａｔｃｈ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。
【００１４】
ログ取得が開始されると、メモリ内にはＩＡＴ Ｐａｔｃｈ用のＤＬＬであるＣ．ＤＬＬ（５８）がロードされる。Ｃ．ＤＬＬ（５８）はインポート関数アドレステーブル（５２）内に書かれた関数のアドレスを、Ｃ．ＤＬＬ（５８）内のログ取得コードであるＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのアドレスに書き換える（６１〜６６）。Ｃ．ＤＬＬ（５８）内のＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのコード（７３〜７８）は、ログを記録すると共に、元々の関数呼び出しを受けるべくメモリにロードされている、該当する関数であるＦｕｎｃ ＡＡ, Ｆｕｎｃ ＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣ（６７〜７２）を呼び出す。
【００１５】
図４Ａは、図３におけるＩＡＴ Ｐａｔｃｈの処理をあらわす図であり、図４Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＡ．ＤＬＬ（５５）内のＦｕｎｃ ＡＡを呼び出す際に、ＩＡＴ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００１６】
ＥＸＥ（図４Ａの９１）がＦｕｎｃ ＡＡをコールすると（図４Ａの９４）、Ｃ．ＤＬＬ（５８）内にあるログ取得コードがＤＬＬ名（Ｃ．ＤＬＬ）／関数名（Ｆｕｎｃ ＡＡ）をメモリに保存し（図４ＢのステップＳ４０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図４Ａの９５、図４ＢのステップＳ４０３）。その後Ｃ．ＤＬＬは本来呼び出されるはずであった、Ａ．ＤＬＬ（図４Ａの９３）内のＦｕｎｃ ＡＡをコールする（図４Ａの９６、図４ＢのステップＳ４０４）。Ａ．ＤＬＬのＦｕｎｃ ＡＡ処理（図４Ａの９７）が終了し、Ｃ．ＤＬＬに制御がリターンすると（図４Ａの９８）、Ｃ．ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図４Ａの９９）。その後、Ｃ．ＤＬＬは保存したログ情報をファイルに書き込み（図４Ａの１００、図４ＢのステップＳ４０５）、あたかもＡ．ＤＬＬのＦｕｎｃ ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（１０１）。
【００１７】
図５は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの機能構成をあらわす図である。通常は実行形式のＥＸＥ（１１３）が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサは、ＤＬＬ−１やＤＬＬ−２の関数定義を記述したファイル（１１１）と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ（トレースシナリオ１１２）を元に動作する。
【００１８】
＜メソッド処理に対する処理ログ取得＞
次に、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、実行ファイルＥＸＥがＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）サーバでエクスポートされているインターフェースのインスタンス作成時に、どのようにメモリにロードされるかを説明するために、まず、図６によって、通常の状態でどのようにメモリにロードされるかを説明する。
【００１９】
通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１，１２２）と、そのメソッド（：オブジェクト指向プログラミングにおいて、オブジェクトの実行する手続きを記述したプログラム、１３０〜１３５）が作成され、それらは、メモリ上に両方がロードされる。ここで、ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（仮想アドレステーブル）は作成された各インターフェース毎に作られ（１１８，１２０）、作成要求を行ったＥＸＥに渡される。このｖｉｒｔｕａｌ ａｄｄｒｅｓ ｔａｂｌｅには各メソッドの作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥはこれら情報を利用し、各インターフェースに対して呼び出しを行う。この図では、１本のＥＸＥがＩｎｔｅｒｆａｃｅ Ａ及びＩｎｔｅｒｆａｃｅ Ｂの２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ ＡＡ, Ｍｅｔｈｏｄ ＡＢ, Ｍｅｔｈｏｄ ＡＣ, Ｍｅｔｈｏｄ ＢＡ, Ｍｅｔｈｏｄ ＢＢ, Ｍｅｔｈｏｄ ＢＣとなっている。
【００２０】
ＥＸＥのコードが関数Ｍｅｔｈｏｄ ＡＡを呼び出す場合には、まずｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ ＡＡのアドレス（１２４）が読み込まれる。ここには実際にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ Ａの一部として作成されたＭｅｔｈｏｄ ＡＡコード（１３０）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄ ＡＡを呼び出すことができる。
【００２１】
図７は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してＶＴａｂｌｅ Ｐａｔｃｈ（ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。
【００２２】
ログ取得が開始されると、メモリ内にはＶＴａｂｌｅ Ｐａｔｃｈ用のＤＬＬ（１４３）がロードされる。このＤＬＬはｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（１３６，１３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ Ａ'Ａ, Ｍｅｔｈｏｄ Ａ'Ｂ, Ｍｅｔｈｏｄ Ａ'Ｃ, Ｍｅｔｈｏｄ Ｂ'Ａ, Ｍｅｔｈｏｄ Ｂ'Ｂ, Ｍｅｔｈｏｄ Ｂ'Ｃのアドレスに書き換える（１４５〜１５０）。ＤＬＬ内のＭｅｔｈｏｄ Ａ'Ａ, Ｍｅｔｈｏｄ Ａ'Ｂ, Ｍｅｔｈｏｄ Ａ'Ｃ, Ｍｅｔｈｏｄ Ｂ'Ａ, Ｍｅｔｈｏｄ Ｂ'Ｂ, Ｍｅｔｈｏｄ Ｂ'Ｃのコード（１５７〜１６２）は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるＭｅｔｈｏｄ ＡＡ, Ｍｅｔｈｏｄ ＡＢ,Ｍｅｔｈｏｄ ＡＣ, Ｍｅｔｈｏｄ ＢＡ, Ｍｅｔｈｏｄ ＢＢ, Ｍｅｔｈｏｄ ＢＣ（１５７〜１６２）を呼び出す。
【００２３】
図８Ａは、図７におけるＶＴａｂｌｅ Ｐａｔｃｈの処理をあらわす図、図８Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄＡＡを呼び出す際に、ＶＴａｂｌｅ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００２４】
ＥＸＥ（図８Ａの１６３）がＭｅｔｈｏｄ ＡＡをコールすると（図８Ａの１６６）、ＤＬＬ内にあるログ取得コードがモジュール名／インターフェース名／メソッド名をメモリに保存し（図８ＢのステップＳ８０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図８Ａの１６７、図８ＢのステップＳ８０３）。その後ＤＬＬは本来呼び出されるはずであった、ＣＯＭサーバ（図８Ａの１６５）内のＭｅｔｈｏｄ ＡＡをコールする（図８Ａの１６８、図８ＢのステップＳ８０４）。ＣＯＭサーバのＭｅｔｈｏｄ ＡＡ処理（図８Ａの１６９）が終了し、ＤＬＬに制御がリターンすると（図８Ａの１７０）、ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図８Ａの１７１）。その後、ＤＬＬは保存したログ情報をファイルに書き込み（図８Ａの１７２、図８ＢのステップＳ８０５）、あたかもＣＯＭサーバのＭｅｔｈｏｄＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（図８Ａの１７３）。
【００２５】
図９は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの機能構成をあらわす図である。通常は実行形式のＥＸＥ（１７６）が、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２の関数定義を記述したファイル（１７４）と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅを書き換えてログを取得するかの設定シナリオ（１７５）を元に動作する。
【００２６】
＜実施例＞
図１０は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。ＤＬＬ／インターフェース名及び関数／メソッド名を記述し（「関数／メソッド」とは、「関数またはメソッド」の意、以下同じ）、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。
【００２７】
図１１は、図１０に示した関数定義ファイルを用いて、本発明の実施形態にかかるソフトウェア評価システムで取得した、ログの一例を示す図である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻（Ｉｎ時刻、Ｏｕｔ時刻）、及びその際のパラメータ／戻り値が、ログとして生成される。
【００２８】
以上の説明から明らかなように、本実施形態にかかるログ取得方法によれば、複数にモジュール分けされたソフトウエアの処理ログの取得において、モジュール自体に変更を加えることなく、モジュール内に用意された関数／メソッドの呼び出しを処理ログとして記録することが可能となり、処理ログ取得のための作業負荷を低減することが可能となる。また、生成される処理ログは、時間順の処理ログとして取得することができ、処理ログの解析が容易となるため、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【００２９】
【第２の実施形態（その１）】
上記第１の実施形態では、ＥＸＥによって呼び出される関数／メソッドすべてについて処理ログを取得することとした。しかしながら、この場合、取得される処理ログの数が膨大になってしまうことも考えられる。そこで、本実施形態ではＥＸＥによって呼び出される関数／メソッドのうち、処理ログの取得対象を限定する場合について述べる。
【００３０】
一般にソフトウェアのモジュール構成は、ＯＳ ＳｕｒｆａｃｅによってＯＳ部分のＤＬＬとアプリケーション部分のＤＬＬとに分けられる。図１２は、一般的なソフトウェアのモジュール構成の一例を示す図である。同図において、１２００はＡＰＰ．ＥＸＥであり、１２０１〜１２０３はそれぞれ、ＭｏｄｕｌｅＡ．ｄｌｌ、ＭｏｄｕｌｅＢ．ｄｌｌ、ＭｏｄｕｌｅＣ．ｄｌｌであり、アプリケーション部分のＤＬＬである。一方、１２０５〜１２１０はそれぞれ、Ｕｓｅｒ３２．ｄｌｌ、ＧＤＩ３２．ｄｌｌ、Ｎｔｄｌｌ．ｄｌｌ、Ｗｓ２＿３２．ｄｌｌ、Ｕｎｉｄｒｖ．ｄｌｌであり、ＯＳ部分のＤＬＬである。
【００３１】
そこで、本実施形態では、このようなモジュール構成を備えるソフトウェアにおいて、アプリケーション部分のＤＬＬ内の関数が呼び出された場合のみ処理ログを取得することで処理ログの収集対象を限定する。
【００３２】
図１３は、オペレーティング・システムのモジュールを定義する例を示す図である。このモジュール定義をもって、図１４に示した処理が行なわれる。
【００３３】
図１４は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【００３４】
ステップＳ１４００で処理が開始されると、まず、図１３で示したオペレーティング・システムのモジュール定義１３００を取得し、ＯＳモジュールリストを保持する（ステップＳ１４０１）。続いて、関数／メソッドの呼び出し元のモジュールが、そのＯＳモジュールリストに存在するか否かを判別し（ステップＳ１４０２、Ｓ１４０３）、存在する場合は呼び出し先のモジュールをＯＳモジュールリストに追加する（ステップＳ１４０９）だけで、そのまま元の関数／メソッドを呼び出す（ステップＳ１４１０）。このステップＳ１４０９の処理により、更にそのモジュール以下の呼び出しが行われた場合でも、その呼び出しの処理ログを取得しない手段が確立されている。
【００３５】
一方、ステップＳ１４０３においてＯＳモジュールリストに存在しない場合は、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ１４０４）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ１４０５）。
【００３６】
続いて、本体の関数／メソッドを呼び出す（ステップＳ１４０６）。関数／メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ１４０７）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ１４０８）。続いて、関数／メソッドのリターン処理を行なう（ステップＳ１４１１）。この処理は、評価対象となるプログラムが終了するまで続行される（ステップＳ１４１２）。
【００３７】
図１５Ａは、図１４における処理によって取得された処理ログの例である。なお、比較のために図１５ＢにＯＳ部分のＤＬＬ内の関数が呼び出された際にも処理ログを取得することとした場合の例を示す。図１５Ａと図１５Ｂとを対比することで明らかなように、図１３におけるオペレーティング・システムのモジュール定義１３００により、図１５ＡではＫｅｒｎｅｌ３２．ｄｌｌからＮｔｄｌｌ．ｄｌｌに対する呼び出し、あるいはＵｓｅｒ３２．ｄｌｌからＷｓ２＿３２．ｄｌｌに対する呼び出しといった、オペレーティング・システムの内部の処理ログも含めた処理ログが取得されていないため、よりサイズの小さい処理ログで解析することが可能となっている。
【００３８】
以上の説明から明らかなように、本実施形態によれば、関数定義ファイルにおいて「オペレーティング・システムのサーフェイス」を指定することで、ソフトウェアに対する適切な処理ログが取得可能となり、バグ原因特定などの解析が可能となる。
【００３９】
【第２の実施形態（その２）】
上記第２の実施形態（その１）においては、オペレーティング・システムのサーフェイス以下すべての処理ログを取得しない例を挙げたが、実際はサーフェイス以下の一部（ＯＳ部分のＤＬＬ）に関しても、処理ログを取得したい場合がある。
【００４０】
例えば、上記第１の実施形態において示したログ取得方法を実現するためのプログラム（以下、「ログ取得プログラム」と称す）は、ドライバＳＤＫ（ＳＤＫ＝Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）に組み込んで利用する場合ことが考えられる。
【００４１】
一般にドライバＳＤＫ（例えばプリンタＳＤＫ）は周辺機器メーカ（プリンタメーカ）により提供されるが、ドライバＳＤＫを用いるソフトウェア（例えば、プリンタに印刷する文書や画像を生成、編集するためのソフトウェア）は他のメーカが作成することが多い。このため、ソフトウェアがドライバＳＤＫ（プリンタＳＤＫ）を使用した際に正常に動作しなかった時は、その原因がドライバＳＤＫ（プリンタＳＤＫ）側のバグによるものなのか、ソフトウェア側のバグによるものなのかを判別することが重要となってくる。このようなケースにおいてはログ取得プログラムにより、プリンタＳＤＫの処理内容を処理ログとして取得しておくことが重要となってくる。そのためには、Ｕｎｉｄｒｖ．ｄｌｌ（１２１０）などのＯＳ部分のＤＬＬ内の関数を呼び出した場合の処理ログも収集対象としておく必要がある。
【００４２】
つまり、処理ログの取得対象を限定するにあたっては、ログ取得プログラムの使用目的に応じて、任意に選択できるようにしておくことが望ましい。本実施形態では、かかる点に考慮したログ取得プログラムについて説明する。
【００４３】
図１６は、このような必要性に鑑みて、オペレーティング・システムの除外モジュール（ログ取得対象外として定義されるオペレーティング・システムのモジュールから除外するモジュール、つまり、ログ取得対象となるモジュール）を定義する例を示す図である。この除外モジュール定義及び図１３に示したサーフェイス定義をもって、図１７にあらわした処理が行なわれる。本実施形態では、サーフェイスから除外の指定をユーザが行なうことにより、上記のケースにおいてドライバの処理ログをソフトウェアの処理ログと併せて取得する。
【００４４】
図１７は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【００４５】
ステップＳ１７００において処理が開始されると、まず本ログ取得プログラムは、図１３で示したオペレーティング・システムのモジュール定義１３００を取得し、ＯＳモジュールリストを保持する（ステップＳ１７０１）。続いて、図１６で示した除外モジュール定義を取得し、除外モジュールリストを保持する（ステップＳ１７０２）。続いて、関数／メソッドの呼び出し元のモジュールが存在するかどうかを、ＯＳモジュールリスト及び除外モジュールリストの両リストから検索する（ステップＳ１７０３）。
【００４６】
続いて、呼び出し元のモジュールがＯＳモジュールリストに存在するか否かを判別し（ステップＳ１７０４）、存在する場合は、呼び出し元が除外モジュールであるかどうかを判別する（ステップＳ１７０５）。ＯＳモジュールリストに存在し、且つ除外モジュールリストに存在しない場合、本ログ取得プログラムは、呼び出し先のモジュールをＯＳモジュールリストに追加する（ステップＳ１７１１）だけで、そのまま元の関数／メソッドを呼び出す（ステップＳ１７１２）。
【００４７】
呼び出し元のモジュールが、ステップＳ１７０４においてＯＳモジュールリストに存在しない場合、及びステップＳ１７０５において除外モジュールリストに存在する場合は、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ１７０６）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ１７０７）。
【００４８】
続いて、本体の関数／メソッドを呼び出す（ステップＳ１７０８）。関数／メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ１７０９）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ１７１０）。続いて、関数／メソッドのリターン処理を行なう（ステップＳ１７１３）。
【００４９】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ１７１４）続行される。
【００５０】
このように「オペレーティング・システムのサーフェイス」及び「サーフェイスからの除外モジュール」を指定可能なＡＰＩトレーサにより、ソフトウェアに対する適切な処理ログが取得可能となり、バグ原因特定などの解析が可能となる。
【００５１】
【第２の実施形態（その３）】
上記第２の実施形態（その１）、（その２）において、図１４のステップＳ１４０１、図１７のステップＳ１７０１では、ＯＳモジュールリストの取得をオペレーティング・システムが提供した情報によって自動的に取得することとしたがこれに限られない。また、「オペレーティング・システムが提供した情報」は、オペレーティング・システムが用意したインターフェースから取得するものでも構わないし、例えばＷｉｎｄｏｗｓ（登録商標） ＯＳの場合、レジストリ情報でも構わない。
【００５２】
また、図１４に示した処理を行なうか、図１７に示した処理を行なうかを、ユーザが明示的に選択できるようにしてもよい。。
【００５３】
さらに、上記第２の実施形態（その２）では、あらかじめオペレーティング・システムの除外モジュールの定義がなされていることとしたが、図１７のステップＳ１７０２において、ユーザが任意に指定できるようにしてもよい。
【００５４】
【第３の実施形態（その１）】
上記第１の実施形態では、関数定義ファイルとして、ＤＬＬ名／インターフェース名／関数名／メソッド名と、その関数／メソッドに対するパラメータ及び戻り値の型とを記述することとしたが（図１０参照）、本発明にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルの記述は、これに限られない。本実施形態では、特殊な構造体データを含む関数として、ＤＥＶＭＯＤＥを含む関数のログを取得する場合の、関数定義ファイルの記述方法と当該関数定義ファイルにおけるログ取得方法とについて説明する。
【００５５】
ＤＥＶＭＯＤＥとは、プリンタドライバのユーザインタフェースで設定できる印刷設定がどのように設定されているかを示すＷｉｎｄｏｗｓ（登録商標）の構造体のことをいい、ＤＥＶＭＯＤＥにはＯＳが共通で定義している部分と、プリンタベンダが拡張して使用できる部分（拡張領域）とがある。そして、ＤＥＶＭＯＤＥの最初に「拡張領域サイズ」が指定されている。このように拡張領域のサイズが指定されている場合には、ＤＥＶＭＯＤＥ構造体へのポインタがＡＰＩトレーサのパラメータとして入力された場合、ＤＥＶＭＯＤＥの標準領域（サイズ固定）の最後のアドレスから指定サイズ分だけデータ内容を読み出してログとして取得するように、関数定義ファイルに書き込むことで、ＤＥＶＭＯＤＥを含む関数の処理ログを取得することが可能となる。以下に詳細に説明する。
【００５６】
図１８は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルの一例であり、一般的に広く用いられているＩＤＬにより記述されている。本ソフトウェア評価システムに於いては、このＩＤＬをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、本実施形態は付加バイナリ情報取得のための定義手段を提供することを特徴とするものであり、関数定義ファイルはＩＤＬでなくても構わない。例えば、通常のテキストファイルを用いることも可能であり、ＸＭＬなどのマークアップ言語を用いることも可能である。
【００５７】
図１９は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対して付加バイナリ情報取得を指定することで、ポインタ・データの実体を処理ログとして取得すべく、ＩＤＬにより記述されている。
【００５８】
ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の定義に於いて、ｌｏｎｇｃＥｘｔｒａＢｉｎａｒｙＤａｔａに対してｃｕｓｔｕｍ（ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ，"ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ（）"）と宣言している（１９０１）。ここで、ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ（１９００）はＩＤＬの中で本ソフトウェア評価システムが利用するための識別子である。ここで、" ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ （）"と定義しておき、ＦｕｎｃＳｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ関数に引数をＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ＊ ｌｐＰａｒａｍと定義しておく（１９０２）ことにより、ＦｕｎｃＳｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ関数が実際に呼び出された際に、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の置かれたメモリ領域の先頭から、ｃＥｘｔｒａＢｉｎａｒｙＤａｔａが指すサイズ分だけの、付加情報としてのバイナリデータを処理ログとして保存する。
【００５９】
図２０は、図１９に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【００６０】
この図では、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体（２０００）が置かれたメモリの先頭アドレスの０ｘ０１Ｆ７Ｂ０００であるとして説明する。１ｂｙｔｅのデータであるｃｈＰａｒａｍ１（２００１）は０ｘ０１Ｆ７Ｂ０００に置かれ、４ｂｙｔｅのデータであるｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅ（２００２）は０ｘ０１Ｆ７Ｂ００１に置かれ、１ｂｙｔｅのデータであるｃｈＰａｒａｍ２（２００３）は０ｘ０１Ｆ７Ｂ００５に置かれ、１ｂｙｔｅのデータであるｃｈＰａｒａｍ３（２００４）は０ｘ０１Ｆ７Ｂ００６に置かれている。
【００６１】
ここまでは通常の構造体メモリ配置と同一であるが、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体はｃｈＰａｒａｍ３に続くメモリ、すなわち０ｘ０１Ｆ７Ｂ００７からの領域にＥｘｔｒａＢｉｎａｒｙＤａｔａ（２００５）という付加データを持っており、そのサイズがｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅに応じて可変となっている。例えば、ｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅの値として８が入っている場合には、ＥｘｔｒａＢｉｎａｒｙＤａｔａは８ｂｙｔｅ存在することになるため、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の最後尾のメモリアドレスは０ｘ０１Ｆ７Ｂ００Ｅとなる。このため、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の指し示すすべてのデータをログに取得するためには、このＥｘｔｒａＢｉｎａｒｙＤａｔａを、ｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅの値の分だけバイナリデータとして取得する必要がある。図１９におけるｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義は、この必要を満たすために記述されている。
【００６２】
図２１は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９に示すように関数定義ファイルが記述されている時の処理ログを取得する場合の処理の流れを示すフローチャートである。
【００６３】
処理が開始されると（ステップＳ２１００）、ログ取得を開始し、モジュール名／インターフェース名／関数名／メソッド名をＨＤＤに保存する（ステップＳ２１０１）。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２１０２）。そして、関数定義にｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの設定が存在するかどうか、すなわちｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を含んだ構造体がパラメータに存在するか否かを判別し（ステップＳ２１０３）、存在する場合には、まずその定義を含む構造体のサイズを計算する（ステップＳ２１０４）。
【００６４】
続いて、構造体の先頭ポインタから計算した構造体サイズの分だけずれたメモリ領域から、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓで示されたメンバの値によって示されるサイズ分だけ、データをＨＤＤに保存する（ステップＳ２１０５）。続いて、元の関数／メソッドを呼び出す（ステップＳ２１０６）。
【００６５】
関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２１０７）。そして、関数定義にｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの設定が存在するかどうか、すなわちｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を含んだ構造体がパラメータ／戻り値に存在するか判別し（ステップＳ２１０８）、存在する場合には、その定義を含む構造体のサイズを計算する（ステップＳ２１０９）。続いて、構造体の先頭ポインタから計算した構造体サイズの分だけずれたメモリ領域から、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓで示されたメンバの値によって示されるサイズ分だけ、データをＨＤＤに保存する（ステップＳ２１１０）。この処理はユーザから終了の命令により終了する（ステップＳ２１１１）。なお、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓで指定されたメンバが複数にわたる場合は、当然ステップＳ２１０４〜ステップＳ２１０５及びステップＳ２１０９〜ステップＳ２１１０の処理が指定された数すべてに対して行なわれる。
【００６６】
図２２は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９の関数定義ファイルにより取得された処理ログを示す図である。
【００６７】
ここでは処理ログはテキスト部分（２２００）とバイナリ部分（２２０１）とに分けて表示しており、テキストデータに書き込まれたＤａｔａＩＤが、バイナリ部分に書き込まれたＤａｔａＩＤに対応している。例えば、一度目の呼び出しのログではＤａｔａＩＤが０ｘ０００１であるが、このＩＤがバイナリ部分に書き込まれた付加バイナリ情報、ＤａｔａＩＤ=０ｘ０００１を指し示している。この場合、ＦｕｎｃＳｔｒｕｃｔｓｉｚｅｅｘｔｒａＩｓの１度目の呼び出しでは８バイト、２度目の呼び出しでは４０バイト、３度目の呼び出しでは５バイト、４度目の呼び出しでは７バイトの付加バイナリデータが取得されている。ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を行なわない場合には、ｃｈＰａｒａｍ１及びｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅ及びｃｈＰａｒａｍ２及びｃｈＰａｒａｍ３のみが取得されるが、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を行なうことにより、付加バイナリデータであるＥｘｔｒａＢｉｎａｒｙＤａｔａを、それぞれの呼び出しに応じたサイズ分、処理ログに取得することが可能となっている。
【００６８】
このように、構造体のメンバに応じた処理ログ取得のための関数定義手段を設けることにより、通常では取得しきれないデータを、バイナリデータとして処理ログに取得することが可能となる。
【００６９】
【第３の実施形態（その２）】
上記第３の実施形態（その１）では、特定の構造体の最後尾のアドレスから所定サイズ分のデータを処理ログとして取得するための関数定義ファイルの記述方法と、その場合のログ取得プログラムの処理について述べたが、本発明にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルの記述方法はこれに限られない。
【００７０】
図２３は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対してメンバをオフセットとして指定することで、ポインタ・データの実体をログとして取得すべく、ＩＤＬにより記述されている。
【００７１】
ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体の定義に於いて、ＬＰＳＴＲ ｌｐｓｚＳｔｒｉｎｇ及びｌｏｎｇ ｎＮｕｍｂｅｒに対してｃｕｓｔｕｍ（ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ, " ｐｔｒｄｉｆｆ （）"）と宣言している（２３０１、２３０２）。ここで、ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ（２３００）はＩＤＬの中で本ソフトウェア評価システムが利用するための識別子である。ここで、" ｐｔｒｄｉｆｆ （）"と定義しておき、ＦｕｎｃＰｔｒｄｉｆｆ関数に引数をＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ＊ ｌｐＰａｒａｍと定義しておく（２３０３）ことにより、ＦｕｎｃＰｔｒｄｉｆｆ関数が実際に呼び出された際に、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体の置かれたメモリ領域の先頭から、ｌｐｓｚＳｔｒｉｎｇ及びｎＮｕｍｂｅｒの数値によって表されるオフセットだけずれたメモリ領域に格納された、ＬＰＳＴＲ及びｌｏｎｇのデータを処理ログとして保存する。
【００７２】
ｐｔｒｄｉｆｆ（）の宣言は、以下の２つの条件定義を兼ねている。
（１）ｐｔｒｄｉｆｆ（）で指定された引数は、実際には規定された型ではなく、構造体の先頭アドレスに対するオフセットを表す数値として扱われること。
（２）そのオフセットの指し示すメモリエリアに、規定された型のデータが保持されていること。
【００７３】
図２４は、図１８に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【００７４】
この図では、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体（２４００）が置かれたメモリの先頭アドレスの０ｘ０１Ｆ７Ｂ０００であるとして説明する。１ｂｙｔｅのデータであるｃｈＰａｒａｍ１（２４０１）は０ｘ０１Ｆ７Ｂ０００に置かれ、４ｂｙｔｅのデータであるｌｐｓｚＳｔｒｉｎｇへのオフセット（２４０２）は０ｘ０１Ｆ７Ｂ００１に置かれ、４ｂｙｔｅのデータであるｎＮｕｍｂｅｒへのオフセット（２４０３）は０ｘ０１Ｆ７Ｂ００５に置かれ、１ｂｙｔｅのデータであるｃｈＰａｒａｍ２（２４０４）は０ｘ０１Ｆ７Ｂ００９に置かれている。ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体において、ｌｐｓｚＳｔｒｉｎｇの実体はオフセット（２４０２）によって示されたサイズ分、構造体の先頭アドレスからずらした領域に格納されており（２４０５）、ｎＮｕｍｂｅｒの実体はオフセット（２４０３）によって示されたサイズ分、構造体の先頭アドレスからずらした領域に格納されている（２４０６）。このため、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体の指し示すすべてのデータを処理ログに取得するためには、これらｌｐｓｚＳｔｒｉｎｇ及びｎＮｕｍｂｅｒに関して、実体のデータをログとして取得する必要がある。図２３におけるｐｔｒｄｉｆｆの定義は、この必要を満たすために記述されている。
【００７５】
図２５は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図２３に示すように関数が定義されている時のログを取得する場合の処理の流れを示すフローチャートである。
【００７６】
処理が開始されると（ステップＳ２５０１）、ログ取得を開始し、モジュール名／インターフェース名／関数名／メソッド名をＨＤＤに保存する（ステップＳ２５０２）。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２５０３）。そして、関数定義ファイルにｐｔｒｄｉｆｆの設定が存在するかどうか、すなわちｐｔｒｄｉｆｆの定義を含んだ構造体がパラメータに存在するか否かを判別し（ステップＳ２５０４）、存在する場合には、構造体の先頭アドレスとｐｔｒｄｉｆｆで定義された構造体メンバのオフセットの値を合算し、ｐｔｒｄｉｆｆで定義された構造体メンバがどのアドレスに格納されているかを計算する（ステップＳ２５０５）。続いて、計算したアドレスの指し示すメモリ領域から、ｐｔｒｄｉｆｆで示されたメンバの型のデータをＨＤＤに保存する（ステップＳ２５０６）。続いて、元の関数／メソッドを呼び出す（ステップＳ２５０７）。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２５０８）。そして、関数定義ファイルにｐｔｒｄｉｆｆの設定が存在するかどうか、すなわちｐｔｒｄｉｆｆの定義を含んだ構造体がパラメータ／戻り値に存在するか否かを判別し（ステップＳ２５０９）、存在する場合には、構造体の先頭アドレスとｐｔｒｄｉｆｆで定義された構造体メンバのオフセットの値を合算し、ｐｔｒｄｉｆｆで定義された構造体メンバがどのアドレスに格納されているかを計算する（ステップＳ２５１０）。続いて、計算したアドレスの指し示すメモリ領域から、ｐｔｒｄｉｆｆで示されたメンバの型のデータをＨＤＤに保存する（ステップＳ２５１１）。この処理はユーザから終了の命令により処理を終了する（ステップＳ２５１２）。なお、ｐｔｒｄｉｆｆで指定されたメンバが複数に渡る場合は、当然ステップＳ２５０５〜ステップＳ２５０６及びステップＳ２５１０〜ステップＳ２５１１の処理が指定された数すべてに対して行なわれる。
【００７７】
図２６は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図２３の関数定義ファイルにより取得された処理ログを示す図である。それぞれの呼び出しでオフセットが異なっているが、本ソフトウェア評価システムは、オフセットで指し示された実体を的確に処理ログとして取得している。
【００７８】
以上の説明から明らかなように、本実施形態によれば、構造体のメンバに応じたログデータ取得のための定義手段を設けることにより、通常では取得しきれないデータを含む関数／メソッドであっても、処理ログを取得することが可能となる。
【００７９】
【第４の実施形態（その１）】
上記第１の実施形態では、関数定義ファイルとして、ＤＬＬ名／インターフェース名／関数名／メソッド名と、その関数／メソッドに対するパラメータ及び戻り値の型とを記述することとしたが（図１０参照）、本発明にかかるログ取得方法を実現するソフトウェア評価システムにける関数定義ファイルの記述は、これに限られない。本実施形態では、特殊なＣＯＭに対してログを取得する場合の、関数定義ファイルの記述方法について説明する。
【００８０】
一般に、プリンタドライバには、ＯＳに予め組み込まれているＵＮＩＤＲＩＶＥＲ（ユニドライバ）を用いる場合と、モノレシックドライバを用いる場合とがある。そして、プリンタベンダーはモノレシックドライバ、またはユニドライバからの出力を受け取るプラグインモジュール（＊．ｄｒｖ）を提供している。モノレシックドライバの場合は、ＧＤＩ３２．ｄｌｌは一般的なＤＤＩ関数を用いる。
【００８１】
ここで、ＤＬＬ同士は、レジストリに登録されているＡＰＩを用いてデータのやり取りを行うが、ユニドライバがプリンタベンダが提供するプラグインモジュールに出力する処理内容は、レジストリに登録されていないＣＯＭ（ｏｂｊｅｃｔ−ＡＰＩ）である。このため、上記第１の実施形態において示した関数定義ファイルでは、特殊なＣＯＭについての処理ログを取得することができない。そこで、本実施形態ではユニドライバが吐き出すレジストリに登録されていないＣＯＭを通常のＣＯＭとして扱うように関数定義ファイルを記述することで適切なログを取得することとする。
【００８２】
図２７は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、それぞれの関数／メソッドのパラメータの形式や、戻り値の形式を指示する関数定義ファイルの例であり、一般的に広く用いられているＩＤＬにより記述されている。ＤＬＬ名／インターフェース名／関数名／メソッド名を記述し、その関数／メソッドに対する、パラメータ／戻り値の型が示されている。本発明の第４の実施形態にかかるソフトウェア評価システムに於いては、このＩＤＬをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、本実施形態は、より詳細な情報取得のための関数定義手段を提供することを特徴とするものであり、関数定義ファイルはＩＤＬにより記述されていなくても構わない。例えば、通常のテキストファイルを用いることも可能であり、ＸＭＬなどのマークアップ言語を用いることも可能である。
【００８３】
本発明の第４の実施形態にかかるソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。なお、本実施形態では、Ｉｎｔｅｒｆａｃｅ ｔｅｓｔに実装されたＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔという名前の関数が、以下のようなパラメータを持つ状態を例としている。
（１）入力パラメータの"ｒｃｌｓｉｄ"、すなわち「クラスＩＤ」をあらわすパラメータ。
（２）入力パラメータの"ｒｉｉｄ"、すなわち「リファレンス・インターフェースＩＤ」をあらわすパラメータ。
（３）出力パラメータの"ｐｐｖ"、すなわち、上記２つの入力パラメータを元に得られた、実体としてのインターフェースポインタ。
【００８４】
ＤＬＬ内にコードとして記述されたＩｎｔｅｒｆａｃｅ内のメソッドを、ＥＸＥが呼び出すためには、先にＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔ関数を用いて、クラスＩＤ及びリファレンス・インターフェースＩＤを元にしたＩｎｔｅｒｆａｃｅのインスタンスを生成し、そのインスタンスのメモリアドレスを知っておく必要がある。
【００８５】
図２７に示された"ｉｉｄ＿ｉｓ"（２７０３）が、本実施形態の特徴を最もよくあらわすものである。すなわち、ｉｉｄ＿ｉｓに第二引数であるｒｉｉｄを指定することで「この出力パラメータは、実際にはｖｏｉｄ * ではなく、ｒｉｉｄに指定された型のインターフェースである」という定義を行なっている。この定義をＡＰＩトレーサが認識することにより、従来取得できなかった「ｐｐｖで返ってきたインターフェース内に実装されたメソッドの呼び出し」に関しても、詳細が処理ログとして取得できるようになっている。
【００８６】
図２８は、ｒｉｉｄに指定するインターフェース型を定義した、関数定義ファイルの例である。ここでは、ＩＵｎｋｎｏｗｎという名前のインターフェースから派生した、ＩＧｅｔＩｎｆｏというインターフェースを定義している。ＩＧｅｔＩｎｆｏには、ＧｅｔＮａｍｅ及びＦｒｅｅＮａｍｅＢｕｆｆｅｒという２つのメソッドが実装されている。
【００８７】
図２９は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【００８８】
処理が開始されると（ステップＳ２９００）、設定された関数／メソッドが呼び出される都度に、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ２９０１）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ２９０２）。続いて、入力パラメータの関数定義ファイルに、図２７によって説明したｉｉｄ＿ｉｓ、すなわち「リファレンス・インターフェースＩＤの定義」があるかどうかを判別し（ステップＳ２９０３）、存在する場合は、そのリファレンス・インターフェースＩＤを、メモリ上の別のエリアに保存しておく（ステップＳ２９０４）。
【００８９】
本体の関数／メソッドを呼び出し（ステップＳ２９０５）、メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ２９０６）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ２９０７）。
【００９０】
次に、出力パラメータがインターフェースへのポインタとして定義されているかどうかを、図２７に示した関数定義ファイルに基づいて判断し（ステップＳ２９０８）、定義されている場合は、リファレンス・インターフェースＩＤがメモリ上に保存されているかどうかを判断する（ステップＳ２９０９、ステップＳ２９１０）。リファレンス・インターフェースＩＤが保存されていない場合には、その出力パラメータをインターフェースそのものへのポインタとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ２９１１）、該当するパラメータ／戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ２９１２）。リファレンス・インターフェースＩＤが保存されている場合、その出力パラメータを、リファレンス・インターフェースＩＤがあらわすインターフェースへ派生した形のポインタ、例えば図２８に示したＩＧｅｔＩｎｆｏとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ２９１３）、該当するパラメータ乃至戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ２９１４）。
【００９１】
ステップＳ２９１２またはステップＳ２９１４の処理が終了するか、もしくはステップＳ２９０８においてインターフェースポインタとして定義されていないことを判断した場合は、関数／メソッドのリターン処理を行なう（ステップＳ２９１５）。
【００９２】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ２９１６）続行される。
【００９３】
図３０は、図２９における処理によって取得された処理ログの例である。図２７におけるｉｉｄ＿ｉｓの定義により、ＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔの出力パラメータｐｐｖをＩＧｅｔＩｎｆｏ型のインターフェースとして認識した結果、ＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔのログだけでなく、ＩＧｅｔＩｎｆｏインターフェース内に実装されたメソッドの呼び出しに関しても、処理ログとして取得することが可能となっている。なお本実施形態は、リファレンス・インターフェースＩＤを認識することを特徴とするものであり、実際のリファレンス・インターフェースＩＤ（３００１）とＩＧｅｔＩｎｆｏとの関連付けは、公知の技術を元に行なわれる。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＯＳにおいては、この情報はレジストリに置かれており、レジストリ情報を元に関連付けが可能である。ただし、他の方法を用いて関連付けを行なっても構わない。
【００９４】
以上の説明から明らかなように、本実施形態によれば、関数定義ファイルとして、「ある入力パラメータが、出力パラメータの型をあらわす」ことを指定することにより、ソフトウェアに対する更に詳細な処理ログを取得することが可能となり、バグ原因特定など、より詳細な解析が可能となる。
【００９５】
【第４の実施形態（その２）】
上記第４の実施形態（その１）においては、実体すなわちインスタンスとしてのインターフェースの解決を行なっているが、これだけでは「インスタンスを生成する元となっている情報」すなわち、オブジェクト指向プログラミングにおける「クラス情報」に基づいた情報を、処理ログとして取得できない。そこで本実施形態では、クラス情報を追加情報として処理ログに取得するために、クラスＩＤをインターフェースＩＤと関連付ける場合について説明する。
【００９６】
本実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルでは、クラスＩＤは、図２７におけるＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔのｒｃｌｓｉｄをもって定義し、その定義のために「ｃｌｓｉｄ＿ｉｓ」という関数定義を用いる。この「ｃｌｓｉｄ＿ｉｓ」とは、「このＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔにおいては、ｃｌｓｉｄ＿ｉｓで指定されたパラメータをクラスＩＤとするクラス情報を元にしてインターフェースのインスタンスが生成されている」ということを指定するための関数定義である。このように関数定義ファイルを記述することにより、本実施形態にかかるソフトウェア評価システムは、より詳細な情報をログとして取得することが可能となっている。
【００９７】
図３１及び図３２は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートであり、図２９とは別の一例である。
【００９８】
処理が開始されると（ステップＳ３１００）、設定された関数／メソッドが呼び出される都度に、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ３１０１）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ３１０２）。続いて、入力パラメータの関数定義ファイルに、図２７及び上記によって説明したｃｌｓｉｄ＿ｉｓ、すなわち「クラスＩＤの定義」があるかどうかを判別し（ステップＳ３１０３）、存在する場合は、そのクラスＩＤをメモリ上の別のエリアに保存しておく（ステップＳ３１０４）。続いて、入力パラメータの関数定義ファイルに、図２７によって説明したｉｉｄ＿ｉｓ、すなわち「リファレンス・インターフェースＩＤの定義」があるかどうかを判別し（ステップＳ３１０５）、存在する場合は、そのリファレンス・インターフェースＩＤをメモリ上の別のエリアに保存しておく（ステップＳ３１０６）。
【００９９】
本体の関数／メソッドを呼び出し（ステップＳ３１０７）、メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ３１０８）、その呼び出しに対してのパラメータ／戻り値をＨＤＤに保存する（ステップＳ３１０９）。次に、出力パラメータがインターフェースへのポインタとして定義されているかどうかを、図２７に示した関数定義ファイルに基づいて判断し（ステップＳ３１１０）、定義されている場合は、リファレンス・インターフェースＩＤがメモリ上に保存されているかどうかを判断する（図３２のステップＳ３２００、Ｓ３２０１）。リファレンス・インターフェースＩＤが保存されていない場合、その出力パラメータを、インターフェースそのものへのポインタとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ３２０３）、該当するパラメータ／戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ３２０４）。リファレンス・インターフェースＩＤが保存されている場合、その出力パラメータをリファレンス・インターフェースＩＤがあらわすインターフェースへ派生した形のポインタ、例えば図２８に示したＩＧｅｔＩｎｆｏとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ３２０５）、該当するパラメータ／戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ３２０６）。
【０１００】
ステップＳ３２０４またはステップＳ３２０６の処理が終了すると、メモリにクラスＩＤが保存されているかを判別し（ステップＳ３２０７）、保存されている場合は、保存されたクラスＩＤをログ取得コードと関連付けてメモリに保持しておく（ステップＳ３２０８）。続いて、関数／メソッドのリターン処理を行なう（図３１のステップＳ３１１２）。この処理は、評価対象となるプログラムが終了するまで（ステップＳ３１１３）続行される。
【０１０１】
ステップＳ３２０８においてクラスＩＤを保持しておくことにより、ＩＧｅｔＩｎｆｏ内の関数が呼ばれた際に、そのクラス情報を元に、ステップＳ３１０１においてより詳細な情報をログに取得することが可能となる。図３３は、図３０に対して、クラスＩＤを元にモジュール名が追加でログ取得可能となっていることをあらわしている（３３０３、３３０４、３３０５、３３０６）。
【０１０２】
なお本実施形態は、クラスＩＤをインターフェース・パラメータと関連付けつつ、リファレンス・インターフェースＩＤを認識することを特徴とするものであり、実際のクラスＩＤ（３０００）と、モジュール名等詳細情報との関連付けは、公知の技術を元に行なわれる。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＯＳにおいては、この情報はレジストリに置かれており、レジストリ情報を元に関連付けが可能である。が、他の方法を用いて関連付けを行なっても構わない。
【０１０３】
以上の説明から明らかなように、本実施形態によれば、関数定義ファイルにおいて「ある入力パラメータが、出力パラメータの型をあらわす」ことを指定することにより、ソフトウェアに対する更に詳細な処理ログを取得することが可能となり、バグ原因特定など、より詳細な解析が可能となる。
【０１０４】
【第５の実施形態（その１）】
上記第４の実施形態によれば、特殊なＣＯＭに対するログを取得することが可能となるが、かかる特殊なＣＯＭの場合、処理ログの対象となるモジュール名がレジストリに定義されていないため、モジュール名に基づいて処理ログを取得することができない。そこで、本実施形態では個々のインターフェース名（ＣＯＭの処理内容）に対するモジュール名を追加定義として用意し、処理ログを作成する際にインターフェース名からモジュール名を判断して書き込むこととする。
【０１０５】
図３４は、本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルの一例であり、一般的に広く用いられているＩＤＬにより記述されている。本ソフトウェア評価システムに於いては、このＩＤＬをトークン化したタイプライブラリ・ファイルを関数定義ファイルとして使用する。
【０１０６】
ＩＤＬはインターフェースの定義に用いられるものであり、標準ではモジュール名の定義は不可能である。例えば、複数のモジュールが、同じインターフェース定義でインターフェースを提供しており、それらが選択的にプラグイン・モジュールとして用いられている場合、インターフェース定義を行なっても、それらのインターフェースがどのプラグイン・モジュールに属するものであるかは、それらプラグイン・モジュールを選択的に呼び出しているモジュールのみが知り得る。例えば、オペレーティング・システムが選択的にドライバ用のプラグイン・モジュールを呼び出している場合、オペレーティング・システムが選択を行なうアルゴリズムが公開されていない場合は、モジュール名を関連付けて呼び出しに関する詳細情報を処理ログに取得することは不可能である。具体的には、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムに搭載されている、ユニバーサル・プリンタドライバのプラグイン・モジュールなどが考えられる。
【０１０７】
ただし、これらのプラグイン・モジュールは、ユーザの操作に関連付けられて選択的に呼び出されているケースが多い。例えば、プリンタドライバにおいては、複数搭載されたプリンタのうち、ユーザがどのプリンタで出力するのかを選択して、その選択操作に対して１対１に対応するプラグイン・モジュールが呼び出される。この場合、ＩＤＬによるインターフェース定義とは別途「今回の操作に対してはこのモジュールが呼び出される」ということを知り得て、尚且つその情報を、ログ取得プログラムに対し指示する手段があれば、その手段を用いて、上記プラグイン・モジュールのモジュール名も含めた形の処理ログを取得することが可能となる。
【０１０８】
図３５は、ライブラリ名に対してモジュール名を定義した関数定義ファイルの例であり、３５００でライブラリ名を、３５０１でモジュールの置かれているフォルダ名を、３５０２でモジュール名をそれぞれ定義している。
【０１０９】
図３６は、インターフェース名に対してモジュール名を定義した関数定義ファイルの例であり、３６００でインターフェース名を、３６０１でモジュールの置かれているフォルダ名を、３６０２でモジュール名をそれぞれ定義している。
【０１１０】
なお、本実施形態では、図３５乃至図３６におけるモジュール名の追加定義を、単なるテキストファイルで示しているが、本実施形態はＩＤＬのような「ＤＬＬ／インターフェース／関数／メソッドを定義するための標準フォーマット」に対して別のフォーマットの追加定義を行ない、それを元に関数／メソッドのログを取得することを特徴とするものであり、追加定義は単なるテキストファイルではなく、ＨＴＭＬやＸＭＬといったマークアップ言語で記述されていても構わない。
【０１１１】
図３７は、本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートであり、本実施形態の特徴を最もよくあらわすものである。
【０１１２】
処理が開始されると（ステップＳ３７００）、設定された関数／メソッドが呼び出される都度に、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ３７０１）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ３７０２）。続いて、入力パラメータの関数定義ファイルに、図３５乃至図３６によって説明した、モジュール名の追加定義が存在するかどうかを判別し（ステップＳ３７０３）、存在する場合は、そのモジュール名をメモリ上の別のエリアに保存しておく（ステップＳ３７０４）。
【０１１３】
本体の関数／メソッドを呼び出し（ステップＳ３７０５）、メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ３７０６）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ３７０７）。続いて、関数／メソッドのリターン処理を行なう（ステップＳ３７０８）。
【０１１４】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ３７０９）続行される。
【０１１５】
このように、モジュール名を関数定義とは別のフォーマットで追加定義して、それを元に処理ログの取得を行なうことにより、例えばプラグイン・モジュールがユーザの操作に関連付けられて選択的に呼び出されているケースに対して、プラグイン・モジュールのモジュール名も含めた形の処理ログを取得することが可能となる。この機能を持つＡＰＩトレーサにより、ソフトウェアに対してモジュール名を必ず含んだ形での処理ログが取得可能となり、バグ原因特定など、より詳細な解析が可能となる。
【０１１６】
【第５の実施形態（その２）】
上記第５の実施形態（その１）においては、モジュール名の追加定義をテキストファイルで行なっているが、これに限られず、モジュール定義をユーザが選択できるようなユーザー・インターフェースを備えてもよい。実現方法としては、図３５乃至図３６におけるＰａｔｈ及びＭｏｄｕｌｅＮａｍｅの設定を、ユーザが選択可能なユーザー・インターフェースを備えても構わないし、全体のモジュール名追加定義テキストファイルを複数用意して、それらのファイルを選択するユーザ・インターフェースを備えても構わない。
【０１１７】
【第５の実施形態（その３）】
上記第５の実施形態（その１）および（その２）においては、モジュール名の追加定義を、ユーザが指定乃至選択しているが、これに限られず、追加のモジュール定義をオペレーティング・システムが備えるインターフェースから取得しても構わない。例えば、Ｍｉｃｒｏｓｏｆｔの．ＮＥＴ Ｆｒａｍｅｗｏｒｋでは、各モジュールがＸＭＬ形式のモジュール定義データを含み、モジュール定義データをオペレーティング・システムのインターフェースで取得できる。また、この場合に、オペレーティング・システムから取得したモジュール定義に示されたモジュールに対して、インポート関数アドレステーブル及びエクスポート関数アドレステーブルなどの、モジュール内部に用意されたヘッダ情報を元に、メモリ上でそのモジュール内に実装された関数／メソッドをログ取得ルーチンにリダイレクトして、更にログ情報を詳細に取得することも可能である。例えば、ＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ（登録商標）オペレーティング・システムでは、この機能によって、通常のＤＬＬに実装されたエクスポート関数の呼び出し、ＣＯＭインターフェースに実装されたメソッドの呼び出し、．ＮＥＴアセンブリに実装されたメソッドの呼び出しの３点について、１つのログデータ内に時系列ですべての情報を並べることが可能である。
【０１１８】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【０１１９】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１２０】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２１】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１２２】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２３】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２４】
以下に本発明の実施態様の例を示す。
【０１２５】
［実施態様１］ 所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に呼び出されるオペレーティングシステム内の関数のうち、指定された関数を識別する工程と、
ロードされた前記所定の処理を行う関数のアドレスと前記指定されたオペレーティングシステム内の関数のアドレスとを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数および前記指定されたオペレーティングシステム内の関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数および前記指定されたオペレーティングシステム内の関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１２６】
［実施態様２］ 前記所定の処理を行う関数および前記指定されたオペレーティングシステム内の関数を呼び出す際の所定の情報は、少なくとも、呼び出された関数の関数名、呼び出す際の時刻、呼び出す際のパラメータ、または呼び出す際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１に記載のログ取得方法。
【０１２７】
［実施態様３］ 前記実行結果を受け取った際の所定の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１に記載のログ取得方法。
【０１２８】
［実施態様４］ 前記所定の処理を行う関数のアドレスは、該関数を提供するダイナミックリンクライブラリごとに、インポート関数アドレステーブルに記載されていることを特徴とする実施態様１に記載のログ取得方法。
【０１２９】
［実施態様５］ 前記所定の処理を行う関数のアドレスのうち、前記ログ取得のための関数のアドレスに書き換えるアドレスを選択する工程を更に備え、
前記書き換える工程は、前記選択する工程により選択された関数のアドレスを書き換えることを特徴とする実施態様１に記載のログ取得方法。
【０１３０】
［実施態様６］ 所定の１または複数のモジュールを定義する工程と、前記関数の呼び出しが当該定義したモジュールを経由したか否かを判別する工程とを更に備え、当該定義されたモジュールを経由した場合には、当該関数を呼び出す際の前記所定の情報を記録対象から除外することを特徴とする実施態様１のログ取得方法。
【０１３１】
［実施態様７］ オペレーティング・システムに含まれる所定の１または複数のモジュールを定義する工程と、前記関数の呼び出しが経由したモジュールを判別する工程とを更に備え、当該定義されたモジュール以外のオペレーティング・システムに含まれるモジュールを経由した場合には、当該関数を呼び出す際の前記所定の情報を記録対象から除外することを特徴とする実施態様１のログ取得方法。
【０１３２】
［実施態様８］ 前記所定の情報が構造体である場合に、当該構造体が置かれたメモリ領域の先頭から当該構造体のサイズ分だけ後のメモリ領域に格納されている情報を、当該構造体に指定されたサイズに応じて記録することを特徴とする実施態様１のログ取得方法。
【０１３３】
［実施態様９］ 前記所定の情報が構造体である場合に、当該構造体が置かれたメモリ領域の先頭から当該構造体に対して指定されたオフセットより後のメモリ領域に格納されている情報を、定義されたデータ型のデータとして記録することを特徴とする実施態様１のログ取得方法。
【０１３４】
［実施態様１０］ 何れのモジュールの何れの関数の所定の情報の何れがオブジェクトの情報を表わし、何れがオブジェクトのクラスＩＤを表わすかを定義しておき、関数の呼び出しにおいて、オブジェクトのクラスＩＤに基づいて、その関数の所定の情報に格納されたオブジェクトの情報を記録することを特徴とする実施態様１のログ取得方法。
【０１３５】
［実施態様１１］ 何れのモジュールの何れの関数の所定の情報の何れがオブジェクトの情報を表わし、何れがオブジェクトのインターフェースＩＤを表わすかを定義しておき、関数の呼び出しにおいて、オブジェクトのインターフェースＩＤに基づいて、その関数の所定の情報に格納されたオブジェクトの情報を記録することを特徴とする実施態様１のログ取得方法。
【０１３６】
［実施態様１２］ ライブラリまたは各インタフェースに対するモジュール名の追加定義を用意しておき、関数を呼び出す際に、当該追加定義を参照してモジュール名を記録することを特徴とする実施態様１のログ取得方法。
【０１３７】
［実施態様１３］ 所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記所定の処理を行う関数がロードされた場合のアドレスから所定のオフセットを有する領域であって、指定された領域を識別する工程と、
前記ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と、
前記指定された領域のデータを読み出して記録する工程と
を備えることを特徴とするログ取得方法。
【０１３８】
［実施態様１４］ 所定の処理を行う第１の関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に該プログラムの実行ファイルから直接呼び出された前記第１の関数によってのみ呼び出される第２の関数のうち、指定された第２の関数を識別する工程と、
前記第１の関数によって呼び出されることでロードされる前記指定された第２の関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記指定された第２の関数を呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記指定された第２の関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１３９】
［実施態様１５］ 所定の処理を行う第１の関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に、該プログラムの実行ファイルから直接呼び出された前記第１の関数によってのみ呼び出される第２の関数に設定されたＩＤを識別する工程と、
前記第１の関数によって呼び出されることでロードされる前記ＩＤが設定された第２の関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記ＩＤが設定された第２の関数を呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記ＩＤが設定された第２の関数を呼び出す際の所定の情報を、前記設定されたＩＤとともに記録する工程と、
前記実行結果を受け取った際の所定の情報を、前記設定されたＩＤとともに記録する工程と
を備えることを特徴とするログ取得方法。
【０１４０】
［実施態様１６］ 所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に呼び出されるオペレーティングシステム内のメソッドのうち、指定されたメソッドを識別する工程と、
ロードされた前記所定の処理を行うメソッドのアドレスと前記指定されたオペレーティングシステム内のメソッドのアドレスとを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドおよび前記指定されたオペレーティングシステム内のメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドおよび前記指定されたオペレーティングシステム内のメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１４１】
［実施態様１７］ 前記所定の処理を行うメソッドおよび前記指定されたオペレーティングシステム内のメソッドを呼び出す際の所定の情報は、少なくとも、呼び出されたメソッドのメソッド名、呼び出す際の時刻、呼び出す際のパラメータ、または呼び出す際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１６に記載のログ取得方法。
【０１４２】
［実施態様１８］ 前記実行結果を受け取った際の所定の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１６に記載のログ取得方法。
【０１４３】
［実施態様１９］ 前記所定の処理を行うメソッドのアドレスは、該メソッドを提供するインターフェースごとに、仮想アドレステーブルに記載されていることを特徴とする実施態様１６に記載のログ取得方法。
【０１４４】
［実施態様２０］ 前記所定の処理を行うメソッドのアドレスのうち、前記ログ取得のためのメソッドのアドレスに書き換えるアドレスを選択する工程を更に備え、
前記書き換える工程は、前記選択する工程により選択されたメソッドのアドレスを書き換えることを特徴とする実施態様１６に記載のログ取得方法。
【０１４５】
［実施態様２１］ 所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記所定の処理を行うメソッドがロードされた場合のアドレスから所定のオフセットを有する領域であって、指定された領域を識別する工程と、
前記ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と、
前記指定された領域のデータを読み出して記録する工程と
を備えることを特徴とするログ取得方法。
【０１４６】
［実施態様２２］ 所定の処理を行う第１のメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に該プログラムの実行ファイルから直接呼び出された前記第１のメソッドによってのみ呼び出される第２のメソッドのうち、指定された第２のメソッドを識別する工程と、
前記第１のメソッドによって呼び出されることでロードされる前記指定された第２のメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記指定された第２のメソッドを呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記指定された第２のメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１４７】
［実施態様２３］ 所定の処理を行う第１のメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に、該プログラムの実行ファイルから直接呼び出された前記第１のメソッドによってのみ呼び出される第２のメソッドに設定されたＩＤを識別する工程と、
前記第１のメソッドによって呼び出されることでロードされる前記ＩＤが設定された第２のメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記ＩＤが設定された第２のメソッドを呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記ＩＤが設定された第２のメソッドを呼び出す際の所定の情報を、前記設定されたＩＤとともに記録する工程と、
前記実行結果を受け取った際の所定の情報を、前記設定されたＩＤとともに記録する工程と
を備えることを特徴とするログ取得方法。
【０１４８】
［実施態様２４］ 実施態様１乃至２３のいずれか１つに記載のログ取得方法をコンピュータによって実現させるための制御プログラム。
【０１４９】
［実施態様２５］ 実施態様２４に記載の制御プログラムを格納した記憶媒体。
【０１５０】
【発明の効果】
以上説明したように本発明によれば、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。
【図２】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。
【図３】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図４Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈを使用時の状態を示す図である。
【図４Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図５】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈを使用時の内部構成をあらわす図である。
【図６】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、ＣＯＭサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。
【図７】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図８Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ Ｐａｔｃｈを使用時の状態を示す図である。
【図８Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図９】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、内部構成をあらわす図である。
【図１０】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１１】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図１２】一般的なソフトウェアのモジュール構成の一例を示す図である。
【図１３】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、処理ログの収集対象となるオペレーティング・システムのモジュールを定義する例を示す図である。
【図１４】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図１５Ａ】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した処理ログの一例を示す図である。
【図１５Ｂ】ＯＳ部分のＤＬＬ内の関数が呼び出された際にも、処理ログを取得することとした場合の処理ログの例を示す図である。
【図１６】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、処理ログの収集対象からオペレーティング・システムの除外モジュールを定義する例を示す図である。
【図１７】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図１８】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義の一例を示す図であり、一般的に広く用いられているＩＤＬにより、記述された図である。
【図１９】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対して付加バイナリ情報取得を指定することで、ポインタ・データの実体をログとして取得すべく、ＩＤＬにより記述したファイルを示す図である。
【図２０】図１９に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【図２１】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９に示すように関数が定義されている時のログを取得する場合の処理の流れを示すフローチャートである。
【図２２】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９の定義により取得されたログデータを示す図である。
【図２３】本発明の一実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対してメンバをオフセットとして指定することで、ポインタ・データの実体をログとして取得すべく、ＩＤＬにより記述したファイルを示す図である。
【図２４】図１８に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【図２５】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１８に示すように関数が定義されている時のログを取得する場合の処理の流れを示すフローチャートである。
【図２６】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１８の定義により取得されたログデータを示す図である。
【図２７】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する関数定義ファイルの例を示す図である。
【図２８】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、ｒｉｉｄに指定するインターフェース型を定義した、関数定義ファイルの例を示す図である。
【図２９】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図３０】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図２９における処理によって取得された処理ログの例を示す図である。
【図３１】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図３２】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図３３】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図３１および図３２における処理によって取得された処理ログの例を示す図である。
【図３４】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義の一例を示す図である。
【図３５】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、ライブラリ名に対してモジュール名を定義する例を示す図である。
【図３６】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、インターフェース名に対してモジュール名を定義する例を示す図である。
【図３７】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【符号の説明】
１：ＣＰＵ
２：チップセット
３：ＲＡＭ
４：ハードディスクコントローラ
５：ディスプレイコントローラ
６：ハードディスクドライブ
７：ＣＤ−ＲＯＭドライブ
８：ディスプレイ
１１：ＣＰＵとチップセットを繋ぐ信号線
１２：チップセットとＲＡＭを繋ぐ信号線
１３：チップセットと各種周辺機器とを繋ぐ周辺機器バス
１４：ハードディスクコントローラとハードディスクドライブを繋ぐ信号線
１５：ハードディスクコントローラとＣＤ−ＲＯＭドライブを繋ぐ信号線
１６：ディスプレイコントローラとディスプレイを繋ぐ信号線
【発明の属する技術分野】
本発明は、複数にモジュール分けされたソフトウェアの処理ログを取得するための技術に関するものである。
【０００２】
【従来の技術】
従来より、再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得し、当該処理ログを解析することによって、障害の原因をつきとめ、その対策を講じてきた（例えば、特許文献１を参照）。
【０００３】
【特許文献１】
特開平１１−２９６４１５号公報
【０００４】
【発明が解決しようとする課題】
しかし、上記従来の処理ログの取得には以下のような問題点がある。
（１）ユーザの動作環境でも処理ログを取得しつづけるためには、ソフトウェアのモジュール自体に手を加え、処理ログ取得ルーチンを追加しなければならず、処理ログ取得のための作業負荷が大きかった。
（２）処理ログ取得はモジュール毎に行うため、生成された処理ログはモジュール単位のものとなってしまい、ソフトウェア全体の処理を、完全に時間順の処理ログとして取得するのが困難である。このため、全体の処理ログとしての見通しが悪く、処理ログを解析して障害の原因を発見するまでのプロセスに工数がかかっていた。
【０００５】
本発明は、上記課題を鑑みてなされたものであり、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法、ならびに該方法をコンピュータによって実現させるためのプログラム、および該プログラムを格納した記憶媒体を提供することを目的とする。
【０００６】
【課題を解決するための手段】
上記の目的を達成するために本発明に係るログ取得方法は以下のような構成を備える。即ち、
関数を記憶したダイナミックリンクライブラリと、該関数のアドレスを記憶したインポート関数アドレステーブルと、該ダイナミックリンクライブラリ内の関数を呼び出して実行する対象プログラムとを記憶するプログラム記憶手段と、プログラムを記憶する記憶媒体と、ログが記録されるログ記録手段と、特定のモジュールのリストを記憶したリスト記憶手段と、プログラムを実行する実行手段とを有し、前記実行手段が前記記憶媒体に記憶されたプログラムを実行することにより実現される書き換え手段と、呼び出し手段とを備えた情報処理装置において、前記対象プログラムの実行中のログを取得するログ取得方法であって、
前記書き換え手段が、前記対象プログラムの実行前に、前記ダイナミックリンクライブラリ内の各関数に対応するログ取得のための関数を当該ダイナミックリンクライブラリ内にロードし、前記インポート関数アドレステーブル上に記憶された各関数のアドレスを、対応する前記ログ取得のための関数のアドレスに書き換える工程と、
前記呼び出し手段が、前記対象プログラムが呼び出そうとする呼び出し対象の関数に対する前記インポート関数アドレステーブル上の書き換え後の前記対応するログ取得のための関数のアドレスに基づいて、前記ログ取得のための関数を呼び出して前記実行手段に実行させることで実現されるログ取得手段を起動する工程と、
前記ログ取得手段が、呼び出し元のモジュールが前記特定のモジュールのリストに含まれているか否かを判断する工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記呼び出し手段による呼び出しに関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記呼び出し手段により呼び出された前記ログ取得のための関数に対応する前記呼び出し対象の関数を呼び出して、該呼び出し対象の関数を前記実行手段に実行させ、実行結果を受け取る工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記実行結果に関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記実行結果を前記対象プログラムに渡す工程とを備える。
【０００７】
【発明の実施の形態】
【第１の実施形態】
本実施形態は、あるモジュールから別のモジュール内に存在する関数の呼び出しが行われる際の仕組みである、メモリに保持されたインポート関数アドレス、または仮想関数アドレステーブル（Ｖｉｒｔｕａｌ Ａｄｄｒｅｓｓ Ｔａｂｌｅ）を利用して、モジュール間の関数呼び出しをフックして処理ログに記録することで、ソフトウェアのモジュール自体に手を加えることなく、ソフトウエア全体の処理を、時間順の処理ログとして取得することを可能にするものである。以下に具体的に説明する。
【０００８】
＜システム構成＞
図１は、本発明の各実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。説明を簡略化するために、本実施形態では、本ソフトウェア評価システムが１台のＰＣ内部に構築されるものとするが、本発明にかかるログ取得方法は１台のＰＣ内部に構築されるか、あるいは複数のＰＣにネットワークシステムとして構築されるかによらず有効である。
【０００９】
本ログ取得方法を実現するソフトウェア評価システムには、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵ１とチップセット２とを繋ぐ信号線１１、チップセット２とＲＡＭ３とを繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とハードディスクドライブ６とを繋ぐ信号線１４、ハードディスクコントローラ４とＣＤ−ＲＯＭドライブ７とを繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８とを繋ぐ信号線１６が搭載されている。
【００１０】
＜関数処理に対する処理ログ取得＞
本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理を説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。
【００１１】
通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行う実行ファイルＥＸＥ（２３）と、モジュールとして存在しＥＸＥの補完的な役割を担うダイナミックリンクライブラリＤＬＬ（２７）とに分かれており、メモリにはＥＸＥとＤＬＬの両方がロードされる。ＥＸＥはコードセグメント（２８）とデータセグメント（２９）、そしてインポート関数アドレステーブル（２２）とから成っている。更に、インポート関数アドレステーブル（２２）は、関数の所属するＤＬＬによって分かれており（２１，２４）、ＤＬＬごとにそれぞれの関数がロードされたアドレスが書かれている（３０〜３５）。ＤＬＬの関数の実体は、ＤＬＬごとに分かれて（２５，２６）ロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。この図では、１本のＥＸＥがＡ．ＤＬＬ及びＢ．ＤＬＬの２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ ＡＡ, ＦｕｎｃＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣの６個となっている。
【００１２】
ＥＸＥのコードセグメント内にあるコードが関数Ｆｕｎｃ ＡＡを呼び出す場合には、まずインポート関数アドレステーブル（２２）内に書かれたＦｕｎｃ ＡＡのアドレス（３０）が読み込まれる。ここには実際にはＡ．ＤＬＬの一部として読み込まれたＦｕｎｃ ＡＡコード（３６）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＡ．ＤＬＬのＦｕｎｃ
ＡＡを呼び出すことができる。
【００１３】
図３は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してＩＡＴ Ｐａｔｃｈ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。
【００１４】
ログ取得が開始されると、メモリ内にはＩＡＴ Ｐａｔｃｈ用のＤＬＬであるＣ．ＤＬＬ（５８）がロードされる。Ｃ．ＤＬＬ（５８）はインポート関数アドレステーブル（５２）内に書かれた関数のアドレスを、Ｃ．ＤＬＬ（５８）内のログ取得コードであるＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのアドレスに書き換える（６１〜６６）。Ｃ．ＤＬＬ（５８）内のＦｕｎｃ ＣＡＡ, Ｆｕｎｃ ＣＡＢ, Ｆｕｎｃ ＣＡＣ, Ｆｕｎｃ ＣＢＡ, Ｆｕｎｃ ＣＢＢ, Ｆｕｎｃ ＣＢＣのコード（７３〜７８）は、ログを記録すると共に、元々の関数呼び出しを受けるべくメモリにロードされている、該当する関数であるＦｕｎｃ ＡＡ, Ｆｕｎｃ ＡＢ, Ｆｕｎｃ ＡＣ, Ｆｕｎｃ ＢＡ, Ｆｕｎｃ ＢＢ, Ｆｕｎｃ ＢＣ（６７〜７２）を呼び出す。
【００１５】
図４Ａは、図３におけるＩＡＴ Ｐａｔｃｈの処理をあらわす図であり、図４Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＡ．ＤＬＬ（５５）内のＦｕｎｃ ＡＡを呼び出す際に、ＩＡＴ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００１６】
ＥＸＥ（図４Ａの９１）がＦｕｎｃ ＡＡをコールすると（図４Ａの９４）、Ｃ．ＤＬＬ（５８）内にあるログ取得コードがＤＬＬ名（Ｃ．ＤＬＬ）／関数名（Ｆｕｎｃ ＡＡ）をメモリに保存し（図４ＢのステップＳ４０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図４Ａの９５、図４ＢのステップＳ４０３）。その後Ｃ．ＤＬＬは本来呼び出されるはずであった、Ａ．ＤＬＬ（図４Ａの９３）内のＦｕｎｃ ＡＡをコールする（図４Ａの９６、図４ＢのステップＳ４０４）。Ａ．ＤＬＬのＦｕｎｃ ＡＡ処理（図４Ａの９７）が終了し、Ｃ．ＤＬＬに制御がリターンすると（図４Ａの９８）、Ｃ．ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図４Ａの９９）。その後、Ｃ．ＤＬＬは保存したログ情報をファイルに書き込み（図４Ａの１００、図４ＢのステップＳ４０５）、あたかもＡ．ＤＬＬのＦｕｎｃ ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（１０１）。
【００１７】
図５は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの機能構成をあらわす図である。通常は実行形式のＥＸＥ（１１３）が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサは、ＤＬＬ−１やＤＬＬ−２の関数定義を記述したファイル（１１１）と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ（トレースシナリオ１１２）を元に動作する。
【００１８】
＜メソッド処理に対する処理ログ取得＞
次に、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、実行ファイルＥＸＥがＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）サーバでエクスポートされているインターフェースのインスタンス作成時に、どのようにメモリにロードされるかを説明するために、まず、図６によって、通常の状態でどのようにメモリにロードされるかを説明する。
【００１９】
通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１，１２２）と、そのメソッド（：オブジェクト指向プログラミングにおいて、オブジェクトの実行する手続きを記述したプログラム、１３０〜１３５）が作成され、それらは、メモリ上に両方がロードされる。ここで、ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（仮想アドレステーブル）は作成された各インターフェース毎に作られ（１１８，１２０）、作成要求を行ったＥＸＥに渡される。このｖｉｒｔｕａｌ ａｄｄｒｅｓ ｔａｂｌｅには各メソッドの作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥはこれら情報を利用し、各インターフェースに対して呼び出しを行う。この図では、１本のＥＸＥがＩｎｔｅｒｆａｃｅ Ａ及びＩｎｔｅｒｆａｃｅ Ｂの２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ ＡＡ, Ｍｅｔｈｏｄ ＡＢ, Ｍｅｔｈｏｄ ＡＣ, Ｍｅｔｈｏｄ ＢＡ, Ｍｅｔｈｏｄ ＢＢ, Ｍｅｔｈｏｄ ＢＣとなっている。
【００２０】
ＥＸＥのコードが関数Ｍｅｔｈｏｄ ＡＡを呼び出す場合には、まずｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ ＡＡのアドレス（１２４）が読み込まれる。ここには実際にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ Ａの一部として作成されたＭｅｔｈｏｄ ＡＡコード（１３０）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄ ＡＡを呼び出すことができる。
【００２１】
図７は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してＶＴａｂｌｅ Ｐａｔｃｈ（ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。
【００２２】
ログ取得が開始されると、メモリ内にはＶＴａｂｌｅ Ｐａｔｃｈ用のＤＬＬ（１４３）がロードされる。このＤＬＬはｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（１３６，１３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ Ａ'Ａ, Ｍｅｔｈｏｄ Ａ'Ｂ, Ｍｅｔｈｏｄ Ａ'Ｃ, Ｍｅｔｈｏｄ Ｂ'Ａ, Ｍｅｔｈｏｄ Ｂ'Ｂ, Ｍｅｔｈｏｄ Ｂ'Ｃのアドレスに書き換える（１４５〜１５０）。ＤＬＬ内のＭｅｔｈｏｄ Ａ'Ａ, Ｍｅｔｈｏｄ Ａ'Ｂ, Ｍｅｔｈｏｄ Ａ'Ｃ, Ｍｅｔｈｏｄ Ｂ'Ａ, Ｍｅｔｈｏｄ Ｂ'Ｂ, Ｍｅｔｈｏｄ Ｂ'Ｃのコード（１５７〜１６２）は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるＭｅｔｈｏｄ ＡＡ, Ｍｅｔｈｏｄ ＡＢ,Ｍｅｔｈｏｄ ＡＣ, Ｍｅｔｈｏｄ ＢＡ, Ｍｅｔｈｏｄ ＢＢ, Ｍｅｔｈｏｄ ＢＣ（１５７〜１６２）を呼び出す。
【００２３】
図８Ａは、図７におけるＶＴａｂｌｅ Ｐａｔｃｈの処理をあらわす図、図８Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄＡＡを呼び出す際に、ＶＴａｂｌｅ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００２４】
ＥＸＥ（図８Ａの１６３）がＭｅｔｈｏｄ ＡＡをコールすると（図８Ａの１６６）、ＤＬＬ内にあるログ取得コードがモジュール名／インターフェース名／メソッド名をメモリに保存し（図８ＢのステップＳ８０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図８Ａの１６７、図８ＢのステップＳ８０３）。その後ＤＬＬは本来呼び出されるはずであった、ＣＯＭサーバ（図８Ａの１６５）内のＭｅｔｈｏｄ ＡＡをコールする（図８Ａの１６８、図８ＢのステップＳ８０４）。ＣＯＭサーバのＭｅｔｈｏｄ ＡＡ処理（図８Ａの１６９）が終了し、ＤＬＬに制御がリターンすると（図８Ａの１７０）、ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図８Ａの１７１）。その後、ＤＬＬは保存したログ情報をファイルに書き込み（図８Ａの１７２、図８ＢのステップＳ８０５）、あたかもＣＯＭサーバのＭｅｔｈｏｄＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（図８Ａの１７３）。
【００２５】
図９は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの機能構成をあらわす図である。通常は実行形式のＥＸＥ（１７６）が、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２の関数定義を記述したファイル（１７４）と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅを書き換えてログを取得するかの設定シナリオ（１７５）を元に動作する。
【００２６】
＜実施例＞
図１０は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。ＤＬＬ／インターフェース名及び関数／メソッド名を記述し（「関数／メソッド」とは、「関数またはメソッド」の意、以下同じ）、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。
【００２７】
図１１は、図１０に示した関数定義ファイルを用いて、本発明の実施形態にかかるソフトウェア評価システムで取得した、ログの一例を示す図である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻（Ｉｎ時刻、Ｏｕｔ時刻）、及びその際のパラメータ／戻り値が、ログとして生成される。
【００２８】
以上の説明から明らかなように、本実施形態にかかるログ取得方法によれば、複数にモジュール分けされたソフトウエアの処理ログの取得において、モジュール自体に変更を加えることなく、モジュール内に用意された関数／メソッドの呼び出しを処理ログとして記録することが可能となり、処理ログ取得のための作業負荷を低減することが可能となる。また、生成される処理ログは、時間順の処理ログとして取得することができ、処理ログの解析が容易となるため、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【００２９】
【第２の実施形態（その１）】
上記第１の実施形態では、ＥＸＥによって呼び出される関数／メソッドすべてについて処理ログを取得することとした。しかしながら、この場合、取得される処理ログの数が膨大になってしまうことも考えられる。そこで、本実施形態ではＥＸＥによって呼び出される関数／メソッドのうち、処理ログの取得対象を限定する場合について述べる。
【００３０】
一般にソフトウェアのモジュール構成は、ＯＳ ＳｕｒｆａｃｅによってＯＳ部分のＤＬＬとアプリケーション部分のＤＬＬとに分けられる。図１２は、一般的なソフトウェアのモジュール構成の一例を示す図である。同図において、１２００はＡＰＰ．ＥＸＥであり、１２０１〜１２０３はそれぞれ、ＭｏｄｕｌｅＡ．ｄｌｌ、ＭｏｄｕｌｅＢ．ｄｌｌ、ＭｏｄｕｌｅＣ．ｄｌｌであり、アプリケーション部分のＤＬＬである。一方、１２０５〜１２１０はそれぞれ、Ｕｓｅｒ３２．ｄｌｌ、ＧＤＩ３２．ｄｌｌ、Ｎｔｄｌｌ．ｄｌｌ、Ｗｓ２＿３２．ｄｌｌ、Ｕｎｉｄｒｖ．ｄｌｌであり、ＯＳ部分のＤＬＬである。
【００３１】
そこで、本実施形態では、このようなモジュール構成を備えるソフトウェアにおいて、アプリケーション部分のＤＬＬ内の関数が呼び出された場合のみ処理ログを取得することで処理ログの収集対象を限定する。
【００３２】
図１３は、オペレーティング・システムのモジュールを定義する例を示す図である。このモジュール定義をもって、図１４に示した処理が行なわれる。
【００３３】
図１４は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【００３４】
ステップＳ１４００で処理が開始されると、まず、図１３で示したオペレーティング・システムのモジュール定義１３００を取得し、ＯＳモジュールリストを保持する（ステップＳ１４０１）。続いて、関数／メソッドの呼び出し元のモジュールが、そのＯＳモジュールリストに存在するか否かを判別し（ステップＳ１４０２、Ｓ１４０３）、存在する場合は呼び出し先のモジュールをＯＳモジュールリストに追加する（ステップＳ１４０９）だけで、そのまま元の関数／メソッドを呼び出す（ステップＳ１４１０）。このステップＳ１４０９の処理により、更にそのモジュール以下の呼び出しが行われた場合でも、その呼び出しの処理ログを取得しない手段が確立されている。
【００３５】
一方、ステップＳ１４０３においてＯＳモジュールリストに存在しない場合は、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ１４０４）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ１４０５）。
【００３６】
続いて、本体の関数／メソッドを呼び出す（ステップＳ１４０６）。関数／メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ１４０７）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ１４０８）。続いて、関数／メソッドのリターン処理を行なう（ステップＳ１４１１）。この処理は、評価対象となるプログラムが終了するまで続行される（ステップＳ１４１２）。
【００３７】
図１５Ａは、図１４における処理によって取得された処理ログの例である。なお、比較のために図１５ＢにＯＳ部分のＤＬＬ内の関数が呼び出された際にも処理ログを取得することとした場合の例を示す。図１５Ａと図１５Ｂとを対比することで明らかなように、図１３におけるオペレーティング・システムのモジュール定義１３００により、図１５ＡではＫｅｒｎｅｌ３２．ｄｌｌからＮｔｄｌｌ．ｄｌｌに対する呼び出し、あるいはＵｓｅｒ３２．ｄｌｌからＷｓ２＿３２．ｄｌｌに対する呼び出しといった、オペレーティング・システムの内部の処理ログも含めた処理ログが取得されていないため、よりサイズの小さい処理ログで解析することが可能となっている。
【００３８】
以上の説明から明らかなように、本実施形態によれば、関数定義ファイルにおいて「オペレーティング・システムのサーフェイス」を指定することで、ソフトウェアに対する適切な処理ログが取得可能となり、バグ原因特定などの解析が可能となる。
【００３９】
【第２の実施形態（その２）】
上記第２の実施形態（その１）においては、オペレーティング・システムのサーフェイス以下すべての処理ログを取得しない例を挙げたが、実際はサーフェイス以下の一部（ＯＳ部分のＤＬＬ）に関しても、処理ログを取得したい場合がある。
【００４０】
例えば、上記第１の実施形態において示したログ取得方法を実現するためのプログラム（以下、「ログ取得プログラム」と称す）は、ドライバＳＤＫ（ＳＤＫ＝Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）に組み込んで利用する場合ことが考えられる。
【００４１】
一般にドライバＳＤＫ（例えばプリンタＳＤＫ）は周辺機器メーカ（プリンタメーカ）により提供されるが、ドライバＳＤＫを用いるソフトウェア（例えば、プリンタに印刷する文書や画像を生成、編集するためのソフトウェア）は他のメーカが作成することが多い。このため、ソフトウェアがドライバＳＤＫ（プリンタＳＤＫ）を使用した際に正常に動作しなかった時は、その原因がドライバＳＤＫ（プリンタＳＤＫ）側のバグによるものなのか、ソフトウェア側のバグによるものなのかを判別することが重要となってくる。このようなケースにおいてはログ取得プログラムにより、プリンタＳＤＫの処理内容を処理ログとして取得しておくことが重要となってくる。そのためには、Ｕｎｉｄｒｖ．ｄｌｌ（１２１０）などのＯＳ部分のＤＬＬ内の関数を呼び出した場合の処理ログも収集対象としておく必要がある。
【００４２】
つまり、処理ログの取得対象を限定するにあたっては、ログ取得プログラムの使用目的に応じて、任意に選択できるようにしておくことが望ましい。本実施形態では、かかる点に考慮したログ取得プログラムについて説明する。
【００４３】
図１６は、このような必要性に鑑みて、オペレーティング・システムの除外モジュール（ログ取得対象外として定義されるオペレーティング・システムのモジュールから除外するモジュール、つまり、ログ取得対象となるモジュール）を定義する例を示す図である。この除外モジュール定義及び図１３に示したサーフェイス定義をもって、図１７にあらわした処理が行なわれる。本実施形態では、サーフェイスから除外の指定をユーザが行なうことにより、上記のケースにおいてドライバの処理ログをソフトウェアの処理ログと併せて取得する。
【００４４】
図１７は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【００４５】
ステップＳ１７００において処理が開始されると、まず本ログ取得プログラムは、図１３で示したオペレーティング・システムのモジュール定義１３００を取得し、ＯＳモジュールリストを保持する（ステップＳ１７０１）。続いて、図１６で示した除外モジュール定義を取得し、除外モジュールリストを保持する（ステップＳ１７０２）。続いて、関数／メソッドの呼び出し元のモジュールが存在するかどうかを、ＯＳモジュールリスト及び除外モジュールリストの両リストから検索する（ステップＳ１７０３）。
【００４６】
続いて、呼び出し元のモジュールがＯＳモジュールリストに存在するか否かを判別し（ステップＳ１７０４）、存在する場合は、呼び出し元が除外モジュールであるかどうかを判別する（ステップＳ１７０５）。ＯＳモジュールリストに存在し、且つ除外モジュールリストに存在しない場合、本ログ取得プログラムは、呼び出し先のモジュールをＯＳモジュールリストに追加する（ステップＳ１７１１）だけで、そのまま元の関数／メソッドを呼び出す（ステップＳ１７１２）。
【００４７】
呼び出し元のモジュールが、ステップＳ１７０４においてＯＳモジュールリストに存在しない場合、及びステップＳ１７０５において除外モジュールリストに存在する場合は、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ１７０６）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ１７０７）。
【００４８】
続いて、本体の関数／メソッドを呼び出す（ステップＳ１７０８）。関数／メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ１７０９）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ１７１０）。続いて、関数／メソッドのリターン処理を行なう（ステップＳ１７１３）。
【００４９】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ１７１４）続行される。
【００５０】
このように「オペレーティング・システムのサーフェイス」及び「サーフェイスからの除外モジュール」を指定可能なＡＰＩトレーサにより、ソフトウェアに対する適切な処理ログが取得可能となり、バグ原因特定などの解析が可能となる。
【００５１】
【第２の実施形態（その３）】
上記第２の実施形態（その１）、（その２）において、図１４のステップＳ１４０１、図１７のステップＳ１７０１では、ＯＳモジュールリストの取得をオペレーティング・システムが提供した情報によって自動的に取得することとしたがこれに限られない。また、「オペレーティング・システムが提供した情報」は、オペレーティング・システムが用意したインターフェースから取得するものでも構わないし、例えばＷｉｎｄｏｗｓ（登録商標） ＯＳの場合、レジストリ情報でも構わない。
【００５２】
また、図１４に示した処理を行なうか、図１７に示した処理を行なうかを、ユーザが明示的に選択できるようにしてもよい。。
【００５３】
さらに、上記第２の実施形態（その２）では、あらかじめオペレーティング・システムの除外モジュールの定義がなされていることとしたが、図１７のステップＳ１７０２において、ユーザが任意に指定できるようにしてもよい。
【００５４】
【第３の実施形態（その１）】
上記第１の実施形態では、関数定義ファイルとして、ＤＬＬ名／インターフェース名／関数名／メソッド名と、その関数／メソッドに対するパラメータ及び戻り値の型とを記述することとしたが（図１０参照）、本発明にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルの記述は、これに限られない。本実施形態では、特殊な構造体データを含む関数として、ＤＥＶＭＯＤＥを含む関数のログを取得する場合の、関数定義ファイルの記述方法と当該関数定義ファイルにおけるログ取得方法とについて説明する。
【００５５】
ＤＥＶＭＯＤＥとは、プリンタドライバのユーザインタフェースで設定できる印刷設定がどのように設定されているかを示すＷｉｎｄｏｗｓ（登録商標）の構造体のことをいい、ＤＥＶＭＯＤＥにはＯＳが共通で定義している部分と、プリンタベンダが拡張して使用できる部分（拡張領域）とがある。そして、ＤＥＶＭＯＤＥの最初に「拡張領域サイズ」が指定されている。このように拡張領域のサイズが指定されている場合には、ＤＥＶＭＯＤＥ構造体へのポインタがＡＰＩトレーサのパラメータとして入力された場合、ＤＥＶＭＯＤＥの標準領域（サイズ固定）の最後のアドレスから指定サイズ分だけデータ内容を読み出してログとして取得するように、関数定義ファイルに書き込むことで、ＤＥＶＭＯＤＥを含む関数の処理ログを取得することが可能となる。以下に詳細に説明する。
【００５６】
図１８は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルの一例であり、一般的に広く用いられているＩＤＬにより記述されている。本ソフトウェア評価システムに於いては、このＩＤＬをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、本実施形態は付加バイナリ情報取得のための定義手段を提供することを特徴とするものであり、関数定義ファイルはＩＤＬでなくても構わない。例えば、通常のテキストファイルを用いることも可能であり、ＸＭＬなどのマークアップ言語を用いることも可能である。
【００５７】
図１９は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対して付加バイナリ情報取得を指定することで、ポインタ・データの実体を処理ログとして取得すべく、ＩＤＬにより記述されている。
【００５８】
ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の定義に於いて、ｌｏｎｇｃＥｘｔｒａＢｉｎａｒｙＤａｔａに対してｃｕｓｔｕｍ（ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ，"ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ（）"）と宣言している（１９０１）。ここで、ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ（１９００）はＩＤＬの中で本ソフトウェア評価システムが利用するための識別子である。ここで、" ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ （）"と定義しておき、ＦｕｎｃＳｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ関数に引数をＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ＊ ｌｐＰａｒａｍと定義しておく（１９０２）ことにより、ＦｕｎｃＳｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓ関数が実際に呼び出された際に、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の置かれたメモリ領域の先頭から、ｃＥｘｔｒａＢｉｎａｒｙＤａｔａが指すサイズ分だけの、付加情報としてのバイナリデータを処理ログとして保存する。
【００５９】
図２０は、図１９に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【００６０】
この図では、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体（２０００）が置かれたメモリの先頭アドレスの０ｘ０１Ｆ７Ｂ０００であるとして説明する。１ｂｙｔｅのデータであるｃｈＰａｒａｍ１（２００１）は０ｘ０１Ｆ７Ｂ０００に置かれ、４ｂｙｔｅのデータであるｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅ（２００２）は０ｘ０１Ｆ７Ｂ００１に置かれ、１ｂｙｔｅのデータであるｃｈＰａｒａｍ２（２００３）は０ｘ０１Ｆ７Ｂ００５に置かれ、１ｂｙｔｅのデータであるｃｈＰａｒａｍ３（２００４）は０ｘ０１Ｆ７Ｂ００６に置かれている。
【００６１】
ここまでは通常の構造体メモリ配置と同一であるが、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体はｃｈＰａｒａｍ３に続くメモリ、すなわち０ｘ０１Ｆ７Ｂ００７からの領域にＥｘｔｒａＢｉｎａｒｙＤａｔａ（２００５）という付加データを持っており、そのサイズがｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅに応じて可変となっている。例えば、ｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅの値として８が入っている場合には、ＥｘｔｒａＢｉｎａｒｙＤａｔａは８ｂｙｔｅ存在することになるため、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の最後尾のメモリアドレスは０ｘ０１Ｆ７Ｂ００Ｅとなる。このため、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＥＸＴＲＡ構造体の指し示すすべてのデータをログに取得するためには、このＥｘｔｒａＢｉｎａｒｙＤａｔａを、ｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅの値の分だけバイナリデータとして取得する必要がある。図１９におけるｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義は、この必要を満たすために記述されている。
【００６２】
図２１は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９に示すように関数定義ファイルが記述されている時の処理ログを取得する場合の処理の流れを示すフローチャートである。
【００６３】
処理が開始されると（ステップＳ２１００）、ログ取得を開始し、モジュール名／インターフェース名／関数名／メソッド名をＨＤＤに保存する（ステップＳ２１０１）。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２１０２）。そして、関数定義にｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの設定が存在するかどうか、すなわちｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を含んだ構造体がパラメータに存在するか否かを判別し（ステップＳ２１０３）、存在する場合には、まずその定義を含む構造体のサイズを計算する（ステップＳ２１０４）。
【００６４】
続いて、構造体の先頭ポインタから計算した構造体サイズの分だけずれたメモリ領域から、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓで示されたメンバの値によって示されるサイズ分だけ、データをＨＤＤに保存する（ステップＳ２１０５）。続いて、元の関数／メソッドを呼び出す（ステップＳ２１０６）。
【００６５】
関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２１０７）。そして、関数定義にｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの設定が存在するかどうか、すなわちｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を含んだ構造体がパラメータ／戻り値に存在するか判別し（ステップＳ２１０８）、存在する場合には、その定義を含む構造体のサイズを計算する（ステップＳ２１０９）。続いて、構造体の先頭ポインタから計算した構造体サイズの分だけずれたメモリ領域から、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓで示されたメンバの値によって示されるサイズ分だけ、データをＨＤＤに保存する（ステップＳ２１１０）。この処理はユーザから終了の命令により終了する（ステップＳ２１１１）。なお、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓで指定されたメンバが複数にわたる場合は、当然ステップＳ２１０４〜ステップＳ２１０５及びステップＳ２１０９〜ステップＳ２１１０の処理が指定された数すべてに対して行なわれる。
【００６６】
図２２は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９の関数定義ファイルにより取得された処理ログを示す図である。
【００６７】
ここでは処理ログはテキスト部分（２２００）とバイナリ部分（２２０１）とに分けて表示しており、テキストデータに書き込まれたＤａｔａＩＤが、バイナリ部分に書き込まれたＤａｔａＩＤに対応している。例えば、一度目の呼び出しのログではＤａｔａＩＤが０ｘ０００１であるが、このＩＤがバイナリ部分に書き込まれた付加バイナリ情報、ＤａｔａＩＤ=０ｘ０００１を指し示している。この場合、ＦｕｎｃＳｔｒｕｃｔｓｉｚｅｅｘｔｒａＩｓの１度目の呼び出しでは８バイト、２度目の呼び出しでは４０バイト、３度目の呼び出しでは５バイト、４度目の呼び出しでは７バイトの付加バイナリデータが取得されている。ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を行なわない場合には、ｃｈＰａｒａｍ１及びｃＥｘｔｒａＢｉｎａｒｙＤａｔａＳｉｚｅ及びｃｈＰａｒａｍ２及びｃｈＰａｒａｍ３のみが取得されるが、ｓｔｒｕｃｔｓｉｚｅｅｘｔｒａ＿ｉｓの定義を行なうことにより、付加バイナリデータであるＥｘｔｒａＢｉｎａｒｙＤａｔａを、それぞれの呼び出しに応じたサイズ分、処理ログに取得することが可能となっている。
【００６８】
このように、構造体のメンバに応じた処理ログ取得のための関数定義手段を設けることにより、通常では取得しきれないデータを、バイナリデータとして処理ログに取得することが可能となる。
【００６９】
【第３の実施形態（その２）】
上記第３の実施形態（その１）では、特定の構造体の最後尾のアドレスから所定サイズ分のデータを処理ログとして取得するための関数定義ファイルの記述方法と、その場合のログ取得プログラムの処理について述べたが、本発明にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルの記述方法はこれに限られない。
【００７０】
図２３は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対してメンバをオフセットとして指定することで、ポインタ・データの実体をログとして取得すべく、ＩＤＬにより記述されている。
【００７１】
ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体の定義に於いて、ＬＰＳＴＲ ｌｐｓｚＳｔｒｉｎｇ及びｌｏｎｇ ｎＮｕｍｂｅｒに対してｃｕｓｔｕｍ（ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ, " ｐｔｒｄｉｆｆ （）"）と宣言している（２３０１、２３０２）。ここで、ＰＡＴ＿ＰＡＲＡＭ＿ＡＴＴＲ＿ＩＤ（２３００）はＩＤＬの中で本ソフトウェア評価システムが利用するための識別子である。ここで、" ｐｔｒｄｉｆｆ （）"と定義しておき、ＦｕｎｃＰｔｒｄｉｆｆ関数に引数をＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ＊ ｌｐＰａｒａｍと定義しておく（２３０３）ことにより、ＦｕｎｃＰｔｒｄｉｆｆ関数が実際に呼び出された際に、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体の置かれたメモリ領域の先頭から、ｌｐｓｚＳｔｒｉｎｇ及びｎＮｕｍｂｅｒの数値によって表されるオフセットだけずれたメモリ領域に格納された、ＬＰＳＴＲ及びｌｏｎｇのデータを処理ログとして保存する。
【００７２】
ｐｔｒｄｉｆｆ（）の宣言は、以下の２つの条件定義を兼ねている。
（１）ｐｔｒｄｉｆｆ（）で指定された引数は、実際には規定された型ではなく、構造体の先頭アドレスに対するオフセットを表す数値として扱われること。
（２）そのオフセットの指し示すメモリエリアに、規定された型のデータが保持されていること。
【００７３】
図２４は、図１８に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【００７４】
この図では、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体（２４００）が置かれたメモリの先頭アドレスの０ｘ０１Ｆ７Ｂ０００であるとして説明する。１ｂｙｔｅのデータであるｃｈＰａｒａｍ１（２４０１）は０ｘ０１Ｆ７Ｂ０００に置かれ、４ｂｙｔｅのデータであるｌｐｓｚＳｔｒｉｎｇへのオフセット（２４０２）は０ｘ０１Ｆ７Ｂ００１に置かれ、４ｂｙｔｅのデータであるｎＮｕｍｂｅｒへのオフセット（２４０３）は０ｘ０１Ｆ７Ｂ００５に置かれ、１ｂｙｔｅのデータであるｃｈＰａｒａｍ２（２４０４）は０ｘ０１Ｆ７Ｂ００９に置かれている。ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体において、ｌｐｓｚＳｔｒｉｎｇの実体はオフセット（２４０２）によって示されたサイズ分、構造体の先頭アドレスからずらした領域に格納されており（２４０５）、ｎＮｕｍｂｅｒの実体はオフセット（２４０３）によって示されたサイズ分、構造体の先頭アドレスからずらした領域に格納されている（２４０６）。このため、ＴＥＳＴＳＴＲＵＣＴ＿ＷＩＴＨＰＴＲＤＩＦＦ構造体の指し示すすべてのデータを処理ログに取得するためには、これらｌｐｓｚＳｔｒｉｎｇ及びｎＮｕｍｂｅｒに関して、実体のデータをログとして取得する必要がある。図２３におけるｐｔｒｄｉｆｆの定義は、この必要を満たすために記述されている。
【００７５】
図２５は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図２３に示すように関数が定義されている時のログを取得する場合の処理の流れを示すフローチャートである。
【００７６】
処理が開始されると（ステップＳ２５０１）、ログ取得を開始し、モジュール名／インターフェース名／関数名／メソッド名をＨＤＤに保存する（ステップＳ２５０２）。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２５０３）。そして、関数定義ファイルにｐｔｒｄｉｆｆの設定が存在するかどうか、すなわちｐｔｒｄｉｆｆの定義を含んだ構造体がパラメータに存在するか否かを判別し（ステップＳ２５０４）、存在する場合には、構造体の先頭アドレスとｐｔｒｄｉｆｆで定義された構造体メンバのオフセットの値を合算し、ｐｔｒｄｉｆｆで定義された構造体メンバがどのアドレスに格納されているかを計算する（ステップＳ２５０５）。続いて、計算したアドレスの指し示すメモリ領域から、ｐｔｒｄｉｆｆで示されたメンバの型のデータをＨＤＤに保存する（ステップＳ２５０６）。続いて、元の関数／メソッドを呼び出す（ステップＳ２５０７）。関数／メソッドからリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をＨＤＤに保存する（ステップＳ２５０８）。そして、関数定義ファイルにｐｔｒｄｉｆｆの設定が存在するかどうか、すなわちｐｔｒｄｉｆｆの定義を含んだ構造体がパラメータ／戻り値に存在するか否かを判別し（ステップＳ２５０９）、存在する場合には、構造体の先頭アドレスとｐｔｒｄｉｆｆで定義された構造体メンバのオフセットの値を合算し、ｐｔｒｄｉｆｆで定義された構造体メンバがどのアドレスに格納されているかを計算する（ステップＳ２５１０）。続いて、計算したアドレスの指し示すメモリ領域から、ｐｔｒｄｉｆｆで示されたメンバの型のデータをＨＤＤに保存する（ステップＳ２５１１）。この処理はユーザから終了の命令により処理を終了する（ステップＳ２５１２）。なお、ｐｔｒｄｉｆｆで指定されたメンバが複数に渡る場合は、当然ステップＳ２５０５〜ステップＳ２５０６及びステップＳ２５１０〜ステップＳ２５１１の処理が指定された数すべてに対して行なわれる。
【００７７】
図２６は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図２３の関数定義ファイルにより取得された処理ログを示す図である。それぞれの呼び出しでオフセットが異なっているが、本ソフトウェア評価システムは、オフセットで指し示された実体を的確に処理ログとして取得している。
【００７８】
以上の説明から明らかなように、本実施形態によれば、構造体のメンバに応じたログデータ取得のための定義手段を設けることにより、通常では取得しきれないデータを含む関数／メソッドであっても、処理ログを取得することが可能となる。
【００７９】
【第４の実施形態（その１）】
上記第１の実施形態では、関数定義ファイルとして、ＤＬＬ名／インターフェース名／関数名／メソッド名と、その関数／メソッドに対するパラメータ及び戻り値の型とを記述することとしたが（図１０参照）、本発明にかかるログ取得方法を実現するソフトウェア評価システムにける関数定義ファイルの記述は、これに限られない。本実施形態では、特殊なＣＯＭに対してログを取得する場合の、関数定義ファイルの記述方法について説明する。
【００８０】
一般に、プリンタドライバには、ＯＳに予め組み込まれているＵＮＩＤＲＩＶＥＲ（ユニドライバ）を用いる場合と、モノレシックドライバを用いる場合とがある。そして、プリンタベンダーはモノレシックドライバ、またはユニドライバからの出力を受け取るプラグインモジュール（＊．ｄｒｖ）を提供している。モノレシックドライバの場合は、ＧＤＩ３２．ｄｌｌは一般的なＤＤＩ関数を用いる。
【００８１】
ここで、ＤＬＬ同士は、レジストリに登録されているＡＰＩを用いてデータのやり取りを行うが、ユニドライバがプリンタベンダが提供するプラグインモジュールに出力する処理内容は、レジストリに登録されていないＣＯＭ（ｏｂｊｅｃｔ−ＡＰＩ）である。このため、上記第１の実施形態において示した関数定義ファイルでは、特殊なＣＯＭについての処理ログを取得することができない。そこで、本実施形態ではユニドライバが吐き出すレジストリに登録されていないＣＯＭを通常のＣＯＭとして扱うように関数定義ファイルを記述することで適切なログを取得することとする。
【００８２】
図２７は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、それぞれの関数／メソッドのパラメータの形式や、戻り値の形式を指示する関数定義ファイルの例であり、一般的に広く用いられているＩＤＬにより記述されている。ＤＬＬ名／インターフェース名／関数名／メソッド名を記述し、その関数／メソッドに対する、パラメータ／戻り値の型が示されている。本発明の第４の実施形態にかかるソフトウェア評価システムに於いては、このＩＤＬをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、本実施形態は、より詳細な情報取得のための関数定義手段を提供することを特徴とするものであり、関数定義ファイルはＩＤＬにより記述されていなくても構わない。例えば、通常のテキストファイルを用いることも可能であり、ＸＭＬなどのマークアップ言語を用いることも可能である。
【００８３】
本発明の第４の実施形態にかかるソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。なお、本実施形態では、Ｉｎｔｅｒｆａｃｅ ｔｅｓｔに実装されたＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔという名前の関数が、以下のようなパラメータを持つ状態を例としている。
（１）入力パラメータの"ｒｃｌｓｉｄ"、すなわち「クラスＩＤ」をあらわすパラメータ。
（２）入力パラメータの"ｒｉｉｄ"、すなわち「リファレンス・インターフェースＩＤ」をあらわすパラメータ。
（３）出力パラメータの"ｐｐｖ"、すなわち、上記２つの入力パラメータを元に得られた、実体としてのインターフェースポインタ。
【００８４】
ＤＬＬ内にコードとして記述されたＩｎｔｅｒｆａｃｅ内のメソッドを、ＥＸＥが呼び出すためには、先にＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔ関数を用いて、クラスＩＤ及びリファレンス・インターフェースＩＤを元にしたＩｎｔｅｒｆａｃｅのインスタンスを生成し、そのインスタンスのメモリアドレスを知っておく必要がある。
【００８５】
図２７に示された"ｉｉｄ＿ｉｓ"（２７０３）が、本実施形態の特徴を最もよくあらわすものである。すなわち、ｉｉｄ＿ｉｓに第二引数であるｒｉｉｄを指定することで「この出力パラメータは、実際にはｖｏｉｄ * ではなく、ｒｉｉｄに指定された型のインターフェースである」という定義を行なっている。この定義をＡＰＩトレーサが認識することにより、従来取得できなかった「ｐｐｖで返ってきたインターフェース内に実装されたメソッドの呼び出し」に関しても、詳細が処理ログとして取得できるようになっている。
【００８６】
図２８は、ｒｉｉｄに指定するインターフェース型を定義した、関数定義ファイルの例である。ここでは、ＩＵｎｋｎｏｗｎという名前のインターフェースから派生した、ＩＧｅｔＩｎｆｏというインターフェースを定義している。ＩＧｅｔＩｎｆｏには、ＧｅｔＮａｍｅ及びＦｒｅｅＮａｍｅＢｕｆｆｅｒという２つのメソッドが実装されている。
【００８７】
図２９は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【００８８】
処理が開始されると（ステップＳ２９００）、設定された関数／メソッドが呼び出される都度に、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ２９０１）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ２９０２）。続いて、入力パラメータの関数定義ファイルに、図２７によって説明したｉｉｄ＿ｉｓ、すなわち「リファレンス・インターフェースＩＤの定義」があるかどうかを判別し（ステップＳ２９０３）、存在する場合は、そのリファレンス・インターフェースＩＤを、メモリ上の別のエリアに保存しておく（ステップＳ２９０４）。
【００８９】
本体の関数／メソッドを呼び出し（ステップＳ２９０５）、メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ２９０６）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ２９０７）。
【００９０】
次に、出力パラメータがインターフェースへのポインタとして定義されているかどうかを、図２７に示した関数定義ファイルに基づいて判断し（ステップＳ２９０８）、定義されている場合は、リファレンス・インターフェースＩＤがメモリ上に保存されているかどうかを判断する（ステップＳ２９０９、ステップＳ２９１０）。リファレンス・インターフェースＩＤが保存されていない場合には、その出力パラメータをインターフェースそのものへのポインタとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ２９１１）、該当するパラメータ／戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ２９１２）。リファレンス・インターフェースＩＤが保存されている場合、その出力パラメータを、リファレンス・インターフェースＩＤがあらわすインターフェースへ派生した形のポインタ、例えば図２８に示したＩＧｅｔＩｎｆｏとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ２９１３）、該当するパラメータ乃至戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ２９１４）。
【００９１】
ステップＳ２９１２またはステップＳ２９１４の処理が終了するか、もしくはステップＳ２９０８においてインターフェースポインタとして定義されていないことを判断した場合は、関数／メソッドのリターン処理を行なう（ステップＳ２９１５）。
【００９２】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ２９１６）続行される。
【００９３】
図３０は、図２９における処理によって取得された処理ログの例である。図２７におけるｉｉｄ＿ｉｓの定義により、ＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔの出力パラメータｐｐｖをＩＧｅｔＩｎｆｏ型のインターフェースとして認識した結果、ＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔのログだけでなく、ＩＧｅｔＩｎｆｏインターフェース内に実装されたメソッドの呼び出しに関しても、処理ログとして取得することが可能となっている。なお本実施形態は、リファレンス・インターフェースＩＤを認識することを特徴とするものであり、実際のリファレンス・インターフェースＩＤ（３００１）とＩＧｅｔＩｎｆｏとの関連付けは、公知の技術を元に行なわれる。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＯＳにおいては、この情報はレジストリに置かれており、レジストリ情報を元に関連付けが可能である。ただし、他の方法を用いて関連付けを行なっても構わない。
【００９４】
以上の説明から明らかなように、本実施形態によれば、関数定義ファイルとして、「ある入力パラメータが、出力パラメータの型をあらわす」ことを指定することにより、ソフトウェアに対する更に詳細な処理ログを取得することが可能となり、バグ原因特定など、より詳細な解析が可能となる。
【００９５】
【第４の実施形態（その２）】
上記第４の実施形態（その１）においては、実体すなわちインスタンスとしてのインターフェースの解決を行なっているが、これだけでは「インスタンスを生成する元となっている情報」すなわち、オブジェクト指向プログラミングにおける「クラス情報」に基づいた情報を、処理ログとして取得できない。そこで本実施形態では、クラス情報を追加情報として処理ログに取得するために、クラスＩＤをインターフェースＩＤと関連付ける場合について説明する。
【００９６】
本実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルでは、クラスＩＤは、図２７におけるＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔのｒｃｌｓｉｄをもって定義し、その定義のために「ｃｌｓｉｄ＿ｉｓ」という関数定義を用いる。この「ｃｌｓｉｄ＿ｉｓ」とは、「このＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔにおいては、ｃｌｓｉｄ＿ｉｓで指定されたパラメータをクラスＩＤとするクラス情報を元にしてインターフェースのインスタンスが生成されている」ということを指定するための関数定義である。このように関数定義ファイルを記述することにより、本実施形態にかかるソフトウェア評価システムは、より詳細な情報をログとして取得することが可能となっている。
【００９７】
図３１及び図３２は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートであり、図２９とは別の一例である。
【００９８】
処理が開始されると（ステップＳ３１００）、設定された関数／メソッドが呼び出される都度に、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ３１０１）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ３１０２）。続いて、入力パラメータの関数定義ファイルに、図２７及び上記によって説明したｃｌｓｉｄ＿ｉｓ、すなわち「クラスＩＤの定義」があるかどうかを判別し（ステップＳ３１０３）、存在する場合は、そのクラスＩＤをメモリ上の別のエリアに保存しておく（ステップＳ３１０４）。続いて、入力パラメータの関数定義ファイルに、図２７によって説明したｉｉｄ＿ｉｓ、すなわち「リファレンス・インターフェースＩＤの定義」があるかどうかを判別し（ステップＳ３１０５）、存在する場合は、そのリファレンス・インターフェースＩＤをメモリ上の別のエリアに保存しておく（ステップＳ３１０６）。
【００９９】
本体の関数／メソッドを呼び出し（ステップＳ３１０７）、メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ３１０８）、その呼び出しに対してのパラメータ／戻り値をＨＤＤに保存する（ステップＳ３１０９）。次に、出力パラメータがインターフェースへのポインタとして定義されているかどうかを、図２７に示した関数定義ファイルに基づいて判断し（ステップＳ３１１０）、定義されている場合は、リファレンス・インターフェースＩＤがメモリ上に保存されているかどうかを判断する（図３２のステップＳ３２００、Ｓ３２０１）。リファレンス・インターフェースＩＤが保存されていない場合、その出力パラメータを、インターフェースそのものへのポインタとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ３２０３）、該当するパラメータ／戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ３２０４）。リファレンス・インターフェースＩＤが保存されている場合、その出力パラメータをリファレンス・インターフェースＩＤがあらわすインターフェースへ派生した形のポインタ、例えば図２８に示したＩＧｅｔＩｎｆｏとして認識し、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ３２０５）、該当するパラメータ／戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ３２０６）。
【０１００】
ステップＳ３２０４またはステップＳ３２０６の処理が終了すると、メモリにクラスＩＤが保存されているかを判別し（ステップＳ３２０７）、保存されている場合は、保存されたクラスＩＤをログ取得コードと関連付けてメモリに保持しておく（ステップＳ３２０８）。続いて、関数／メソッドのリターン処理を行なう（図３１のステップＳ３１１２）。この処理は、評価対象となるプログラムが終了するまで（ステップＳ３１１３）続行される。
【０１０１】
ステップＳ３２０８においてクラスＩＤを保持しておくことにより、ＩＧｅｔＩｎｆｏ内の関数が呼ばれた際に、そのクラス情報を元に、ステップＳ３１０１においてより詳細な情報をログに取得することが可能となる。図３３は、図３０に対して、クラスＩＤを元にモジュール名が追加でログ取得可能となっていることをあらわしている（３３０３、３３０４、３３０５、３３０６）。
【０１０２】
なお本実施形態は、クラスＩＤをインターフェース・パラメータと関連付けつつ、リファレンス・インターフェースＩＤを認識することを特徴とするものであり、実際のクラスＩＤ（３０００）と、モジュール名等詳細情報との関連付けは、公知の技術を元に行なわれる。例えば、Ｗｉｎｄｏｗｓ（登録商標） ＯＳにおいては、この情報はレジストリに置かれており、レジストリ情報を元に関連付けが可能である。が、他の方法を用いて関連付けを行なっても構わない。
【０１０３】
以上の説明から明らかなように、本実施形態によれば、関数定義ファイルにおいて「ある入力パラメータが、出力パラメータの型をあらわす」ことを指定することにより、ソフトウェアに対する更に詳細な処理ログを取得することが可能となり、バグ原因特定など、より詳細な解析が可能となる。
【０１０４】
【第５の実施形態（その１）】
上記第４の実施形態によれば、特殊なＣＯＭに対するログを取得することが可能となるが、かかる特殊なＣＯＭの場合、処理ログの対象となるモジュール名がレジストリに定義されていないため、モジュール名に基づいて処理ログを取得することができない。そこで、本実施形態では個々のインターフェース名（ＣＯＭの処理内容）に対するモジュール名を追加定義として用意し、処理ログを作成する際にインターフェース名からモジュール名を判断して書き込むこととする。
【０１０５】
図３４は、本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける関数定義ファイルの一例であり、一般的に広く用いられているＩＤＬにより記述されている。本ソフトウェア評価システムに於いては、このＩＤＬをトークン化したタイプライブラリ・ファイルを関数定義ファイルとして使用する。
【０１０６】
ＩＤＬはインターフェースの定義に用いられるものであり、標準ではモジュール名の定義は不可能である。例えば、複数のモジュールが、同じインターフェース定義でインターフェースを提供しており、それらが選択的にプラグイン・モジュールとして用いられている場合、インターフェース定義を行なっても、それらのインターフェースがどのプラグイン・モジュールに属するものであるかは、それらプラグイン・モジュールを選択的に呼び出しているモジュールのみが知り得る。例えば、オペレーティング・システムが選択的にドライバ用のプラグイン・モジュールを呼び出している場合、オペレーティング・システムが選択を行なうアルゴリズムが公開されていない場合は、モジュール名を関連付けて呼び出しに関する詳細情報を処理ログに取得することは不可能である。具体的には、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムに搭載されている、ユニバーサル・プリンタドライバのプラグイン・モジュールなどが考えられる。
【０１０７】
ただし、これらのプラグイン・モジュールは、ユーザの操作に関連付けられて選択的に呼び出されているケースが多い。例えば、プリンタドライバにおいては、複数搭載されたプリンタのうち、ユーザがどのプリンタで出力するのかを選択して、その選択操作に対して１対１に対応するプラグイン・モジュールが呼び出される。この場合、ＩＤＬによるインターフェース定義とは別途「今回の操作に対してはこのモジュールが呼び出される」ということを知り得て、尚且つその情報を、ログ取得プログラムに対し指示する手段があれば、その手段を用いて、上記プラグイン・モジュールのモジュール名も含めた形の処理ログを取得することが可能となる。
【０１０８】
図３５は、ライブラリ名に対してモジュール名を定義した関数定義ファイルの例であり、３５００でライブラリ名を、３５０１でモジュールの置かれているフォルダ名を、３５０２でモジュール名をそれぞれ定義している。
【０１０９】
図３６は、インターフェース名に対してモジュール名を定義した関数定義ファイルの例であり、３６００でインターフェース名を、３６０１でモジュールの置かれているフォルダ名を、３６０２でモジュール名をそれぞれ定義している。
【０１１０】
なお、本実施形態では、図３５乃至図３６におけるモジュール名の追加定義を、単なるテキストファイルで示しているが、本実施形態はＩＤＬのような「ＤＬＬ／インターフェース／関数／メソッドを定義するための標準フォーマット」に対して別のフォーマットの追加定義を行ない、それを元に関数／メソッドのログを取得することを特徴とするものであり、追加定義は単なるテキストファイルではなく、ＨＴＭＬやＸＭＬといったマークアップ言語で記述されていても構わない。
【０１１１】
図３７は、本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートであり、本実施形態の特徴を最もよくあらわすものである。
【０１１２】
処理が開始されると（ステップＳ３７００）、設定された関数／メソッドが呼び出される都度に、ＤＬＬ名／インターフェース名／関数名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ３７０１）、その呼び出しに対してのパラメータをＨＤＤに保存する（ステップＳ３７０２）。続いて、入力パラメータの関数定義ファイルに、図３５乃至図３６によって説明した、モジュール名の追加定義が存在するかどうかを判別し（ステップＳ３７０３）、存在する場合は、そのモジュール名をメモリ上の別のエリアに保存しておく（ステップＳ３７０４）。
【０１１３】
本体の関数／メソッドを呼び出し（ステップＳ３７０５）、メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／関数名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ３７０６）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ３７０７）。続いて、関数／メソッドのリターン処理を行なう（ステップＳ３７０８）。
【０１１４】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ３７０９）続行される。
【０１１５】
このように、モジュール名を関数定義とは別のフォーマットで追加定義して、それを元に処理ログの取得を行なうことにより、例えばプラグイン・モジュールがユーザの操作に関連付けられて選択的に呼び出されているケースに対して、プラグイン・モジュールのモジュール名も含めた形の処理ログを取得することが可能となる。この機能を持つＡＰＩトレーサにより、ソフトウェアに対してモジュール名を必ず含んだ形での処理ログが取得可能となり、バグ原因特定など、より詳細な解析が可能となる。
【０１１６】
【第５の実施形態（その２）】
上記第５の実施形態（その１）においては、モジュール名の追加定義をテキストファイルで行なっているが、これに限られず、モジュール定義をユーザが選択できるようなユーザー・インターフェースを備えてもよい。実現方法としては、図３５乃至図３６におけるＰａｔｈ及びＭｏｄｕｌｅＮａｍｅの設定を、ユーザが選択可能なユーザー・インターフェースを備えても構わないし、全体のモジュール名追加定義テキストファイルを複数用意して、それらのファイルを選択するユーザ・インターフェースを備えても構わない。
【０１１７】
【第５の実施形態（その３）】
上記第５の実施形態（その１）および（その２）においては、モジュール名の追加定義を、ユーザが指定乃至選択しているが、これに限られず、追加のモジュール定義をオペレーティング・システムが備えるインターフェースから取得しても構わない。例えば、Ｍｉｃｒｏｓｏｆｔの．ＮＥＴ Ｆｒａｍｅｗｏｒｋでは、各モジュールがＸＭＬ形式のモジュール定義データを含み、モジュール定義データをオペレーティング・システムのインターフェースで取得できる。また、この場合に、オペレーティング・システムから取得したモジュール定義に示されたモジュールに対して、インポート関数アドレステーブル及びエクスポート関数アドレステーブルなどの、モジュール内部に用意されたヘッダ情報を元に、メモリ上でそのモジュール内に実装された関数／メソッドをログ取得ルーチンにリダイレクトして、更にログ情報を詳細に取得することも可能である。例えば、ＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ（登録商標）オペレーティング・システムでは、この機能によって、通常のＤＬＬに実装されたエクスポート関数の呼び出し、ＣＯＭインターフェースに実装されたメソッドの呼び出し、．ＮＥＴアセンブリに実装されたメソッドの呼び出しの３点について、１つのログデータ内に時系列ですべての情報を並べることが可能である。
【０１１８】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【０１１９】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１２０】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１２１】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０１２２】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２３】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２４】
以下に本発明の実施態様の例を示す。
【０１２５】
［実施態様１］ 所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に呼び出されるオペレーティングシステム内の関数のうち、指定された関数を識別する工程と、
ロードされた前記所定の処理を行う関数のアドレスと前記指定されたオペレーティングシステム内の関数のアドレスとを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数および前記指定されたオペレーティングシステム内の関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数および前記指定されたオペレーティングシステム内の関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１２６】
［実施態様２］ 前記所定の処理を行う関数および前記指定されたオペレーティングシステム内の関数を呼び出す際の所定の情報は、少なくとも、呼び出された関数の関数名、呼び出す際の時刻、呼び出す際のパラメータ、または呼び出す際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１に記載のログ取得方法。
【０１２７】
［実施態様３］ 前記実行結果を受け取った際の所定の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１に記載のログ取得方法。
【０１２８】
［実施態様４］ 前記所定の処理を行う関数のアドレスは、該関数を提供するダイナミックリンクライブラリごとに、インポート関数アドレステーブルに記載されていることを特徴とする実施態様１に記載のログ取得方法。
【０１２９】
［実施態様５］ 前記所定の処理を行う関数のアドレスのうち、前記ログ取得のための関数のアドレスに書き換えるアドレスを選択する工程を更に備え、
前記書き換える工程は、前記選択する工程により選択された関数のアドレスを書き換えることを特徴とする実施態様１に記載のログ取得方法。
【０１３０】
［実施態様６］ 所定の１または複数のモジュールを定義する工程と、前記関数の呼び出しが当該定義したモジュールを経由したか否かを判別する工程とを更に備え、当該定義されたモジュールを経由した場合には、当該関数を呼び出す際の前記所定の情報を記録対象から除外することを特徴とする実施態様１のログ取得方法。
【０１３１】
［実施態様７］ オペレーティング・システムに含まれる所定の１または複数のモジュールを定義する工程と、前記関数の呼び出しが経由したモジュールを判別する工程とを更に備え、当該定義されたモジュール以外のオペレーティング・システムに含まれるモジュールを経由した場合には、当該関数を呼び出す際の前記所定の情報を記録対象から除外することを特徴とする実施態様１のログ取得方法。
【０１３２】
［実施態様８］ 前記所定の情報が構造体である場合に、当該構造体が置かれたメモリ領域の先頭から当該構造体のサイズ分だけ後のメモリ領域に格納されている情報を、当該構造体に指定されたサイズに応じて記録することを特徴とする実施態様１のログ取得方法。
【０１３３】
［実施態様９］ 前記所定の情報が構造体である場合に、当該構造体が置かれたメモリ領域の先頭から当該構造体に対して指定されたオフセットより後のメモリ領域に格納されている情報を、定義されたデータ型のデータとして記録することを特徴とする実施態様１のログ取得方法。
【０１３４】
［実施態様１０］ 何れのモジュールの何れの関数の所定の情報の何れがオブジェクトの情報を表わし、何れがオブジェクトのクラスＩＤを表わすかを定義しておき、関数の呼び出しにおいて、オブジェクトのクラスＩＤに基づいて、その関数の所定の情報に格納されたオブジェクトの情報を記録することを特徴とする実施態様１のログ取得方法。
【０１３５】
［実施態様１１］ 何れのモジュールの何れの関数の所定の情報の何れがオブジェクトの情報を表わし、何れがオブジェクトのインターフェースＩＤを表わすかを定義しておき、関数の呼び出しにおいて、オブジェクトのインターフェースＩＤに基づいて、その関数の所定の情報に格納されたオブジェクトの情報を記録することを特徴とする実施態様１のログ取得方法。
【０１３６】
［実施態様１２］ ライブラリまたは各インタフェースに対するモジュール名の追加定義を用意しておき、関数を呼び出す際に、当該追加定義を参照してモジュール名を記録することを特徴とする実施態様１のログ取得方法。
【０１３７】
［実施態様１３］ 所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記所定の処理を行う関数がロードされた場合のアドレスから所定のオフセットを有する領域であって、指定された領域を識別する工程と、
前記ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と、
前記指定された領域のデータを読み出して記録する工程と
を備えることを特徴とするログ取得方法。
【０１３８】
［実施態様１４］ 所定の処理を行う第１の関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に該プログラムの実行ファイルから直接呼び出された前記第１の関数によってのみ呼び出される第２の関数のうち、指定された第２の関数を識別する工程と、
前記第１の関数によって呼び出されることでロードされる前記指定された第２の関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記指定された第２の関数を呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記指定された第２の関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１３９】
［実施態様１５］ 所定の処理を行う第１の関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に、該プログラムの実行ファイルから直接呼び出された前記第１の関数によってのみ呼び出される第２の関数に設定されたＩＤを識別する工程と、
前記第１の関数によって呼び出されることでロードされる前記ＩＤが設定された第２の関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程と、を備え、
前記ログ取得のための関数は、
前記ＩＤが設定された第２の関数を呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記ＩＤが設定された第２の関数を呼び出す際の所定の情報を、前記設定されたＩＤとともに記録する工程と、
前記実行結果を受け取った際の所定の情報を、前記設定されたＩＤとともに記録する工程と
を備えることを特徴とするログ取得方法。
【０１４０】
［実施態様１６］ 所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に呼び出されるオペレーティングシステム内のメソッドのうち、指定されたメソッドを識別する工程と、
ロードされた前記所定の処理を行うメソッドのアドレスと前記指定されたオペレーティングシステム内のメソッドのアドレスとを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドおよび前記指定されたオペレーティングシステム内のメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドおよび前記指定されたオペレーティングシステム内のメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１４１】
［実施態様１７］ 前記所定の処理を行うメソッドおよび前記指定されたオペレーティングシステム内のメソッドを呼び出す際の所定の情報は、少なくとも、呼び出されたメソッドのメソッド名、呼び出す際の時刻、呼び出す際のパラメータ、または呼び出す際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１６に記載のログ取得方法。
【０１４２】
［実施態様１８］ 前記実行結果を受け取った際の所定の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする実施態様１６に記載のログ取得方法。
【０１４３】
［実施態様１９］ 前記所定の処理を行うメソッドのアドレスは、該メソッドを提供するインターフェースごとに、仮想アドレステーブルに記載されていることを特徴とする実施態様１６に記載のログ取得方法。
【０１４４】
［実施態様２０］ 前記所定の処理を行うメソッドのアドレスのうち、前記ログ取得のためのメソッドのアドレスに書き換えるアドレスを選択する工程を更に備え、
前記書き換える工程は、前記選択する工程により選択されたメソッドのアドレスを書き換えることを特徴とする実施態様１６に記載のログ取得方法。
【０１４５】
［実施態様２１］ 所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記所定の処理を行うメソッドがロードされた場合のアドレスから所定のオフセットを有する領域であって、指定された領域を識別する工程と、
前記ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と、
前記指定された領域のデータを読み出して記録する工程と
を備えることを特徴とするログ取得方法。
【０１４６】
［実施態様２２］ 所定の処理を行う第１のメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に該プログラムの実行ファイルから直接呼び出された前記第１のメソッドによってのみ呼び出される第２のメソッドのうち、指定された第２のメソッドを識別する工程と、
前記第１のメソッドによって呼び出されることでロードされる前記指定された第２のメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記指定された第２のメソッドを呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記指定された第２のメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【０１４７】
［実施態様２３］ 所定の処理を行う第１のメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
前記プログラム実行時に、該プログラムの実行ファイルから直接呼び出された前記第１のメソッドによってのみ呼び出される第２のメソッドに設定されたＩＤを識別する工程と、
前記第１のメソッドによって呼び出されることでロードされる前記ＩＤが設定された第２のメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程と、を備え、
前記ログ取得のためのメソッドは、
前記ＩＤが設定された第２のメソッドを呼び出し、該所定の処理を実行させ、実行結果を受け取る工程と、
前記ＩＤが設定された第２のメソッドを呼び出す際の所定の情報を、前記設定されたＩＤとともに記録する工程と、
前記実行結果を受け取った際の所定の情報を、前記設定されたＩＤとともに記録する工程と
を備えることを特徴とするログ取得方法。
【０１４８】
［実施態様２４］ 実施態様１乃至２３のいずれか１つに記載のログ取得方法をコンピュータによって実現させるための制御プログラム。
【０１４９】
［実施態様２５］ 実施態様２４に記載の制御プログラムを格納した記憶媒体。
【０１５０】
【発明の効果】
以上説明したように本発明によれば、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。
【図２】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。
【図３】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図４Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈを使用時の状態を示す図である。
【図４Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図５】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ Ｐａｔｃｈを使用時の内部構成をあらわす図である。
【図６】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、ＣＯＭサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。
【図７】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図８Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ Ｐａｔｃｈを使用時の状態を示す図である。
【図８Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図９】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、内部構成をあらわす図である。
【図１０】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１１】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図１２】一般的なソフトウェアのモジュール構成の一例を示す図である。
【図１３】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、処理ログの収集対象となるオペレーティング・システムのモジュールを定義する例を示す図である。
【図１４】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図１５Ａ】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した処理ログの一例を示す図である。
【図１５Ｂ】ＯＳ部分のＤＬＬ内の関数が呼び出された際にも、処理ログを取得することとした場合の処理ログの例を示す図である。
【図１６】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、処理ログの収集対象からオペレーティング・システムの除外モジュールを定義する例を示す図である。
【図１７】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図１８】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義の一例を示す図であり、一般的に広く用いられているＩＤＬにより、記述された図である。
【図１９】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対して付加バイナリ情報取得を指定することで、ポインタ・データの実体をログとして取得すべく、ＩＤＬにより記述したファイルを示す図である。
【図２０】図１９に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【図２１】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９に示すように関数が定義されている時のログを取得する場合の処理の流れを示すフローチャートである。
【図２２】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１９の定義により取得されたログデータを示す図である。
【図２３】本発明の一実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義ファイルを示す図であり、構造体へのポインタに対してメンバをオフセットとして指定することで、ポインタ・データの実体をログとして取得すべく、ＩＤＬにより記述したファイルを示す図である。
【図２４】図１８に示された関数定義による構造体が、どのようにメモリ上に配置されるかを表す図である。
【図２５】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１８に示すように関数が定義されている時のログを取得する場合の処理の流れを示すフローチャートである。
【図２６】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図１８の定義により取得されたログデータを示す図である。
【図２７】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する関数定義ファイルの例を示す図である。
【図２８】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、ｒｉｉｄに指定するインターフェース型を定義した、関数定義ファイルの例を示す図である。
【図２９】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図３０】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図２９における処理によって取得された処理ログの例を示す図である。
【図３１】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図３２】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【図３３】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、図３１および図３２における処理によって取得された処理ログの例を示す図である。
【図３４】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの関数定義の一例を示す図である。
【図３５】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、ライブラリ名に対してモジュール名を定義する例を示す図である。
【図３６】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、インターフェース名に対してモジュール名を定義する例を示す図である。
【図３７】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける処理の流れを示すフローチャートである。
【符号の説明】
１：ＣＰＵ
２：チップセット
３：ＲＡＭ
４：ハードディスクコントローラ
５：ディスプレイコントローラ
６：ハードディスクドライブ
７：ＣＤ−ＲＯＭドライブ
８：ディスプレイ
１１：ＣＰＵとチップセットを繋ぐ信号線
１２：チップセットとＲＡＭを繋ぐ信号線
１３：チップセットと各種周辺機器とを繋ぐ周辺機器バス
１４：ハードディスクコントローラとハードディスクドライブを繋ぐ信号線
１５：ハードディスクコントローラとＣＤ−ＲＯＭドライブを繋ぐ信号線
１６：ディスプレイコントローラとディスプレイを繋ぐ信号線
Claims (13)
- 関数を記憶したダイナミックリンクライブラリと、該関数のアドレスを記憶したインポート関数アドレステーブルと、該ダイナミックリンクライブラリ内の関数を呼び出して実行する対象プログラムとを記憶するプログラム記憶手段と、プログラムを記憶する記憶媒体と、ログが記録されるログ記録手段と、特定のモジュールのリストを記憶したリスト記憶手段と、プログラムを実行する実行手段とを有し、前記実行手段が前記記憶媒体に記憶されたプログラムを実行することにより実現される書き換え手段と、呼び出し手段とを備えた情報処理装置において、前記対象プログラムの実行中のログを取得するログ取得方法であって、
前記書き換え手段が、前記対象プログラムの実行前に、前記ダイナミックリンクライブラリ内の各関数に対応するログ取得のための関数を当該ダイナミックリンクライブラリ内にロードし、前記インポート関数アドレステーブル上に記憶された各関数のアドレスを、対応する前記ログ取得のための関数のアドレスに書き換える工程と、
前記呼び出し手段が、前記対象プログラムが呼び出そうとする呼び出し対象の関数に対する前記インポート関数アドレステーブル上の書き換え後の前記対応するログ取得のための関数のアドレスに基づいて、前記ログ取得のための関数を呼び出して前記実行手段に実行させることで実現されるログ取得手段を起動する工程と、
前記ログ取得手段が、呼び出し元のモジュールが前記特定のモジュールのリストに含まれているか否かを判断する工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記呼び出し手段による呼び出しに関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記呼び出し手段により呼び出された前記ログ取得のための関数に対応する前記呼び出し対象の関数を呼び出して、該呼び出し対象の関数を前記実行手段に実行させ、実行結果を受け取る工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記実行結果に関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記実行結果を前記対象プログラムに渡す工程と
を備えることを特徴とするログ取得方法。 - 前記呼び出しに関わるログは、少なくとも、前記呼び出し対象の関数の関数名、呼び出す際の時刻、呼び出す際のパラメータのいずれかを備えることを特徴とする請求項１に記載のログ取得方法。
- 前記実行結果に関わるログは、少なくとも、該実行結果を受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値のいずれかを備えることを特徴とする請求項１に記載のログ取得方法。
- 前記情報処理装置は更に、設定シナリオを記憶するシナリオ記憶手段を備え、前記書き換える工程では、前記インポート関数アドレステーブル上に記憶された各関数のアドレスのうち、ログ取得の対象として当該設定シナリオに設定された関数のアドレスを書き換えることを特徴とする請求項１に記載のログ取得方法。
- 前記リスト記憶手段が、オペレーティング・システムに含まれる所定の１または複数のモジュールを記憶していることを特徴とする請求項１に記載のログ取得方法。
- 前記ログが構造体である場合に、前記記録する工程において、当該構造体が置かれたメモリ領域の先頭から当該構造体のサイズ分だけ後のメモリ領域に格納されている情報を、当該構造体に指定されたサイズに応じて前記ログ記録手段に記録することを特徴とする請求項１に記載のログ取得方法。
- 前記ログが構造体である場合に、前記記録する工程において、当該構造体が置かれたメモリ領域の先頭から当該構造体に対して指定されたオフセットより後のメモリ領域に格納されている情報を、定義されたデータ型のデータとして前記ログ記録手段に記録することを特徴とする請求項１に記載のログ取得方法。
- 何れのモジュールの何れの関数の所定の情報の何れがオブジェクトの情報を表わし、何れがオブジェクトのクラスＩＤを表わすかを定義した定義情報を定義情報記憶手段に記憶しておき、前記記録する工程において、オブジェクトのクラスＩＤに基づいて、当該定義情報を参照してその関数の所定の情報に格納されたオブジェクトの情報を記録することを特徴とする請求項１に記載のログ取得方法。
- 何れのモジュールの何れの関数の所定の情報の何れがオブジェクトの情報を表わし、何れがオブジェクトのインターフェースＩＤを表わすかを定義しておき、前記記録する工程において、オブジェクトのインターフェースＩＤに基づいて、その関数の所定の情報に格納されたオブジェクトの情報を記録することを特徴とする請求項１に記載のログ取得方法。
- ライブラリまたは各インターフェースに対するモジュール名の追加定義を用意しておき、前記記録する工程において、関数を呼び出す際に、当該追加定義を参照してモジュール名を記録することを特徴とする請求項１に記載のログ取得方法。
- メソッドを記憶したインターフェースと、該メソッドのアドレスを記憶した仮想アドレステーブルと、該インターフェース内のメソッドを呼び出して実行する対象プログラムとを記憶するプログラム記憶手段と、プログラムを記憶する記憶媒体と、ログが記録されるログ記録手段と、特定のモジュールのリストを記憶したリスト記憶手段と、プログラムを実行する実行手段とを有し、前記実行手段が前記記憶媒体に記憶されたプログラムを実行することにより実現される書き換え手段と、呼び出し手段とを備えた情報処理装置において、前記対象プログラムの実行中のログを取得するログ取得方法であって、
前記書き換え手段が、前記対象プログラムの実行前に、前記インターフェース内の各メソッドに対応するログ取得のためのメソッドをインターフェース内にロードし、前記仮想アドレステーブル上に記憶された各メソッドのアドレスを、対応する前記ログ取得のためのメソッドのアドレスに書き換える工程と、
前記呼び出し手段が、前記対象プログラムが呼び出そうとする呼び出し対象のメソッドに対する前記仮想アドレステーブル上の書き換え後の前記アドレスに基づいて、前記ログ取得のためのメソッドを呼び出して前記実行手段に実行させることで実現されるログ取得手段を起動する工程と、
前記ログ取得手段が、呼び出し元のモジュールが前記特定のモジュールのリストに含まれているか否かを判断する工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記呼び出し手段による呼び出しに関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記呼び出し手段により呼び出された前記ログ取得のためのメソッドに対応する前記呼び出し対象のメソッドを呼び出して、該呼び出し対象のメソッドを前記実行手段に実行させ、実行結果を受け取る工程と、
前記ログ取得手段が、前記呼び出し元のモジュールが前記特定のモジュールのリストに含まれていなければ、前記実行結果に関わるログを前記ログ記録手段に記録する工程と、
前記ログ取得手段が、前記実行結果を前記対象プログラムに渡す工程と
を備えることを特徴とするログ取得方法。 - 前記呼び出しに関わるログは、少なくとも、前記呼び出し対象のメソッドのメソッド名、呼び出す際の時刻、呼び出す際のパラメータのいずれかを備えることを特徴とする請求項１１に記載のログ取得方法。
- 前記実行結果に関わるログは、少なくとも、該実行結果を受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値のいずれかを備えることを特徴とする請求項１１に記載のログ取得方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003099465A JP4125169B2 (ja) | 2003-04-02 | 2003-04-02 | ログ取得方法 |
| US10/815,506 US7478282B2 (en) | 2003-04-02 | 2004-03-31 | Log acquisition method and its control program and storage medium |
| CNB2004100333576A CN100334559C (zh) | 2003-04-02 | 2004-04-02 | 日志获取方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003099465A JP4125169B2 (ja) | 2003-04-02 | 2003-04-02 | ログ取得方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004310203A JP2004310203A (ja) | 2004-11-04 |
| JP2004310203A5 JP2004310203A5 (ja) | 2006-06-01 |
| JP4125169B2 true JP4125169B2 (ja) | 2008-07-30 |
Family
ID=33095206
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003099465A Expired - Fee Related JP4125169B2 (ja) | 2003-04-02 | 2003-04-02 | ログ取得方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7478282B2 (ja) |
| JP (1) | JP4125169B2 (ja) |
| CN (1) | CN100334559C (ja) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4125169B2 (ja) * | 2003-04-02 | 2008-07-30 | キヤノン株式会社 | ログ取得方法 |
| US7266726B1 (en) | 2003-11-24 | 2007-09-04 | Time Warner Cable Inc. | Methods and apparatus for event logging in an information network |
| US8302111B2 (en) | 2003-11-24 | 2012-10-30 | Time Warner Cable Inc. | Methods and apparatus for hardware registration in a network device |
| US9213538B1 (en) | 2004-02-06 | 2015-12-15 | Time Warner Cable Enterprises Llc | Methods and apparatus for display element management in an information network |
| US8078669B2 (en) | 2004-02-18 | 2011-12-13 | Time Warner Cable Inc. | Media extension apparatus and methods for use in an information network |
| JP4886188B2 (ja) * | 2004-12-16 | 2012-02-29 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム及び記憶媒体 |
| FR2882449A1 (fr) * | 2005-01-21 | 2006-08-25 | Meiosys Soc Par Actions Simpli | Procede non intrusif de rejeu d'evenements internes au sein d'un processus applicatif, et systeme mettant en oeuvre ce procede |
| FR2881246B1 (fr) * | 2005-01-21 | 2007-03-23 | Meiosys Soc Par Actions Simpli | Procede perdictif de gestion, de journalisation ou de rejeu d'operations non deterministes au sein du deroulement d'un processus applicatif |
| CN100472469C (zh) * | 2005-02-07 | 2009-03-25 | 佳能株式会社 | 运行日志获取方法 |
| JP4681923B2 (ja) * | 2005-04-01 | 2011-05-11 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム、記憶媒体 |
| US8370818B2 (en) | 2006-12-02 | 2013-02-05 | Time Warner Cable Inc. | Methods and apparatus for analyzing software interface usage |
| CN101196848B (zh) * | 2006-12-04 | 2011-10-12 | 佳能株式会社 | 运行日志获取方法 |
| WO2013091167A1 (zh) * | 2011-12-21 | 2013-06-27 | 华为技术有限公司 | 日志存储方法及系统 |
| CN104636240B (zh) * | 2014-12-31 | 2018-09-04 | 广东欧珀移动通信有限公司 | 一种信息报表的获取方法及终端 |
| US10810099B2 (en) * | 2017-09-11 | 2020-10-20 | Internatinal Business Machines Corporation | Cognitive in-memory API logging |
| US11716558B2 (en) | 2018-04-16 | 2023-08-01 | Charter Communications Operating, Llc | Apparatus and methods for integrated high-capacity data and wireless network services |
| CN108984409B (zh) * | 2018-07-13 | 2021-10-22 | 郑州云海信息技术有限公司 | 一种函数定位的方法及装置 |
| US11129213B2 (en) | 2018-10-12 | 2021-09-21 | Charter Communications Operating, Llc | Apparatus and methods for cell identification in wireless networks |
| CN109409040B (zh) * | 2018-10-31 | 2020-09-11 | 厦门市美亚柏科信息股份有限公司 | 一种操作系统时间可信度的判定方法及装置 |
| US11129171B2 (en) | 2019-02-27 | 2021-09-21 | Charter Communications Operating, Llc | Methods and apparatus for wireless signal maximization and management in a quasi-licensed wireless system |
| US11026205B2 (en) | 2019-10-23 | 2021-06-01 | Charter Communications Operating, Llc | Methods and apparatus for device registration in a quasi-licensed wireless system |
| CN113141269B (zh) * | 2020-01-20 | 2022-12-27 | 北京华为数字技术有限公司 | 数据采集方法、装置及系统 |
| CN113986517B (zh) * | 2021-12-28 | 2022-04-08 | 深圳市明源云科技有限公司 | Api调用日志采集方法、装置、电子设备及存储介质 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05173838A (ja) * | 1991-12-19 | 1993-07-13 | Nec Corp | 命令実行過程記録システム |
| JPH0667942A (ja) * | 1992-08-17 | 1994-03-11 | Mitsubishi Electric Corp | ログ採取方式 |
| JPH06314221A (ja) | 1993-05-06 | 1994-11-08 | Mitsubishi Electric Corp | コンパイル方式 |
| JPH07141222A (ja) * | 1993-11-17 | 1995-06-02 | Nec Corp | サブルーチンの履歴をトレースするデータ処理装置 |
| JPH08179964A (ja) | 1994-12-27 | 1996-07-12 | Fujitsu Ltd | プログラムチェック方法 |
| JPH08314752A (ja) | 1995-05-17 | 1996-11-29 | Ricoh Co Ltd | オブジェクト指向システムの開発支援装置 |
| US5812828A (en) * | 1995-06-01 | 1998-09-22 | Centerline Software, Inc. | Function simulation |
| US5970245A (en) * | 1997-01-03 | 1999-10-19 | Ncr Corporation | Method for debugging shared procedures contained in dynamic link library files |
| JPH1165885A (ja) * | 1997-08-12 | 1999-03-09 | Nec Corp | ソフトウェアディバッグ装置及びソフトウェアディバッグ方法 |
| JPH11296415A (ja) | 1998-04-09 | 1999-10-29 | Toshiba Tec Corp | ログ出力制御方法及び装置並びにログ出力制御プログラムを記録した記録媒体 |
| US6161216A (en) * | 1998-04-29 | 2000-12-12 | Emc Corporation | Source code debugging tool |
| US6996808B1 (en) * | 2000-02-12 | 2006-02-07 | Microsoft Corporation | Function injector |
| US7086034B2 (en) * | 2002-06-28 | 2006-08-01 | Canon Kabushiki Kaisha | Method, program, and storage medium for acquiring logs |
| US7188279B2 (en) * | 2002-06-28 | 2007-03-06 | Canon Kabushiki Kaisha | Method, program, and storage medium for acquiring logs |
| JP4125169B2 (ja) * | 2003-04-02 | 2008-07-30 | キヤノン株式会社 | ログ取得方法 |
| CN100347669C (zh) * | 2003-12-30 | 2007-11-07 | 佳能株式会社 | 运行日志取得方法 |
-
2003
- 2003-04-02 JP JP2003099465A patent/JP4125169B2/ja not_active Expired - Fee Related
-
2004
- 2004-03-31 US US10/815,506 patent/US7478282B2/en not_active Expired - Fee Related
- 2004-04-02 CN CNB2004100333576A patent/CN100334559C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004310203A (ja) | 2004-11-04 |
| US7478282B2 (en) | 2009-01-13 |
| CN1534470A (zh) | 2004-10-06 |
| CN100334559C (zh) | 2007-08-29 |
| US20040199903A1 (en) | 2004-10-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4125169B2 (ja) | ログ取得方法 | |
| US7340726B1 (en) | Systems and methods for performing static analysis on source code | |
| US9727436B2 (en) | Adding a profiling agent to a virtual machine to permit performance and memory consumption analysis within unit tests | |
| US8156476B2 (en) | Debugging support for tasks in multithreaded environments | |
| US9183114B2 (en) | Error detection on the stack | |
| US7086034B2 (en) | Method, program, and storage medium for acquiring logs | |
| CN113434131A (zh) | 编写程序方法、装置、计算机设备和存储介质 | |
| EP1376365A2 (en) | Method for acquiring logs for program debugging | |
| JP4280749B2 (ja) | ログ取得方法およびプログラム、記憶媒体 | |
| US7194479B1 (en) | Data generator system and method | |
| JP2009237610A (ja) | コード変換装置及びコード変換方法 | |
| CN117076338A (zh) | 基于kprobe的linux内核动态调试方法及系统 | |
| CN110806891A (zh) | 嵌入式设备软件版本的生成方法及装置 | |
| JP4125055B2 (ja) | ログ取得方法 | |
| US7975198B2 (en) | Test system and back annotation method | |
| US8191050B2 (en) | Information processor, control method therefor, computer program and storage medium | |
| US20050261857A1 (en) | System and method for linking and loading compiled pattern data | |
| CN1982908A (zh) | 实时生成闪存测试向量的方法 | |
| JP2004038314A (ja) | ログ取得方法およびプログラム、記憶媒体 | |
| JP2004038311A (ja) | ログ取得方法およびプログラム、記憶媒体 | |
| JP2006031248A (ja) | 関数呼び出しをフックしてログを生成するソフトウェア評価システム | |
| JP3745968B2 (ja) | 試験システム及び試験方法及び試験プログラム及び試験プログラムを記録した計算機で読み取り可能な記録媒体 | |
| CN117435171A (zh) | 一种面向risc-v架构处理器的集成开发方法 | |
| CN116069302A (zh) | 编译器硬件后端的扩展方法、装置、设备及可读存储介质 | |
| CN115016850A (zh) | 一种基于国产处理器平台的uefi固件启动模式切换方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060403 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060403 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071001 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071225 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080225 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080414 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080507 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4125169 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110516 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120516 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120516 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130516 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140516 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |