Umdhtools.exe:如何使用 Umdh.exe 尋找記憶體遺漏

文章翻譯 文章翻譯
文章編號: 268343 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

在此頁中

結論

使用者模式傾印 (UMDH) 公用程式能夠與作業系統搭配使用,為特定的處理程序分析 Windows 堆積配置。這個公用程式和其他相關聯的工具以 Windows 2000 和 Windows XP 做為主要的目標作業系統。按一下 [播放] 按鈕,以檢視此串流媒體示範。
注意因為 C 執行階段 (CRT) 模組中的 malloc 函式在 Windows Server 2003 的原始發行版本上使用框架指標省略 (FPO),所以您可能無法透過使用 UMDH 工具看到 malloc 函式完整的堆疊資訊。這個問題已經在 Windows Server 2003 Service Pack 1 (SP1) 的 CRT 模組中獲得修正。因此,您可在 Windows Server 2003 SP1 中看到 malloc 函式完整的堆疊資訊。

其他相關資訊

使用 UMDH 之前

如果您認為有記憶體遺漏的問題,請注意記憶體遺漏可能不只是表面上的問題。您可能會發現記憶體遺漏並不是真正的問題,而是效能需增強。例如,Microsoft Jet 資料庫引擎可能會耗用大量的記憶體 (電腦記憶體若為 256 MB,可能耗用高達 128 MB),原因來自擷取資料和寫入快取。快取可以讓 Jet 引擎快速取得預先讀取及預先寫入的緩衝處理。

若要判斷某程序是否正發生記憶體遺漏問題,請使用 Windows 效能監視器 (Perfmon.exe),並監視應用程式中程序類別下的私用位元組。私用位元組是處理程序已配置的記憶體總數,但並不會與其他處理程序共用。請注意,這與另一項值得監視的虛擬位元組不同。虛擬位元組是以位元組為單位,目前處理程序所使用的虛擬位址空間大小。應用程式可能會遺漏虛擬記憶體,但是卻未必能分辨系統配置的私用位元組和虛擬位元組之間有何差異。如果監視私用位元組時未察覺耗用記憶體增加,但是仍然懷疑記憶體即將用完,則請監視虛擬位元組以確認虛擬記憶體是否即將用完。如需有關偵測記憶體遺漏和 Windows 效能監視器 (Perfmon.exe) 概觀的詳細資訊,請造訪下列 Microsoft 網站:
http://msdn.microsoft.com/zh-tw/library/ms404355.aspx (英文)
若要確定應用程式是否發生記憶體遺漏的問題,請將您懷疑的程式碼加入多次反覆運算的迴圈中,然後監視私用和虛擬位元組之記憶體耗用的增加情形。觀察並確認私用和虛擬位元組的最終數量不同,且數量停止增加。如果在某個時間點記憶體耗用停止增加,(例如,耗用量不再無止盡地上升),則您所遭遇的情況較有可能是快取檔案的大小已為最大值,而非記憶體遺漏。

如果您判斷目前正遭遇記憶體遺漏而非 UMDH,請依照下列步驟執行:
  1. 安裝 UMDH 公用程式。
  2. 設定系統 PATH 環境變數,來包含安裝 UMDH 的資料夾。
  3. 將 _NT_SYMBOL_PATH 環境變數設為 Microsoft 符號伺服器路徑,以供 UMDH 找出偵錯符號檔。
下列 Microsoft 網站的 Windows 偵錯工具產品隨附 UMDH 公用程式:
http://msdn.microsoft.com/zh-tw/windows/hardware/gg487428.aspx (英文)
下載並安裝公用程式,然後將 PATH 系統環境變數設為先前安裝偵錯工具的路徑。

使用 UMDH 之前,您必須安裝適用於您的應用程式和作業系統元件的正確偵錯工具。您可以使用 Microsoft 符號伺服器取得 Microsoft 元件的偵錯符號。 如需有關 Microsoft 符號伺服器的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
311503 您可以使用 Microsoft 符號伺服器取得偵錯符號檔 (機器翻譯)
UMDH 會嘗試使用 _NT_SYMBOL_PATH 環境變數來尋找符號檔。從命令提示字元設定路徑的指令,看起來像這樣:
set _NT_SYMBOL_PATH=SRV*c:\LocalSymbolCache
如需有關設定偵錯符號的詳細資訊,請參閱本文稍後的<偵錯符號>一節。

