Bagikan melalui

Memverifikasi Simbol

Masalah simbol dapat muncul dengan berbagai cara. Mungkin jejak tumpukan menunjukkan informasi yang salah atau gagal mengidentifikasi nama fungsi dalam tumpukan. Atau mungkin perintah debugger gagal memahami nama modul, fungsi, variabel, struktur, atau jenis data.

Jika Anda menduga bahwa debugger tidak memuat simbol dengan benar, ada beberapa langkah yang dapat Anda ambil untuk menyelidiki masalah ini.

Pertama, gunakan perintah lm (List Loaded Modules) untuk menampilkan daftar modul yang dimuat dengan informasi simbol. Bentuk yang paling berguna dari perintah ini adalah sebagai berikut:

0:000> lml

Jika Anda menggunakan WinDbg, Debug | Perintah menu modul juga akan memungkinkan Anda melihat informasi ini.

Perhatikan catatan atau singkatan apa pun yang mungkin Anda lihat di tampilan ini. Untuk interpretasi ini, lihat Singkatan Status Simbol.

Jika Anda tidak melihat file simbol yang tepat, hal pertama yang harus dilakukan adalah memeriksa jalur simbol:

0:000> .sympath
Current Symbol Path is: d:\MyInstallation\i386\symbols\retail

Jika jalur simbol Anda salah, perbaiki. Jika Anda menggunakan debugger kernel, pastikan %WINDIR% lokal Anda tidak ada di jalur simbolik Anda.

Kemudian muat ulang simbol menggunakan perintah .reload (Reload Module):

0:000> .reload ModuleName

Jika jalur simbol Anda benar, Anda harus mengaktifkan mode berisik agar Anda dapat melihat file simbol apa saja yang sedang dimuat oleh dbghelp. Kemudian muat ulang modul Anda. Lihat Mengatur Opsi Simbol untuk informasi tentang cara mengaktifkan mode berisik.

Berikut adalah contoh pemuatan ulang yang ramai dari simbol Microsoft Windows:

kd> !sym noisy
kd> .reload nt
 1: Kernel Version 2081 MP Checked
 2: Kernel base = 0x80400000 PsLoadedModuleList = 0x80506fa0
 3: DBGHELP: FindExecutableImageEx-> Looking for D:\MyInstallation\i386\ntkrnlmp.exe...mismatched timestamp
 4: DBGHELP: No image file available for ntkrnlmp.exe
 5: DBGHELP: FindDebugInfoFileEx-> Looking for
 6: d:\MyInstallation\i386\symbols\retail\symbols\exe\ntkrnlmp.dbg... no file
 7: DBGHELP: FindDebugInfoFileEx-> Looking for
 8: d:\MyInstallation\i386\symbols\retail\symbols\exe\ntkrnlmp.pdb... no file
 9: DBGHELP: FindDebugInfoFileEx-> Looking for d:\MyInstallation\i386\symbols\retail\exe\ntkrnlmp.dbg... OK
10: DBGHELP: LocatePDB-> Looking for d:\MyInstallation\i386\symbols\retail\exe\ntkrnlmp.pdb... OK
11: *** WARNING: symbols checksum and timestamp is wrong 0x0036a4ea 0x00361a83 for ntkrnlmp.exe

Penangan simbol pertama-tama mencari gambar yang cocok dengan modul yang coba dimuat (baris tiga dan empat). Gambar itu sendiri tidak selalu diperlukan, tetapi jika ada yang salah, penangan simbol akan sering gagal. Baris ini menunjukkan bahwa debugger menemukan gambar di D:\MyInstallation\i386\ntkrnlmp.exe, tetapi stempel tanggal waktu tidak cocok. Karena stempel tanggal waktu tidak cocok, pencarian berlanjut. Selanjutnya, debugger mencari file .dbg dan file .pdb yang cocok dengan gambar yang dimuat. Ini adalah pada baris 6 sampai 10. Baris 11 menunjukkan bahwa meskipun simbol dimuat, stempel tanggal waktu untuk gambar tidak cocok (artinya, simbolnya salah).

