LoadLibraryでAccess Violation 発生。

LoadLibraryでAccess Violation 発生。

開発言語はC++ 開発環境はVisual Studio 6.0 です。

exeファイルを作成し、別のマシンでそのexeファイルを動作させたところアプリが落ちてしまいました。
Dependency Walkerでプロファイルしたところ
LoadLibraryで"UNLHA32.DLL"を呼び出した所でAccess Violationのエラーが発生しています。
何か原因に心当たりはありますでしょうか？

現象の詳細は以下の通りです。

(1)同じアプリで動くマシンと動かないマシンがある。
(2)OS依存では無い。（同じOSでも動くマシンと動かないマシンがある）
(3)UNLHA32.DLLのバージョンは複数で試しており、またDLLが破損している事も無さそう。
(4)ソースコードを少し変更するとアプリが落ちていたマシンでも正常に動くようになる。
例：
○起動しない
----------------------
// UNLHA32.dllを読んでみる
m_hUnlha = LoadLibrary( "UNLHA32.dll" );
----------------------

○起動する
----------------------
strcmpi("a", "c");
// UNLHA32.dllを読んでみる
m_hUnlha = LoadLibrary( "UNLHA32.dll" );
----------------------

例の他にLoadLibraryの後のソースに同じ様な変更を加えても正常に動きました。


具体的な原因や対処法など知恵を貸して頂ければ幸いです。

No.4 ベストアンサー 回答者： kmee 回答日時： 2010/08/17 20:21

私の経験からなのですが、Access Violationが出るときは、止った箇所はトリガーにすぎず、真因は別のメモリ関係(確保忘れ、解放忘れ、多重解放など)でした。

その「起動する」の例のように、関係ないコードを入れると、最終的なバイナリが変って回避されたり、逆に発生しやすくなったりします。
デバグビルドで発生したり、逆に発生しなくなったりします。

ですので、いったんそのLoadLibraryは忘れて、他の箇所、特にメモリ関連を中心に確認するのがいいと思います。
(ポインタはNULLで初期化する、確保/解放でのエラーチェック、解放したらNULLを代入したおく、添字の範囲チェック等、面倒でも入れておくとか)

この回答への補足

回答ありがとうございます。

現在、メモリ管理の観点でソースの他の個所を見直しております。
初見のソース・アプリを
デバッグのみを担当という事で難航しておりますが…。

何か進展ありましたら、報告します。

補足日時：2010/08/18 13:04

この回答へのお礼

調査進展がありましたのでご報告です。

ご指摘の通り、LoadLibrary自体には問題無く
m_hUnlha（グローバル変数）に値を登録する所でAccess Violationが発生しておりました。
以下の様に、ソースを変更したため発覚しました。
----------
HMODULE hTest;
hTest = LoadLibrary( "UNLHA32.dll" );
m_hUnlha = hTest; ←ここでAccess Violation
----------

アセンブラに詳しい者が調査したところ
正常に動いているアプリと動かないアプリでは
m_hUnlha = hTestの時に使用しているレジスタが違っていたようです。

原因は不明で、あくまでも予想ですが
こちらもご指摘の通り、初期化やメモリの解放などの処理が雑になっており、
おそらくメモリの管理、マッピングに不備があるのでは？と考えています。

継続調査は致しますが、応急処置をし問題をクローズする事になりましたので
質問の方も解決済みとさせて頂きたいと思っています。

中途半端で申し訳ないですがよろしくお願いします。

お付き合いいただきありがとうございました。

お礼日時：2010/08/19 13:22

No.3 回答者： CanvasShoes 回答日時： 2010/08/17 12:46

読み込まれているはずだと思っているDLLと、実際に読み込まれているDLLが、異なっている（別々の場所に同じ名前のDLLが存在する）可能性はないでしょうか。

LoadLibraryでDLL名だけを指定すると、決まった順序でフォルダを探しに行きます。(MSDN御参照)
始めに検索されるのはexeと同じフォルダだったと思います。

この回答への補足

回答ありがとうございます。

DLLはexeと同フォルダに置いています。
また、MSDNのリファレンスを見て、他の参照場所にDLLは無い事を確認しました。
そのため、おそらく読み込んでいるDLLはあっているのではないかと思っています。

補足日時：2010/08/17 13:03

この回答へのお礼

調査進展がありましたのでご報告です。
kmeeさんへのお礼と同じ文面となりますがご容赦下さい。

ご指摘の通り、LoadLibrary自体には問題無く
m_hUnlha（グローバル変数）に値を登録する所でAccess Violationが発生しておりました。
以下の様に、ソースを変更したため発覚しました。
----------
HMODULE hTest;
hTest = LoadLibrary( "UNLHA32.dll" );
m_hUnlha = hTest; ←ここでAccess Violation
----------

