วิธีการใช้ Pageheap.exe ใน Windows XP, Windows 2000 และ Windows Server 2003

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

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

สรุป

บทความนี้อธิบายวิธีการใช้ฮีปหน้าเครื่องมือ (Pageheap.exe) ใน Microsoft Windows XP, Microsoft Windows 2000 และ Microsoft Windows Server 2003

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

Pageheap.exe เป็นการตั้งค่าสถานะฮีปหน้าซึ่งช่วยให้การค้นหาความเสียหายฮีปเกี่ยวข้อง นอกจากนี้คุณสามารถช่วยตรวจหา leaks ในโปรแกรมที่ทำงานบน Windows 2000 Professional Service Pack 2 (SP2) และระบบของ Windows XP Professional

Pageheap.exe กับซอฟต์แวร์ตรวจสอบชั้น (หน้า Heap manager) ระหว่างแอพลิเคชันและระบบที่สามารถตรวจสอบการดำเนินงานหน่วยความจำแบบไดนามิกทั้งหมดที่แนะนำ (การปันส่วน เพิ่ม และการดำเนินการอื่น ๆ ของฮีป) เมื่อมีการเปิดใช้หน้า Heap manager แอพลิเคชันที่จะมีการทดสอบไม่เริ่มทำงานภายใต้ดีบักเกอร์ที่แล้ว หากเกิดปัญหา มันจะทำให้ตัวแบ่งการดีบักเกอร์

สิ่งสำคัญPageheap.exe ไม่ได้ระบุจุดบกพร่องคืออะไร แต่มันจะล้มเหลวระบบเมื่อเกิดปัญหา จะเปิดใช้งานชั้นของการตรวจสอบที่มีอยู่แล้วในไลบรารี Ntdll.dll ระบบใน Windows 2000 Professional SP2 และ Windows XP Professional Pageheap.exe จะไม่ทำงานบน Microsoft Windows รุ่นก่อนหน้านี้

มีถ้าแอพลิเคชันที่กำลังทดสอบไม่เริ่มทำงานภายใต้การดีบัก และพบกับปัญหาที่เกิดขึ้น มันจะเพียงแค่ปัญหา โดยไม่มีความคิดเห็นใด ๆ

แนวคิด

ปัญหาที่พบโดยทั่วไปในการพัฒนาโปรแกรมประยุกต์มีความเสียหายฮีป ซึ่งโดยปกติจะเกิดเมื่อโปรแกรมประยุกต์การจัดสรรบล็อกของหน่วยความจำฮีปของขนาดที่กำหนด และเขียนไปยังที่อยู่หน่วยความจำเกินกว่าขนาดที่ร้องขอของบล็อกฮีป ความเสียหายฮีปสามารถยังเกิดขึ้นเมื่อโปรแกรมประยุกต์เขียนไปยังบล็อกของหน่วยความจำที่มีอยู่แล้วลง

แนวคิดที่สองคือศูนย์กลางการทำความเข้าใจเกี่ยวกับคำสั่งที่เกี่ยวข้องกับ Pageheap.exe และวิธีการใช้:
  • corruptions ในบล็อกท็อปฮีปถูกค้นพบได้ โดยการอย่างใดอย่างหนึ่งทำหน้าที่ไม่สามารถเข้าถึงส่วนท้ายของการปันส่วน หรือ โดยการตรวจสอบรูปแบบเติมเมื่อมีการบล็อกอยู่ลง
  • มีสอง heaps (full-page ฮีปและหน้าปกติ heap) สำหรับแต่ละฮีปที่สร้างขึ้นภายในกระบวนการที่มีเพฮีปที่เปิดใช้งาน
    • ท็อปฮีป full-pagereveals corruptions ในบล็อกฮีป โดยทำหน้าที่ไม่สามารถเข้าถึงส่วนท้ายของการปันส่วน ประโยชน์ของวิธีการนี้ไม่ว่า คุณได้รับ "sudden death หมายความ ว่า กระบวนการที่จะเข้าถึง violate (AV) เท่านั้นที่อยู่ point เกิดความล้มเหลว ลักษณะการทำงานนี้ทำล้มเหลวง่ายต่อการตรวจแก้จุดบกพร่อง disadvantage ที่ถูกปันส่วนทั้งหมดใช้หน่วยความจำที่ยอมรับอย่างน้อยหนึ่งหน้า หมดสำหรับการประมวลผลหน่วยความจำสูง ทรัพยากรระบบสามารถเป็นได้อย่างรวดเร็วแล้ว
    • เพปกติฮีปสามารถใช้ในสถานการณ์ที่ข้อจำกัดของหน่วยความจำแสดงกระแสฮีป full-page ไม่สามารถใช้งาน ทำการตรวจสอบรูปแบบการเติมเมื่อบล็อกท็อปฮีปคือลง ข้อดีของวิธีนี้คือ ว่า มัน drastically ลดปริมาณการใช้หน่วยความจำ disadvantage ที่ถูกว่า corruptions จะเท่านั้นถูกตรวจพบเมื่อมีการบล็อกอยู่ลง ซึ่งทำให้ความล้มเหลวยากขึ้นเพื่อตรวจแก้จุดบกพร่อง

