Umdhtools.exe: วิธีการใช้ Umdh.exe เพื่อค้นหาการรั่วไหลของหน่วยความจำ

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 268343 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

โปรแกรมอรรถประโยชน์ User-Mode Dump Heap (UMDH) ทำงานร่วมกับระบบปฏิบัติการเพื่อวิเคราะห์การจัดสรรฮีป Windows สำหรับกระบวนการเฉพาะ โปรแกรมอรรถประโยชน์นี้และเครื่องมืออื่นๆ ที่เกี่ยวข้องเป็นเป้าหมายหลักสำหรับ Windows 2000 และ Windows XP คลิกที่ปุ่ม เล่น เพื่อดูการสาธิตสื่อการสตรีมนี้

หมายเหตุ วิดีโอถูกเขียนด้วยตัวแปลงสัญญาณ ACELP? คุณจำเป็นต้องติดตั้งตัวแปลงสัญญาณ ACELP? ฟรีซึ่งดาวน์โหลดได้ที่ http://www.acelp.net/acelp_eval.php



หมายเหตุ เนื่องจากฟังก์ชัน malloc ในโมดูล C run-time (CRT) ใช้ Frame Pointer Omission (FPO) ในรุ่นวางจำหน่ายต้นฉบับของ Windows Server 2003 คุณจึงอาจไม่พบข้อมูลสแตกที่สมบูรณ์ของฟังก์ชัน malloc โดยการใช้เครื่องมือ UMDH ปัญหานี้ได้รับการแก้ไขในโมดูล CRT ของ Windows Server 2003 Service Pack 1 (SP1) ดังนั้น คุณสามารถดูข้อมูลสแตกที่สมบูรณ์ของฟังก์ชัน malloc ได้ใน Windows Server 2003 SP1

ข้อมูลเพิ่มเติม

ก่อนที่คุณจะใช้ UMDH

ถ้าคุณคิดว่าคุณกำลังประสบเหตุการณ์รั่วไหลของหน่วยความจำ โปรดทราบว่าการรั่วไหลของหน่วยความจำอาจไม่ได้มีลักษณะอย่างที่ปรากฏ คุณอาจพบว่า การรั่วไหลของหน่วยความจำไม่ใช่การรั่วไหลของหน่วยความจำจริง แต่เป็นการปรับปรุงประสิทธิภาพการทำงาน ตัวอย่างเช่น โปรแกรมฐานข้อมูล Microsoft Jet อาจใช้หน่วยความจำจำนวนมาก (สูงถึง 128 เมกะไบต์ในคอมพิวเตอร์ 256 เมกะไบต์) เนื่องจากโปรแกรมนี้จะมีการดึงข้อมูลและเขียนแคช การแคชนี้ช่วยให้ Jet engine สามารถกำหนดบัฟเฟอร์การอ่านล่วงหน้าและเขียนล่วงหน้าได้