完成這些步驟之後,就可以開始使用 UMDH 公用程式。

使用 UMDH 擷取堆積傾印

UMDH 為傾印處理程序的堆積配置相關資訊的公用程式。此資訊包含每個配置的呼叫堆疊,透過呼叫堆疊產生的配置數,以及執行該呼叫堆疊所耗用的位元組數。例如:
0x14 配置 (@ 0x00000428) 的 00005320 位元組耗用於:BackTrace00053
ntdll!RtlDebugAllocateHeap+0x000000FD
ntdll!RtlAllocateHeapSlowly+0x0000005A
ntdll!RtlAllocateHeap+0x00000808
MyApp!_heap_alloc_base+0x00000069
MyApp!_heap_alloc_dbg+0x000001A2
MyApp!_nh_malloc_dbg+0x00000023
MyApp!_nh_malloc+0x00000016
MyApp!operator new+0x0000000E
MyApp!LeakyFunc+0x0000001E
MyApp!main+0x0000002C
MyApp!mainCRTStartup+0x000000FC
KERNEL32!BaseProcessStart+0x0000003D
				
這個 UMDH 輸出顯示呼叫堆疊總計已配置 21280 (0x5320) 個位元組。1064 個位元組 (0x428) 中的 20 (0x14) 個不同配置,配置了 21280 個位元組。系統給予呼叫堆疊 BackTrace00053 識別項。

若要產生堆積配置的傾印檔案,您必須使用 Windows 偵錯工具產品隨附的 Gflags.exe 公用程式,以便作業系統核心追蹤該配置。

假設您想要傾印 Notepad.exe 的堆積內容,首先,您必須為想要測試的應用程式啟用擷取堆疊追蹤。此功能預設是停用的。若要啟用這項功能,命令如下所示:
gflags -i notepad.exe +ust
此命令不會為已經在執行的處理程序啟用堆疊追蹤,而是為未來所執行的 Notepad.exe 啟用堆疊追蹤。或者,您可以透過 GFLAGS 使用者介面設定旗標 (不使用任何引數執行 Gflags.exe 以取得使用者介面)。當您完成偵錯,請使用 gflags 中的 -ust 選項來停用堆疊追蹤。

當您透過 Gflags.exe 設定影像旗標,並且完成偵錯符號設定,就可以開始啟動 [記事本] (該應用程式正在使用 UMDH)。啟動程式之後,您必須判斷剛啟動的記事本程序的處理序識別碼 (PID)。該命令如下所示:
tlist
您可以從 TLIST 應用程式的輸出找到 PID。PID 資訊也可以從工作管理員取得。假設剛啟動的記事本程序的 PID 為 124,則您可以使用 UMDH 搭配下列命令取得堆積傾印:
umdh-p: 124-f:notepad124.log
的結果:Notepad124.log 檔案中有記事本程序的完整堆積傾印。這個檔案會顯示所有所做的配置和完成配置的呼叫堆疊位置。

使用 Umdh.exe 比較 UMDH 記錄

UMDH 記錄檔除了包含關於處理程序堆積目前狀態的寶貴資訊,如果您擔心記憶體遺漏問題,比較兩個記錄之輸出並找出傾印檔案中成長最多的呼叫堆疊更能發揮其功用。Umdh.exe 公用程式可協助比較兩個 UMDH 記錄檔,以提供它們之間差異的分析。不同時間間隔的兩個記錄檔一旦擷取完成,便可以接著使用下列命令:
UMDH dh1.log dh2.log > cmp12.txt
或是
UMDH -d dh1.log dh2.log > cmp12.txt
-d 命令列選項可以讓 UMDH 以十進位的格式顯示,而非十六進位。該命令的輸出將會比較兩個記錄間的配置差異,並提供類似下列的資訊:
+ 5320 ( f110 - 9df0) 3a allocs BackTrace00053 Total increase == 5320
UMDH 記錄檔中的每個 BackTrace,皆存在兩個記錄檔的比較結果。這個案例顯示指定於 UMDH 命令列的最後一個記錄檔配置了 0xF110 個位元組,而 UMDH 命令列的第一個記錄檔在同一個 BackTrace (呼叫堆疊) 中配置了 0x9DF0 個位元組。「5320」是配置位元組數的差異。本案例所擷取的兩個記錄檔,在指定的時間間隔中,系統配置了 0x5320 個以上的位元組。此位元組數是來自識別碼為 "BackTrace00053" 的呼叫堆疊。

