經典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，這永遠是我的核心選擇，因爲學習曲線非常龐大。但是，假設你學習了這些命令，你可以在崩潰中斷開，然後向後走棧，並有可能找出錯誤來自哪裏。

當然，你可以重新安裝一切，這可能會解決你所有的問題。