人に聞けない痔の悩み、これでスッキリ >>

以下のエラーが表示されるのですが、原因がよくわかりません

-----------------------------------------
エラー 'ASP 0115'
予期しないエラーです。
******.asp
外部オブジェクトでトラップできるエラーが発生しました。
スクリプトの実行を続行できません。
-----------------------------------------
環境:WindowsNTServer IIS ASP SQLServer7
NTServerから、[他のコンピュータにある共有]の設定で
WinXP(クライアント)の共有フォルダを参照しています。
WinXPからローカルアドレスでクライアント自身にアクセスすると表示できるのですがNTServerを経由してアクセスするとエラーで表示されない時がよくあります。
自分で調べた限りでは、ソースコードのエラーではないようです。
ソースコードを更新(クライアント)した時も、更新が反映されません。
NTServerを再起動すると正しく表示できます。
キャッシュを読み込んでいるのでしょうか。
プロキシサーバーも存在しますがこれが影響しているのかは不明です。
ACLの設定も参照先フォルダには、読み取り専用で設定しています。
サーバーを何度も再起動するわけにはいかないので何とかしたいです。
よろしくお願いします。

このQ&Aに関連する最新のQ&A

A 回答 (1件)

過去ログに同じ投稿があります。



参考URL:http://oshiete1.goo.ne.jp/kotaeru.php3?q=1145886

この回答への補足

サーバー側で、「ISAPIアプリケーションをキャッシュする」
にチェックしてあったのが原因で更新しても「キャッシュを読みに行っていたみたいです。
しかし、エラー 'ASP 0115'についてはいまだに原因がわかりません。
「IISが複数起動していたので干渉していたのでしょうか・・・?」

補足日時:2006/02/25 22:13
    • good
    • 0
この回答へのお礼

ご連絡ありがとうございます。
知ってはいたのですが解決できなかったので投稿させていただきました。
もう少し的を絞って質問させていただこうと思うのですが、ファイルを更新してもブラウザで外部から参照すると更新されていないのはなぜでしょうか?
プロキシでしょうか。ACLの設定が間違っている可能性があるのでしょうか?

お礼日時:2006/02/19 18:02

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

このQ&Aと関連する良く見られている質問

Qエラー 'ASP 0115' について

メールサーバーへ接続し、メールを送信する際、
下記、エラーが生じてしまいます。
-----------------------------------------------
Active Server Pages エラー 'ASP 0115'
予期しないエラーです
/sendNoticeMail.asp
外部オブジェクトでトラップできるエラー (C06D007E) が発生しました。スクリプトの実行を続行できません。
-----------------------------------------------
まったく同じプログラムである他のサーバーでは生じないのですし、他のメール送信以外ですとASPは正常に動きます。
レジストリ等の問題でしょうか?
いろいろと調べてみたのですがどうしても分かりません。
分かる方、教えてください。よろしくお願いします。

Aベストアンサー

URLの解決方法はもう試しましたか?

参考URL:http://support.microsoft.com/kb/210457/ja

Qアプリケーション終了時例外エラー(アクセス違反)の調査方法について

大変困っています。

アプリケーションが終了するときに「アクセス違反」がワトソン博士によって取得されています。
当方アプリケーションなどに弱く、解決策の想像が付きません。どなたかご教授お願いいたします。

<解決策例>
・どういったスキルを持った人にどの様な調査を進めさせれば良いのか。。。
・以前同様な事があり原因は○○だった
・恐らく○○だろう
 など、お願いいたします。

<ユーザ報告>
処理終了し、画面が消えたところでワトソン博士のメッセージが表示された

<ログ抜粋>
例外番号c0000005(アクセス違反)

ファンクション:RtlDestroyHeap
~略~
フォールト → 77f6d672 8908 mov [eax],ecx ds:09000001=00000000

<備考>
開発環境:MSVC6.0
動作環境:Windows NT4.0 SP6a
発生頻度:2回/年
使用頻度:2~3回/(平日)

以上、よろしくお願いします。

Aベストアンサー

発生頻度が年2回というのはなかなか厳しい条件ですね。

さて・・・

「私であれば、次の手順で調査を行います。」という書き始めで延々とデバッグ方法を書いていたのですが、書き終わってからちょっとGoogleで検索したら、ひょっとするとちょうど質問者さんのトラブルと同じかもしれない現象がMicrosoftのKBにありました。

場所はここです: http://support.microsoft.com/kb/168006/ja

要点をかいつまんで書くと、MSVCRT/MFCのDLLのバージョン不整合でエラーが発生することがある、という内容です。KB自体は特定のアプリケーションについて書かれていますが、記述されている現象と原因の関係から考えるに、他のアプリケーションでも同様の現象が発生すると思われます。

さてさて。

せっかく書いた文章を捨てるのがもったいないので(貧乏性)、邪魔かもしれませんが下に続けることにします。もし上のKBの内容がそれらしいようであれば、読み飛ばしてください。