เมื่อต้องการตรวจสอบว่ากระบวนการกำลังประสบกับการรั่วไหลของหน่วยความจำหรือไม่ ให้ใช้ Windows Performance Monitor (Perfmon.exe) และตรวจสอบไบต์ส่วนตัวภายใต้หมวดหมู่ กระบวนการ สำหรับแอปพลิเคชันของคุณ ไบต์ส่วนตัวคือหน่วยความจำทั้งหมดที่กระบวนการมีการจัดสรร แต่ไม่ได้ใช้ร่วมกันกับกระบวนการอื่นๆ โปรดทราบว่า ไบต์ส่วนตัวจะแตกต่างจากไบต์เสมือนซึ่งควรมีการตรวจสอบ ไบต์เสมือนคือขนาดไบต์ปัจจุบันของเนื้อที่ที่อยู่เสมือนที่กระบวนการใช้อยู่ แอปพลิเคชันสามารถทำให้หน่วยความจำเสมือนรั่วไหลได้แต่อาจจะไม่พบความแตกต่างในไบต์ส่วนตัวที่ได้รับการจัดสรร ถ้าคุณไม่พบการเพิ่มของหน่วยความจำเมื่อคุณตรวจสอบไบต์ส่วนตัว แต่คุณสงสัยว่าคุณอาจยังคงประสบกับการสิ้นเปลืองหน่วยความจำ ให้ตรวจสอบไบต์เสมือนเพื่อดูว่าคุณกำลังใช้หน่วยความจำเสมือนอยู่หรือไม่ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตรวจหาการรั่วไหลของหน่วยความจำและภาพรวมของ Windows Performance Monitor (Perfmon.exe) โปรดไปที่เว็บไซต์ของ Microsoft ต่อไปนี้:
http://msdn.microsoft.com/th-th/library/ms404355.aspx
เพื่อเป็นการตรวจสอบว่าแอปพลิเคชันของคุณมีการรั่วไหลของหน่วยความจำ ให้ใส่รหัสที่สงสัยในวนรอบที่มีการทำซ้ำจำนวนมาก จากนั้นตรวจสอบไบต์ส่วนตัวและไปต์เสมือนว่ามีการเพิ่มขึ้นใดๆ ของหน่วยความจำหรือไม่ ติดตามดูเพื่อให้แน่ใจว่าในที่สุดแล้วจำนวนของไบต์ส่วนตัวและไบต์เสมือนยังคงเดิมและจำนวนหยุดเพิ่มขึ้น หากมีจุดที่หน่วยความจำหยุดเพิ่มขึ้น (ตัวอย่างเช่น ไม่มีการไต่ระดับขึ้นไปเรื่อยๆ) คุณจะไม่พบการรั่วไหลของหน่วยความจำ แต่เป็นไปได้มากว่าคุณจะพบแคชที่มีการขยายเพิ่มจนมีขนาดสูงสุด

ถ้าคุณระบุแล้วว่าคุณเห็นการรั่วไหลของหน่วยความจำ ก่อนที่คุณจะใช้ UMDH ให้ทำตามขั้นตอนเหล่านี้:
  1. ติดตั้งโปรแกรมอรรถประโยชน์ UMDH
  2. ตั้งค่าตัวแปรสภาพแวดล้อมเส้นทางระบบเพื่อรวมโฟลเดอร์ไว้ในที่ที่คุณติดตั้ง UMDH
  3. ตั้งค่าตัวแปรสภาพแวดล้อม _NT_SYMBOL_PATH ไปยังเส้นทางเซิร์ฟเวอร์สัญลักษณ์ของ Microsoft เพื่อให้ UMDH สามารถค้นหาแฟ้มสัญลักษณ์ตรวจแก้จุดบกพร่องได้
โปรแกรมอรรถประโยชน์ UMDH มาพร้อมกับเครื่องมือตรวจแก้จุดบกพร่องสำหรับผลิตภัณฑ์ Windows ที่เว็บไซต์ของ Microsoft ต่อไปนี้:
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
ดาวน์โหลดและติดตั้งโปรแกรมอรรถประโยชน์ จากนั้นตั้งค่าตัวแปรสภาพแวดล้อมระบบ PATH ไปยังเส้นทางที่มีการติดตั้งเครื่องมือการตรวจแก้จุดบกพร่อง

ก่อนที่คุณจะใช้ UMDH คุณต้องติดตั้งสัญลักษณ์ตรวจแก้จุดบกพร่องที่ถูกต้องสำหรับคอมโพเนนต์ของแอปพลิเคชันของคุณและระบบปฏิบัติการของคุณ ใช้เซิร์ฟเวอร์สัญลักษณ์ของ Microsoft เพื่อขอรับสัญลักษณ์ตรวจแก้จุดบกพร่องสำหรับคอมโพเนนต์ของ Microsoft สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์สัญลักษณ์ของ Microsoft โปรดคลิกที่หมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
311503 ใช้เซิร์ฟเวอร์สัญลักษณ์ของ Microsoft เพื่อขอรับแฟ้มสัญลักษณ์ตรวจแก้จุดบกพร่อง
UMDH จะพยายามค้นหาแฟ้มสัญลักษณ์โดยใช้ตัวแปรสภาพแวดล้อมของ _NT_SYMBOL_PATH คำสั่งสำหรับการตั้งค่าเส้นทางจากพร้อมท์คำสั่งอาจมีลักษณะคล้ายกับคำสั่งต่อไปนี้:
ตั้งค่า _NT_SYMBOL_PATH=SRV*c:\LocalSymbolCache
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าข้อมูลการตรวจแก้จุดบกพร่องที่เป็นสัญลักษณ์ โปรดดูส่วน "สัญลักษณ์ตรวจแก้จุดบกพร่อง" ถัดไปในบทความนี้