Jika pencarian simbol mengalami kegagalan besar, Anda akan melihat pesan formulir:

ImgHlpFindDebugInfo(00000000, module.dll, c:\MyDir;c:\SomeDir, 0823345, 0) failed

Hal ini dapat disebabkan oleh item seperti kegagalan sistem file, kesalahan jaringan, dan file .dbg yang rusak.

Mendiagnosis Kesalahan Pemuatan Simbol

Ketika dalam mode berisik, debugger dapat mencetak kode kesalahan ketika tidak dapat memuat file simbol. Kode kesalahan untuk file .dbg tercantum dalam winerror.h. Kode kesalahan .pdb berasal dari sumber lain dan kesalahan yang paling umum dicetak dalam teks bahasa Inggris biasa.

Beberapa kode kesalahan umum untuk file .dbg dari winerror.h adalah:

0xB
KESALAHAN_FORMAT_BURUK

0x3
GALAT_JALUR_TIDAK_DITEMUKAN

0x35
Kesalahan_Jalur_Jaringan_Buruk

Ada kemungkinan bahwa file simbol tidak dapat dimuat karena kesalahan jaringan. Jika Anda melihat ERROR_BAD_FORMAT atau ERROR_BAD_NETPATH dan Anda memuat simbol dari komputer lain di jaringan, coba salin file simbol ke komputer host Anda dan letakkan jalurnya di jalur simbol Anda. Kemudian coba muat ulang simbol.

Memverifikasi Jalur dan Simbol Pencarian Anda

Biarkan "c:\MyDir; c:\SomeDir" mewakili jalur simbol Anda. Di mana Anda harus mencari informasi debug?

Dalam kasus di mana file biner telah dilucuti informasi debug, seperti versi gratis Windows, pertama-tama cari file .dbg di lokasi-lokasi berikut:

c:\MyDir\symbols\exe\ntoskrnl.dbg
c:\SomeDir\symbols\exe\ntoskrnl.dbg
c:\MyDir\exe\ntoskrnl.dbg
c:\SomeDir\exe\ntoskrnl.dbg
c:\MyDir\ntoskrnl.dbg
c:\SomeDir\ntoskrnl.dbg
current-working-directory\ntoskrnl.dbg

Selanjutnya, cari file .pdb di lokasi berikut:

c:\MyDir\symbols\exe\ntoskrnl.pdb
c:\MyDir\exe\ntoskrnl.pdb
c:\MyDir\ntoskrnl.pdb
c:\SomeDir\symbols\exe\ntoskrnl.pdb
c:\SomeDir\exe\ntoskrnl.pdb
c:\SomeDir\ntoskrnl.pdb
current-working-directory\ntoskrnl.pdb

Perhatikan bahwa dalam pencarian file .dbg, debugger melakukan pencarian melalui direktori MyDir dan SomeDir, tetapi dalam pencarian .pdb tidak.

Windows XP dan versi Windows yang lebih baru tidak menggunakan file simbol .dbg apa pun. Lihat Simbol dan File Simbol untuk detailnya.

Versi yang Tidak Sesuai

Salah satu masalah paling umum dalam kegagalan debugging pada komputer yang sering diperbarui adalah ketidakcocokan simbol antara build yang berbeda. Tiga penyebab umum masalah ini adalah: menunjuk pada simbol untuk build yang salah, menggunakan biner yang dibangun secara pribadi tanpa simbol yang sesuai, dan menggunakan tingkat abstraksi perangkat keras uniprosesor (HAL) serta simbol kernel pada mesin multiprosesor. Dua yang pertama hanya masalah mencocokkan biner dan simbol Anda; yang ketiga dapat dikoreksi dengan mengganti nama hal*.dbg dan ntkrnlmp.dbg anda menjadi hal.dbg dan ntoskrnl.dbg.