下一個步驟就是找出 backtrace 的內容。如果您開啟第二個記錄檔並搜尋 BackTrace00053 可能會發現類似下列的內容:
0x14 配置 (@ 0x00000428) 的 00005320 位元組耗用於:BackTrace00053
ntdll!RtlDebugAllocateHeap+0x000000FD
ntdll!RtlAllocateHeapSlowly+0x0000005A
ntdll!RtlAllocateHeap+0x00000808
MyApp!_heap_alloc_base+0x00000069
MyApp!_heap_alloc_dbg+0x000001A2
MyApp!_nh_malloc_dbg+0x00000023
MyApp!_nh_malloc+0x00000016
MyApp!operator new+0x0000000E
MyApp!LeakyFunc+0x0000001E
MyApp!main+0x0000002C
MyApp!mainCRTStartup+0x000000FC
KERNEL32!BaseProcessStart+0x0000003D
				
當檢視呼叫堆疊時,可以看到 LeakyFunc 函式透過 Visual C++ 執行階段程式庫之新增運算子函式配置記憶體。如果您發覺移除傾印檔案之後配置數仍然增加,或許可以斷定記憶體並未釋放。

啟用堆疊追蹤

UMDH 記錄檔中最重要的資訊是堆積配置的堆疊追蹤。您可以分析堆疊追蹤,驗證處理程序是否遺漏堆積記憶體。預設情況下,不會取得堆疊追蹤項目。您可以對個別處理程序或整個系統啟用此功能。若要對整個系統啟用堆疊追蹤,請使用下列命令:
gflags r + ust
執行此命令後,請重新啟動電腦。對個別處理程序啟用此功能,命令如下所示:
gflags -i APPNAME +ust
APPNAME 為可執行檔的檔名,包括副檔名 (例如,Services.exe、Lsass.exe)。此命令不會對正在執行中的處理程序啟用堆疊追蹤。因此,對於無法重新啟動的處理程序 (如範例、服務、lsass、Winlogon),您必須重新啟動您的測試電腦。

若要確認整個系統或特定的處理程序中已完成的設定為何,請使用下列命令:整個系統:
gflags r
特定處理程序:
gflags -i APP-NAME
根據預設,堆疊追蹤的深度最大為 16。如果想要查看較深的呼叫堆疊,可以透過執行 GFLAGS 來增加。按一下以選取 [系統登錄],然後在 [堆疊追蹤深度最大值] 的編輯控制項中輸入新的深度。按一下 [確定],然後重新啟動電腦。
重要:如果您使用 Windows NT 4.0 Service Pack 6,則必須使用 Umdh_nt4.exe,而非 Umdh.exe,還必須執行 gflags -r 命令以設定整個系統的堆疊追蹤。請務必重新啟動電腦。Umdh_nt4 堆疊追蹤並非針對 Windows NT 4.0 的個別處理程序執行。整個系統都必須執行相同的設定。

偵錯符號