アセンブラに詳しい者が調査したところ
正常に動いているアプリと動かないアプリでは
m_hUnlha = hTestの時に使用しているレジスタが違っていたようです。

原因は不明で、あくまでも予想ですが
こちらもご指摘の通り、初期化やメモリの解放などの処理が雑になっており、
おそらくメモリの管理、マッピングに不備があるのでは？と考えています。

継続調査は致しますが、応急処置をし問題をクローズする事になりましたので
質問の方も解決済みとさせて頂きたいと思っています。

中途半端で申し訳ないですがよろしくお願いします。

お付き合いいただきありがとうございました。

お礼日時：2010/08/19 13:25

No.2 回答者： gamera2950 回答日時： 2010/08/17 11:13

こんちは

上記現象は解決できませんが、面倒くさくても、該当の部分だけの
簡単なプログラムを作成し、複数のPCで実施してみてはどうでしょうか？
そして、
１）現象は同じ
＝＞PCの環境依存
２）動く
＝＞作成したソースコードの他の部分に問題がある

と、なりまして２）の時には
今あるソースコードから、LHAの部分は当然残して、余計な部分を削除していき
障害が発生しなく（２）の状態）なるまで試す。

ソースコードが膨大ならば、ぐぐって似た現象を探す

でしょうか、おちからになれず

この回答への補足

回答ありがとうございます。

簡単なプログラムを作ってみたところ、正常に動いているようでした。

ソースコードは少し大き目なので、
bluecampusさんの回答も参考にプログラムの別の部分も見直してみようと思います。

補足日時：2010/08/17 13:07

この回答へのお礼

調査進展がありましたのでご報告です。
kmeeさんへのお礼と同じ文面となりますがご容赦下さい。

ご指摘の通り、LoadLibrary自体には問題無く
m_hUnlha（グローバル変数）に値を登録する所でAccess Violationが発生しておりました。
以下の様に、ソースを変更したため発覚しました。
----------
HMODULE hTest;
hTest = LoadLibrary( "UNLHA32.dll" );
m_hUnlha = hTest; ←ここでAccess Violation
----------

アセンブラに詳しい者が調査したところ
正常に動いているアプリと動かないアプリでは
m_hUnlha = hTestの時に使用しているレジスタが違っていたようです。

原因は不明で、あくまでも予想ですが
こちらもご指摘の通り、初期化やメモリの解放などの処理が雑になっており、
おそらくメモリの管理、マッピングに不備があるのでは？と考えています。

継続調査は致しますが、応急処置をし問題をクローズする事になりましたので
質問の方も解決済みとさせて頂きたいと思っています。

中途半端で申し訳ないですがよろしくお願いします。

お付き合いいただきありがとうございました。

お礼日時：2010/08/19 13:25

No.1 回答者： bluecampus 回答日時： 2010/08/17 10:19

(4)からLoadLibraryのせいではなく、別の個所で、なにかメモリを壊している可能性が

あるかもしれません。

たとえば、

char m_hoge[10];
HANDLE m_handle;

というメンバ変数があったとき

strcpy(m_hoge, "12345467890");

のような処理があったりすると、m_hogeには１バイト分領域が足りないため、
次のメンバ変数のm_handleの領域まで上書きしてしまうとか。

この回答への補足

回答ありがとうございます。

ご指摘の通り、メモリの領域確保がまずそうなので、
今、別の個所の洗い直しをしているところです。

何か進展ありましたら、また報告いたします。

補足日時：2010/08/17 13:11

この回答へのお礼

調査進展がありましたのでご報告です。
kmeeさんへのお礼と同じ文面となりますがご容赦下さい。

ご指摘の通り、LoadLibrary自体には問題無く
m_hUnlha（グローバル変数）に値を登録する所でAccess Violationが発生しておりました。
以下の様に、ソースを変更したため発覚しました。
----------
HMODULE hTest;
hTest = LoadLibrary( "UNLHA32.dll" );
m_hUnlha = hTest; ←ここでAccess Violation
----------

アセンブラに詳しい者が調査したところ
正常に動いているアプリと動かないアプリでは
m_hUnlha = hTestの時に使用しているレジスタが違っていたようです。

原因は不明で、あくまでも予想ですが
こちらもご指摘の通り、初期化やメモリの解放などの処理が雑になっており、
おそらくメモリの管理、マッピングに不備があるのでは？と考えています。

継続調査は致しますが、応急処置をし問題をクローズする事になりましたので
質問の方も解決済みとさせて頂きたいと思っています。

中途半端で申し訳ないですがよろしくお願いします。

お付き合いいただきありがとうございました。

お礼日時：2010/08/19 13:26