Untuk mengetahui build Windows apa yang diinstal pada komputer target, gunakan perintah vertarget (Tampilkan Versi Komputer Target):

kd> vertarget 
Windows XP Kernel Version 2505 UP Free x86 compatible
Built by: 2505.main.010626-1514
Kernel base = 0x804d0000 PsLoadedModuleList = 0x80548748
Debug session time: Mon Jul 02 14:41:11 2001
System Uptime: 0 days 0:04:53

Menguji Simbol

Menguji simbol lebih sulit. Ini melibatkan verifikasi trace stack pada debugger dan melihat apakah output debug sudah benar. Berikut adalah salah satu contoh untuk dicoba:

kd> u videoprt!videoportfindadapter2
Loading symbols for 0xf2860000     videoprt.sys ->   videoprt.sys

VIDEOPRT!VideoPortFindAdapter2:
f2856f42 55               push    ebp
f2856f43 8bec             mov     ebp,esp
f2856f45 81ecb8010000     sub     esp,0x1b8
f2856f4b 8b4518           mov     eax,[ebp+0x18]
f2856f4e 53               push    ebx
f2856f4f 8365f400         and     dword ptr [ebp-0xc],0x
f2856f53 8065ff00         and     byte ptr [ebp-0x1],0x0
f2856f57 56               push    esi

Perintah u membongkar string videoportfindadapter pada videoprt.sys. Simbol-simbol benar di debugger karena perintah-perintah stack umum seperti push dan mov muncul di tumpukan. Sebagian besar fungsi dimulai dengan operasi tambah, sub, atau push menggunakan base pointer (ebp) atau stack pointer (esp).

Biasanya jelas ketika simbol tidak berfungsi dengan benar. Glintmp.sys tidak memiliki simbol dalam contoh ini karena fungsi tidak tercantum di samping Glintmp:

kd> kb
Loading symbols for 0xf28d0000     videoprt.sys ->   videoprt.sys
Loading symbols for 0xf9cdd000      glintmp.sys ->   glintmp.sys
*** ERROR: Symbols could not be loaded for glintmp.sys
ChildEBP RetAddr  Args to Child
f29bf1b0 8045b5fa 00000001 0000a100 00000030 ntoskrnl!RtlpBreakWithStatusInstruction
f29bf1b0 8044904e 00000001 0000a100 00000030 ntoskrnl!KeUpdateSystemTime+0x13e
f29bf234 f28d1955 f9b7d000 ffafb2dc f9b7d000 ntoskrnl!READ_REGISTER_ULONG+0x6
f29bf248 f9cde411 f9b7d000 f29bf2b0 f9ba0060 VIDEOPRT!VideoPortReadRegisterUlong+0x27
00000002 00000000 00000000 00000000 00000000 glintMP+0x1411 [No function listed.]

Simbol build yang salah dimuat untuk pelacakan tumpukan ini. Perhatikan bagaimana tidak ada fungsi yang tercantum untuk dua panggilan pertama. Jejak tumpukan ini menyerupai masalah dengan menggambar persegi panjang win32k.sys.

1: kd> 
1: kd> kb                      [Local        9:50 AM]
Loading symbols for 0xf22b0000       agpcpq.sys ->   agpcpq.sys
*** WARNING: symbols checksum is wrong 0x0000735a 0x00000000 for agpcpq.sys
*** ERROR: Symbols could not be loaded for agpcpq.sys
Loading symbols for 0xa0000000       win32k.sys ->   win32k.sys
*** WARNING: symbols checksum is wrong 0x00191a41 0x001995a9 for win32k.sys
ChildEBP RetAddr  Args to Child
be682b18 f22b372b 82707128 f21c1ffc 826a70f8 agpCPQ+0x125b [No function listed.]
be682b4c a0140dd4 826a72f0 e11410a8 a0139605 agpCPQ+0x372b [No function listed.]
be682b80 a00f5646 e1145100 e1cee560 e1cee560 win32k!vPatCpyRect1_6x6+0x20b
00000001 00000000 00000000 00000000 00000000 win32k!RemoteRedrawRectangle+0x32