หลังจากที่คุณดำเนินการตามขั้นตอนเหล่านี้แล้ว คุณพร้อมที่จะใช้โปรแกรมอรรถประโยชน์ UMDH

การจับการถ่ายโอนฮีปด้วย UMDH

UMDH เป็นโปรแกรมอรรถประโยชน์ที่จะถ่ายโอนข้อมูลเกี่ยวกับการจัดสรรฮีปของกระบวนการหนึ่ง ข้อมูลนี้รวมถึง Callstack สำหรับการจัดสรรแต่ละรายการ จำนวนของการจัดสรรที่ทำผ่าน Callstack นั้น และจำนวนของไบต์ที่มีการใช้ผ่าน Callstack นั้น ตัวอย่างเช่น:
ไบต์ 00005320 ในการจัดสรร 0x14 (@ 0x00000428) โดย: 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) ไบต์ที่จัดสรรจาก Callstack 21280 ไบต์จะถูกจัดสรรจาก 20 (0x14) การจัดสรรละ 1064 ไบต์ (0x428) แยกต่างหาก Callstack จะถูกกำหนดตัวระบุ BackTrace00053

เมื่อต้องสร้างแฟ้มการถ่ายโอนของการจัดสรรฮีป คุณต้องใช้โปรแกรมอรรถประโยชน์ Gflags.exe ซึ่งมาพร้อมกับเครื่องมือตรวจแก้จุดบกพร่องสำหรับผลิตภัณฑ์ Windows ด้วย เพื่อให้ระบบปฏิบัติการทราบว่าคุณต้องการเคอร์เนลในการติดตามการจัดสรร

สมมติว่าคุณต้องการถ่ายโอนเนื้อหาฮีปสำหรับ Notepad.exe ก่อนอื่น คุณต้องเปิดใช้งานการขอรับการติดตามสแตกสำหรับแอปพลิเคชันที่คุณต้องการทดสอบ ตามค่าเริ่มต้น คุณสมบัตินี้จะไม่เปิดใช้งาน คำสั่งในการเปิดใช้งานคุณสมบัตินี้คือ:
gflags -i notepad.exe +ust
คำสั่งจะไม่เปิดใช้งานการติดตามสแตกสำหรับกระบวนการที่กำลังใช้งานอยู่แล้ว แต่จะเปิดใช้งานการติดตามสแตกสำหรับการดำเนินงานทั้งหมดของ Notepad.exe ในอนาคต อีกทางเลือกหนึ่งก็คือ คุณสามารถตั้งค่าสถานะผ่านอินเทอร์เฟซผู้ใช้ GFLAGS (เรียกใช้ Gflags.exe โดยไม่มีอาร์กิวเมนต์ใดๆ เพื่อไปยังอินเทอร์เฟซผู้ใช้) ใช้ตัวเลือก -ust สำหรับ gflags เพื่อปิดการใช้งานการติดตามสแตกเมื่อคุณตรวจแก้จุดบกพร่องเสร็จสมบูรณ์