ดาวน์โหลดที่ตั้งสำหรับเครื่องมือการ Pageheap

เมื่อต้องการดาวน์โหลดแพคเกจเครื่องมือการตรวจแก้จุดบกพร่องล่าสุด คลิกการเชื่อมโยงต่อไปนี้:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx


เลือกเครื่องมือการตรวจแก้จุดบกพร่องรุ่นล่าสุด เมื่อคุณติดตั้งเครื่องมือ เลือกนั้นกำหนดเองการติดตั้ง และติดตั้งแล้วกับไดเรกทอรีด้วยชื่อที่เหมาะสม ตัวอย่างเช่น ติดตั้งถึงเครื่องมือเพื่อ C:\Debug หรือ C:\Debugtools

เลือกวิธีการการตรวจสอบ Corruptions บล็อกฮีป

สูงสุด corruptions ในบล็อกท็อปฮีปสามารถถูกค้นพบในหนึ่งในสองวิธี:
  • ท็อปฮีป full-page: ทำหน้าที่ไม่สามารถเข้าถึงส่วนท้ายของการปันส่วนไว้
  • หน้าปกติท็อปฮีป: ตรวจสอบเติม patterns เมื่อมีการบล็อกได้ลง

ฮีป full-Page

ท็อปฮีป full-page ควรถูกเปิดใช้งาน สำหรับแต่ละกระบวน หรือภาย ใต้พารามิเตอร์ที่จำกัดสำหรับการประมวลผลที่มีขนาดใหญ่ เนื่องจากข้อกำหนดของหน่วยความจำสูงสุดของงาน คุณไม่สามารถถูกเปิดใช้งานทั้งระบบ เนื่องจากเป็นการยากที่ประเมินขนาดของแฟ้มเพที่จำเป็นต้อง การใช้แฟ้มเพจที่มีขนาดเล็กเกินไปกับฮีป full-page ของทั้งระบบ renders ระบบ unbootable

ประโยชน์ของท็อปฮีป full-page คือการ ที่จะทำให้กระบวนการการเข้าถึง violate (AV) เท่านั้นที่อยู่ point เกิดความล้มเหลว ซึ่งทำให้เกิดความล้มเหลวง่ายต่อการตรวจแก้จุดบกพร่อง เพื่อให้สามารถ pinpoint ล้มเหลว ก่อน ใช้ฮีปหน้าปกติเพื่อกำหนดช่วงที่กระบวนการที่มีความล้มเหลว แล้ว ใช้ฮีป full-page บนแต่ละกระบวน large-scale สำหรับคลาสนั้นจำกัดของการปันส่วน (นั่นคือ ช่วงที่มีขนาดเฉพาะหรือไลบรารีที่ระบุ)

ฮีปหน้าปกติ

Normal page heap can be used for the testing of large-scale processes without the high memory consumption that full-page heap requires. However, normal page heap delays detection until blocks are freed, thus making failures more difficult to debug.

In general, use normal page heap for initial large-scale processes testing. Then, if problems are detected, enable full-page heap for a restricted class of allocations in those processes.

Normal page heap can be safely enabled system-wide for all processes. This is very useful on test benches that perform general system validation, rather than component focused testing. Normal page heap can also be enabled for a single process.

Using GFlags with System-Wide Page Heap

กระบวนการGFlagstool is used to enable system-wide page heap. In order for a GFlags command to take effect, you must restart your computer after you issue the command.

To enable system-wide normal page heap:
  1. Type the following at the command line:gflags -r +hpa

  2. รีสตาร์ทเครื่องคอมพิวเตอร์
