views:

24

answers:

1

I'm having trouble with an old legacy app that recently started crashing. I'm trying to investigate the DebugDiag analysis, but don't have much luck. Either there is a sql query that locks and somehow the calling thread doesn't die away? Then again callstack points to oledb32!CImpIErrorInfo::GetHelpFile+a1.

Here's the info from DebugDiag which I think is relevant to this problem:

The following threads in w3wp.exe_MyApp_PID_7572_Date__10_21_2010__Time_08_43_22AM_720_Manual Dump.dmp are making a database operation using ADO.

The call to MSADO15!CERRORLOOKUP::GETHELPINFO originated from oledb32!CImpIErrorInfo::GetHelpFile+a1

...clip...clip...

Thread 17 - System ID 4160 Entry point msvcrt!_endthreadex+2f Create time 21.10.2010 0:08:16 Time spent in user mode 0 Days 00:11:22.781 Time spent in kernel mode 0 Days 00:27:49.953

This thread is making a database operation using ADO.

The call to MSADO15!CERRORLOOKUP::GETHELPINFO originated from oledb32!CImpIErrorInfo::GetHelpFile+a1

Function Source 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!RcmConstructModuleInstance+8f
oleaut32!DispCallFunc+16a
msvbvm60!VBStrToLong+cf
msvbvm60!FileOutString+bb
msvbvm60!_vbaPrintObj+51
MSWCRUN!DllUnregisterDesigner+8ad3
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!InvokeDispatch+13a
vbscript!InvokeByName+42
vbscript!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
comsvcs!CSTAActivityWork::STAActivityWorkHelper+32
ole32!EnterForCallback+c4
ole32!SwitchForCallback+1a3
ole32!PerformCallback+54
ole32!CObjectContext::InternalContextCallback+159
ole32!CObjectContext::DoCallback+1c
comsvcs!CSTAActivityWork::DoWork+12d
comsvcs!CSTAThread::DoWork+18
comsvcs!CSTAThread::ProcessQueueWork+37
comsvcs!CSTAThread::WorkerLoop+190
msvcrt!_endthreadex+a3
kernel32!BaseThreadStart+34

...clip...clip...

Client connection from 194.241.111.228:26238 to 81.175.250.2:80
Host Header 81.175.250.2:80 GET request for /MyApp/netk.asp HTTP Version HTTP/1.1 SSL Request False Time alive 00:49:33 QueryString
Request mapped to
HTTP Request State HTR_READING_CLIENT_REQUEST Native Request State NREQ_STATE_PROCESS

A: 

Hard to say, but I'd start with throwing ProcessMonitor/RegMon/FileMon/TcpViewer from live.sysinternals.com. Fiddler wouldn't be a bad idea either.

Then, if you still get no clues, I'd break out WinDBG, which is always my nuclear option, because the learning curve is so massive. But, assuming, you learn the commands, you could break on the crash, then walk the stack backwards and potentially figure out where the error is coming from.

And of course, you could just reinstall everything and that will probably solve all your problems.

AngryHacker
Yeah, I'm aware that windbg will be the next tool to use if I can't find the answer elsewhere. I also know that since I'm not experienced with windbg, it'll be quite a lot of work to figure this on out.
Morri