เมื่อคุณตั้งค่าสถานะของภาพผ่าน Gflags.exe และคุณตั้งค่าสัญลักษณ์ตรวจแก้จุดบกพร่องเอาไว้ คุณพร้อมที่จะเริ่ม Notepad (แอปพลิเคชันที่ใช้ UMDH) แล้ว หลังจากที่โปรแกรมเริ่มทำงาน คุณจะต้องกำหนด Process ID (PID) ของกระบวนการ Notepad ที่เพิ่งเริ่มทำงาน คำสั่งนี้คือ:
tlist
คุณสามารถค้นหา PID ได้จากผลลัพธ์ของแอปพลิเคชัน TLIST ข้อมูล PID ยังสามารถรับได้จาก 'ตัวจัดการงาน' สมมติว่า PID สำหรับกระบวนการ Notepad ที่คุณเพิ่งเริ่มคือ 124 คุณสามารถใช้ UMDH เพื่อรับการถ่ายโอนฮีปด้วยคำสั่งต่อไปนี้:
umdh -p:124 -f:notepad124.log
ผลลัพธ์: คุณมีการถ่ายโอนฮีปที่สมบูรณ์ของกระบวนการ Notepad ในแฟ้ม Notepad124.log แฟ้มนี้แสดงการจัดสรรทั้งหมดที่เกิดขึ้นและ Callstacks ที่มีการจัดสรร

ใช้ Umdh.exe to เพื่อเปรียบเทียบบันทึก UMDH

แม้ว่าแฟ้มบันทึก UMDH จะมีข้อมูลที่มีประโยชน์เกี่ยวกับสถานะปัจจุบันของฮีปสำหรับกระบวนการก็ตาม แต่ถ้าคุณมีความกังวลเกี่ยวกับการหาการรั่วไหลของหน่วยความจำ การเปรียบเทียบเอาต์พุตของบันทึกทั้งสอง และการค้นหาสิ่งที่ Callstack ได้พบการเจริญเติบโตมากที่สุดระหว่างแฟ้มการถ่ายโอนสองแฟ้มอาจจะมีประโยชน์มากกว่า โปรแกรมอรรถประโยชน์ Umdh.exe จะช่วยในการเปรียบเทียบแฟ้มบันทึก UMDH สองแฟ้มเพื่อให้การวิเคราะห์ผลต่างระหว่างสองแฟ้ม หลังจากที่คุณได้จับบันทึกสองบันทึกในช่วงเวลาที่ต่างกัน คุณจะสามารถใช้คำสั่งต่อไปนี้ได้:
UMDH dh1.log dh2.log > cmp12.txt
-or-
UMDH -d dh1.log dh2.log > cmp12.txt
ตัวเลือกบรรทัดคำสั่ง -d จะสั่ง UMDH ให้แสดงผลเป็นทศนิยมแทนเลขฐานสิบหก ผลลัพธ์ของคำสั่งจะเปรียบเทียบความแตกต่างของการจัดสรรระหว่างบันทึกสองบันทึก และให้ข้อมูลที่คล้ายกับข้อมูลต่อไปนี้:
+ 5320 ( f110 - 9df0) 3a allocs BackTrace00053 การเพิ่มขึ้นทั้งหมด == 5320
สำหรับ BackTrace แต่ละรายการในแฟ้มบันทึก UMDH จะมีการเปรียบเทียบระหว่างแฟ้มบันทึกสองแฟ้ม กรณีนี้แสดงให้เห็นว่าแฟ้มบันทึกล่าสุดที่ระบุไว้ในบรรทัดคำสั่ง UMDH ได้มีการจัดสรรไปแล้ว 0xF110 ไบต์ในขณะที่บันทึกแรกในบรรทัดคำสั่ง UMDH ได้มีการจัดสรรไปแล้ว 0x9DF0 ไบต์สำหรับ BackTrace เดียวกัน (Callstack) "5320" คือความแตกต่างในจำนวนของไบต์ที่จัดสรร ในกรณีนี้ มีการจัดสรรไบต์เพิ่มขึ้น 0x5320 ไบต์ระหว่างเวลาที่มีการบันทึกแฟ้มบันทึกสองแฟ้มไว้ ไบต์มาจาก Callstack ที่ถูกระบุด้วย "BackTrace00053"