To disable system-wide normal page heap:
  1. Type the following at the command line:gflags -r -hpa

  2. รีสตาร์ทเครื่องคอมพิวเตอร์
หมายเหตุ:No other GFlags settings are useful when you enable page heap. If other settings that appear to be related to the heap are enabled, then page heap bugs can be introduced due to conflicts between page heap manager and these "harmless" heap flags.

Using GFlags With a Single Process Page Heap

You can enable the page heap to monitor one specific process. To do this, follow these steps:
  1. At a command prompt, change the directory where you installed the debug tools.
  2. At the command prompt, type the following, and then press ENTER:
    Gflags.exe /p /enablelsass.exe
    หมายเหตุ:lsass.exestands for the name of the process that you want to monitor with the Pageheap tool.
  3. When you no longer need page heap monitoring, disable the monitoring. To do this, type the following at a command prompt, and then press ENTER:
    Gflags.exe /p /disablelsass.exe
    หมายเหตุ:lsass.exestands for the name of the process that you want to monitor with the Pageheap tool.
  4. To list all programs that currently have Pageheap verification enabled, type the following at a command prompt, and then pressป้อน:
    Gflags.exe /p

Unaligned Allocations

The Windows heap managers (all versions) have always guaranteed that the heap allocations have a start address that is 8-byte aligned (on 64-bit platforms the alignment is 16-bytes). The page heap manager makes the same guarantee. This is impossible, however, if you want to have the end-of-the-allocation exactly at the end of a page. The exact end-of-page allocation is needed so that an off-by-one-byte error will trigger a read or write into the non-accessible page and cause an immediate fault.

If the user-requested size for the block is not 8-byte aligned, then page heap cannot meet both the "start address 8-byte aligned" and the "end address page aligned" constraints. The solution is to meet the first constraint and make the start of the block 8-byte aligned. Then use a small fill pattern between the end of the block and the start of the non-accessible page. This fill pattern can be from 0 bytes through 7 bytes in length on 32-bit architectures. The fill pattern is checked upon free.

If immediate fault detection is needed for these allocations that otherwise will have a fill pattern at the end, make the page heap manager ignore the 8-byte alignment rule, and always align the end of the allocation at a page boundary by using the/unalignedและ/fullparameters. สำหรับข้อมูลเพิ่มเติม ให้ดู/unalignedพารามิเตอร์

หมายเหตุ:: Some programs make assumptions about 8-byte alignment and they stop working correctly with the/unalignedพารามิเตอร์ Microsoft Internet Explorer is one such program.

Uncommitted Pages for Full-Page Heap Allocations

The core full-page heap implementation commits two pages for any allocation smaller than one page. One page is used for the user allocation, and the other is made non-accessible at the end of the buffer.

จุดสิ้นสุดของบัฟเฟอร์ overruns สามารถตรวจพบ โดยการใช้เขตพื้นที่ที่มีการเสมือนสำรอง แทนหน้าที่กำหนดให้ไม่สามารถเข้าถึงได้ มีข้อยกเว้นการละเมิดการเข้าถึงเกิดขึ้นเมื่อกระบวนการ touches เนื้อที่เสมือนที่สงวนไว้ วิธีการนี้สามารถลดปริมาณการใช้หน่วยความจำ โดยถึง 50 เปอร์เซ็นต์ สำหรับข้อมูลเพิ่มเติม ให้ดู/ decommitพารามิเตอร์

Injection ข้อบกพร่อง

คุณสามารถควบคุมหน้า heap manager เพื่อให้การปันส่วนบางส่วนโดยเจตนาจะล้มเหลว ซึ่งเป็นประโยชน์ในการจำลองเงื่อนไขหน่วยความจำเหลือน้อยโดยไม่ได้ ใช้ทรัพยากรระบบทั้งหมด

ระบุหมายเลขตั้งแต่ 1 ถึง 10000 แสดงถึงความน่าเป็นที่การปันส่วนจะล้มเหลว ใช้ความน่าเป็น 10000 แน่ใจว่า 100 เปอร์เซ็นต์ของการปันส่วนจะล้มเหลว ความน่าเป็นของ 2,000 ระบุว่า ประมาณ 20 เปอร์เซ็นต์ของการปันส่วนจะล้มเหลว

