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 文檔。

現象

XMsg II 組件的調用不頻繁的時候，并沒有出現崩潰。

我制作了一個 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

COM+對象池組件崩潰調試手記

更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索：z360901061

微信掃一掃加我為好友

QQ號聯系： 360901061

您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。

【本文對您有幫助就好】元

2元

5元

10元

20元

自定義