ขั้นตอนถัดไปคือการค้นหาสิ่งที่อยู่ใน Backtrace นั้น ถ้าคุณเปิดแฟ้มบันทึกที่สองแล้วค้นหา BackTrace00053 คุณอาจพบบางสิ่งที่คล้ายกับรายการต่อไปนี้:
ไบต์ 00005320 ในการจัดสรร 0x14 (@ 0x00000428) โดย: 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
				
เมื่อคุณดู Callstack คุณจะสามารถเห็นได้ว่าฟังก์ชัน 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 หากคุณต้องการดู Callstack ที่ลึกขึ้น คุณสามารถเพิ่มค่านี้โดยการเรียกใช้ GFLAGS คลิกเพื่อเลือก รีจิสทรีระบบ แล้วพิมพ์ความลึกใหม่ในการควบคุมการแก้ไข ความลึกการจับการติดตามสแตกสูงสุด คลิก นำไปใช้ แล้วรีสตาร์ทคอมพิวเตอร์
สิ่งสำคัญ: ถ้าคุณใช้ Windows NT 4.0 Service Pack 6 คุณจะต้องใช้ Umdh_nt4.exe แทน Umdh.exe และคุณต้องใช้คำสั่ง gflags -r ในการตั้งค่าการติดตามสแตกทั้งระบบ ตรวจสอบให้แน่ใจว่าคุณได้เริ่มการทำงานของคอมพิวเตอร์ใหม่ การติดตาม Umdh_nt4 จะไม่ทำงานบนพื้นฐานสำหรับแต่ละกระบวนการบน Windows NT รุ่น 4 คุณต้องตั้งค่าสำหรับทั้งระบบ

สัญลักษณ์ตรวจแก้จุดบกพร่อง

หนึ่งในขั้นตอนที่สำคัญที่สุดสำหรับการใช้ UMDH คือการตรวจสอบให้แน่ใจว่าคุณมีแฟ้มสัญลักษณ์ที่ดี (แฟ้ม .dbg หรือ .pdb) เพื่อการติดตามสแต็กที่มีประสิทธิภาพ อย่างน้อยสุด คุณจำเป็นต้องมีแฟ้มสัญลักษณ์ Kernel32.dbg และ Ntdll.dbg คุณสามารถรับสัญลักษณ์ตรวจแก้จุดบกพร่องเพิ่มเติมที่คุณอาจจำเป็นต้องใช้ในขณะที่คุณค้นหาข้อมูลเพิ่มเติมว่าคอมโพเนนต์ใดที่มีการรั่วไหลของหน่วยความจำ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการรับแฟ้มสัญลักษณ์ตรวจแก้จุดบกพร่องสำหรับคอมโพเนนต์ของ Microsoft ให้คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
311503 ใช้เซิร์ฟเวอร์สัญลักษณ์ของ Microsoft เพื่อขอรับแฟ้มสัญลักษณ์ตรวจแก้จุดบกพร่อง
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการใช้เซิร์ฟเวอร์สัญลักษณ์ของ Microsoft และวิธีการรับแพคเกจสัญลักษณ์ของ Windows โปรดไปที่ที่เว็บไซต์ของ Microsoft ต่อไปนี้:
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
เมื่อคุณสร้างคอมโพเนนต์ด้วย Visual C++ คุณต้องไม่เลือกฐานข้อมูลโปรแกรมสำหรับ แก้ไข และ ดำเนินการต่อ สำหรับตัวเลือกคอมไพเลอร์ C++ แต่ให้เลือกฐานข้อมูลโปรแกรมแทน เมื่อต้องการตั้งค่าเส้นทางสัญลักษณ์ ให้ใช้งานตัวแปรสภาพแวดล้อมของ _NT_SYMBOL_PATH ไปยังเส้นทางที่จะใช้ คุณสามารถใช้เซิร์ฟเวอร์สัญลักษณ์ของ Microsoft เพื่อขอรับสัญลักษณ์สำหรับคอมโพเนนต์ของ Microsoft
311503 ใช้เซิร์ฟเวอร์สัญลักษณ์ของ Microsoft เพื่อขอรับแฟ้มสัญลักษณ์ตรวจแก้จุดบกพร่อง
ทำตามขั้นตอนเหล่านี้เพื่อตั้งค่าตัวแปรสภาพแวดล้อมของ _NT_SYMBOL_PATH:
  1. ในแผงควบคุม คลิกสองครั้งที่ ระบบ
  2. คลิกที่แท็บ ขั้นสูง แล้วคลิก ตัวแปรสภาพแวดล้อม