使用 UMDH 最重要的步驟之一,是確定您有適用的符號檔 (.dbg 或 .pdb 檔案) 以取得正確的堆疊追蹤結果。您最少需要 Kernel32.dbg 和 Ntdll.dbg 符號檔。當找到遺漏記憶體的元件增加,您也可以嘗試取得其他可能需要的偵錯符號。 如需有關如何取得 Microsoft 元件偵錯符號檔的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
311503 您可以使用 Microsoft 符號伺服器取得偵錯符號檔 (機器翻譯)
如需有關如何使用 Microsoft 符號伺服器以及如何取得 Windows 符號套件的詳細資訊,請造訪下列 Microsoft 網站:
http://msdn.microsoft.com/zh-tw/windows/hardware/gg487428.aspx (英文)
當您使用 Visual C++ 建立元件時,一定要確認 C++ 編譯器選項中未選取 [供編輯以便繼續的程式資料庫]。而是應選取 [程式資料庫]。若要設定符號路徑,請初始化 _NT_SYMBOL_PATH 環境變數,以供路徑使用。您可以使用 Microsoft 的符號伺服器,取得 Microsoft 元件的符號。
311503 您可以使用 Microsoft 符號伺服器取得偵錯符號檔 (機器翻譯)
請依照下列步驟執行,以設定 _NT_SYMBOL_PATH 環境變數:
  1. 在 [控制台] 中,按兩下 [系統]
  2. 按一下 [進階] 索引標籤,再按一下 [環境變數]
執行 UMDH 之前,您也可以在 [命令視窗] 中設定 _NT_SYMBOL_PATH 環境變數。

注意:請加入您的應用程式元件的 PDBs 路徑。例如,將 _NT_SYMBOL_PATH 的路徑進行如下設定:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\myapplicationssymbols
此路徑的第一個部分指向 Microsoft 符號伺服器,並表示使用的符號將下載至 c:\symbols 資料夾。分號後面的部分為遺漏記憶體的應用程式所指定的 PDB 檔案 (符號檔) 路徑。

叫用 UMDH

UMDH 所需的唯一命令列參數為 -p 選項,其指定了處理程序的 PID,堆積傾印將從中取得。可以使用工作管理員或 Tlist.exe 程式,取得 PID。對於類似下列的命令,記錄檔將傾印至標準輸出:
umdh -p:PID
UMDH 也會顯示各種不同的告知性訊息和標準錯誤,因此如果您未將其重新導向,則會與實際的記錄混合。若要收集 UMDH 檔案中的告知性訊息,請使用下列命令:
umdh -p:PID 2>umdh.msg
如果您要收集檔案中 UMDH 傾印的記錄,請使用下列命令:
umdh-p: PID>umdh.log
- 或 -
umdh-p: PID-f:umdh.log
這些指令作用是相同的。

UMDH 取得的預設記錄檔包含堆積耗用者的列舉,根據配置計數排序。若要進行偵錯,您還需要所有已配置區塊及相對應的堆疊追蹤之傾印檔案,可使用 -d 選項達成:
umdh-p: PID d
如果您使用此命令,您可能會在 UMDH 記錄檔中看到下列資訊:
BackTrace00046 追蹤的配置:005F69A0 005F6150
這些都是該呼叫堆疊配置的記憶體位址。如果您的偵錯工具附加於處理程序,則可以傾印這些位址的記憶體內容,以查看配置。

如果記錄檔包含過多資訊,則可將設定限制為只顯示配置計數達特定臨界值的主要使用者。執行下列命令:
umdh -p:PID -t:THRESHOLD
可以同時以不同的順序指定所有命令列選項 (例如,-p, -f, -t, -d)。下列是較困難的命令列範例:
umdh -p:123 -t:1000 -f:umdh.log -d
此命令將 PID 123的處理程序堆積傾印至 Umdh.log 檔案。系統將只會傾印占據超過 1000 個配置的堆疊追蹤,並同時傾印透過個別堆疊追蹤所配置的堆積區塊位址。

另一個有用的 UMDH 選項是 -l 選項。這會使檔案和行號盡可能列印於呼叫堆疊中。

UMDH 輸出說明