เพ heap manager จะระมัดพิเศษเพื่อหลีกเลี่ยงข้อบกพร่อง injection ในทั้งสองแบบแรก 5 วินาทีของอายุการใช้งานของกระบวนการ และ Windows NT เส้นทางรหัสตัวโหลด (ตัวอย่าง exampole, LoadLibrary, FreeLibrary) ถ้า 5 วินาทีไม่เพียงพอเพื่ออนุญาตการประมวลผลของคุณเพื่อเริ่มต้นการทำให้เสร็จสมบูรณ์ จากนั้นคุณสามารถระบุการหมดเวลานานกว่าที่ตำแหน่งเริ่มต้นของกระบวนการ สำหรับข้อมูลเพิ่มเติม ให้ดู/faultพารามิเตอร์

เมื่อคุณใช้การ/faultพารามิเตอร์และกระบวนการในการทดสอบได้เป็นจุดบกพร่อง ข้อยกเว้นจะถูกยกกำลัง โดยทั่วไป เหตุผลสำหรับการนี้จะให้การดำเนินการ allocate ส่งกลับค่า NULL เป็น และโปรแกรมประยุกต์ในภายหลังคุณได้พยายามเข้าถึงหน่วยความจำที่ปันส่วน เนื่องจาก allocate ล้มเหลว อย่างไรก็ตาม ไม่สามารถเข้าถึงหน่วยความจำ และดังนั้น เกิดการละเมิดการเข้าถึง

เหตุผลอื่น ๆ ที่ว่า ข้อยกเว้นยกกำลังคือ ว่า ความพยายามที่จัดการกับความล้มเหลวในการปันส่วนโปรแกรมประยุกต์ ไม่ แต่ไม่ปล่อยบางทรัพยากร manifests เป็นหน่วยความจำรั่ว และเป็นการยากต่อการตรวจแก้จุดบกพร่อง

เพื่อที่ช่วยวิเคราะห์ความล้มเหลวเหล่านี้ หน้า heap manager จะประวัติของกองซ้อนสืบจากปัจจุบันของความบกพร่อง injection ข้อมูลเหล่านี้สามารถแสดงผล ด้วยคำสั่งการดีบักเกอร์ต่อไปนี้:

! heap -p -f [หมายเลขความสืบ]

โดยค่าเริ่มต้น ส่วนขยายจะแสดงข้อมูลที่สี่ล่าสุดเท่านั้น

แนบการดีบักเกอร์โดยอัตโนมัติเมื่อเริ่มการทำงานในแอพลิเคชัน

โปรแกรมประยุกต์บางโปรแกรมได้ยากที่เริ่มการทำงานจากพรอมต์คำสั่ง หรือพวกเขาจะ spawned จากกระบวนการอื่น สำหรับโปรแกรมประยุกต์เหล่านี้ ระบุว่า ทุกครั้งที่พวกเขาจะเริ่มต้น การดีบักเกอร์จะโดยอัตโนมัติถูกแนบไปกับแฟ้มเหล่านั้น ซึ่งเป็นประโยชน์ถ้าฮีปเพจที่ถูกเปิดใช้งานสำหรับว่า กระบวนการและท็อปฮีปล้มเหลวเกิดขึ้น สำหรับข้อมูลเพิ่มเติม ให้ดู/debugพารามิเตอร์

Pageheap.exe จะมีผลบังคับใช้เมื่อใช้การตรวจสอบการมีกระบวนการจัดสรรหน่วยความจำ รวมทั้งลักษณะ c ++ การปันส่วนใหม่และลบ เป็นเวลานาน ตามฟังก์ชันแบบกำหนดเองปันส่วน/ว่างจนเรียกเข้า NT heap อินเทอร์เฟซการจัดการ (นั่นคือ RtlAllocateHeap, RtlFreeHeap) ฟังก์ชันต่อไปนี้จะมีการทำการ:
  • ฟังก์ชันต้องHeapAlloc,HeapFree,HeapReAlloc: ฟังก์ชันเหล่านี้จะมีการส่งออก โดย kernel32.dll และโทรโดยตรงไปยังอินเทอร์เฟซฮีป NT ฟังก์ชันต้องGlobalAlloc,GlobalFree,GlobalReAlloc: ฟังก์ชันเหล่านี้ส่งออก โดย kernel32.dll และโทรโดยตรง หรือโดยทางอ้อมในอินเทอร์เฟซฮีป NT
  • ฟังก์ชันต้องLocalAlloc,LocalFree,LocalReAlloc: ฟังก์ชันเหล่านี้ส่งออก โดย kernel32.dll และโทรโดยตรง หรือโดยทางอ้อมในอินเทอร์เฟซฮีป NT
  • ฟังก์ชันmalloc,ว่าง,realloc,msize,ขยาย: ฟังก์ชันเหล่านี้ส่งออก โดย msvcrt.dll และโทรโดยตรง หรือโดยทางอ้อมในฮีป NT ซึ่งไม่เสมอได้ในกรณีที่ต้องการ C รันเวลาที่ใช้เพื่อให้มีการใช้งานฮีปที่แตกต่างกัน แต่เรียกทำ C ที่ปัจจุบันลงในฮีป NT โดยตรง
  • ตัวดำเนินการใหม่,ลบ,[] ใหม่,ลบ[]: ฟังก์ชันเหล่านี้ส่งออก โดย msvcrt.dll และโทรโดยตรง หรือโดยทางอ้อมในฮีป NT