หรือคุณสามารถตั้งค่าตัวแปรสภาพแวดล้อมของ _NT_SYMBOL_PATH ในหน้าต่างคำสั่งก่อนเรียกใช้ UMDH

หมายเหตุ: นอกจากนี้ยังมีเส้นทางไปยัง PDB สำหรับคอมโพเนนต์ของแอปพลิเคชันของคุณ ตัวอย่างเช่น ให้ตั้งค่าเส้นทางสำหรับ _NT_SYMBOL_PATH ดังต่อไปนี้:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\myapplicationssymbols
ส่วนแรกของเส้นทางนี้ชี้ไปยังเซิร์ฟเวอร์สัญลักษณ์ของ Microsoft และระบุว่าสัญลักษณ์ที่นำมาใช้จะถูกดาวน์โหลดในโฟลเดอร์ c:\symbols ส่วนที่ตามหลังเครื่องหมายอัฒภาคคือเส้นทางไปยังแฟ้ม PDB (แฟ้มสัญลักษณ์) สำหรับแอปพลิเคชันที่มีการรั่วไหลโดยเฉพาะ

การเรียกใช้งาน UMDH

พารามิเตอร์บรรทัดคำสั่งเดียวที่จำเป็นสำหรับ UMDH คือตัวเลือก -p ซึ่งจะระบุ PID ของกระบวนการที่มีการถ่ายโอนฮีป สามารถรับ PID ได้โดยใช้ตัวจัดการงานหรือโปรแกรม Tlist.exe สำหรับคำสั่งคล้ายกับคำสั่งต่อไปนี้ บันทึกจะถูกถ่ายโอนไปยังผลลัพธ์มาตรฐาน:
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
นี่คือที่อยู่หน่วยความของการจัดสรรสำหรับ Callstack นั้น ถ้าตัวแก้จุดบกพร่องของคุณติดอยู่กับกระบวนการ คุณสามารถถ่ายโอนเนื้อหาของหน่วยความจำที่ที่อยู่เหล่านี้ได้เพื่อดูสิ่งที่ได้รับการจัดสรร

ถ้าบันทึกมีข้อมูลมากเกินไป บันทึกก็จะสามารถถูกจำกัดไว้เฉพาะสำหรับผู้ใช้ขนาดใหญ่ที่มีจำนวนการจัดสรรสูงกว่าเกณฑ์ขั้นต่ำที่กำหนด ใช้คำสั่งต่อไปนี้:
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 ซึ่งจะทำให้มีการพิมพ์หมายเลขแฟ้มและบรรทัดใน Callstack เมื่อใดก็ตามที่เป็นไปได้

ผลลัพธ์ UMDH ที่ได้รับการอธิบาย

หากคุณเปลี่ยนเส้นทางบันทึกไปยังแฟ้ม (umdh -p:PID -f:umdh.log) เนื้อหาก็จะมีลักษณะที่คล้ายกับเนื้อหาต่อไปนี้ซึ่งได้รับจากกระบวนการ Notepad ที่ทำงานอยู่:
UMDH: Logtime 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
   *********** Heap 00270000 Hogs ********************
   000001A0 ไบต์ในการจัดสรร 0x4 (@ 0x00000068) โดย: 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

   000001A0 ไบต์ในการจัดสรร 0x4 (@ 0x00000068) โดย: 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: Logtime 2000-06-28 12:43 - Machine=MyMachine - PID=1140 กำลังเชื่อมต่อ...การแจงนับโมดูลที่เสร็จสมบูรณ์ SymGetSymFromName(process, ntdll!RtlpStackTraceDataBase, xxx) ล้มเหลว LastError = 126 UmdhGetAddrFromName ไม่สามารถค้นหาตัวชี้การติดตาม DB (ntdllRtlpStackTraceDataBase) สัญลักษณ์ ntdll.dll ไม่ถูกต้อง เราต้องสามารถดูสัญลักษณ์ที่ไม่มีการนำเข้าได้
