ADOでJetデータベースに接続しようとするとクラッシュする

村田敦 0

Visual C++でADOを使用してJetデータベースに接続しようとすると、Openの実行でクラッシュする事象が発生しています。
イベントログを見ますと発生個所はmsjetoledb40.dllになっています。

事象の発生は環境に依存しているようなのですが、条件については特定できていません。
報告は昨年あたりから増えていますが、Windows11でOffice365を使用している場合が考えられます。

発生個所のソースコードは以下のようになっています。

ADODB::_ConnectionPtr		pConnection;
CString conect.Format("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=%s;Jet OLEDB:Database Password=%s;",dbname,pass);
pConnection.CreateInstance(__uuidof(ADODB::Connection));
pConnection->PutMode(ADODB::adModeReadWrite);
_bstr_t conect_bstr(conect);
pConnection->Open(conect_bstr,"","",ADODB::adConnectUnspecified);

プログラムは32ビットアプリケーションとして作成しています。
データベースファイルのファイルパスとパスワードに間違いがないことは確認済みです。
Jet4.0を使用しているのが問題である可能性もあるため、
ACE16.0に変更して、事象が発生している環境で実行しましたが同様の結果となりました。

この事象の対応策があれば教えていただけないでしょうか。

人間 20 評価のポイント

2025-01-22T07:08:34.78+00:00

Visual Studio がクラッシュするということでしょうか？

イベントビューアーでの該当エラーログに表示されている、「例外コード」や「障害が発生しているアプリケーションパス」の情報を提示してもらえますか？

(「障害が発生しているモジュールパス」が "msjetoledb40.dll" ということですよね？)
村田敦 0 評価のポイント

2025-01-22T08:40:29.5633333+00:00

デバッグではなく、リリースビルドしたプログラムの実行で発生しています。

イベントビューアーのログは以下のようになっています。

障害バケット 1905708999280772496、種類 1

イベント名: APPCRASH

応答: 使用不可

Cab ID: 0

問題の署名:

P1: ****.exe

P2: 15.0.6.0

P3: 5e620243

P4: msjetoledb40.dll

P5: 4.0.9801.0

P6: 596f958c

P7: c000041d

P8: 00010ab8

P9:

P10:
人間 20 評価のポイント

2025-01-22T22:21:02.9333333+00:00

提示されたイベントログは、"Windows Error Reporting 1001" のログですよね？

私が見たかったのは、この [情報ログ] の基になった [エラーログ] の方だったのですが。。。

まぁ、"Windows Error Reporting 1001" でも確認は出来るのですが、見ずらかったので。

("Windows Error Reporting 1001" の1～3 秒前に、"Application Error 1000" のエラーログが記録されているはずです。)

提示してもらったイベントログでは P7 が c000041d となっていることから、例外コード STATUS_FATAL_USER_CALLBACK_EXCEPTION でのエラーが発生したことを示しています。

STATUS_FATAL_USER_CALLBACK_EXCEPTION は、User Callback 内での処理中にハンドルされていない例外が発生したことを意味しています。

なので、どこの User Callback 内で例外が発生したのかを特定する必要があります。

この問題現象は Release Build で発生しているとのことですが、Debug Build では発生しないのでしょうか？

Release Build Module を Visual Studio 上からデバッグ実行させた場合、例外発生時にデバッガにブレークインしないのでしょうか？

デバッガにブレークインするのであれば、そのタイミングでのコールスタックを確認すれば、どこの User Callback 内で例外が発生したのかを特定出来るので、そこから backtrace していけば大元の原因も特定出来ると思います。

ちなみに backtrace をしたいのであれば、"WinDBG Preview" デバッガの TTD (Time Travel Debugging) 機能が便利です。
村田敦 0 評価のポイント

2025-01-23T06:55:46.22+00:00

自分の手元の環境で発生しているのではないためRelease Buildでしか確認はできない状況です。

例外は補足する処理になっていますが、その前にクラッシュが発生します。

ADOを通して実行しているのでCallbackの設定もADOで行うということだと思いますが、

ADOで該当するようなメソッドやプロパティについてはありませんでした。
村田敦 0 評価のポイント

2025-01-23T08:21:03.46+00:00

間違いましたのでこちらは削除します。
人間 20 評価のポイント

2025-01-23T08:59:35.0933333+00:00

> ADOを通して実行しているのでCallbackの設定もADOで行うという

> ことだと思いますが、 ADOで該当するようなメソッドやプロパティ

> についてはありませんでした。

必ずしも ADO に関連しているとは限りません。

なので、現象発生時のスレッド状態の確認をお勧めしているのです。

(根拠の無い前提は、問題を複雑化させるだけです。)

問題現象が再現できる PC に、"WinDBG Preview" をインストールして TTD レコードファイルを採取されることをお勧めします。

TTD レコードファイルを採取すれば、他の PC で発生した問題現象を、自分の PC 環境でデバッグトレースすることが可能になります。

"WinDBG Preview" は、Microsoft Store からインストールできます。

TTD レコードの採取およびトレース手順は、下記サイトが参考になると思います。

WinDbg で時間を巻き戻すデバッグ TTD を試してみた

https://usimitu.com/tech/?p=109

【WinDbg Preview】Time Travel Debuggingで始める新しいデバッグ手法

https://kashiwaba-yuki.com/windows-windbg-008-time-travel-debugging

次の方法で共有

ADOでJetデータベースに接続しようとするとクラッシュする

お客様の回答