ชุดอื่นที่ปันส่วน/ว่างของฟังก์ชันเป็นชุดรูปแบบที่กำหนดเอง และไม่มีการเรียกใช้โดยตรง หรือโดยทางอ้อมใน NT อาจฮีป แหล่งตรวจสอบรหัสเท่านั้น หรือทำงานภายใต้ดีบักเกอร์สามารถเปิดเผยการใช้งานจริง

หลีกเลี่ยงการใช้การเชื่อมโยงแบบคงที่ โปรแกรมประยุกต์บางโปรแกรมได้รันไทม์ C รุ่นที่ถูกเชื่อมโยงกับข้อความเก่า statically รุ่นที่เก่าเหล่านี้ไม่เรียกใช้ Windows NT ฮีป APIs และ Pageheap.exe ไม่สามารถใช้ในการตรวจสอบการปันส่วนเหล่านี้ การเชื่อมโยงแบบไดนามิกแน่ใจว่า คุณได้รับการไลบราล่าสุดของรันไทม์ C (msvcrt.dll)

คลาสที่ของของที่พบ โดย Pageheap.exe

Pageheap.exe บักที่เกี่ยวข้องฮีปส่วนใหญ่ที่ตรวจพบ อย่างไรก็ตาม focused บนปัญหาความเสียหายฮีป และไม่ focused leaks Pageheap.exe ได้จำกัดสำเร็จ ด้วยการค้นหา leaks ฮีป ถึงแม้ว่ามีหน้าที่การใช้งานการแสดงนี้

ข้อดีของ Pageheap.exe อย่างใดอย่างหนึ่งคือว่า ข้อผิดพลาดจำนวนมากจะตรวจพบเมื่อพวกเขาอาจเกิดขึ้น ตัวอย่างเช่น ข้อผิดพลาดเศษตามแบบหนึ่งไบต์ในตอนท้ายของบัฟเฟอร์ที่มีการปันส่วนแบบไดนามิกอาจทำให้เกิดการละเมิดการเข้าถึงการโต้ตอบแบบทันที มีข้อผิดพลาดที่ไม่ถูกตรวจพบเมื่อมันเกิดขึ้นบางชนิด ในกรณีเหล่านั้น รายงานข้อผิดพลาดถูกเลื่อนออกจนกว่าการบล็อกอยู่ลง
  • ตัวชี้ฮีปไม่ถูกต้อง: อินเทอร์เฟซท็อปฮีประดับ Win32 และ Windows NT ทั้งหมดสำหรับใช้เป็นพารามิเตอร์ตัวแรกตัวชี้ไปฮีปซึ่งการดำเนินการที่จะเกิดขึ้น เพ heap manager ตรวจพบการชี้ฮีปไม่ถูกต้องในที่ทำการโทร
  • ตัวชี้บล็อกฮีปไม่ถูกต้อง: After a block is allocated, it can be used as a parameter for several heap interfaces, notably the free() class of interfaces. The page heap manager immediately detects an invalid heap block pointer. See Debugging Page Heap Failures for a way to determine if the invalid address is a few bytes off, or is completely incorrect.
  • Multithreaded unsynchronized access to the heap: Some applications call into a heap from multiple threads. This type of scenario requires setting a flag (by the user) which will trigger acquiring a heap lock. The page heap manager will detect this type of violation when two threads attempt to call simultaneously into the heap.
  • Assumptions about reallocation of a block at the same address: A reallocation operation is not guaranteed to return the same address. This is especially true when the reallocation reduces the size of the block. Some applications assume that reallocation will return the same address. The page heap manager always allocates a new block during a reallocation and frees the old block. The free block is protected for read/write access, and therefore any access to it will raise an access violation.
  • Double free: This bug, where the same heap blocks are freed several times, is common in some applications. This is detected immediately by the page heap manager because, on the second free, the block will not have the proper prefix header and cannot be found among the allocated blocks. See Debugging Page Heap Failures for ways to analyze the stack trace of the first free operation. This error can be a variant of the reallocation problem because, when the application frees what it thinks it is the address of the block, that block was already freed as part of the reallocation.
  • Access of block after free: Freed memory blocks are kept for a short time by the page heap manager in a pool of protected memory. Any access to those blocks will raise an access violation. Based on the "locality" principle, most of the problems should be caught if the free protected pool is large enough. If the freed block is still in the protected pool, the bug is caught instantly. However, if the memory was reused, then there is less chance of finding the bug or identifying the code that caused it.
  • Access after the end of allocated block: The page heap manager places an inaccessible page immediately following the allocated block. Any access past the end of the block will raise an access violation. Some applications expect allocations to be 8-byte aligned. This feature has been supported since Windows NT 3.5 heap managers. A request size that is not 8-byte aligned will still get an 8-byte aligned address, but this leaves a few bytes after the end of the block that are still accessible. If the application corrupts only those few bytes, then the error will be caught only by checking the block suffix pattern when the block is freed.
  • Access before the start of allocated block: The page heap manager can be instructed through a settable flag to place the inaccessible page at the beginning of the block, rather than at the end. Any access before the start of the block will raise an access violation.