ใช้คำสั่งต่อไปนี้เพื่อตรวจสอบการตั้งค่าสำหรับกระบวนการที่คุณกำลังตรวจสอบอีกครั้ง:
gflags -i APPNAME
ใช้คำสั่งต่อไปนี้เมื่อคุณใช้การติดตามฮีปทั้งระบบ:
gflags -r
คำสั่งเหล่านี้จะแสดงรายการของค่าสถานะที่ตั้งไว้สำหรับแอปพลิเคชัน โปรดทราบว่าในกรณีของการติดตามสแตกทั้งระบบ คุณสมบัติดังกล่าวอาจปรากฏเป็นกำลังทำงานอยู่ แต่หากคุณไม่ได้เริ่มการทำงานของคอมพิวเตอร์ใหม่หลังจากเรียกใช้คำสั่ง gflags -r +ust คุณสมบัติดังกล่าวจะไม่ถูกเปิดใช้งานจริง หากคุณต้องการทราบทุกแอปพลิเคชันที่เปิดใช้งานการติดตามสแตก คุณสามารถดูคีย์ USTEnabled ภายใต้รีจิสทรีคีย์ต่อไปนี้ได้:
ตัวเลือกการดำเนินการแฟ้ม HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image
หากคุณเรียกใช้ UMDH บนกระบวนการที่มีการเปิดใช้งานการติดตามสแตก แต่คุณยังไม่ได้เริ่มแอปพลิเคชันใหม่ตั้งแต่ตอนที่คุณตั้งค่าสถานะ คุณอาจจะได้รับข้อความต่อไปนี้ในบันทึกของคุณ:
การติดตามสแตกไม่ถูกบันทึกสำหรับการจัดสรรนี้ (ดัชนี== 0)
ถ้าคุณเรียกใช้งานโดยไม่ตั้งค่าเส้นทางสัญลักษณ์ที่ถูกต้องหรือสัญลักษณ์ไม่ถูกต้อง และคุณเรียกใช้ UMDH คุณอาจได้รับข้อความแสดงข้อผิดพลาดในบันทึก อย่างไรก็ตาม คุณอาจได้รับ Callstacks ที่ไม่ถูกต้องหรือคลาดเคลื่อนเท่านั้น เพื่อเป็นการตรวจสอบว่าคุณมีสัญลักษณ์ที่ถูกต้อง ให้เริ่มตัวแก้จุดบกพร่องระบบ NTSD สำหรับกระบวนการ ตัวอย่างเช่น:
ntsd notepad
จากนั้นจากคอนโซลตัวแก้จุดบกพร่อง ให้เรียกใช้คำสั่ง LD เพื่อโหลดข้อมูลสัญลักษณ์สำหรับโมดูลและคำสั่ง LM เพื่อสร้างรายการว่าโมดูลใดมีการโหลดสัญลักษณ์แล้ว ถ้าผลลัพธ์ของคำสั่ง LM แสดงว่าสัญลักษณ์การส่งออกมีการโหลดแล้ว แสดงว่าสัญลักษณ์นั้นไม่ถูกต้อง ถ้าคุณได้โหลดสัญลักษณ์ PDB แล้ว แสดงว่าสัญลักษณ์นั้นถูกต้อง คุณอาจได้รับข้อความแสดงข้อผิดพลาดต่อไปนี้ถ้าคุณระบุ PID ไม่ถูกต้อง:
C:\>umdh -p:1000 UMDH: Logtime 2000-06-28 09:45 - Machine=MyMachine - PID=1000 กำลังเชื่อมต่อ... OpenProcess ล้มเหลว, LastError = 0x57

เรียก UMDH จาก Visual Basic

