2011-03-31 36 views
10

Tôi đã cài đặt WinDBG từ 7.1 Windows SDK. Sau đó, với VC++ 2008, tôi đã tạo một chương trình 'CleanPayload.exe' không chứa gì ngoài một 'chính' và một lời gọi đến một hàm cố tình chứa một lỗi. Nó là một phiên bản phát hành bao gồm các biểu tượng gỡ lỗi. Tôi đã mở chương trình đó vào WindDBG và sau đóSử dụng WinDBG để xác định chức năng bị lỗi

  1. đã làm một số .sympath+ để chỉ ra nơi PDB là cho chương trình đó.
  2. đã làm một ld * để tải tất cả các ký hiệu
  3. đã làm một số lm để xác minh tất cả các biểu tượng đã được tải (biểu tượng riêng cho chương trình của tôi, biểu tượng công cộng cho thư viện Windows).

Sau đó, tôi chạy chương trình và nó đã ném ngoại lệ đầu tiên, được mong đợi. Như sau:

(910.12a0): WOW64 breakpoint - code 4000001f (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 
ntdll32!LdrpDoDebuggerBreak+0x2c: 
771e0f2b cc    int  3 

Nhưng khi tôi yêu cầu WinDBG hiển thị cho tôi ngăn xếp, nó không hiển thị cho tôi bất kỳ chương trình nào của tôi 'CleanPayload.exe'. Thay vào đó, nó cho tôi thấy điều này:

0:000:x86> kb 
ChildEBP RetAddr Args to Child    
004bf5ec 771c122b 7efdd000 7efde000 7724206c ntdll32!LdrpDoDebuggerBreak+0x2c 
004bf764 77192187 004bf7d8 77140000 7c185e6a ntdll32!LdrpInitializeProcess+0x132f 
004bf7b4 77179e89 004bf7d8 77140000 00000000 ntdll32!_LdrpInitialize+0x78 
004bf7c4 00000000 004bf7d8 77140000 00000000 ntdll32!LdrInitializeThunk+0x10 

Tôi cần làm gì để hiển thị cho tôi một dấu vết ngăn xếp (1) bao gồm chương trình của tôi và (2) chức năng ngoại lệ được ném?

Cập nhật Tôi đi theo đề nghị của Larry, chạy quá khứ ngoại lệ đầu tiên, và có kết quả như sau:

0:000:x86> g 
ntdll!NtTerminateProcess+0xa: 
00000000`76faf97a c3    ret 
0:000> kb 
RetAddr   : Args to Child               : Call Site 
00000000`74c6601a : 00000000`00000000 00000000`000de600 00000000`000ddc80 00000000`74c60304 : ntdll!NtTerminateProcess+0xa 
00000000`74c5cf87 : 00000000`0030f988 00000000`0030dba8 00000000`7efdb000 00000000`0030f934 : wow64!whNtTerminateProcess+0x46 
00000000`74be276d : 00000000`77150190 00000000`74c50023 00000000`00000000 00000000`0030fab8 : wow64!Wow64SystemServiceEx+0xd7 
00000000`74c5d07e : 00000000`00000000 00000000`74be1920 00000000`000de820 00000000`76f93501 : wow64cpu!TurboDispatchJumpAddressEnd+0x24 
00000000`74c5c549 : 00000000`00000000 00000000`00000000 00000000`74c54ac8 00000000`7ffe0030 : wow64!RunCpuSimulation+0xa 
00000000`76faae27 : 00000000`004a3100 00000000`00000000 00000000`7707a1e0 00000000`7efdf000 : wow64!Wow64LdrpInitialize+0x429 
00000000`76fa72f8 : 00000000`00000000 00000000`76fa8641 00000000`76fb84e0 00000000`00000000 : ntdll!LdrpInitializeProcess+0x1780 
00000000`76f92ace : 00000000`000df1b0 00000000`00000000 00000000`7efdf000 00000000`00000000 : ntdll! ?? ::FNODOBFM::`string'+0x2af20 
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe 

Do đó, không may, tôi vẫn không thấy có liên quan thông tin stack trace. Tôi cũng đã thử lệnh .effmach x86, trước các bước ở trên và dường như không có tác động. Ngẫu nhiên, tôi cũng đã thực hiện lại toàn bộ bài kiểm tra với trình kiểm tra ứng dụng được kích hoạt cho chương trình đích mà tôi đang thử nghiệm. Tôi nhận được kết quả rất mâu thuẫn:

0:000> g 
ModLoad: 00000000`76d40000 00000000`76e5f000 WOW64_IMAGE_SECTION 
ModLoad: 00000000`74f90000 00000000`75090000 WOW64_IMAGE_SECTION 
ModLoad: 00000000`76d40000 00000000`76e5f000 NOT_AN_IMAGE 
ModLoad: 00000000`76e60000 00000000`76f5a000 NOT_AN_IMAGE 
ModLoad: 00000000`71160000 00000000`711c0000 C:\Windows\syswow64\verifier.dll 
Page heap: pid 0x1A54: page heap enabled with flags 0x3. 
AVRF: CleanPayload.exe: pid 0x1A54: flags 0x80643027: application verifier enabled 
ModLoad: 00000000`71130000 00000000`7115b000 C:\Windows\SysWOW64\vrfcore.dll 
ModLoad: 00000000`710d0000 00000000`71128000 C:\Windows\SysWOW64\vfbasics.dll 
ModLoad: 00000000`74f90000 00000000`75090000 C:\Windows\syswow64\kernel32.dll 
ModLoad: 00000000`76830000 00000000`76876000 C:\Windows\syswow64\KERNELBASE.dll 
ModLoad: 00000000`715c0000 00000000`7164e000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCP90.dll 
ModLoad: 00000000`73dc0000 00000000`73e63000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.dll 
(1a54.17dc): WOW64 breakpoint - code 4000001f (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 
ntdll32!LdrpDoDebuggerBreak+0x2c: 
771e0f2b cc    int  3 

0:000:x86> !avrf 
************************************************************************* 
***                 *** 
***                 *** 
*** Your debugger is not using the correct symbols     *** 
***                 *** 
*** In order for this command to work properly, your symbol path *** 
*** must point to .pdb files that have full type information.  *** 
***                 *** 
*** Certain .pdb files (such as the public OS symbols) do not  *** 
*** contain the required information. Contact the group that  *** 
*** provided you with these symbols if you need this command to *** 
*** work.               *** 
***                 *** 
*** Type referenced: wow64!_TEB32         *** 
***                 *** 
************************************************************************* 
Application verifier is not enabled for this process. 
Use appverif.exe tool to enable it. 

Thực hiện ở trên nói AVRF: Cleanpayload.exe ... application verifier enabled, cho biết rằng nó bị khóa cho mục tiêu. Nhưng sau đó lệnh !avrf tiếp theo cho thấy rằng các biểu tượng gỡ lỗi là xấu, mặc dù lệnh lm cho biết tất cả chúng đều được tải đúng cách! Điều gì trên trái đất đang xảy ra ở đây?

+0

bạn có tìm ra lý do ngoại lệ không? –

Trả lời

11

Bạn đang chạy phiên bản 64 bit của windbg và ứng dụng 32 bit. Điểm ngắt đầu tiên đang chạy trong mã 64bit.

Nếu bạn nhấn "g", bạn nên nhấn điểm ngắt ban đầu cho ứng dụng 32 bit, bạn sẽ có thể đi từ đó.

Để chuyển từ 64bit gỡ lỗi để 32bit gỡ lỗi (nếu bạn nhấn tổ hợp phím CTRL-C chẳng hạn), gõ vào:

.effmach x86 

mà sẽ chuyển đổi các chương trình gỡ rối từ chế độ 64bit sang chế độ 32bit.

+0

Rõ ràng, 32 bit debuggin trong 64 bit WinDBG là một nửa vấn đề. Một nửa còn lại là tìm các biểu tượng gỡ lỗi thích hợp cho chương trình 32 bit. Lưu ý cuộc thảo luận này: 'http: // www.eggheadcafe.com/software/aspnet/29430292/teb32-and-peb32-type-info-missing-từ-public-wow64pdb.aspx'. Điều đó nói rằng, nếu tôi đang gỡ lỗi một ứng dụng 64 bit, để làm cho 'ứng dụng xác minh' hạnh phúc, tôi phải chắc chắn để đặt 'c: \ windows \ system32' trong đường dẫn biểu tượng trước khi 'srv *'. –

+0

Tốt nhất, tôi cũng quên vấn đề đường dẫn biểu tượng. –

+0

@LO: Bạn có thể giải thích thêm một chút được không? Bạn có ý nghĩa gì bởi điểm ngắt đầu tiên nằm trong mã 64bit? Cụ thể, bạn có thể so sánh nó với cùng một kịch bản dưới windbg32 không? Ngoài ra, ngoại lệ ban đầu này được tạo ra: nó được chèn vào bởi trình gỡ lỗi sao cho debuggee sẽ dừng khi được gọi? CẢM ƠN. – Sabuncu

1

Bạn đang cố gắng tìm ra cách gỡ lỗi các vấn đề thực sự khi phần mềm của bạn được đóng gói và gửi đến QA hoặc khách hàng? Nếu có, có một công cụ khác mà bạn có thể sử dụng, adplus. Adplus khởi chạy trình gỡ lỗi dưới mui xe và chỉ có một mục đích (thực sự là hai, nếu bạn chạy trong chế độ treo, nhưng đó không phải là những gì bạn muốn ở đây), đó là để chờ các ngoại lệ. Khi một ngoại lệ xảy ra, nó sẽ tạo ra một tệp kết xuất bộ nhớ xử lý có thể được tải vào WinDbg.

Sử dụng phương pháp này, bạn không phải dựa vào QA hoặc khách hàng của mình để biết cách làm việc với WinDbg. Bạn chỉ cần cung cấp cho họ hướng dẫn cách chạy một dòng lệnh. Sau khi chạy, chúng chỉ nén toàn bộ thư mục đầu ra và gửi nó cho bạn để phân tích.

Sau khi được tải vào WinDbg, tệp kết xuất bộ nhớ sẽ hiển thị cho bạn vị trí chính xác của ngoại lệ và tất cả biến cục bộ/thành viên tại thời điểm đó (mặc dù bạn có thể phải trả một chút cho các giá trị đó nếu mã của bạn được tối ưu hóa).

+0

Tác giả đã mua lại bãi chứa. Tuy nhiên, anh ta có vấn đề khi phân tích nó. –

+0

@YauheniSivukha - có lẽ không phải khi tôi đăng câu trả lời này ... hơn 3 năm trước – DXM

Các vấn đề liên quan