如果您將記錄重新導向至某個檔案 (umdh -p:PID -f:umdh.log),記錄將類似下列內容,此內容是從執行中的記事本程序所取得:
UMDH:記錄時間 2000-06-28 10:54 - Machine=MYMachine - PID=704
*********** 堆積 00270000 資訊 ********************
旗標: 58000062
項目數目: 87
標籤數目:<不明>
已配置的位元組:00008DF0
已認可的位元組:0000A000
可用空間總和: 00001210
已使用虛擬位址區塊數目: 1
已使用位址空間:<不明>
項目額外負荷: 8
建立者:(Backtrace00007)
ntdll!RtlDebugCreateHeap+0x00000196
ntdll!RtlCreateHeap+0x0000023F
ntdll!LdrpInitializeProcess+0x00000369
ntdll!LdrpInitialize+0x0000028D
ntdll!KiUserApcDispatcher+0x00000007
*********** 堆積 00270000 資訊 ********************
0x4 配置 (@ 0x00000068) 的 000001A0 位元組耗用於:BackTrace00031
ntdll!RtlDebugAllocateHeap+0x000000FB
ntdll!RtlAllocateHeapSlowly+0x0000005B
ntdll!RtlAllocateHeap+0x00000D81
ntdll!LdrpAllocateDataTableEntry+0x00000039
ntdll!LdrpMapDll+0x000002A4
ntdll!LdrpLoadImportModule+0x0000010D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpLoadImportModule+0x0000011D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpLoadImportModule+0x0000011D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpInitializeProcess+0x000009DC
ntdll!LdrpInitialize+0x0000028D
ntdll!KiUserApcDispatcher+0x00000007

0x4 配置 (@ 0x00000068) 的 000001A0 位元組耗用於:BackTrace00034
ntdll!RtlDebugAllocateHeap+0x000000FB
ntdll!RtlAllocateHeapSlowly+0x0000005B
ntdll!RtlAllocateHeap+0x00000D81
ntdll!LdrpAllocateDataTableEntry+0x00000039
ntdll!LdrpMapDll+0x000002A4
ntdll!LdrpLoadImportModule+0x0000010D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpLoadImportModule+0x0000011D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpLoadImportModule+0x0000011D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpLoadImportModule+0x0000011D
ntdll!LdrpWalkImportDescriptor+0x0000008B
ntdll!LdrpInitializeProcess+0x000009DC
ntdll!LdrpInitialize+0x0000028D
ntdll!KiUserApcDispatcher+0x00000007
				
記錄檔包含處理程序中每個堆積的傾印。在此範例中,記錄開始於堆積位址 270000。堆積進行數次全域計數之後,記錄檔會包含負責大多數配置之堆疊追蹤傾印,以遞減順序排序。當您對不同時刻所使用的記憶體動態進行比較時,便能推斷處理程序內發生的狀況,以及任何堆積是否疑似遺漏。

使用 UMDH 可能遭遇的問題

使用 UMDH 最常見的錯誤是未啟用堆疊追蹤。而且,不正確的 Ntdll.dll 符號將使 UMDH 無法執行。對於其他符號檔,UMDH 會執行,但是記錄檔的堆疊追蹤不會包含函式名稱,而是在模組內包含相對位址。遠端的第三方錯誤,指定錯誤的 PID。下列錯誤訊息發生於嘗試為某處理程序執行 UMDH,卻未啟用堆疊追蹤時:
C:\>umdh -p:1140 UMDH:記錄時間 2000-06-28 12: 43 - Machine=MyMachine - PID=1140 連線.....模組列舉完成。SymGetSymFromName(process, ntdll!RtlpStackTraceDataBase, xxx) 失敗, LastError = 126 UmdhGetAddrFromName 找不到堆疊追蹤資料庫指標 (ntdll!RtlpStackTraceDataBase)。ntdll.dll 符號不正確,必須要使用非匯入符號。
若要再次檢查調查中的處理程序設定,請使用下列命令:
gflags-i APPNAME
當您使用整個系統的堆疊追蹤,請使用下列命令:
gflags r
這些命令會顯示應用程式設定的旗標清單。請注意,若使用整個系統的堆疊追蹤,此功能可能會顯示為使用中,但是如果執行 gflags -r +ust 命令之後沒有重新啟動電腦,此功能實際上並未啟動。如果您想要知道所有啟用堆疊追蹤的應用程式,可以在下列登錄機碼中檢視 USTEnabled 機碼:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
如果您在啟用堆疊追蹤的處理程序執行 UMDH,但是在設定旗標之後尚未重新啟動應用程式,可能會在記錄檔中收到下列訊息:
這個配置未儲存的堆疊追蹤 (索引 = = 0)
如果您未設定正確的符號路徑或是符號不正確,卻仍然執行 UMDH,可能會在記錄檔中收到錯誤訊息。但是,可能只收到不正確或使人產生誤解的呼叫堆疊。若要確認您有正確的符號,請為處理程序啟動 NTSD 系統偵錯工具,例如:
ntsd notepad
然後,從偵錯工具主控台執行 LD 命令,載入模組的符號資訊,再執行 LM 命令以列出符號已載入的模組清單。如果 LM 命令的輸出顯示已經載入匯出符號,則該符號不適用。如果您已經載入 PDB 符號,則該符號適用。如果您指定了錯誤的 PID,可能會收到下列錯誤訊息:
C:\>umdh -p:1000 UMDH:記錄時間 2000-06-28 09: 45 - Machine=MyMachine - PID=1000 連線...LastError OpenProcess 失敗,LastError = 0x57