การถ่ายโอนบันทึกจำนวนหนึ่งเมื่อเวลาผ่านไปอาจมีประโยชน์ในบางครั้งเนื่องจากการรั่วไหลอาจไม่สังเกตได้อย่างชัดเจนในตอนแรก ตัวอย่างเช่น หากคุณสงสัยว่าแอปพลิเคชันบนเว็บ Active Server Pages (ASP) ของคุณรั่วไหลหน่วยความจำหรือไม่ การเขียนคอมโพเนนต์ COM ใน Visual Basic ที่ทำการ Shell Out ไปยัง UMDH อาจจะเป็นประโยชน์ จากนั้น คุณจะสามารถเรียกคอมโพเนนต์จากเพจ ASP ของคุณได้

ต่อไปนี้เป็นรหัส Visual Basic บางอย่างที่เรียก UMDH และสร้างแฟ้มบันทึกที่อยู่บนพื้นฐานของเวลาปัจจุบัน:
ฟังก์ชันการประกาศส่วนตัว GetCurrentProcessId Lib "kernel32" ()เป็นระยะเวลานาน
      ฟังก์ชันสาธารณะ GetProcessID()
      GetProcessID = GetCurrentProcessId()
      จบฟังก์ชัน  
   .
   .
   .
      Dim strTime As String

      Dim sProcID As String
      sProcID = GetProcessID()
      strTime = "MYLOG_" & Format(Now(), "hhmm")
     
      เชลล์ (" C:\UMDH\umdh-p: " & sProcID & " -f:d:\logs\ " & strTime & ".txt")
				

ใช้ UMDH กับ Windows NT 4.0 Service Pack 6a (SP6a)

โปรแกรมอรรถประโยชน์ UMDH ที่มาพร้อมกับเครื่องมือตรวจแก้จุดบกพร่องสำหรับผลิตภัณฑ์ Windows ไม่ทำงานบน Windows NT 4.0 แฟ้มที่สั่งงานได้แบบมีการแตกด้วยตัวเอง (Umdhnt4tools.exe) จะรวมอยู่ในบทความนี้ และมีเครื่องมือต่อไปนี้เพื่อการใช้งานกับ NT 4.0:
  • Umdh_nt4.exe และ Dbghelp.dll
    นี่คือโปรแกรมอรรถประโยชน์ UMDH รุ่น Windows NT 4.0 SP6
  • Dhcmp.exe
    โปรแกรมอรรถประโยชน์นี้จะใช้ในการเปรียบเทียบการถ่ายโอนข้อมูล UMDH สองรายการเพื่อกำหนดตำแหน่งหน่วยความจำอาจมีการรั่วไหล
แฟ้มต่อไปนี้สามารถดาวน์โหลดได้จาก Microsoft Download Center:
ยุบรูปภาพนี้ขยายรูปภาพนี้
ดาวน์โหลด
ดาวน์โหลด Umdhnt4tools.exe เดี๋ยวนี้
วันที่ออก: 28 สิงหาคม 2545

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการดาวน์โหลดแฟ้มสนับสนุนของ Microsoft ให้คลิกที่หมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base:
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 จะไม่เปรียบเทียบแฟ้มบันทึก ตัวอย่างเช่น คุณไม่สามารถทำต่อไปนี้ได้:
UMDH_NT4 dh1.log dh2.log > cmp12.txt
แต่คุณต้องใช้โปรแกรมอรรถประโยชน์ Dhcmp.exe ที่มีอยู่ในบทความนี้แทน คำสั่งจะมีลักษณะคล้ายคำสั่งต่อไปนี้:
DHCMP dh1.log dh2.log > cmp12.txt

คุณสมบัติ

หมายเลขบทความ (Article ID): 268343 - รีวิวครั้งสุดท้าย: 30 สิงหาคม 2556 - Revision: 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
Keywords: 
kbdownload kbarttypeshowme kbfile kbgraphxlinkcritical kbhowto kbsample KB268343

ให้ข้อเสนอแนะ

 

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