Berikut adalah jejak tumpukan yang benar. Masalahnya benar-benar dengan AGP440.sys. Item pertama yang muncul pada pelacakan tumpukan biasanya salah. Perhatikan bahwa kesalahan persegi win32k.sys hilang:

1: kd> kb                      [Local        9:49 AM]
ChildEBP RetAddr  Args to Child
be682b18 f22b372b 82707128 f21c1ffc 826a70f8 agpCPQ!AgpReleaseMemory+0x88
be682b30 f20a385c 82703638 e183ec68 00000000 agpCPQ!AgpInterfaceReleaseMemory+0x8b
be682b4c a0140dd4 826a72f0 e11410a8 a0139605 VIDEOPRT!AgpReleasePhysical+0x44
be682b58 a0139605 e1cee560 e11410a8 a00e5f0a win32k!OsAGPFree+0x14
be682b64 a00e5f0a e1cee560 e11410a8 e1cee560 win32k!AGPFree+0xd
be682b80 a00f5646 e1145100 e1cee560 e1cee560 win32k!HeapVidMemFini+0x49
be682b9c a00f5c20 e1cee008 e1cee008 be682c0c win32k!vDdDisableDriver+0x3a
be682bac a00da510 e1cee008 00000000 be682c0c win32k!vDdDisableDirectDraw+0x2d
be682bc4 a00da787 00000000 e1843df8 e1843de8 win32k!PDEVOBJ__vDisableSurface+0x27
be682bec a00d59fb 00000000 e1843de8 00000000 win32k!PDEVOBJ__vUnreferencePdev+0x204
be682c04 a00d7421 e1cee008 82566a98 00000001 win32k!DrvDestroyMDEV+0x30
be682ce0 a00a9e7f e1843e10 e184a008 00000000 win32k!DrvChangeDisplaySettings+0x8b3
be682d20 a008b543 00000000 00000000 00000000 win32k!xxxUserChangeDisplaySettings+0x106
be682d48 8045d119 00000000 00000000 00000000 win32k!NtUserChangeDisplaySettings+0x48
be682d48 77e63660 00000000 00000000 00000000 ntkrnlmp!KiSystemService+0xc9

Perintah dan Ekstensi yang Berguna

Perintah dan ekstensi berikut mungkin berguna dalam melacak masalah simbol:

lm (Daftar Modul yang Dimuat)
Mencantumkan semua modul dan memberikan status pemuatan semua simbol dalam modul ini.

!dh image-header-base
Menampilkan informasi header untuk gambar yang dimuat yang dimulai pada image-header-base.

.reload /n
Memuat ulang semua simbol kernel.

.reload [image-name]
(hanya CDB atau WinDbg) Memuat ulang simbol untuk gambar-nama. Jika tidak ada nama gambar yang ditentukan, muat ulang simbol untuk semua gambar. (Perlu memuat ulang simbol setelah jalur simbol diubah.)

!sym noisy
Mengaktifkan verbose mode untuk pemuatan simbol. Ini dapat digunakan untuk mendapatkan informasi tentang pemuatan modul. Lihat Mengatur Opsi Simbol untuk detailnya.

.sympath [new-symbol-path]
Mengatur jalur simbol baru, atau menampilkan jalur simbol saat ini. Lihat Jalur Simbol untuk detailnya.

Jika simbol kernel benar, tetapi Anda tidak mendapatkan tumpukan lengkap, perintah berikut mungkin juga berguna:

X *!
Ini akan mencantumkan modul yang saat ini memiliki simbol yang dimuat. Ini berguna jika simbol kernel benar.

.reload /user
Ini akan mencoba memuat ulang semua simbol mode pengguna. Ini diperlukan saat melakukan debugging kernel jika simbol dimuat saat satu proses berjalan, dan jeda kemudian terjadi pada proses lainnya. Dalam hal ini, simbol mode pengguna dari proses baru tidak akan dimuat kecuali perintah ini dijalankan.

