金蝶产品性能稳定性优化指导手册模板

金蝶K/3產品性能穩定性優化指導手冊(輔助工具)（V3.0）金蝶軟體(中國)研發中心K/3產品事業部.設計部解釋目标本手冊在於指導技術支援人員、分支機搆實施服務人員和客戶處理K/3系統應用過程中產生性能問題、中間層伺服器問題等；同時也指導我們實施服務人員和客戶在實施中怎样避免將來可能發生性能問題和中間層問題。讓研發人員、技術支援人員和分支機搆實施人員一起共同提升工作能力，快速反應快速解決客戶問題。適合對象 本手冊关键閱讀物件是K/3系統研發人員、技術支援人員、實施人員、客戶服務人員和企业授權有一定技術能力客戶系統管理員。回饋本手冊是對研發在處理客戶性能和穩定性問題搜集和總結，所以包含到面有可能還不夠。完善本手冊，提供一個愈加完整客戶問題解決指導方案，離不開大家支持，所以大家在碰到相關問題時，請回饋K/3設計部，我們將及時對手冊更新。導讀 本手冊包含資料庫、中間層、用戶端和輔助分析工具介紹四大篇，分別介紹K/3客戶性能和穩定性問題處理方法、案例和輔助工具，請您根據您需要選擇相應章節閱讀。注意由於此手冊可能牽涉部分K/3在技術方面細節，為了预防有些人用意不良，斷章取義來攻擊K/3和企业，請注意保密。目錄TOC\h\z\t"功效标题1,1,功效标题2,2,功效标题3,3,功效标题4,4"目錄 .5元件服務关键用來分析中間層性能表現一) 使用方法使用元件服務管理工具能够配置和管理COM元件及COM+應用程式，在K/3中間層伺服器監視元件使用情況。1）啟動元件服務管理工具在“開始”功效表，依次指向“程式”、“管理工具”，然後單擊“元件服務”。2）檢查K/3中間層元件是否在運行以下圖，選擇“Com+應用程式”能够發現哪些元件正在運行；選擇工具條上“狀態查詢”能夠愈加直觀查找哪些元件在運行中。假如用戶端用戶比較多或網路速度比較慢情況下，中間層伺服器有可能出現服務，從而引发性能問題。能够通過元件服務事件列表檢查是否有比較多事件在排隊等候。介面以下圖：二) 怎样找到正在執行資源耗用多組件有時候假如中間層CPU或記憶體耗用很嚴重，由於在多個客戶併發下有時候客戶很難發現是那一項操作引發了問題，這時候能够找一下那一個元件包中哪一個元件耗用資源比較嚴重，配合其它觀察：如在此階段用戶全部在做那些操作，有助於發現引發問題功效。首先在任務管理器進程選頁簽上尋找耗用資源較多DLLHOST進程，在這兒說明一下，每一個中間層元件包在運行時有一個DLLHOST進程，每一個包包含很多元件。找到耗用資源較多DLLHOST，找對應PID(進程標示號)，根據PID在元件管理中能够找到對應元件包，然後在對元件包下面尋找調用時間長元件，把此元件資訊和其它用戶操作資訊回饋到研發，能够定位到具體功效。三) 怎样判斷中間層阻塞對於中間層伺服器，有可能發生阻塞，這時候关键看上面所描述元件伺服器中事務列表中元件排隊情況，假如有較長排隊情況，就代表出現阻塞，能够考慮把組塞較多元件分離出來重新放到一個新建包中，因為每一個COM+元件包有一個進程。四) 關於STA模式COM+元件線程數限制問題對於VB編寫COM+元件，由於不能編譯為MTA線程模型，每個元件包進程線程數默認為10個，也就是說同一個元件包中全部元件功效只能最多有十個同時運行。對此問題，微軟提供了一個修改線程數量限制方法，那就是修改註冊表選項，能够讓線程數達到100。此項改進在V10.0已經在安裝包做了修改，假如是以前版本客戶能够直接修改中間層伺服器註冊表選項。能够直接把以下註冊表檔導入。修改默認設置後，會提升中間層併發性能。1.6SQLDiag.exeSQLDiag.exe工具程式默認檔路徑位於<系統磁碟機>:\ProgramFiles\MicrosoftSQLServer\MSSQL\Binn目錄之下，產生出來日誌檔默認放在<系統磁碟機>:\ProgramFiles\MicrosoftSQLServer\MSSQL\LOG目錄之下，檔案名為SQLDiag.txt。它能够在同一時間、一次幫你搜集相當多資訊。在相同時間區段內，搜集各種方面資訊很关键。比如你觀察到SQLServer對某個查詢回應遲緩，可能需要同時觀察系統硬體各項資源使用，SQLServer當時鎖狀況，是否有錯誤發生等等，必須要相互參照，才轻易找出禍首。SQLDiag.exe就能够在同一時間搜集到相當多資訊，它必須在SQLServer伺服器本身執行，而不能在用戶端工作站執行。輸出相關資料列述以下：獲取記錄檔，若是SQLServer版本，這些記錄檔默認是位於“<系統磁碟機>\ProgramFiles\MicrosoftSQLServer\MSSQL\LOG”目錄下，名稱為ERRORLOG及副檔名是數字先前版本，如Errorlog.1、Errorlog.2一直到Errorlog.6等等，若版本是SQLServer7.0，則這些記錄檔路徑默認是<系統磁碟機>\MSSQL7\log\。這些日誌檔是文本類型，雖然名稱是ErrorLog，但放不儘然是錯誤，SQLServer會將部分資訊，如啟動時所完成動作，放在這個檔中。當然，若有錯誤，也會存放在這個檔中，SQLDiag默認會將這些ErrorLog檔一併放到輸出結果檔內。獲取相關註冊(registry)資訊。獲取相關程式庫(dlllibrary)版本資訊。通過sp_configure系統存儲過程獲取SQLServer執行實例各項配置。通過sp_who系統存儲過程獲取當前登錄SQLServer執行實例用戶各項細節。通過sp_lock系統存儲過程獲取鎖相關資訊。通過sp_helpdb系統存儲過程獲取SQLServer執行實例內各資料庫相關資訊。通過xp_msver擴展存儲過程獲取軟硬體平臺簡要資訊。通過sp_helpextendedproc系統存儲過程獲取擴展存儲過程(extendedstoredprocedures)相關資訊。由於擴展存儲過程是以DLL形式與SQLServer关键執行在同一個程式中，若有任何閃失，輕則造成記憶體洩露，重則導致服務程式當掉。通過這個系統存儲過程會表列出全部擴展存儲過程，你能够將它輸出與通常安裝SQLServer做個比較，看看是否有用戶自行安裝擴展存儲過程，造成系統不穩定。從master.dbo.Sysprocesses系統資料表獲取程式(process)相關資訊。當系統忙碌時，你能够通過它觀察到底有哪些程式在伺服器內執行，各用了多少資源等等。搭配其它系統存儲過程，如sp_who、sp_who2、sp_lock等等，能够獲得整體狀況。比如通過waittime欄位知道有哪些程式已經等候很久，從cpu、physical_io和memusage欄位能够看出哪些程式在耗CPU、磁片輸出入或記憶體資源。和打開了事務，但執行狀況卻是sleeping不當事務管理。通過DBCCINPUTBUFFER(spid)獲取各進程正在執行命令。獲取鎖鏈接起始者(headblocker)。通過MSInfo32.exe獲取系統細節資料，這需要耗掉部分時間。最後100個查詢和異常狀況(Exception)。SQLDiag.exe獲取系統資訊是靠MSInfo32.exe工具程式取得系統相關資訊，你能够直接執行該工具程式以查看更豐富資訊，以下圖：點擊MSInfo32.exe主功效表[檔]-[導出]選項，能够將系統當前各項資訊導出成文字檔案，供你日後參考。由於導出屬性包含軟硬體各項細節資訊，所以按下[導出]後可能要稍等一下。SQLDiag.exe是一個相當轻易執行工具程式，若要參照它使用方法，能够進入“命令提醒符”程式，轉到SQLDiag.exe所在目錄下執行SQLDiag/?(SQLDiag.exe默認目錄是<系統磁碟機>:\ProgramFiles\MicrosoftSQLServer\MSSQL\Binn)，以顯示各項參數，或是在SQLServer所附“聯機文檔”利用SQLDiag關鍵字找尋使用細節，URL是：mk:@MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\coprompt.chm::/cp_sqldiag_96k9.htm以下簡述它各項參數使用方法：-?：顯示使用說明。-I<SQLServer執行實例名稱>：指定要連接本機SQLServer執行實例(Instance)。若不指定–I選項，則連接至本機默認執行實例。-U<帳號>：指定登錄SQLServer帳號。-P<密碼>：上述帳號對應密碼。若指定-P選項但不賦予值，則SQLDiag認定密碼為空。密碼有區分大小寫。-E：使用信任連接，也就是以當前登錄作業系統帳號來連接SQLServer。-O<導出檔案名稱>：將SQLDiag導出重新導向到指定檔。若未指定-O選項，則默認輸出檔名稱為SQLDiag.txt。此時，跟蹤檔案名稱仍維持原先blackbox.trc和blackbox_01.trc。若指定-O選項，則SQLDiag根據你配置名稱，重新命名跟蹤文件blackbox.trc和blackbox_01.trc(比如，若output_file指定為MyDiagnostics.txt，跟蹤檔將分別重新命名為MyDiagnostics.trc和MyDiagnostics_01.trc)。-X：排除錯誤日誌檔。-M：執行DBCC堆疊列印(stackdump)。-C：抽取聚集信息。執行範例以下：SQLDiag-E-Odiag.log通過–E參數，會以登錄作業系統帳號登錄SQLServer，而–Odiag.log參數則會產生名稱為diag.log輸出。1.7性能監視器(PerformanceMonitor)WindowsNT之後所附性能監視器是顯示各種性能資料很詳盡工具。你能够用它來觀測伺服器當前運行，記錄整個系統多台機器上各種性能計數器，以找出整個系統瓶頸。我們在性能調校過程中會一再地用它。WindowsNT之後，就直接提供性能監視器(PerformanceMonitor)，通常是用來查看、跟蹤在整個系統中，是否有哪個部分顯示資源不足狀態，或是系統使用狀況、演變趨勢等等。而性能計數器代表是一種指標，它本身不是問題，一些背後隱含問題導致該指標變化。所以不要看到單一性能計數器值就下定論，一定要建立推論：是什麼原因導致該性能計數器有當前值，若該原因是真，那同時哪些性能計數器應該顯示什麼現象？而你當然應該再進一步分析與推論相關計數器。性能監視器讓你獲得證據以完成：支持自己假設，或是推翻結論另尋原因。獲取電腦全盤狀態，讓你能够發現電腦發生了什麼狀況(WHAT)，而不是為何(WHY)或怎样(HOW)發生這種狀況。抽取電腦變化狀態，有基線以供比較是很关键，它讓你能够知道什麼是正常，而什麼不是。假如無法獲取基線，則尋找記錄中變化，查看計數器相對值而非絕對值，並與先前使用經驗做一個比較。除了通常硬體，如記憶體、硬碟、中央處理器乃至於網路等系統提供性能計數器外，大部分微軟提供伺服器軟體在安裝完畢後，也會註冊它本身性能計數器，而SQLServer會增加相當多類性能計數器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。在要抽取性能記錄之前，儘量將不相關、當前不需要服務先停掉，如IIS，系統掃毒等等。假如需要調校電腦可能會當機，則要採用遠端記錄，避免資料未記錄到就掛了。相反地，若網路有問題，當然需要在本機完成記錄。而一旦採用遠端監控，要先同时兩台機器時間才好比對結果。你能够在命令提醒視窗中，通過以下命令同时系統之間時間：NETTIME\\RemoteMachine/SET就SQLServer使用特征來說，依其关键程度，觀察硬體資源不足順序依序是：記憶體、硬碟、中央處理器乃至於網路。SQLServer是很耗用記憶體軟體，因為它凡用過資料必先留在記憶體中，除非資源不足，否則不輕易從緩衝區清掉，讓資料庫運行儘量少使用硬碟。當記憶體不足時，會連帶地影響硬碟和中央處理器。比如有新資料要放到屬性已滿緩衝區，則SQLServer內部負責將緩衝區屬性更新到硬碟LazyWriter程式就需要持續地執行，好更新緩衝區資料，並釋放較沒有使用到記憶體區塊，這會同時讓CPU與硬碟忙碌起來。也就是說，當CPU和硬碟性能不足時，有可能源頭是記憶體不足造成。磁片子系統性能不佳，也一定會讓SQLServer性能好不起來，畢竟它需要大量讀寫存在硬碟上資料庫內資料。若你沒錢購置RAID，最好也多買幾顆硬碟，讓Log檔、資料庫檔和Windows作業系統用做虛擬記憶體交換檔分在不一样硬碟上，因為這三種檔設計目标不一样，存取習性與頻率也不一样，當三者在同一顆硬碟上時，有可能因為多個人存取資料庫，有做更新，有查詢，這些運行讓作業系統要配置虛擬記憶體，所以硬碟要同時存取三種檔，這會導致磁頭忙碌地移動，讓硬碟存取大多是隨機讀取，無法做循序讀取，導致硬碟性能降低。所以建議將三種檔分別放在不一样硬碟上。硬碟性能遲緩，肯定導致資料庫查詢與資料異動延遲(這兩種動作分別是存取資料庫檔與Log檔)，這又造成事務要花較長時間才能結束，進而讓鎖資源無法釋放，多人存取系統相互等候資源，進入大家全部被延遲慘況。CPU性能关键性不用強調了吧，它慢，週邊設備再快全部沒有用。但要注意是，我們當前電腦設計往往是中央處理器極快，但週邊運行緩慢，導致CPU無法有效發揮它能力。所以當考慮加強中央處理器時，要看看是否是周邊設備不足，導致CPU忙碌。通常來說，啟動性能監視器後，只要記錄資訊而不需要做圖。以較穩定方法抽取電腦完整狀態，由於在事前你很難預料判斷瓶頸時，會需要哪些資料，所以儘量記錄全部計數器5。如圖3.5所表示，除了通過默認視窗觀察系統當前情況外，最好還要通過添加記錄方法，對系統作較長時間監控。執行性能監視器時間要長到足以抓取到問題，通常粗略配置綱要以下：記錄2小時–每4秒記錄一次。記錄1天–每30秒記錄一次。記錄1天–每180秒記錄一次。活動中圖形只能顯示瞬間系統狀況，長時間記錄資料才能看出趨勢時間間隔不要小於4秒，以免記錄這個動作本身就傷害電腦性能，除非是要抽取磁片I/O性能，最高頻率也勿超過每2秒記錄一次。另外，為減輕對電腦長期影響，若沒有特殊需求，只要記錄2小時就好。假如需要話，執行'diskperf–y'以抽取磁片性能資訊。首次記錄時，在不傷及性能前提下，僅可能地抽取全部物件，供你對整個系統有一個全方面性概觀。縮略表列通常要記錄物件以下(假如不可能取得全部物件)：Cache,memory,objects,pagingfile,physicaldisk,logicaldisk,process,thread,processor,server,system。全部SQLServer物件。假如有網路相關問題，全部與網路相關物件(ProtocolStackObjects)。一次記錄通常無法包含全部需要資訊，可能要数次後續不一样記錄資料。另外，在記錄上还有其它考量，如每個記錄存成一個檔，在記錄停止後，下次打開一個新檔。檢查記錄檔所花硬碟空間。若某個日誌檔屬性太大，而你只需要其中关键部分，重新建立記錄(Re-logging)可能會很有用。日誌檔最大極限1gigabyte(GB)，而單一日誌檔太大也很難處理，可行日誌檔大小應該在100megabytes(MB)左右，建議取50MB。若你需要長時間記錄，而系統是在WindowsNT上，考慮以script自動停掉並重起記錄，以減低記錄檔大小。若在Windows則能够利用Sysmon計畫任務，定時停掉並重起記錄，以分成多個日誌檔。使用WindowsXP或Windows，能够通過Relog.exe工具程式對事件重新建立記錄，它能够將日誌檔轉換成不一样格式，並在新建立日誌檔中包含較少計數器數目。使用relog.exe步驟以下：1.查看日誌檔資料：打開先前抽取.blg文件。2.選擇你要繪圖計數器。3.圖表上以滑鼠右鍵選擇“另存新檔”，格式為HTML。4.將新建html檔以附屬應用程式“記事本”打開。5.保留你有興趣計數器，將其餘計數器刪掉，同時把全部格式通通刪掉，只保留以下格式屬性：[\\Computer]\Object[Parent/Instance#Index]\Counter若需要多個計數器，則每個名稱間以換行符號分開，範例以下：\\BYRONNB\Memory\Pages/sec\\BYRONNB\PhysicalDisk(_Total)\Avg.DiskQueueLength\\BYRONNB\Processor(_Total)\%ProcessorTime其中\\Computer名稱能够省略。6.以通常文字檔案格式ANSI編碼存檔，或許換個檔案名比較合適，比如以.txt為副檔名。要小心是默認“WindowsSystemMonitor”將HTML格式配置檔是以Unicode存檔，“記事本”會依据原編碼格式也就是Unicode存檔，而Relog.exe看不懂這種檔格式。命令執行範例以下：relogSQLPerformance.blg-cfGeneral.txt-fCSV-oGeneral.csv在範例中，原始日誌性能檔案名稱是SQLPerformance.blg，而該檔以二進位格式存放性能日誌資料，而我們只取部分計數器，定義在General.txt文件中。過濾結果將以逗號分隔通常文字存檔，也就是默認給Excel看.csv檔，所以結果輸出到General.csv檔中，你能够直接通過Excel打開查看分析。上述步驟相關細節能够參閱微軟支援網站，查詢檔“Q195654MethodsforCondensingaPerformanceMonitorLogFile”，或是執行範例光碟第3章“重新過濾Log”目錄下myRelog.cmd批次檔案來測試錄製完一段時間系統執行狀況後，接著要做是顯示和替日誌檔繪圖，WindowsNT所附Perfmon受限在只能畫到100%，而Windows之後Sysmon則能够超過這個範圍。若系統間有不一样時區差異，Sysmon會做調整，Perfmon則不會。若要與其它資料做比較而時區不一样，如SQLProfiler跟蹤檔，可能會造成混淆。在查看資料時，應先繪製全部記錄圖表，以瞭解整體趨勢。對於同一個日誌檔能够繪製多個圖表，以避免單一圖表顯示過多資訊。為不一样記錄instance配置不一样值域範圍(range)，若要突顯圖表中某個instance線條，能够在下方區塊選到該線條後按快捷鍵Ctrl+H。查看圖形時，利用時間範圍slider來取得特定趨勢時段細節，並利用鍵盤上左右箭頭一次移動一個點，若偶有一兩個點遠高出邊界，可能是除零運算結果，能够忽略不計。最後要注意是不要利用WindowsNTPerfmon讀取WindowsSysmon產生日誌檔當要分析記錄所得資料時，尋找一些模式，和不正常之高或低計數值，這有助於瞭解什麼是“正常”值，對建立基線是有幫助，假如一個計數器顯示某個問題，可尋找其它證據以支持你理論，比如：%ProcessTime值持續很高，瓶頸不一定是在CPU。也可能因實體記憶體不足，為了處理pagefaults造成很高%PrivilegeTime。SQLServerTotalServerMemory持續飆高不一定是memoryleak。BufferPool會在SQLServer还未用到記憶體限制或極限時，持續增加。不要忘了查看SQLProfiler跟蹤檔、errorlog，或其它相關資訊，有助於解釋你在性能記錄所看到現象。當特定計數值走高時：SQLProfiler是否同時抽取到值得注意現象？是否有大量recompile和compile事件？是否有特別查詢或批次處理工作在執行？是否在errorlog中看到任何錯誤或資訊？性能監視器就介紹到此，我們接著要討論是針對個別問題需要進一步研究時，能够採用工具程式。1.8VBCheckW2k用於檢查使用VB編寫DLL編譯是否正確，能够檢查整個系統中COM+元件物件、IISWeb應用程式和單個DLL檔使用方法：vbchkw2k[/sc]or[dllname]參數說明：1：/sc掃描IIS（進程中），OOPPooled、和安裝在COM+元件和COM+目錄下獨立應用程式；（由於K/3系統相應DLL比較多，能够把內容輸出成一個日誌檔，然後在進行分析，方法在後面加上”>log.txt“）2：dllname掃描指定DLL3：無掃描IIS（進程中），OOPPooled、和安裝在COM+元件下獨立應用程式；示例命令：vbchkw2k/sc>log.txt結果：Scanningdllhost.exe(PID:828)kdsvrmgrC:\WINNT\system32\KDCOM\Kdsvrmgr.dllisfine...RetainedInMemory:ONUnattendedExecution:ONRetainedInMemory:OFFUnattendedExecution:OFFC:\WINNT\system32\KDCOM\MTSCACHESERVICE.DLL<<<PleaseRecompile!RetainedInMemory:OFFUnattendedExecution:OFFC:\WINNT\system32\KDVBF.dll<<<PleaseRecompile!RetainedInMemory:OFFUnattendedExecution:OFFC:\ProgramFiles\Kingdee\K/3ERP\KDLOG4VB.DLL<<<PleaseRecompile!從上面結果能够看出：在COM+元件服務中Kdsvrmgr.dll是沒有問題，而且保持在記憶體中；但MTSCACHESERVICE.DLL，KDVBF.dll，KDLOG4VB.DLL需要重新編譯。1.9ADPlus通過自動運行CDB調試器來產生一個或多個進程記憶體DUMP和LOG檔，CDB（MicrosoftConsoleDebugger）是基於字元控制臺程式，能够分析更底層Windows用戶模式記憶體構造情況。ADPlus能够創建不一样場景下詳細dump檔。這個檔包含了出現問題時所需要調試資訊。使用之前需要設置符號表資訊路徑：1：假如当地沒有符號表，但能够訪問網路能够在環境變數中增加下面內容set_NT_SYSMBOL_PATH=srv*DownstreamStore*；（DownstreamStore為当地符號表目錄）。2：也能够到微軟網站下載符號表，安裝到当地，然後在環境表量中增加下面內容set_NT_SYSMBOL_PATH=c:\symbol（假設根据在c:\symbol目錄下）[下載路徑：]。何時使用，何時不使用在系統出現下面情況時，能够考慮使用ADPlus：進程掛起在單個處理器電腦上100%CPU，在雙CPU上50%CPU，在4個CPU上25% CPU等候進程出現異常或非正常關閉但在下面情況不要使用ADPlus 假如需要對程式進行故障檢查或進程啟動時異常結束如在crash模式下使用對執行性能有明顯影響應用場景ADPlus應用場景关键包含以下方面： 進程掛起或消耗100%CPU 進程異常結束 MTS或COM+服務應用異常結束 在遠端Crash模式下運行 在Crash模式下監視ADPlus使用方法ADPlus.vbs–hang–pndllhost.exe獲取掛起進程dump檔；ADPlus.vbs–hang–p1860獲取掛起進程ID為1860dump文件；進程ID能够通過任務管理器來獲取；ADPlus.vbs-crash–p1860獲取掛起進程ID為1860crash文件；進程ID能够通過任務管理器來獲取；示例：在CMD模式下，執行ADPlus.vbs–hang–p1960，出現下面提醒下面資訊：選擇確定後，系統將提醒下面資訊： 選擇確定選擇確定系統提醒生成檔在：D:\ProgramFiles\DebuggingToolsforWindows\Hang_Mode__Date_07-20-__Time_16-08-1515目錄下，檔案名為PID-1960__DLLHOST.EXE_System_Application__full_0568_-07-20_16-08-31-794_07A8.dmp，該檔即是需要DUMP檔。必須確定有符號表，假如未設置符號表，那麼在生成檔目錄下，日誌檔中會看到下面錯誤資訊，將影響分析。***ERROR:Symbolfilecouldnotbefound.DefaultedtoexportsymbolsforC:\WINNT\system32\KERNEL32.DLL-ChildEBPRetAddrArgstoChildWARNING:Stackunwindinformationnotavailable.Followingframesmaybewrong.0006fd5077e63b500000004cffffffff00000000ntdll!NtWaitForSingleObject+0xb***ERROR:Symbolfilecouldnotbefound.DefaultedtoexportsymbolsforC:\WINNT\system32\ole32.dll-0006fd6077a8a7010000004c0000000000000000000000000000000000000000ole32!CoRegisterSurrogateEx+0x95b1.10COM+SPYCOMspy用於獲取COM+元件調用時相應進程事件或應用程式調用所花費時間，來查找產生性能問題瓶頸。使用方法以下：1：運行ComSpy.exe程式，在運行時候首先保證“ComSpyCtl.dll”和“ComSpyAudit.dll”已經註冊；2：選擇功效表“spy”下“selectevents…”，將彈出下面介面，選擇後點擊“close”按鈕，此時系統將自動對選擇內容進行跟蹤：3：跟蹤結果以下圖：4：同時該工具也支持將跟蹤結果導出到檔中。同時也能够打開導出檔進行分析。1.11ProcessExplorer進程流覽器用於查看當前運行全部進程，進程中調用DLL，線程和控制碼和記憶體分配情況。同時能够設置進程優先順序別或殺掉進程。在刪除檔時候，假如報檔已經被系統引用，這時候也能够根據該工具來查找對應被那個進程調用，查看其相應控制碼，通過關閉控制碼操作來結束對該檔調用。下面對基础使用方法進行介紹：1：啟動後介面以下：2：查看CPU使用情況：3：查看進程相應資訊：上面為SQLSERVER屬性資訊包含了線程，性能，TCP/IP連接，安全，環境變數設置，服務等資訊。1.12DebugDiag用於分析記憶體分配和使用情況，在使用時候儘量把不需要使用進程關閉。它原理在於抓取進程影像檔，對影像檔進行分析，最後統計出進程分配情況。下面對使用進行一個簡單說明：1：設置符號表路徑2：選擇需要抓取進程記憶體鏡像3：抓取完成後就能够使用工具進行分析了，下圖選擇了兩個DUMP檔進行分析：然後選擇“StartAnalysis”進行分析；4：分析過程：5：分析結果：分析結構將生成一個以下分析檔，該檔中包含分析摘要和明細資訊，資訊中會提醒檔導致花費了多少記憶體，和產生記憶體洩露百分比等等。具體資訊同附件類似。不過現在微軟所出版本分析內容有限，可能不一定能滿足實際需求。1.13WinDBGWinDBG是基於對DUMP和Crash檔進行分析工具，用於查看靜態記憶體使用情況，在出現了COM+掛起，CPU100%，異常退出和性能問題時候，全部能够通過該工具進行分析，查看問題所在。本部分关键是對常见使用命令進行一個說明（首先還是需要設置好符號表，符號表設置參見ADPlus使用）：~*：查看全部進程；~*kb：查看全部進程代碼段；~10s：進入10號進程；kb：在進入具體某個進程後，查看對應全部代碼段內容；kP：在進入具體某個進程後，查看對應全部代碼段內容，包含內部參數情況；dc,du,dtaddr：查看addr記憶體位址值；lm：查看進程調用資源情況；!lmiModualName:顯示Module詳細資訊；vertarget：顯示目標電腦版本；!loadsieext.dll:調用DLL文件；!sieext.critlist：查看鎖死進程；!calls：查看進程內部調用相關進程；1.14搜集電腦資訊工具 自動搜集伺服器事件日誌，系統配置環境，作業系統版本等資訊。對與中間層伺服器使用MPSRPT_Alliance_X86.EXE，對於資料庫伺服器使用MPSRPT_SQL.exe 工具位置： MPSRPT_Alliance_X86.EXE：； MPSRPT_SQL.exe：假如現場問題需要總部支援話，請使用上面工具搜集電腦資訊。MPSRPT_SQL.exe運行後：將會生成CAB檔，CAB會被生成在%systemroot%\MPSReports\SQLServer\<ReportType>\Cab目錄。通常名字為%COMPUTERNAME%_SQL_MPSReports_XXXXXXXXXX_X.CAB。(%systemroot%為Windows系統目錄，比如C:\WindowsorC:\Winnt)1.15檢查網路工具1.15.1PingPing是個使用頻率極高實用程式，用於確定当地主機是否能與另一台主機交換（發送與接收）資料報。根據返回資訊，你就能够推斷TCP/IP參數是否設置得正確和運行是否正常。簡單說，Ping就是一個測試程式，假如Ping運行正確，你大體上就能够排除網路訪問層、網卡、MODEM輸入輸出線路、電纜和路由器等存在故障，從而減小了問題範圍。但由於能够自定義所發資料報大小及無休止高速發送，Ping也被一些別有用心人作為DDOS（拒絕服務攻擊）工具，Yahoo就曾經被駭客利用數百台能够高速接入互聯網電腦連續發送大量Ping資料報而癱瘓。根据缺省設置，Windows上運行Ping命令發送4個ICMP（網間控制報文協定）回送請求，每個32位元組資料，假如一切正常，你應能得到4個回送應答。Ping能夠以毫秒為單位顯示發送回送請求到返回回送應答之間時間量。假如應答時間短，表示資料報无须通過太多路由器或網路連接速度比較快。Ping還能顯示TTL（TimeToLive存在時間）值，你能够通過TTL值推算一下資料包已經通過了多少個路由器：源地點TTL起始值（就是比返回TTL略大一個2乘方數）減去返回時TTL值。比如，返回TTL值為119，那麼能够推算資料報離開源位址TTL起始值為128，而源地點到目標地點要通過9個路由器網段（128-119）；假如返回TTL值為246，TTL起始值就是256，源地點到目標地點要通過9個路由器網段。通過Ping檢測網路故障经典次序正常情況下，當你使用Ping命令來查找問題所在或檢驗網路運行情況時，你需要使用許多Ping命令，假如全部全部運行正確，你就能够相信基础連通性和配置參數沒有問題；假如一些Ping命令出現運行故障，它也能够指明到何處去查找問題。下面就給出一個经典檢測次序及對應可能故障：ping--這個Ping命令被送到当地電腦IP軟體，你電腦始終全部應該對該Ping命令作出應答，假如沒有，就表示TCP/IP安裝或運行存在一些最基础問題。ping本機IP--這個命令被送到你電腦所配置IP位址，你電腦始終全部應該對該Ping命令作出應答，假如沒有，則表示当地配置或安裝存在問題。出現此問題時，局域網用戶請斷開網路電纜，然後重新發送該命令。假如網線斷開後本命令正確，則表示另一台電腦可能配置了相同IP位址。ping局域網內其它IP--這個命令應該離開你電腦，經過網卡及網路電纜到達其它電腦，再返回。收到回送應答表明当地網路中網卡和載體運行正確。但假如收到0個回送應答，那麼表示子網路遮罩（進行子網分割時，將IP位址網路部分與主機部分分開代碼）不正確或網卡配置錯誤或電纜系統有問題。ping閘道IP--這個命令假如應答正確，表示局域網中閘道路由器正在運行並能夠作出應答。ping遠端IP--假如收到4個應答，表示成功使用了缺省閘道。（但假如對方設置了防火牆,則可能會收不到應答）。pinglocalhost--localhost是個系統網路保留名，它是別名，每台電腦全部應該能夠將該名字轉換成該位址。假如沒有做到這一點，則表示主機檔（/Windows/host）中存在問題。ping.--對這個功效變數名稱執行Ping位址，你也能够利用該命令實現功效變數名稱對IP位址轉換功效。假如得不到IP位址，則表示DNS伺服器IP位址配置不正確或DNS伺服器有故障。假如上面所列出全部Ping命令全部能正常運行，那麼你對你電腦進行当地和遠端通信功效基础上就能够放心了。不过，這些命令成功並不表示你全部網路配置全部沒有問題，比如，一些子網路遮罩錯誤就可能無法用這些方法檢測到。Ping命令常见參數選項pingIP-t--連續對IP位址執行Ping命令，直到被用戶以Ctrl+C中斷。pingIP-l--指定Ping命令中資料長度為位元組，而不是缺省32位元組。pingIP-n--執行特定次數Ping命令。1.15.2NetstatNetstat用於顯示與IP、TCP、UDP和ICMP協定相關統計資料，通常见於檢驗本機各埠網路連接情況。假如你電腦有時候接收到資料報會導致出錯資料刪除或故障，你无须感到奇怪，TCP/IP能够容許這些類型錯誤，並能夠自動重發資料報。但假如累計出錯情況數目占到所接收IP資料報相當大百分比，或它數目正快速增加，那麼你就應該使用Netstat查一查為什麼會出現這些情況了。netstat部分常见選項：netstat-s--本選項能夠根据各個協定分別顯示其統計資料。假如你應用程式（如Web流覽器）運行速度比較慢，或不能顯示Web頁之類資料，那麼你就能够用本選項來查看一下所顯示資訊。你需要仔細查看統計資料各行，找到出錯關鍵字，進而確定問題所在。netstat-e--本選項用於顯示關於乙太網統計資料。它列出專案包含傳送資料報總位元組數、錯誤數、刪除數、資料報數量和廣播數量。這些統計資料现有發送資料報數量，也有接收資料報數量。這個選項能够用來統計部分基础網路流量）。netstat-r--本選項能够顯示關於路由表資訊，類似於後面所講使用routeprint命令時看到資訊。除了顯示有效路由外，還顯示當前有效連接。netstat-a--本選項顯示一個全部有效連接資訊列表，包含已建立連接（ESTABLISHED），也包含監聽連接請求（LISTENING）那些連接。netstat-n—顯示全部已建立有效連接,並用數位形式來顯示位址.1.15.3ARP（位址轉換協定）ARP是一個关键TCP/IP協議，並且用於確定對應IP位址網卡物理位址。實用arp命令，你能夠查看当地電腦ARP快取記憶體中當前內容。另外，使用arp命令，也能够用人工方法輸入靜態網卡物理/IP位址對，你可能會使用這種方法為缺省閘道和本端伺服器等常见主機進行這項工作，有助於減少網路上信息量。根据缺省設置，ARP快取記憶體中專案是動態，每當發送一個指定地點資料報且快取記憶體中不存在當前專案時，ARP便會自動添加該項目。一旦快取記憶體專案被輸入，它們就已經開始走向失效狀態。比如，在WindowsNT網路中，假如輸入專案後不進一步使用，物理/IP位址對就會在2至10分鐘內失效。所以，假如ARP快取記憶體中項目极少或根本沒有時，請不要奇怪，通過另一台電腦或路由器ping命令即可添加。所以，需要通過arp命令查看快取記憶體中內容時，請最好先ping此台電腦。常见命令選項：arp-a或arp-g--用於查看快取記憶體中全部項目。-a和-g參數結果是一樣，多年來-g一直是UNIX平臺上用來顯示ARP快取記憶體中全部專案選項，而Windows用是arp-a（-a可被視為all，即全部意思），但它也能够接收比較傳統-g選項。arp-aIP--假如你有多個網卡，那麼使用arp-a加上介面IP位址，就能够只顯示與該介面相關ARP緩存項目。arp-sIP物理位址——你能够向ARP快取記憶體中人工輸入一個靜態專案。該專案在電腦引導過程中將保持有效狀態，或在出現錯誤時，人工配置物理位址將自動更新該項目。arp-dIP--使用本命令能夠人工刪除一個靜態專案。1.15.4Tracert當資料報從你電腦經過多個閘道傳送到目标地時，Tracert命令能够用來跟蹤資料報使用路由（路徑）。該實用程式跟蹤路徑是源電腦到目标地一條路徑，不能保證或認為資料報總遵照這個路徑。假如你配置使用DNS，那麼你常常會從所產生應答中得到城市、位址和常見通信企业名字。Tracert是一個運行得比較慢命令（假如你指定目標位址比較遠），每個路由器你大約需要給它15秒鐘Tracert使用很簡單，只需要在tracert後面跟一個IP位址或URL，Tracert會進行相應功效變數名稱轉換。Tracert通常见來檢測故障位置，你能够用tracertIP在哪個環節上出了問題，雖然還是沒有確定是什麼問題。Tracert工作原理通過向目標發送不一样IP生存時間(TTL)值“Internet控制消息協定(ICMP)”回應資料包，Tracert診斷程式確定到目標所採取路由。要求路徑上每個路由器在轉發資料包之前最少將資料包上TTL遞減1。資料包上TTL減為0時，路由器應該將“ICMP已超時”消息發回源系統。Tracert先發送TTL為1回應資料包，並在隨後每次發送過程將TTL遞增1，直到目標響應或TTL達到最大值，從而確定路由。通過檢查中間路由器發回“ICMP已超時”消息確定路由。一些路由器不經詢問直接丟棄TTL過期資料包，這在Tracert實用程式中看不到。Tracert命令按順序列印出返回“ICMP已超時”消息路徑中近端路由器介面列表。假如使用-d選項，則Tracert實用程式不在每個IP位址上查詢DNS。在下例中，資料包必須通過兩個路由器（和）才能到達主機9。主機默認閘道是，網路上路由器IP地址是。C:\>tracert9-dTracingrouteto9overamaximumof30hops12s3s2s275ms83ms88ms373ms79ms93ms9Tracecomplete.用tracert解決問題能够使用tracert命令確定資料包在網路上停止位置。下例中，默認閘道確定9主機沒有有效路徑。這可能是路由器配置問題，或是網路不存在（錯誤IP位址）。C:\>tracert9Tracingrouteto9overamaximumof30hops1reportsestinationnetunreachable.Tracecomplete.Tracert實用程式對於解決大網路問題很有用，此時能够採取幾條路徑到達同一個點。Tracert命令行選項Tracert命令支援多種選項，以下表所表示。tracert[-d][-hmaximum_hops][-jhost-list][-wtimeout]target_name選項描述-d指定不將IP位址解析到主機名稱。-hmaximum_hops指定躍點數以跟蹤到稱為target_name主機路由。-jhost-list指定Tracert實用程式資料包所採用路徑中路由器介面列表。-wtimeout等候timeout為每次回復所指定毫秒數。target_name目標主機名稱或IP位址。1.15.5IPConfigIPConfig實用程式和它等價圖形用戶介面——Windows95/98中WinIPCfg可用於顯示當前TCP/IP配置設置值。這些資訊通常见來檢驗人工配置TCP/IP設置是否正確。不过，假如你電腦和所在局域網使用了動態主機配置協定（DynamicHostConfigurationProtocol，DHCP--WindowsNT下一種把較少IP位址分配給較多主機使用協定，類似於撥號上網動態IP分配），這個程式所顯示資訊也許愈加實用。這時，IPConfig能够讓你瞭解你電腦是否成功租用到一個IP位址，假如租用到則能够瞭解它现在分配到是什麼位址。瞭解電腦當前IP位址、子網路遮罩和缺省閘道實際上是進行測試和故障分析必需專案。最常见選項：ipconfig--當使用IPConfig時不帶任何參數選項，那麼它為每個已經配置了介面顯示IP位址、子網路遮罩和缺省閘道值ipconfig/all--當使用all選項時，IPConfig能為DNS和WINS伺服器顯示它已配置且所要使用附加資訊（如IP位址等），並且顯示內置於当地網卡中物理位址（MAC）。假如IP地址是從DHCP伺服器租用，IPConfig將顯示DHCP伺服器IP位址和租用地址預計失效日期.ipconfig/release和ipconfig/renew--這是兩個附加選項，只能在向DHCP伺服器租用其IP位址電腦上起作用。假如你輸入ipconfig/release，那麼全部介面租用IP位址便重新交付給DHCP伺服器（歸還IP位址）。假如你輸入ipconfig/renew，那麼当地電腦便設法與DHCP伺服器取得聯繫，並租用一個IP地址。請注意，大多數情況下網卡將被重新賦予和以前所賦予相同IP位址。1.15.6Route大多數主機通常全部是駐留在只連接一台路由器網段上。由於只有一台路由器，所以不存在使用哪一台路由器將資料報發表到遠端電腦上去問題，該路由器IP地址可作為該網段上全部電腦缺省閘道來輸入。不过，當網路上擁有兩個或多個路由器時，你就不一定想只依賴缺省閘道了。實際上你可能想讓你一些遠端IP位址通過某個特定路由器來傳遞，而其它遠端IP則通過另一個路由器來傳遞。在這種情況下，你需要相應路由資訊，這些資訊儲存在路由表中，每個主機和每個路由器全部配有自己獨一無二路由表。大多數路由器使用專門路由協定來交換和動態更新路由器之間路由表。但在有些情況下，必須人工將專案添加到路由器和主機上路由表中。Route就是用來顯示、人工添加和修改路由表項目标。通常使用選項：routeprint--本命令用於顯示路由表中當前項目，在單路由器網段上輸出結果以下：C:\DocumentsandSettings\zhgcui>routeprintIPv4RouteTable===========================================================================InterfaceList0x1MSTCPLoopbackinterface0x10003...00112568953aIntel(R)PRO/100VENetworkConnection======================================================================================================================================================ActiveRoutes:NetworkDestinationNetmaskGatewayInterfaceMetric92019920955205555992099205555991DefaultGateway:===========================================================================PersistentRoutes:None由於用IP位址配置了網卡，所以全部這些項目全部是自動添加。routeadd--使用本命令，能够將信路由項目添加給路由表。比如，假如要設定一個到目标網路3路由，其間要經過5個路由器網段，首先要經過当地網路上一個路由器，器IP為，子網路遮罩為24，那麼你應該輸入以下命令：routeadd3mask24metric5routechange--你能够使用本命令來修改資料傳輸路由，不過，你不能使用本命令來改變資料目标地。下面這個例子能够將資料路由改到另一個路由器，它採用一條包含3個網段更直路徑：routeadd3mask2450metric3routedelete--使用本命令能够從路由表中刪除路由。比如：routedelete31.15.7nbtstatnbtstat（TCP/IP上NetBIOS統計資料）實用程式用於提供關於關於NetBIOS統計資料。運用NetBIOS，你能够查看当地電腦或遠端電腦上NetBIOS名字表格。常见選項：nbtstat-n--顯示寄存在当地名字和服務程式nbtstat-c--本命令用於顯示NetBIOS名字快取記憶體內容。NetBIOS名字快取記憶體用於存放與本電腦最近進行通信其它電腦NetBIOS名字和IP位址對。nbtstat-r--本命令用於清除和重新載入NetBIOS名字快取記憶體。nbtstat-aIP--通過IP顯示另一台電腦物理位址和名字列表，你所顯示內容就像對方電腦自己運行nbtstat-n一樣nbtstat-R清除名稱緩存，然後從Lmhosts檔重新載入。nbtstat-RR釋放在WINS伺服器上註冊NetBIOS名稱，然後刷新它們註冊。nbtstat-S列出當前NetBIOS會話及其狀態（包含統計）.1.15.8使用pathping測試路由器pathping命令是一個路由跟蹤工具，它將ping和tracert命令功效和這兩個工具所不提供其它資訊結合起來。pathping命令在一段時間內將資料包發送到到達最終目標路徑上每個路由器，然後基於資料包電腦結果從每個躍點返回。由於命令顯示資料包在任何給定路由器或鏈結上丟失程度，所以能够很轻易地確定可能導致網路問題路由器或鏈結。一些選項是可用，以下表所表示。選項名稱功效-nHostnames不將地址解析成主機名-hMaximumhops搜索目標最大躍點數-gHost-list沿著路由列表釋放源路由-pPeriod在ping之間等候毫秒數-qNum_queries每個躍點查詢數-wTime-out為每次回復所等候毫秒數-TLayer2tag將第2層優先標記（如：對于IEEE802.1P）連接到數據包并將它發送到路徑中每個網絡設備。這又助于標識沒有正確配置第2層優先網絡設備。-T開關用于測試服務質量（QoS）連通性-RRSVPisbaseChe檢查以確定路徑中每個路由是否支持“資源保留協議（RSVP）”，此協議允許主機數據保留一定量帶寬。-R開關用于測試服務質量（QoS）連通性默認躍點數是30，並且超時前默認等候時間是3秒。默認時間是250毫秒，並且沿著路徑對每個路由器進行查詢次數是100。以下是经典pathping報告。躍點列表後所編輯統計資訊表明在每個獨立路由器上資料包丟失情況。D:\>pathping-nmswTracingroutetomsw[96]overamaximumof30hops:051182344596Computingstatisticsfor125seconds...SourcetoHereThisNode/LinkHopRTTLost/Sent=PctLost/Sent=PctAddress050/100=0%|141ms0/100=0%0/100=0%1813/100=13%|222ms16/100=16%3/100=3%0/100=0%|324ms13/100=13%0/100=0%0/100=0%|421ms14/100=14%1/100=1%40/100=0%|524ms13/100=13%0/100=0%96Tracecomplete.當運行pathping時，在測試問題時首先查看路由結果。此路徑與tracert命令所顯示路徑相同。然後pathping命令對下一個125毫秒顯示忙消息（此時間根據躍點計數變化）。在此期間，pathping從以前列出全部路由器和它們之間鏈結之間搜集資訊。在此期間結束時，它顯示測試結果。最右邊兩欄ThisNode/LinkLost/Sent=Pct和Address包含資訊最有用。18（躍點1）和（躍點2）丟失13%資料包。全部其它鏈結工作正常。在躍點2和4中路由器也丟失定址到它們資料包（如ThisNode/Link欄中所表示），不过該丟失不會影響轉發路徑。對鏈結顯示丟失率（在最右邊欄中標記為|）表明沿路徑轉發丟失資料包。該丟失表明鏈結阻塞。對路由器顯示丟失率（通過最右邊欄中IP位址顯示）表明這些路由器CPU可能超負荷運行。這些阻塞路由器可能也是端對端問題一個原因，尤其是在軟體路由器轉發資料包時。1.15.9網路診斷實例：1．當對伺服器進行Ping命令，發現時通時不通。C:\>ping8Replyfrom8:bytes=32time=30msTTL=54Requesttimedout.Replyfrom8:bytes=32time=30msTTL=54Requesttimedout.2.用tracert跟蹤路由路徑：C:\>tracert-d8Tracingrouteto8overamaximumof30hops110ms20ms20ms4230ms30ms40ms783**130ms8Tracecomplete.發現在路由2到路由3之間，存在丟包現象3.使用pathping命令確認是路由器還是鏈路問題：C:\>pathping-n8Tracingrouteto8overamaximumof30hopsoveramaximumof30hops:0271427838Computingstatisticsfor75seconds...SourcetoHereThisNode/LinkHopRTTLost/Sent=PctLost/Sent=PctAddress0270/100=0%|141ms0/100=0%0/100=0%40/100=0%|222ms0/100=0%0/100=0%7831/100=31%|324ms13/100=13%0/100=0%8Tracecomplete.發現路由2到路由3鏈路嚴重阻塞，包丟失率為31%.需排除路由2到路由3鏈結問題 附錄1：應用/測試環境關於應用/測試環境，最好不要通過非標準安裝方法來安裝Windows.詳細內容，請您參考：

DonotdiskduplicateinstalledversionsofWindows

\o""

從上面文章能够看到，假如我們用克隆來安裝，您伺服器狀態是不穩定，註冊表，用戶，檔全部有不匹配和損害風險，我們也不保證程式能夠運行在這樣安裝系統上。請您千萬不要在生產環境中用這樣方法來安裝。

您假如覺得手動安裝Windows比較麻煩，您能够用無人值守安裝方法:

INFO:ChangestoWindowsUnattendedWinnt[32].exeCommandLine

\o""附錄2：DTC部分資料MSDTC運行包含到下面部分組件:

COM+

OLEDB

DTC

DataBase

任何一部分全部有可能是導致鎖死，所以，對於MSDTC問題，我們通常是通過逐步隔離方法先進行錯誤定位，然後再具體分析。

關於DTC討論請您參考下面部分文章:TransactionalComponentServices:AGuidetoReviewingMicrosoftTransactionServer2.0

\o""

AnIntroductiontoMicrosoftTransactionServer

\o""

根據我們以往經驗，DTC本身出問題幾率是比較小，跟DTC相關問題往往是由於環境問題導致，所以重新安裝DTC是一個值得嘗試方法。而鎖死往往發生在COM+和資料庫上面。重新安裝DTC能够參考下面步驟:HowtoreinstallMSDTCforanonclusteredWindowsServer

\o""

同時,DTC也有自己trace機制來記錄log檔幫助分析問題，詳細情況請您參考:

\o""能够使用DTCPING進行問題排查，如檢查GUID是否一樣。附錄3中間層COM+問題分類和處理1．問題分類1.1COM+掛起症狀：1．COM+管理器裏調用時間不斷增長，以下圖.2．用戶端程式沒有回應，最終出現錯誤，”由於其它應用程式忙,不能執行該操作.選擇’切換到’按鈕以啟動忙應用程式並糾正該錯誤”3．CPU利用率較低，以下圖.1.2COM+出現100%CPU症狀1．DLLHost.exeCPU利用率很高：90%；以下圖. 2．用戶端程式沒有回應，或最終得到一個錯誤，”由於其它應用程式忙,不能執行該操作.選擇’切換到’按鈕以啟動忙應用程式並糾正該錯誤”1.3COM+性能問題症狀：1．運行速度慢，但最終能够得到正確結果。2．COM+管理器裏元件顯示較長調用時間，但不出現掛起。1.4COM+異常症狀：1．運行程式在DOS模式下下面錯誤提醒。2．在WINDOWS下出現下面錯誤提醒:”運行時錯誤’-(8007007e)’:Automation錯誤”此時查看中間層伺服器日誌時候，會有COM+日誌錯誤，內容以下：系統調用了一個客戶自定義元件，該元件已失敗並產生了一個異常錯誤。這說明自定義元件有問題。請將該失敗通知元件開發者關於並提供她們下列資訊。組件ProgID:伺服器應用程式ID:{5482A3AD-574C-4D03-8998-B949C5D0682F伺服器應用程式名稱:comhangup該錯誤嚴重性已導致進程終止。異常:C0000005地址:0x100034D3調用堆疊:Crash!CTestCrash::CrashMe(void)+0x0OLEAUT32!ClearCustData+0x588Crash!ATL::IDispatchImpl<structITestCrash,&struct_GUIDconstIID_ITestCrash,&struct_GUIDconstLIBID_CRASHLib,1,0,classATL::CComTypeInfoHolder>::Invoke(long,struct_GUIDconst&,unsignedlong,unsignedshort,structtagDISPPARAMS*,structtagVARIANT*,structtagEXCEPINFO*,unsignedint*)+0x41OLEAUT32!UserEXCEPINFO_free_local+0x57D上面情況，表明元件服務comhangup，在調用CTestCrash::CrashMe(void)時候出現了異常。1.5COM+應用記憶體洩漏症狀：1．在中間層Windows資源管理器中，記憶體使用不斷增加，能够看到類似下圖情況。2．在性能監視器中，增加process物件DLLHOST實例，顯示狀況以下圖，當前COM+物件privatebytes能够看到曲線總體趨勢一直在上升，此時假如用戶端運行多個這樣進程，現象會愈加明顯。2.COM+問題分類分析和處理方法 當出現COM+問題時，能够嘗試使用HYPERLINK\l"OLE_LINK7"~進行問題處理看能否解決，假如不能解決，需要參照下面具體分析和處理每一類問題。2.1COM+掛起分析COM+掛起，需要在出現問題時候使用HYPERLINK\l"OLE_LINK9"6.9ADPLus連續抓取幾個DUMP（記憶體鏡像）檔，時間上間隔為5分鐘作用，然後發回檔到研發中心，對其進行分析。出現COM+掛起原因可分為以下三種情況：COM+服務進程中有UI(FORM視窗)或消息對話方塊（如MsgBox）這種情況关键出現在WINDOWS下，能够在中間層出現提醒框時候點擊一下確定按鈕，能够暫時解決使用問題。在WINDOWS下已經解決該問題，相應消息能够在應用程式事務日誌中查看到。出現這樣情況，必須修改程式碼。分析DUMP檔會出現下面情況0:000>~10kbChildEBPRetAddrArgstoChild00a1e6a877d0744e77d0fa570000000000000000SharedUserData!SystemCallStub+0x400a1e6ac77d0fa57000000000000000000000000user32!NtUserWaitMessage+0xc[d:\nt\windows\core\umode\daytona\obj\i386\usrstubs.c@4795]00a1e6e077d12e1f000301c60000000000000001user32!DialogBox2+0x1fb[d:\nt\windows\core\ntuser\client\dlgmgr.c@1200]00a1e70877d25e6f77d00000000bede800000000user32!InternalDialogBox+0xce[d:\nt\windows\core\ntuser\client\dlgmgr.c@1353]00a1e9c477d258b20000000100000000ffffffffuser32!SoftModalMessageBox+0x75b[d:\nt\windows\core\ntuser\client\msgbox.c@1156]00a1eb1077d2610b000000020000002800000000user32!MessageBoxWorker+0x281[d:\nt\windows\core\ntuser\client\msgbox.c@754]00a1eb6877d2607b00000000000beda8000bedd0user32!MessageBoxTimeoutW+0x78[d:\nt\windows\core\ntuser\client\msgbox.c@398]00a1eb9c77d2600300000000000bed84000bed6cuser32!MessageBoxTimeoutA+0x9a[d:\nt\windows\core\ntuser\client\msgbox.c@432]00a1ebbc77d25fe200000000000bed84000bed6cuser32!MessageBoxExA+0x19[d:\nt\windows\core\ntuser\client\msgbox.c@342]00a1ebd4110019c300000000000bed84000bed6cuser32!MessageBoxA+0x44[d:\nt\windows\core\ntuser\client\msgbox.c@309]00a1ec1c770f6109000bdb28000000000000000aprjCOM!clsCOMHang::TestHang+0x63[F:\MyDoc\demos\COMHang\clsCOMHang.cls@17]00a1ec347359a2fb000bdb280000001c00000004oleaut32!tPushValJmpTab+0xf5[D:\srv03rtm\com\oleaut32\dispatch\i386\invoke.asm@342]00a1f5907359a0f4000bdb28110012fc60030000msvbvm60!EpiInvokeMethod+0x00a1f5ec7714d7ac00a1f6207714c00a1f65877ce947b00a1f690000b00a1fa2c77ce6862000b16f0000ba3380008dddcrpcrt4!NdrStubCall2+0x1a4[d:\nt\com\rpc\ndr20\srvcall.cxx@1394]00a1fa8477114196000b16f00008dddc000ba338rpcrt4!CStdStubBuffer_Invoke