COM+
對象池組件
崩潰調試手記
?
文檔版本
|
版本
|
創建時間
|
創建人
|
備注
|
|
1.0.0.1
|
2003-7-20
|
鄭
昀
|
第一稿
|
|
?
|
?
|
?
|
?
|
Implementation Scope
：
本文檔將說明
XMsg II
組件在
COM+
應用中面對高頻率的并發調用發生了崩潰，崩潰地址在
NTDLL.DLL
內。以及調試的過程。
?
繼續閱讀之前，我們假設您熟悉以下知識：
n
????????
n
????????
Exception Monitor
n
????????
n
????????
進程映像轉儲
n
????????
n
????????
W32dasm
?
如果有 Windows XP Symbols ，那么我們也許會更快找到 NTDLL.DLL 的崩潰函數。
?
背景知識
XMsg II 組件是一個 COM+ 對象池組件，線程模型是 MTA 。當它被 COM+ 激活時，它會先去讀取本地配置 XML 文件，得到相關的啟動參數。然后，用戶調用它的接口方法發送。最后，用戶調用它的 GetResponse 方法得到 Response XML 文檔。
?
現象
1:
XMsg II
組件的調用不頻繁的時候，并沒有出現崩潰。
2:
我制作了一個
testXMsg.asp
頁面，模擬服務器調用
XMsg.Dll
；
我制作了一個
Windows Console Application
(
TestXMsg.ASP.exe)
，模擬
200
個線程并發向發起
HTTP POST
請求；
而
XMsg II
組件所在的
COM+
應用
Tomo_X
，會在所有調用結束三分鐘之后，自動關閉
COM+
應用，結束這個
DLLHOST.EXE
進程。
在整個 TestXMsg.ASP.exe 運行過程中，沒有出現任何崩潰。但是在事隔三分鐘之后，崩潰出現。
跟蹤的困難所在
在反復測試
TestXMsg.ASP.exe
的時候，最大的問題重現崩潰必須有以下要素：
n
????????
n
???????
組件在
COM+
應用中；
n
????????
n
???????
組件的接口啟用了對象池；
n
????????
n
???????
并發調用。
?
這樣有以下難點：
n
????????
n
???????
很難用
VC IDE
進行跟蹤。其實，單元測試的時候，用
BounsChecker
并沒有查出問題，組件實例釋放的時候也很順利。
n
????????
n
???????
很難從
Trace Log
中看到有價值的信息。幾百個調用并發調用，而且崩潰是在
NTDLL.DLL
中。
利用
Exception Monitor
確定崩潰源頭
這種進入運行中的
COM+
應用的調試，最好的工具就是
Microsoft
Exception Monitor 7.0
了。
它可以跟蹤進入各種
Windows
服務運行實例，其中最重要的兩個服務是：
t
???????
t
??????
Microsoft Internet Information Service (In Process)
t
???????
t
??????
COM+ Application / MTS Package / IIS (Pooled/Out Of Process)
?
我們選擇監視“
COM+ Application / MTS Package / IIS (Pooled/Out Of Process)
”。你會看到以下對話框，列出了可供監視的所有
COM+
進程外應用：
?
?
選擇我們的“
Tomo_UM_X
”
COM+
應用。
在下面的“
Start Monitoring
”對話框中，點擊“
Run This Monitoring Session
”按鈕：
?
?
這樣，就會啟動 WinDBG Debugger ， Attach 到 Tomo_X 應用實例上。如下圖所示：
?
?
之后，靜靜等待 COM+ 應用在三分鐘之后的自動關閉應用了。那一刻， WinDBG 屏幕上一陣狂閃，然后消失，只留下了 Exception Monitor 的“ Session Status ”對話框，如下所示：
?
?
你可以選擇最近的那個日志，然后點擊“ View Log ”按鈕，如下所示：
?
?
P.T.C
首先，我們來查看“
P.T.C
”報告了什么：
***** Activity prior to crash *****
……….
Thread Terminate:
?
Process=0, Thread=11, Exit Code=0
Thread Terminate:
?
Process=0, Thread=6, Exit Code=0
First chance exception c0000005 (Access Violation) occurred
Thread stopped.
?
它基本上打印出了崩潰之前的
DEBUG OUTPUT
的內容。
?
Report
這個“
Report
”是
Exception Monitor
一個很強悍的功能，看看它都能告訴我些什么：
***********************************************************
* Exception Monitor Log Analyzer Report version 7.0.0.0
* Report Created from: f:\Program Files\Exception Monitor 7.1\bin\em\logs\OOP_5456-15335-719-2003.dbl
* Report Created on: July 20,2003 at 05:49 PM
* The following fault type was detected: Access Violation
* Exception Monitor 7.1.2195.5
* Log generated on: 2003-7-19 15:04:23
***********************************************************
?
The service faulted in thread # 15
?
The stack for the faulting thread follows.
?
Column 1 shows the Child EBP, Column 2 shows the Return Address, Column 3 shows the module called, and column 4 shows the resolved name if column 3 was not able to locate or use symbols.
?
To read the stack, start at the bottom and work your way up.
?
The function on the bottom called the function above it, which called the function above it, etc.
?
0000000000c6fce4
?
0000000077f58cca
?
ntdll!0x0000000077F83AED (No FPO)
0000000000c6fdb8
?
0000000077190729
?
ntdll!0x0000000077F58CCA (No FPO)
??
0000000000000001
?
0000000000000000
?
ole32!0x0000000077190729 (No FPO)
?
*****
The following is extended information from the log:
00c6fcd8 : 00080000
00c6fcdc : 000e78a8
00c6fce0 : 00000000
00c6fce4 : 00c6fdb8
00c6fce8 : 77f58cca : C:\WINDOWS\System32\ntdll.dll+0x8cca
00c6fcec : 00080000
……
!inetdbg.ds c6fd98 to dump next block
?……………..
……………….
…………………..
…………..
?
由于沒有
Windows XP Symbols
，
Exception Monitor
并不能如愿地告訴你崩潰到底發生在哪一個函數，雖然我們知道是
NTDLL.DLL
的
0x77f83aed
指令。
?
?
W32dasm
NTDLL.DLL
的“
0x77f83aed
”指令可能是什么方面的函數調用呢？
我們用
W32dasm
加載了
NTDLL.DLL
，它會進行
Disassemble
，我們可以看到輸出的函數，如下圖所示：
?
?
從指令地址來看，“
0x77f83aed
”指令似乎是
RtlFreeHeap
附近，總之都是涉及釋放堆棧。
?
COM+
進程映像轉儲
Windows XP
的
Component Service
提供了一種新功能“進程映像轉儲”。
進程轉儲工具概念
通過將
COM+
應用程序失敗時的狀態轉儲到指定目錄中，進程轉儲工具允許管理員簡化開發人員調試應用程序的任務。以下是失敗情況的例子：
-
應用程序掛起并不再響應客戶端。
-
應用程序導致了異常并被
COM+
運行時終止。
-
應用程序失敗。
在所有這些情況中，進程轉儲功能允許轉儲失敗時的整個進程狀態，啟用更為有效的應用程序失敗調試。
這個設置針對某一個
COM+
應用，如下圖所示：
?
這樣，當
Tomo_UM_X
應用自動關閉時發生的崩潰，就會被
COM+
把進程映像轉儲到指定的目錄中，存儲的文件名類似于：
{424102D6-D93F-42D8-98A4-E39ADDD8DD32}_2003_07_20_11_51_02.dmp
?
可以用
Microsoft Visual Studio .NET
打開這個文件，然后“啟動新實例”，就可以重現當時的情景，如下所示：
?
?
Disclaimers
：
本文檔所包含的信息代表了在發布之日，
zhengyun
對所討論問題的當前看法。本文檔不應理解為
zhengyun
一方的承諾，
zhengyun
不保證所給信息在發布之日以后的準確性。
本文檔僅供參考。
用戶必須遵守所有適用的版權法。在不對版權法所規定的權利加以限制的情況下，如未得到
zhengyun
和
CSDN.Net
明確的書面許可，不得出于任何目的、以任何形式或手段（電子的、機械的、影印、錄制等等）復制、傳播本文的任何部分，也不得將其存儲或引入到檢索系統中。
?
Written by zhengyun (at) tomosoft.com
?
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=12722
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
