ツールの類のプログラムを作ってみようと思っています。壊れていない状態でのチェックサム(たとえばCRC)をどっかに記録しておく。もって任意の時点でチェックサムを計算し、記録と異なればたぶん壊れてる。ツールの類のプログラムを作ってみようと思っています。やってくれてると思いますよ。バージョンによるけどそれはそれとして分解が足りないと思います。チェックのほうですが、「チェックする」で止まってしまうと、そういう部品を探してしまいます。一歩、どうなっていたらチェックできるかまで考えていたら、例えば「コピーを取っておいて、コピーと1バイトずつ比較する」とかまでは分解できたのではないでしょうか。分解が足りないと思います。チェックのほうですが、「チェックする」で止まってしまうと、そういう部品を探してしまいます。「コピーを取っておいて、コピーと1バイトずつ比較する」とかまでは分解できたのではないでしょうか。ぎゃぴ・・・チェックする部品探してしまっていた私。(汗)後学までに便乗で教えて下さい。EXEファイルのCRCをチェックするとして、http://support.microsoft.com/kb/65122によると、ファイル上のCRCが保存されている場所が記述してありマス。分解が足りないと思います。「チェック」と「表示」の二つに分けるのは最初の一歩としてはベストの手だと私は思います。どのような状態を破損と認識するのか?この分解が変なことです。「どのような状態を破損と認識するのか?」は「1システムファイルをチェックする」に入ってないと変です。ぎゃぴ・・・チェックする部品探してしまっていた私。後学までに便乗で教えて下さい。チェックサムを計算するにはCheckSumMappedFileあたりを使うことになるでしょうか??(自信ナシ)現在Windowsで使われてるのはPEフォーマットで、その仕様書はhttp://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspxここにあります。カンタービレさんのリンク先はたぶん3.1時代のもので、「NE」フォーマットです。#懐かしい:Dで、PE内部のCheckSumはWindowsSpecificHeaderにあって、アルゴリズムは非公開です。最近はAuthenticode関連で修正が入ってるので、私にはよくわかりません。Authenticodeで署名するとCheckSumは一致しなくなります。Authenticodeの部分を抜いてCheckSumを取るのだと思いますが、方法も真偽のほども知りません。MapFileAndCheckSumはイメージを読みこまないとCheckSumを確認できません。ImageHlp.dllの関数たちは遅くてやたらリソースを食います。間違ってるdllやexeがたくさんあります。