1

最近クラッシュし始めた古いレガシー アプリで問題が発生しています。DebugDiag 分析を調査しようとしていますが、うまくいきません。ロックする SQL クエリがあり、呼び出し元のスレッドが消えませんか? 次に、コールスタックは再び oledb32!CImpIErrorInfo::GetHelpFile+a1 を指します。

この問題に関連すると思われるDebugDiagからの情報は次のとおりです。

w3wp.exe_ MyApp _PID_ 7572 _Date__10_21_2010__Time_08_43_22AM_ 720 _Manual Dump.dmp 内の次のスレッドは、ADO を使用してデータベース操作を行っています。

MSADO15!CERRORLOOKUP::GETHELPINFO への呼び出しは、oledb32!CImpIErrorInfo::GetHelpFile+a1 から発信されました。

...クリップ...クリップ...

スレッド 17 - システム ID 4160 エントリ ポイント msvcrt!_endthreadex+2f 作成時刻 21.10.2010 0:08:16 ユーザー モードで費やされた時間 0 日 00:11:22.781 カーネル モードで費やされた時間 0 日 00:27:49.953

このスレッドは、ADO を使用してデータベース操作を行っています。

MSADO15!CERRORLOOKUP::GETHELPINFO への呼び出しは、oledb32!CImpIErrorInfo::GetHelpFile+a1 から発信されました。

関数ソース ntdll!GetUILangID+31
ntdll!LdrpSearchResourceSection_U+186
ntdll!LdrFindResource_U+18
kernel32!FindResourceExW+65
user32!LoadStringOrError+31
user32!LoadStringW+18
msado15!FetchInfo+ba
msado15!CErrorLookup::GetHelpInfo+1e
oledb32!CImpIErrorInfo:: GetHelpFile+a1
msvbvm60!ExecProj::SetModuleCount+a
msvbvm60!CEcProjTypeComp::Release+4
msvbvm60!Rc​​mConstructModuleInstance+8f
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60!_ vbaPrintObj+51
MSWCRUNllUnregisterer!
MSWCRUN!DllUnregisterDesigner+accb
MSWCRUN!DllUnregisterDesigner+af8c
MSWCRUN!DllUnregisterDesigner+a7de
MSWCRUN!DllUnregisterDesigner+7b51
MyApp!DllCanUnloadNow+212e
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60!
_vbaPrintObj+51
MSWCRUN!DllUnregisterDesigner+8ad3
MSWCRUN!DllUnregisterDesigner+7d13
MSWCRUN!DllUnregisterDesigner+6e64
MSWCRUN!DllUnregisterDesigner+9097
MSWCRUN!DllUnregisterDesigner+8fa6
vbscript!IDispatchInvoke2+b2
vbscript!IDispatchInvoke+59
vbscript!InvokeDispatchName!InvokeDispatch+ 12a
vb4
CScriptRuntime::RunNoEH+234c
vbscript!CScriptRuntime::Run+62
vbscript!CScriptEntryPoint::Call+51
vbscript!CSession::Execute+c8
vbscript!COleScript::ExecutePendingScripts+144
vbscript!COleScript::SetScriptState+14d
asp!CActiveScriptEngine::TryCall+19
asp!CActiveScriptEngine::Call+31
asp!CallScriptFunctionOfEngine+5b
asp!ExecuteRequest+17e
asp!Execute+24c
asp!CHitObj::ViperAsyncCallback+3f0
asp!CViperAsyncRequest::OnCall+92
comsvc​​s!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback +159
ole32!CObjectContext::DoCallback+1c
comsvc​​s!CSTAActivityWork::DoWork+12d
comsvc​​s!CSTAThread::DoWork+18
comsvc​​s!CSTAThread::ProcessQueueWork+37
comsvc​​s!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34

...クリップ...クリップ...

194.241.111.228:26238から 81.175.250.2:80 へのクライアント接続
ホスト ヘッダー 81.175.250.2:80 /MyApp/netk.asp に対する GET
要求
リクエストの状態 HTR_READING_CLIENT_REQUEST ネイティブのリクエストの状態 NREQ_STATE_PROCESS

4

1 に答える 1

0

言うのは難しいですが、 live.sysinternals.com から ProcessMonitor/RegMon/FileMon/TcpViewer をスローすることから始めます。 Fiddlerも悪い考えではありません。

それでも手がかりが得られない場合は、学習曲線が非常に大きいため、常に私の核となるオプションであるWinDBGを分解します。ただし、コマンドを学習したと仮定すると、クラッシュで中断し、スタックを逆方向にたどって、エラーの原因を突き止めることができます。

そしてもちろん、すべてを再インストールするだけで、おそらくすべての問題が解決します。

于 2010-10-22T17:55:19.223 に答える