X wdmaud!*start\*
Ini hanya akan mencantumkan simbol dalam modul wdmaud yang namanya berisi string "start". Ini memiliki keuntungan bahwa ia memaksa pemuatan ulang semua simbol dalam wdmaud, tetapi hanya menampilkan yang dengan "mulai" di dalamnya. (Ini berarti daftar yang lebih pendek, tetapi karena selalu ada beberapa simbol dengan "start" di dalamnya, akan ada beberapa verifikasi bahwa pemuatan telah terjadi.)

Teknik berguna lainnya untuk memverifikasi simbol adalah dengan membongkar kode. Sebagian besar fungsi dimulai dengan operasi tambahkan, sub, atau dorong menggunakan penunjuk dasar (ebp) atau penunjuk tumpukan (esp atau sp). Coba membongkar (Fungsi U) beberapa fungsi pada tumpukan fungsi (dari offset nol) untuk memverifikasi simbol.

Masalah Jaringan dan Port

Masalah akan terjadi dengan file simbol dan saat menyambungkan ke debugger. Berikut adalah beberapa hal yang perlu diingat jika Anda mengalami masalah:

  • Tentukan port COM mana yang tersambung dengan kabel debug pada sistem pengujian.

  • Periksa pengaturan boot.ini sistem pengujian. Cari sakelar /debug dan periksa laju baud dan pengaturan port COM.

  • Masalah jaringan dapat mengganggu debugging jika file simbol diakses melalui jaringan.

  • .dll dan .sys file dengan nama yang sama (misalnya − mga64.sys dan mga64.dll) akan membingungkan debugger jika tidak dipisahkan ke dalam direktori pohon simbol yang tepat.

  • Debugger kernel tidak selalu suka mengganti file simbol build dengan file simbol privat. Periksa kembali jalur simbol dan lakukan .reloadFileName pada simbol yang tidak berperilaku. Perintah !dlls terkadang berguna.

Pertanyaan dan Kesalahpahaman

Q: Saya telah berhasil memuat simbol, tetapi tumpukan sepertinya salah. Apakah debugger rusak?

A: Belum tentu. Penyebab paling mungkin dari masalah Anda adalah bahwa Anda memiliki simbol yang salah. Buka langkah-langkah yang diuraikan di bagian ini untuk menentukan apakah Anda telah memuat simbol yang valid atau tidak. Jangan berasumsi bahwa Anda memiliki simbol yang valid hanya karena beberapa hal berfungsi. Misalnya, Anda mungkin saja dapat menjalankan dd nt!ntbuildnumber atau u nt!KeInitializeProcess dengan simbol yang salah. Verifikasi bahwa prosedur tersebut sudah benar menggunakan prosedur yang diuraikan di atas.

T: Apakah debugger masih berfungsi dengan simbol yang salah?

A: Ya dan tidak. Seringkali Anda dapat menggunakan simbol yang tidak sepenuhnya cocok. Misalnya, simbol dari build Windows sebelumnya akan sering berfungsi dalam kasus tertentu, tetapi tidak ada aturan kapan ini akan berfungsi dan kapan tidak akan berfungsi.

T: Saya dihentikan di debugger kernel dan saya ingin melihat simbol untuk proses mode pengguna saya. Dapatkah saya melakukannya?

A: Sebagian besar. Dukungan untuk skenario ini buruk karena debugger kernel tidak menyimpan informasi yang cukup untuk melacak beban modul untuk setiap proses, tetapi ada solusi yang wajar. Untuk memuat simbol untuk modul mode pengguna, jalankan perintah .reload -user . Ini akan memuat modul mode pengguna untuk konteks saat ini.

T: Apa arti pesan berikut?

*** WARNING: symbols checksum and timestamp is wrong 0x0036d6bf 0x0036ab55 for ntkrnlmp.exe

A: Ini berarti simbol Anda untuk ntkrnlmp.exe salah.

  • Last updated on