经典asp（vb6）应用程序崩溃，CPU使用率达到100％

Question

我在最近开始崩溃的旧应用程序中遇到问题。我试图调查DebugDiag分析，但没有太多的运气。要么有一个SQL查询锁定和调用线程不会消失？然后再次调用堆栈指向oledb32！CImpIErrorInfo :: GetHelpFile + a1。

下面是DebugDiag资料的信息，我认为是有关这一问题：

在w3wp.exe_以下线程MyApp的 _PID_ _Date__10_21_2010__Time_08_43_22AM_ _Manual Dump.dmp使用正在数据库操作ADO。 ！

到MSADO15 CERRORLOOKUP :: GETHELPINFO调用源自oledb32 CImpIErrorInfo :: GetHelpFile + A1

... ...夹夹......

螺纹17 - 系统ID 4160 进入点MSVCRT _endthreadex + 2F 发布日期2010年10月21日0点08分16秒 时间在用户模式下0花费数天时间00：11：27：22.781 时间在内核模式下0天00花了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 +一个
MSVBVM60！CEcProjTypeComp ::版本+ 4
MSVBVM60！RcmConstructModuleInstance + 8F
OLEAUT32！ DispCallFunc + 16A
MSVBVM60！VBStrToLong + CF
MSVBVM60！FileOutString + BB
MSVBVM60！_ vbaPrintObj + 51
MSWCRUN！DllUnregisterDesigner + 8ad3
MSWCRUN！DllUnregisterDesigner + ACC b
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 ::运行+ 62
的VBScript！CScriptEntryPoint ::拨打+ 51
的VBScript！CSession ::执行+ C8
的VBScript！COleScript :: ExecutePendingScripts + 144
的VBScript！COleScript :: SetScriptState + 14D
ASP！CActiveScriptEngine :: TryCall + 19
ASP！CActiveScriptEngine ::拨打+ 31
ASP！CallScriptFunctionOfEngine + 5B
ASP！ExecuteRequest + 17E
ASP！执行+ 24C
ASP！CHitObj :: ViperAsyncCallback + 3f0
ASP！CViperAsyncRequest :: OnCall中+ 92个
COMSVCS！CSTAActivityWork :: STAActivityWorkH ！elper + 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

... ...夹夹......从194.241.111.228:26238到81.175.250.2:80
主机头

客户端连接81.175.250.2:80 GET请求/MyApp/netk.asp HTTP版本HTTP/1.1 SSL请求假 时间活着○时49分33秒 查询字符串
请求映射到
HTTP请求国家HTR_READING_CLIENT_REQUEST 本地请求状态NREQ_STATE_PROCESS

Answer 1

很难说，但我会从live.sysinternals.com开始投掷ProcessMonitor/RegMon/FileMon/TcpViewer。 Fiddler也不是一个坏主意。然后，如果你仍然没有线索，我会打出WinDBG，这永远是我的核心选择，因为学习曲线非常庞大。但是，假设你学习了这些命令，你可以在崩溃中断开，然后向后走栈，并有可能找出错误来自哪里。

当然，你可以重新安装一切，这可能会解决你所有的问题。