從 Visual Basic 呼叫 UMDH

每隔一段時間傾印多個記錄檔可能很有用,因為一開始的遺漏可能不太明顯。例如,如果您懷疑所用的 Active Server Pages (ASP) Web 應用程式正在遺漏記憶體,在 Visual Basic 中寫入可散佈至 UMDH 的 COM 元件可能會有幫助。稍後您可以從 ASP 網頁呼叫該元件。

下列為某些叫用 UMDH 並根據目前時間建立記錄檔的 Visual Basic 程式碼:
私用宣告函式 GetCurrentProcessId Lib "kernel32" () 為長整數
公用函式 GetProcessID()
GetProcessID = GetCurrentProcessId()
函式結束  
   .
   .
   .
定義 strTime 為字串

定義 sProcID 為字串
sProcID = GetProcessID()
strTime = "MYLOG_" & Format(Now(), "hhmm")
     
Shell ("C:\UMDH\umdh -p:"& sProcID & " -f:d:\logs\" & strTime & ".txt")
				

使用 UMDH 搭配 Windows NT 4.0 Service Pack 6a (SP6a)

Windows 偵錯工具產品隨附的 UMDH 公用程式無法在 Windows NT 4.0 上運作。此文件包含可自動解壓縮的執行檔 (Umdhnt4tools.exe),並包含可於 NT 4.0 使用的下列工具:
  • Umdh_nt4.exe 和 Dbghelp.dll
    這是適用於 Windows NT 4.0 SP6 版本的 UMDH 公用程式。
  • Dhcmp.exe
    這個公用程式用來比較兩個 UMDH 傾印,以判斷記憶體遺漏可能發生的位置。
您可以從「Microsoft 下載中心」下載下列檔案:
摺疊此圖像展開此圖像
下載
立即下載 Umdhnt4tools.exe
發行日期:2002 年 8 月 28 日

如需有關如何下載 Microsoft 支援檔案的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
119591 如何從線上服務取得 Microsoft 支援檔案
Microsoft 已對這個檔案做過病毒掃描。Microsoft 是利用發佈當日的最新病毒偵測軟體來掃描檔案,看看有沒有病毒感染。檔案會儲存在安全的伺服器上,以避免任何未經授權的更改。 將 Umdh_nt4.exe 和 Dbghelp.dll 放在同一個資料夾中,然後將它們放置在 PATH 環境變數中第一個位置。使用 Umdh_nt4.exe 而非 UMDH。

在執行 Windows NT 4.0 電腦上,您必須使用 Gflags.exe 設定整個系統的堆疊追蹤。例如:
gflags r
請務必重新啟動電腦。Umdh_nt4 堆疊追蹤並非針對 Windows NT 4.0 的個別處理程序執行。整個系統都必須執行相同的設定。

UMDH_NT4 與 UMDH 不同的是,它並不會比較記錄檔。例如,您無法執行下列命令:
UMDH_NT4 dh1.log dh2.log>cmp12.txt
而必須使用此文件包含的 Dhcmp.exe 公用程式。該命令看起來像這樣:
DHCMP dh1.log dh2.log > cmp12.txt

屬性

文章編號: 268343 - 上次校閱: 2011年9月17日 - 版次: 2.0
這篇文章中的資訊適用於:
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
關鍵字:?
kbdownload kbarttypeshowme kbfile kbgraphxlinkcritical kbhowto kbsample KB268343
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com