========

私であれば、次の手順で調査を行います。

1. MAPファイル、CODファイル作成

「ワトソン博士のログを取得した際に実行していたEXEファイル」をビルドした際、一緒にMAPファイルやCODファイル(リスティングファイル)を作成していれば、そのファイルを用意しておきます。

もし作成していない場合は、「ワトソン博士のログを取得したEXEファイル」と、バイナリレベルで全く同じEXEファイル(バイト単位で比較すると、ファイルに埋め込まれたタイムスタンプ・チェックサム以外は一致する)が作成可能かどうか調べます。(ビルドに必要なソースファイルやビルドオプションに変更を加えていなければ作成可能です。)

作成可能であれば、コンパイルオプションに「リスティングファイルタイプ:マシン語コードとソースを含む」、リンクオプションに「MAPファイル作成」を追加してEXEを再作成してください。これで、「ワトソン博士のログを取得した際に実行していたEXEファイル」に対応するMAPファイルとCODファイルが得られます。

2. エラー発生行を特定

ワトソン博士のログがどれだけ取れているかにもよりますが、スタックダンプが含まれていればたいていエラー発生行を特定できます。

まず「フォールト->」が含まれる逆アセンブルリストを探します。次に、その下にある「スタックバックトレース」を探します。

スタックバックトレースを上から下に順にたどっていくと、そのうち「ReturnAd」(リターンアドレス)がアプリケーションのアドレス範囲(VC++6の標準オプション設定を変更していなければ0x00400000~)に入るところが出てきます。見つかったら、そのアドレスの直前にあるcall命令が例外を発生させたAPIを直接呼び出している場所です。

さて、仮にリターンアドレスが0x00401234だったとします。そうしたら、次はMAPファイルを見てこのアドレスがどの関数に属しているか探します。ちょうど0x00401234というアドレスは見つからないでしょうけれども、これに近いアドレスは見つかるはずです。そのアドレスに対応する関数名もMAPファイルにあります。

次はその関数名をCODファイルから探します。見つかったら、MAPファイルにあるアドレスがCODファイルにあるマシン語コードの先頭アドレスになるので、そこからリターンアドレス0x00401234に対応するはずの場所まで順番にアドレスを辿っていきます。関数の先頭アドレスが0x00401200であれば、0x34バイト先を探すわけです。

そうすると、その探した場所にある命令の直前の命令がcall命令になっているはずです。CODファイルには、その場所のC++ソースでの行番号とソース文もコメントとして入っているはずなので、あとは対応するソースをよーく見てエラーの見当をつけてください。

アセンブラの知識があれば、そこでcallを使った(他の関数を呼び出した)ときの引数の内容もある程度分かります。(ポインタ渡しだと、そのポインタの先の内容までは分かりませんが。)

3. 置き換え用EXEファイルと対応するMAPファイル作成

これ以降は将来への備えです。

コンパイルオプションでデバッグ情報を「プログラムデータベースを使用」、リスティングファイルタイプを「マシン語コードとソースを含む」、リンクオプションで「MAPファイルを作成する」、デバッグ情報「他の種類」を追加してビルドし、出来たEXEファイルを本番用として使用します。同時に作成されるMAPファイル、CODファイル、PDBファイルは保管しておきます。

MAPファイル、CODファイルの使い方は上記2.のとおりです。PDBファイルは、もし完全なクラッシュダンプが取得できればWinDbgを使って事後ソースレベルデバッグが可能になりデバッグ作業が非常に楽になるので、念のため取っておきます。

4. ワトソン博士のオプション変更

drwtsn32.exeを起動し、「クラッシュダンプファイルの作成」をチェックします。(デフォルトは、チェックが入っています。)

クラッシュダンプファイルとEXEとPDBがあればWinDbgで事後ソースレベルデバッグができます。(いわゆるポストモーテムデバッグです。UNIX系でコアダンプしたコアをデバッガで読み込んでデバッグするのと同じ種類のものです。)


普段何とも思わずに行っていることでも、文章にすると長いですね・・・

えーと、「どういうスキルを持った人に調査させればいいか」については、上記の内容を読んで『なるほど!』と言える人でしょうか。

参考URL:http://support.microsoft.com/kb/168006/ja

発生頻度が年2回というのはなかなか厳しい条件ですね。

さて・・・

「私であれば、次の手順で調査を行います。」という書き始めで延々とデバッグ方法を書いていたのですが、書き終わってからちょっとGoogleで検索したら、ひょっとするとちょうど質問者さんのトラブルと同じかもしれない現象がMicrosoftのKBにありました。

場所はここです: http://support.microsoft.com/kb/168006/ja

要点をかいつまんで書くと、MSVCRT/MFCのDLLのバージョン不整合でエラーが発生することがある、という内容です。KB...続きを読む


人気Q&Aランキング