ยุบตารางนี้ขยายตารางนี้
Failureเพปกติฮีปท็อปฮีป full-page
Invalid heap pointerCaught instantlyCaught instantly
ตัวชี้บล็อกฮีปไม่ถูกต้องพบทันทีพบทันที
การเข้าถึง unsynchronizedพบทันทีพบทันที
assumption เกี่ยวกับ reallocation อยู่90% จนกว่าว่างจริง% 90 พบทันที
สองฟรี% 90 พบทันที% 90 พบทันที
นำมาใช้ใหม่หลังจากได้ฟรี90% จนกว่าว่างจริง% 90 พบทันที
หลังจากจุดสิ้นสุดของบล็อกการเข้าถึงพบเมื่อข้อความอิสระพบทันที
ก่อนที่จะเริ่มต้นของบล็อกการเข้าถึงพบเมื่อข้อความอิสระพบทันที (ค่าสถานะพิเศษ)

ความล้มเหลวท็อปฮีปหน้าตรวจแก้จุดบกพร่อง

สำหรับข้อมูลเพิ่มเติมบนความดีบักการล้มฮีปหน้าเหลว โปรดดูที่ข้อมูลอ้างอิง Tookit ความเข้ากันได้ของโปรแกรมประยุกต์พร้อมใช้งานอยู่ภายในของความเข้ากันได้ของโปรแกรมประยุกต์ Toolkit

สำหรับการไวยากรณ์ของ Pageheap.exe และตัวอย่างการใช้ Pageheap.exe โปรดดูที่ข้อมูลอ้างอิง Tookit ความเข้ากันได้ของโปรแกรมประยุกต์พร้อมใช้งานอยู่ภายในของความเข้ากันได้ของโปรแกรมประยุกต์ Toolkit

สำหรับข้อมูลเพิ่มเติมโปรดดูบทความฐานความรู้ของ Microsoft ต่อไปนี้:
294895วิธีการขอรับ Toolkit ความเข้ากันได้ของโปรแกรมประยุกต์ Windows

คุณสมบัติ

หมายเลขบทความ (Article ID): 286470 - รีวิวครั้งสุดท้าย: 8 มกราคม 2554 - Revision: 2.0
ใช้กับ
  • Microsoft Windows Server 2003 Standard Edition
  • Microsoft Windows Server 2003 Enterprise Edition
  • Microsoft Windows Server 2003 Datacenter Edition
  • Microsoft Windows XP Professional Edition
  • Microsoft Windows XP Home Edition
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
Keywords: 
kbenv kbinfo kbmt KB286470 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:286470

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

 

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