Membaca kode error Windows — struktur tiga lapis Win32, HRESULT, dan NTSTATUS

“Layar aplikasi menampilkan error 0x80004005. Apa artinya?” — Pertanyaan semacam ini sudah jadi klasik dalam konsultasi investigasi gangguan. Banyak orang menempelkan angka di dialog error langsung ke mesin pencari, lalu disambut banjir artikel yang tidak terkait — kegagalan Windows Update, folder bersama yang tidak tersambung, error runtime VBA, kegagalan koneksi basis data — dan justru semakin bingung.

Itu terjadi karena 0x80004005 (E_FAIL) adalah kode generik yang hanya berarti “kegagalan yang tidak ditentukan”. Kode yang sama dipakai di situasi yang tak terhitung, jadi mencari hanya berdasarkan kode tidak akan sampai ke penyebab. Sebaliknya, kode seperti 0x80070005, jika strukturnya diketahui, dapat diuraikan dalam beberapa detik sebelum mencari: “error Win32 nomor 5 = akses ditolak, dibungkus ulang sebagai HRESULT”.

Karena sejarahnya, kode error Windows membentuk tiga lapis — kode error Win32, HRESULT, dan NTSTATUS — dan saling dikonversi antarlapis. Setelah struktur itu dipahami, kita dapat menilai sendiri “lapis mana, pihak mana yang mengembalikan kode ini” dan “apa kode esensialnya”, sehingga langkah awal investigasi menjadi jauh lebih cepat.

Artikel ini ditujukan kepada staf IT usaha kecil dan menengah serta pengembang aplikasi Windows. Isinya menata cara membedakan dan menguraikan ketiga sistem kode error, hubungan dengan exception .NET, serta cara penelusuran praktis dengan err.exe dan PowerShell, berdasarkan Microsoft Learn dan spesifikasi publik [MS-ERREF] per Agustus 2026.

1. Kesimpulan dulu

• Kode error Windows terutama terdiri dari tiga sistem. Kode error Win32 (bilangan desimal kecil yang dikembalikan GetLastError), HRESULT (kode 32-bit sejak era COM, heksadesimal yang dimulai 0x8 atau desimal negatif), dan NTSTATUS (kode lapis kernel; error dimulai 0xC).¹²³
• Desimal dan heksadesimal adalah notasi berbeda untuk kode yang sama. “Error 5”, “0x5”, dan “16 bit rendah dari 0x80070005” semuanya merujuk ERROR_ACCESS_DENIED (akses ditolak).¹
• 0x8007xxxx adalah “bungkus ulang error Win32”. Itu kode error Win32 yang disimpan di FACILITY_WIN32 (7) pada HRESULT. Ubah 16 bit rendah ke desimal, maka kode esensialnya terlihat. Ini pola paling penting dalam membaca kode error.⁴⁵
• 0x80004005 (E_FAIL) bukan kode penyebab. Artinya “Unspecified failure” dan tidak membawa informasi lebih. Alih-alih menggali kode ini, carilah konteks asal dan log yang menyertainya.⁶
• Desimal negatif (-2147467259 dan sejenisnya) adalah HRESULT. Bit paling signifikan 32-bit (bit kegagalan) menyala, sehingga tampilan bertanda menjadi negatif. Ubah ke heksadesimal, baru dibaca.²
• Nilai 8 digit yang dimulai 0xC adalah NTSTATUS. 0xC0000005 (pelanggaran akses) dan 0xC0000135 (DLL tidak ditemukan) sering muncul di event log dan dump saat crash. Keduanya tidak terkait dengan error Win32 nomor 5.⁷
• Kode yang sama maknanya berubah menurut konteks. Penyebab error 5 mencakup ACL, elevasi hak, antivirus, file yang sedang dipegang, dan lain-lain. “File tidak ditemukan” pada error 2 pun sering kali DLL dependen. Makna kode dan API mana yang gagal terhadap apa harus dibaca sebagai satu paket.¹
• Alat konversi dan pencarian sudah tersedia secara standar. certutil -error dan net helpmsg built-in di Windows; Win32Exception di PowerShell mengambil pesan; di mesin pengembangan ada err.exe (Microsoft Error Lookup Tool); dalam analisis dump dipakai !error di WinDbg.⁸⁹¹⁰
• Di .NET, HRESULT dipetakan ke tipe exception. HRESULT yang dikenal menjadi tipe yang sesuai (E_ACCESSDENIED → UnauthorizedAccessException, dan sejenisnya); yang tidak dikenal menjadi COMException; nilai asli tetap di Exception.HResult.¹¹

Dalam satu kalimat, pola investigasi kode error Windows adalah "selaraskan notasi ke heksadesimal → tentukan lapis mana kodenya → uraikan dan keluarkan kode esensial → baca bersama konteks".

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 18, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Windows punya tiga sistem kode error

Pertama, peta keseluruhan. Kode error Windows terbagi terutama menjadi tiga sistem berikut, menurut lapis yang mengembalikannya.

Secara historis ketiganya bertumpuk dalam urutan ini: kode error Win32 yang mewarisi nomor error MS-DOS, NTSTATUS yang dipakai kernel NT secara internal, lalu HRESULT yang dirancang saat pengenalan COM untuk “mengemas sukses/gagal dan sumber ke 32 bit”. Di Windows sekarang, alur konversi yang terjadi sehari-hari adalah: kernel mengembalikan NTSTATUS, subsistem Win32 mengonversinya menjadi kode error Win32, dan lapis COM membungkusnya lebih jauh sebagai HRESULT.¹²⁴

flowchart TB
    accTitle: Alur konversi lintas tiga sistem
    accDescr: Subsistem Win32 mengonversi NTSTATUS yang dikembalikan kernel menjadi kode error Win32, lalu lapis COM membungkusnya lebih jauh sebagai HRESULT
    kernel["Kernel dan driver"] --> nt["NTSTATUS（error 0xC…）"]
    nt -->|Subsistem Win32 mengonversi| win["Kode error Win32（5 dan sejenisnya）"]
    win -->|Lapis COM membungkus ulang| hr["HRESULT（0x8007xxxx）"]

Gambar 1: Alur konversi lintas lapis. NTSTATUS dari kernel menjadi error Win32, lalu dibungkus ulang sebagai HRESULT.

2.1. Biasakan membaca desimal dan heksadesimal secara bergantian

Sebelum membedakan ketiga sistem, variasi notasi perlu diserap. Kode yang sama ditampilkan sebagai desimal atau heksadesimal, tergantung situasinya.

• “Error 5”, “kode error: 0x5” → ERROR_ACCESS_DENIED yang sama
• “Error 1223”, “0x4C1” → ERROR_CANCELLED yang sama
• “0x80070005”, “-2147024891” → HRESULT yang sama

Di PowerShell konversinya satu baris.

# desimal → heksadesimal
'0x{0:X8}' -f 1223          # 0x000004C1
'0x{0:X8}' -f -2147024891   # 0x80070005 (negatif = HRESULT ke heksadesimal)

# heksadesimal → desimal
0x4C1                        # 1223

Jika desimal negatif yang dimulai “-214…” muncul, secara refleks ubah ke heksadesimal. Itu saja sudah banyak mengurangi tersesat di pintu masuk investigasi.

flowchart TB
    accTitle: Tiga tampilan kode yang sama
    accDescr: Error desimal 5, heksadesimal 0x5, dan 16 bit rendah 0x80070005 semuanya merujuk ERROR_ACCESS_DENIED yang sama
    d["Notasi desimal: error 5"] --> same["ERROR_ACCESS_DENIED"]
    h["Notasi heksadesimal: 0x5"] --> same
    l["16 bit rendah 0x80070005"] --> same
    same -.-> memo["Notasi berbeda, kode sama"]

Gambar 2: Desimal, heksadesimal, dan 16 bit rendah HRESULT hanyalah notasi berbeda untuk kode yang sama.

3. Kode error Win32 — GetLastError dan FORMAT_MESSAGE

3.1. Perilaku dasar GetLastError

Banyak API Win32 seperti CreateFile dan RegOpenKeyEx menandai kegagalan lewat nilai kembali (FALSE, NULL, INVALID_HANDLE_VALUE, dan sejenisnya), dan menyimpan kode error rinci di “last-error code” yang dipegang per thread. Pemanggil mengambilnya dengan GetLastError segera setelah mengonfirmasi kegagalan.¹³

Ada dua peringatan praktis.¹³

1. Baca segera setelah gagal. Jika panggilan API lain (fungsi logging, misalnya) diselipkan di antaranya, panggilan itu dapat menimpa last-error code.
2. Jangan andalkan nilai saat sukses. Beberapa API mengosongkan last-error code ke 0 saat sukses; beberapa tidak menyentuhnya. Aturannya: konfirmasi kegagalan dari nilai kembali, baru kemudian baca.

sequenceDiagram
    accTitle: Baca GetLastError segera setelah gagal
    accDescr: Setelah mengonfirmasi kegagalan dari nilai kembali, ambil last-error code dengan GetLastError segera, tanpa menyelipkan panggilan API lain
    participant app as Aplikasi
    participant api as Win32 API
    app->>api: Panggilan CreateFile
    api-->>app: Nilai kembali gagal
    app->>api: GetLastError
    api-->>app: Kode 5
    Note over app: Menyelipkan API lain di antaranya dapat menimpa

Gambar 3: Baca last-error code segera setelah gagal. Menyelipkan panggilan API lain di antaranya dapat menimpanya.

Untuk mendapatkan string pesan dari kode, pakai FormatMessage dengan flag FORMAT_MESSAGE_FROM_SYSTEM.¹

#include <windows.h>
#include <stdio.h>

void PrintLastError(const wchar_t* apiName)
{
    DWORD code = GetLastError();   // panggil segera setelah gagal (jangan selipkan API lain)
    wchar_t message[512] = L"";
    FormatMessageW(
        FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
        nullptr, code, 0, message, 512, nullptr);
    wprintf(L"%s failed: %lu (0x%08lX) %s", apiName, code, code, message);
}

Di log aplikasi sendiri, sisakan desimal dan heksadesimal sekaligus, plus teks pesan, seperti di atas. Investigasi di kemudian hari menjadi lebih cepat.

flowchart TB
    accTitle: Ambil pesan dari kode lalu sisakan di log
    accDescr: Tentukan flag FORMAT_MESSAGE_FROM_SYSTEM pada FormatMessage untuk mengambil string pesan kode error, lalu sisakan desimal, heksadesimal, dan teks pesan di log
    code["Kode error（contoh: 5）"] --> fm["Ambil string dengan FormatMessage"]
    fm --> msg["Teks pesan"]
    msg --> log["Catat di log"]
    log -.-> both["Tulis desimal, heksadesimal, dan teks bersamaan"]

Gambar 4: Kode error diubah menjadi string pesan dengan FormatMessage. Di log, sisakan desimal, heksadesimal, dan teks pesan bersamaan.

3.2. Kode representatif yang sering muncul di lapangan

Kode error Win32 didefinisikan dalam rentang 0–15999, dan daftar lengkapnya ada di Microsoft Learn.¹ Di antaranya, kode-kode berikut berulang kali muncul dalam investigasi gangguan.

Di antaranya, 998 (ERROR_NOACCESS) bukan “akses ditolak”, melainkan representasi Win32 dari pelanggaran akses memori. Itu wujud NTSTATUS STATUS_ACCESS_VIOLATION setelah dikonversi ke lapis Win32 (dibahas nanti). Jangan dikacaukan dengan nomor 5. Selain itu, 1223 (ERROR_CANCELLED) muncul misalnya saat pengguna memilih “Tidak” pada dialog elevasi UAC; ini lebih menandai “dibatalkan” daripada error.

flowchart TB
    accTitle: Error 998 dan 5 adalah hal yang berbeda
    accDescr: 998 adalah pelanggaran akses memori, yaitu pelanggaran akses NTSTATUS yang dikonversi ke lapis Win32; maknanya berbeda dari 5 yang menyatakan akses ditolak
    nt["NTSTATUS 0xC0000005"] -->|Dikonversi ke lapis Win32| e998["Error 998（ERROR_NOACCESS）"]
    e998 -.-> m1["Maknanya pelanggaran akses memori"]
    e5["Error 5（akses ditolak）"] -.-> m2["Masalah hak. Bukan 998"]

Gambar 5: Error 998 adalah wujud pelanggaran akses NTSTATUS setelah dikonversi ke lapis Win32. Berbeda dari 5 (akses ditolak).

3.3. Kode yang sama, makna berubah menurut konteks

Lebih penting daripada menghafal tabel kode representatif adalah rasa bahwa kode error hanya memberi tahu “jenis kegagalan”.

• Error 5 (akses ditolak): kandidat penyebabnya luas — ACL NTFS kurang, penulisan ke area terlindungi tanpa hak administrator, blokir perangkat lunak antivirus atau AppLocker, hak akun layanan tidak cukup, dan lain-lain.
• Error 2 (file tidak ditemukan): tidak selalu file yang ditentukan pengguna. DLL dependen yang coba dimuat secara implisit oleh EXE, file pengaturan yang dilihat di lokasi lain karena pengalihan registri (32-bit/64-bit), path yang gagal diekspansi variabel lingkungan — “file mana” yang tidak ditemukan tidak terlihat dari kodenya.
• Error 32 (pelanggaran berbagi): inti masalahnya “proses mana yang memegangnya”, tetapi kode tidak memberitahukannya.

flowchart TB
    accTitle: Penyebab error 5 ditentukan konteks
    accDescr: Meski sama-sama akses ditolak, kandidat penyebabnya banyak — ACL kurang, tanpa hak administrator, dan lain-lain — sehingga perlu diidentifikasi API mana yang gagal terhadap apa
    e5["Error 5（akses ditolak）"] --> c1["ACL kurang"]
    e5 --> c2["Tanpa hak administrator"]
    e5 --> c3["Blokir perangkat lunak keamanan"]
    e5 --> c4["Hak layanan kurang"]
    c1 --> next["Identifikasi sasaran yang gagal dengan Procmon"]
    c2 --> next
    c3 --> next
    c4 --> next

Gambar 6: Kode hanya memberi tahu “jenis kegagalan”. Kandidat penyebab error 5 banyak, sehingga sasaran harus diidentifikasi.

Alat untuk mengukur “API mana · terhadap nama objek mana · mengembalikan hasil apa” adalah Process Monitor. Cara memakainya dibahas secara rinci di “Panduan praktis Process Monitor (ProcMon)”. Mencari arti kode error dan mengidentifikasi sasaran yang gagal adalah dua roda yang harus berjalan bersama.

4. HRESULT — membaca struktur yang dikemas dalam 32 bit

4.1. Tata letak bit

HRESULT adalah format yang mengemas sukses/gagal, sumber, dan kode rinci ke satu nilai 32-bit. Spesifikasi publik [MS-ERREF] mendefinisikan tata letak berikut.²

Bit S paling atas bernilai 1, yaitu HRESULT yang notasi heksadesimalnya dimulai 0x8 atau lebih adalah kegagalan. Jika ditampilkan sebagai bilangan bulat 32-bit bertanda, nilainya menjadi negatif — itulah identitas “-214…” yang disebutkan sebelumnya.

flowchart TB
    accTitle: Hubungan bit S dan tampilan negatif
    accDescr: HRESULT gagal menyetel bit S paling atas ke 1, sehingga heksadesimal dimulai 0x8 atau lebih, dan sebagai bilangan bulat 32-bit bertanda menjadi negatif
    s["Bit S = 1（gagal）"] --> hex["Heksadesimal dimulai 0x8 atau lebih"]
    hex --> neg["Tampilan bertanda menjadi negatif"]
    neg --> back["Jika negatif, ubah ke heksadesimal lalu baca"]

Gambar 7: HRESULT gagal menyetel bit S ke 1, sehingga dimulai 0x8 atau lebih, dan tampilan bertanda menjadi negatif.

Nilai Facility yang representatif adalah sebagai berikut.⁵

4.2. Menguraikan 0x80004005 dan 0x80070005

Mari diuraikan secara konkret.

Kasus 0x80004005: S = 1 (gagal), Facility = (0x80004005 » 16) & 0x7FF = 0 (FACILITY_NULL), Code = 0x4005. Ini kode generik FACILITY_NULL, didefinisikan sebagai E_FAIL “Unspecified failure” (kegagalan yang tidak ditentukan).⁶ Dengan kata lain, kode ini hanya berarti “kegagalan yang tidak dapat melaporkan rincian”. Jika 0x80004005 muncul, hentikan penggalian kode di situ, lalu alihkan fokus investigasi ke “komponen mana yang mengembalikannya” dan “apakah event log atau log aplikasi pada waktu yang sama memuat rincian”.

Kasus 0x80070005: S = 1, Facility = 7 (FACILITY_WIN32), Code = 0x0005 = 5. Terlihat bahwa ini error Win32 nomor 5 (ERROR_ACCESS_DENIED) yang dibungkus ulang sebagai HRESULT. Alias E_ACCESSDENIED pun, substansinya adalah nilai ini.⁶

Meski sama-sama “akses ditolak”, 0x80070005 adalah bungkus ulang kegagalan konkret yang terjadi di lapis Win32, dan jumlah informasinya sama sekali berbeda dari 0x80004005.

flowchart TB
    accTitle: Penguraian 0x80004005 dan 0x80070005
    accDescr: 0x80004005 adalah kode generik E_FAIL FACILITY_NULL tanpa rincian sehingga investigasi harus pindah ke konteks; 0x80070005 adalah FACILITY_WIN32, bungkus ulang akses ditolak error Win32 nomor 5
    a["0x80004005"] --> af["Facility=0（FACILITY_NULL）"]
    af --> ac["Code=0x4005 → E_FAIL"]
    ac --> ax["Kegagalan tidak ditentukan. Lanjut ke investigasi konteks"]
    b["0x80070005"] --> bf["Facility=7（FACILITY_WIN32）"]
    bf --> bc["Code=0x0005 → 5"]
    bc --> bx["ERROR_ACCESS_DENIED"]

Gambar 8: Meski sama-sama “gagal”, penguraian mengubah jumlah informasi. 0x80070005 dapat ditelusuri sampai error Win32 nomor 5.

4.3. Pola terpenting: 0x8007xxxx = HRESULT_FROM_WIN32

Agar kegagalan lapis bawah yang hanya dapat mengembalikan kode error Win32 dapat disampaikan ke lapis atas yang mengembalikan HRESULT (metode COM atau runtime .NET), winerror.h menyediakan makro HRESULT_FROM_WIN32.⁴ Perilakunya: “simpan kode error Win32 di 16 bit rendah, setel Facility ke FACILITY_WIN32 (7), setel bit S ke 1”.

flowchart TB
    accTitle: Perilaku HRESULT_FROM_WIN32
    accDescr: Menyimpan kode error Win32 di 16 bit rendah, menyetel Facility ke 7 dan bit S ke 1, lalu merakit HRESULT 0x8007xxxx
    win["Kode error Win32（contoh: 5）"] --> low["Simpan di 16 bit rendah"]
    low --> fac["Setel Facility ke 7"]
    fac --> sbit["Setel bit S ke 1"]
    sbit --> hr["0x80070005"]

Gambar 9: HRESULT_FROM_WIN32 menyimpan error Win32 di 16 bit rendah, lalu menyalakan Facility = 7 dan bit S.

ERROR_ACCESS_DENIED (5)        --HRESULT_FROM_WIN32-->  0x80070005
ERROR_SHARING_VIOLATION (32)   --HRESULT_FROM_WIN32-->  0x80070020
ERROR_INVALID_PARAMETER (87)   --HRESULT_FROM_WIN32-->  0x80070057 (= E_INVALIDARG)
ERROR_OUTOFMEMORY (14)         --HRESULT_FROM_WIN32-->  0x8007000E (= E_OUTOFMEMORY)

Saat membaca arah sebaliknya, keluarkan 16 bit rendah dengan PowerShell.

0x80070005 -band 0xFFFF   # 5 → ERROR_ACCESS_DENIED
0x80072EE7 -band 0xFFFF   # 12007 → ERROR_INTERNET_NAME_NOT_RESOLVED (WinINet)

Seperti contoh kedua, error WinINet dan WinHTTP (rentang 12000-an) juga didefinisikan di ruang kode error Win32,¹ sehingga 0x8007xxxx terkait jaringan dapat diuraikan dengan prosedur yang sama. Membiasakan diri pada “jika melihat 0x8007, ubah 4 digit rendah ke desimal” adalah keterampilan praktis utama yang ingin dibawa pulang dari artikel ini.

Catatan sebaliknya berlaku untuk 0x8004xxxx (FACILITY_ITF). Kode FACILITY_ITF didefinisikan maknanya per antarmuka, sehingga nilai 32-bit yang sama dapat berarti lain jika pihak yang mengembalikannya berbeda.⁵ Untuk 0x8004xxxx yang tidak familiar, jangan mengandalkan pencarian generik; telusuri di dokumentasi komponen yang mengembalikannya (pustaka, SDK driver, produk server).

flowchart TB
    accTitle: Cara menelusuri 0x8007 dan 0x8004 berbeda
    accDescr: 0x8007xxxx FACILITY_WIN32 dapat dibaca dengan penguraian mekanis 16 bit rendah, sedangkan 0x8004xxxx FACILITY_ITF didefinisikan maknanya per antarmuka sehingga harus ditelusuri di bahan komponen yang mengembalikannya
    hr{"Facility-nya?"} -->|7, WIN32| w["Ubah 16 bit rendah ke desimal"]
    hr -->|4, ITF| i["Makna berbeda menurut pihak yang mengembalikan"]
    w --> ww["Baca sebagai error Win32"]
    i --> ii["Telusuri di bahan pihak yang mengembalikan"]

Gambar 10: 0x8007xxxx dapat diuraikan secara mekanis, sedangkan 0x8004xxxx ditelusuri di bahan komponen yang mengembalikannya.

5. NTSTATUS — kode lapis kernel dan dunia crash

5.1. Tata letak dan Severity

NTSTATUS adalah kode 32-bit yang dipakai kernel, driver perangkat, dan API native ntdll. Tata letaknya mirip HRESULT, tetapi tidak sama.³

Karena tingkat keparahan 2 bit, jenisnya dapat dibaca dari 1 digit heksadesimal terdepan. 0xC… adalah error (11), 0x8… peringatan (10), 0x4… informasi (01), 0x0–0x3… sukses. Contoh representatif “peringatan, bukan error” adalah exception breakpoint 0x80000003 (STATUS_BREAKPOINT).³⁷

flowchart TB
    accTitle: NTSTATUS dapat dibaca jenisnya dari 1 digit terdepan
    accDescr: Karena tingkat keparahan 2 bit, NTSTATUS dibedakan dari 1 digit heksadesimal terdepan: 0xC error, 0x8 peringatan, 0x4 informasi, 0x0 sampai 0x3 sukses
    head{"1 digit heksadesimal terdepan?"} -->|0xC| e["Error"]
    head -->|0x8| w["Peringatan"]
    head -->|0x4| i["Informasi"]
    head -->|0x0〜0x3| s["Sukses"]
    w -.-> ex["Contoh: 0x80000003 adalah peringatan"]

Gambar 11: Jenis NTSTATUS dapat dibaca dari 1 digit heksadesimal terdepan. 0x80000003 adalah “peringatan, bukan error”.

5.2. Di mana bertemu — exception code, STOP code, event log

Staf IT dan pengembang terutama bertemu NTSTATUS di sekitar crash.

• Exception code saat aplikasi crash: “Exception code: 0xc0000005” yang tercatat di event log “Application Error (Event ID 1000)” adalah NTSTATUS. Nilai representatifnya sebagai berikut.⁷

• STOP code layar biru: Sepintas mirip, tetapi STOP code (bug check code) seperti 0x0000009F (DRIVER_POWER_STATE_FAILURE) adalah sistem penomoran sendiri yang terpisah dari NTSTATUS, dengan referensi khusus.¹⁴ Cukup ingat pembedaan ini: “jika 0xC0000005 maka NTSTATUS; jika STOP 0x9F maka bug check code — jangan menarik tabel NTSTATUS”.
• Kolom Result Process Monitor: NAME NOT FOUND dan ACCESS DENIED di kolom Result Procmon adalah nama tampilan NTSTATUS yang dikembalikan kernel (STATUS_OBJECT_NAME_NOT_FOUND atau STATUS_ACCESS_DENIED). Ini juga tempat untuk merasakan korespondensi lapis: kegagalan I/O file diamati dalam kosakata NTSTATUS, lalu dikonversi menjadi error Win32 sebelum sampai ke aplikasi.

flowchart TB
    accTitle: Membaca exception code dan STOP code secara terpisah
    accDescr: Exception code di event log dibaca sebagai NTSTATUS; STOP code layar biru ditarik dari referensi khusus bug check code, sistem yang berbeda
    q{"Kode muncul di mana?"} -->|Exception code| nt["Baca sebagai NTSTATUS"]
    q -->|STOP code| bc["Tarik dari tabel bug check code"]
    nt -.-> n1["Contoh: 0xC0000005"]
    bc -.-> b1["Contoh: 0x0000009F"]

Gambar 12: Exception code di event log adalah NTSTATUS; STOP code layar biru sistem lain. Jangan salah tabel yang ditarik.

Investigasi setelah exception code, yaitu pengambilan dan analisis crash dump, lihat “Pengantar pengumpulan crash dump Windows” dan “Membaca crash dump dengan WinDbg + SOS”.

5.3. Hubungan dengan HRESULT — bit N dan RtlNtStatusToDosError

Jembatan NTSTATUS ke dua lapis lainnya ada dua jalur.

1. Pemetaan ke ruang HRESULT: Jika bit N HRESULT (0x10000000) dinyalakan, nilai NTSTATUS dapat dibawa utuh ke ruang HRESULT (makro HRESULT_FROM_NT di winerror.h). 0xC0000005 yang dipetakan menjadi 0xD0000005, misalnya. Jika HRESULT yang dimulai 0xD muncul, matikan bit N lalu baca sebagai NTSTATUS — itu prosedur yang benar.²
2. Konversi ke kode error Win32: RtlNtStatusToDosError di ntdll mengonversi NTSTATUS ke kode error Win32 yang sesuai. Nilai yang tidak punya korespondensi menjadi ERROR_MR_MID_NOT_FOUND.¹² Misalnya STATUS_ACCESS_VIOLATION (0xC0000005) menjadi ERROR_NOACCESS (998), dan STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034) menjadi ERROR_FILE_NOT_FOUND (2). Berguna juga diingat bahwa kosakata kaya kernel kadang dibulatkan menjadi kategori kasar di lapis Win32.

flowchart TB
    accTitle: Dua jembatan NTSTATUS ke lapis lain
    accDescr: NTSTATUS sampai ke lapis lain lewat dua jalur: dipetakan ke ruang HRESULT dengan menyalakan bit N, atau dikonversi ke kode error Win32 dengan RtlNtStatusToDosError
    nt["NTSTATUS（0xC0000005）"] -->|Nyalakan bit N| hr["HRESULT（0xD0000005）"]
    nt -->|RtlNtStatusToDosError| win["Error Win32 998（ERROR_NOACCESS）"]
    win -.-> memo["Jika korespondensi tidak didefinisikan: ERROR_MR_MID_NOT_FOUND"]

Gambar 13: Jembatan NTSTATUS ada dua jalur. Yang dimulai 0xD dibaca sebagai NTSTATUS setelah bit N dimatikan.

6. COM dan .NET — bagaimana kode error dipetakan ke exception

6.1. Cara COM — HRESULT + IErrorInfo

Metode COM pada dasarnya mengembalikan HRESULT, tetapi informasi yang muat di 32 bit terbatas, sehingga sebagai pelengkap mekanisme IErrorInfo dapat menyampaikan string penjelasan error dan sumber secara terpisah. Di C++, kelas dukungan kompiler _com_error menangani HRESULT dan IErrorInfo bersama. Aplikasi yang menampilkan “kode + teks penjelasan” di dialog error sering mengangkut teks itu lewat mekanisme ini.

flowchart TB
    accTitle: IErrorInfo yang melengkapi HRESULT
    accDescr: Informasi yang muat di HRESULT 32-bit terbatas, sehingga string penjelasan error dan sumber disampaikan terpisah lewat IErrorInfo; di C++ kelas _com_error menangani keduanya bersama
    hr["HRESULT（hanya 32 bit）"] --> lim["Informasi yang muat terbatas"]
    lim --> ei["IErrorInfo mengangkut teks penjelasan"]
    ei --> ce["_com_error menanganinya bersama"]
    ce -.-> dlg["Kode + teks penjelasan di dialog"]

Gambar 14: String penjelasan yang tidak muat di HRESULT 32-bit diangkut terpisah oleh IErrorInfo.

6.2. Cara .NET — dari HRESULT ke tipe exception

Runtime .NET, saat menerima kegagalan HRESULT lewat interop COM, mengonversinya menjadi exception. HRESULT yang dikenal dipetakan ke tipe exception yang sesuai; yang tidak dikenal menjadi COMException.¹¹

flowchart TB
    accTitle: Pemetaan HRESULT ke exception .NET
    accDescr: HRESULT gagal yang diterima lewat interop COM dikonversi ke tipe exception yang sesuai jika dikenal, atau ke COMException jika tidak; di keduanya nilai asli disimpan di Exception.HResult
    hr["HRESULT gagal"] --> known{"Ada pemetaan yang dikenal?"}
    known -->|Ya| typed["Konversi ke tipe exception yang sesuai"]
    known -->|Tidak| comex["Konversi ke COMException"]
    typed --> keep["Nilai asli disimpan di Exception.HResult"]
    comex --> keep

Gambar 15: .NET memetakan HRESULT ke tipe exception, dan di exception mana pun nilai asli tetap di Exception.HResult.

Pada exception mana pun, HRESULT asli disimpan di properti Exception.HResult. Percabangan seperti “hanya retry saat pelanggaran berbagi” dalam penanganan exception I/O file dapat ditulis dengan nilai ini.

try
{
    using var stream = File.Open(path, FileMode.Open, FileAccess.Read, FileShare.None);
}
catch (IOException ex) when (ex.HResult == unchecked((int)0x80070020))
{
    // 0x80070020 = HRESULT_FROM_WIN32(ERROR_SHARING_VIOLATION)
    // proses lain sedang memegang file — tunggu sebentar lalu retry, dan sejenisnya
}

6.3. P/Invoke dan GetLastError

Jika API Win32 dipanggil langsung lewat P/Invoke, tetapkan SetLastError = true pada DllImport (atau LibraryImport), lalu ambil dengan Marshal.GetLastWin32Error (di .NET 6 ke atas, GetLastPInvokeError yang setara). Mendefinisikan P/Invoke GetLastError sendiri lalu memanggilnya tidak akurat, karena panggilan API internal runtime dapat menimpa nilainya.¹⁵

flowchart TB
    accTitle: Mengambil last-error pada P/Invoke
    accDescr: Yang benar adalah SetLastError true lalu mengambil dengan Marshal.GetLastWin32Error; P/Invoke GetLastError secara langsung menjadi tidak akurat karena ditimpa runtime
    pi["Memanggil API Win32 lewat P/Invoke"] --> ok["Tetapkan SetLastError=true"]
    ok --> get["Ambil dengan GetLastWin32Error"]
    pi --> ng["Definisi yang memanggil GetLastError langsung"]
    ng --> bad["Runtime menimpa, tidak akurat"]

Gambar 16: Pada P/Invoke, pakai SetLastError=true dan Marshal.GetLastWin32Error sebagai satu paket. Pemanggilan GetLastError secara langsung tidak akurat.

[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
static extern SafeFileHandle CreateFileW(string fileName, uint access, uint share,
    IntPtr security, uint disposition, uint flags, IntPtr template);

// Terima nilai kembali sebagai SafeFileHandle, bukan IntPtr, lalu tutup pasti dengan using
// (jika dibiarkan sebagai IntPtr, handle kernel bocor)
using var handle = CreateFileW(@"C:\ProgramData\MyApp\config.dat",
    0x80000000 /*GENERIC_READ*/, 0, IntPtr.Zero, 3 /*OPEN_EXISTING*/, 0, IntPtr.Zero);
if (handle.IsInvalid)
{
    int code = Marshal.GetLastWin32Error();              // contoh: 5
    var message = new Win32Exception(code).Message;       // contoh: Akses ditolak.
    logger.LogError("CreateFileW failed: {Code} (0x{Code:X8}) {Message}",
        code, code, message);
}

Win32Exception mengambil string pesan OS dari kode error Win32, sehingga langsung dipakai untuk menyisakan kode dan pesan di log. Desain di lapis mana exception harus di-catch dan bagaimana dicatat di log dibahas di “Di mana catch dan log harus diletakkan dalam penanganan exception”.

7. Praktik alat konversi dan investigasi — rujukan cepat siap tempel

7.1. err.exe (Microsoft Error Lookup Tool)

Alat pencarian error berupa file eksekusi mandiri yang didistribusikan Microsoft. Alat ini menelusuri banyak file header seperti winerror.h dan ntstatus.h, lalu merinci definisi dan pesan yang cocok dengan kode yang ditentukan.⁸

err 0x80070005
err 5
err 0xC0000005

Satu angka dapat mengenai beberapa header (misalnya “5” cocok dengan definisi di berbagai tempat selain ERROR_ACCESS_DENIED Win32), sehingga kandidat mana yang layak harus dipilih dari konteks. Nama file unduhan berversi (pada saat penulisan, Err_6.4.5.exe), dan definisi kode mengikuti header pada saat bundel — perhatikan itu juga.⁸

flowchart TB
    accTitle: Hasil pencarian err.exe dipilih dari konteks
    accDescr: err.exe merinci definisi yang cocok dengan menelusuri banyak file header, sehingga jika satu angka menghasilkan beberapa kandidat, yang layak dipilih dari konteks
    in["Masukkan err 5"] --> scan["Pencarian lintas banyak header"]
    scan --> hits["Beberapa definisi mengenai"]
    hits --> pick["Pilih kandidat yang layak dari konteks"]

Gambar 17: Karena err.exe menelusuri lintas header, kandidat bisa lebih dari satu; yang layak dipilih dari konteks.

7.2. Perintah standar Windows

Yang dapat dipakai tanpa instalasi tambahan adalah certutil dan net helpmsg. Opsi -error certutil menampilkan teks pesan yang sesuai dengan kode error, dan menerima HRESULT heksadesimal maupun desimal.⁹

certutil -error 0x80070005
certutil -error 5
net helpmsg 5

net helpmsg khusus untuk desimal kode error Win32, tetapi pada lingkungan bahasa Jepang pesan dikembalikan dalam bahasa Jepang, sehingga dapat dipakai langsung untuk penjelasan kepada pengguna.

flowchart TB
    accTitle: Pembagian peran perintah standar
    accDescr: Kode error Win32 desimal ditelusuri dengan net helpmsg; kode yang mencakup HRESULT heksadesimal ditelusuri dengan opsi -error certutil
    q{"Kode di tangan?"} -->|Win32 desimal| net["net helpmsg"]
    q -->|Termasuk heksadesimal| cert["certutil -error"]
    net -.-> jp["Pesan dalam bahasa sistem dikembalikan"]
    cert -.-> any["Menerima heksadesimal maupun desimal"]

Gambar 18: Pembagian peran perintah standar. Error Win32 desimal: net helpmsg; jika mencakup heksadesimal: certutil -error.

7.3. Kumpulan one-liner PowerShell

# kode error Win32 → string pesan OS
[System.ComponentModel.Win32Exception]::new(5).Message
# → Akses ditolak.

# desimal negatif → notasi heksadesimal (konfirmasi identitas HRESULT)
'0x{0:X8}' -f -2147467259     # 0x80004005

# 0x8007xxxx → kode error Win32 16 bit rendah
0x80070005 -band 0xFFFF        # 5

# HRESULT → konfirmasi exception yang dipetakan .NET
[System.Runtime.InteropServices.Marshal]::GetExceptionForHR(-2147024891)
# → UnauthorizedAccessException (0x80070005)

# kode error Win32 → HRESULT (reproduksi bungkus ulang)
'0x{0:X8}' -f (0x80070000 -bor 32)   # 0x80070020

7.4. !error di WinDbg

Untuk menelusuri kode saat analisis dump, ekstensi !error WinDbg cepat. Secara default ditafsirkan sebagai kode error Win32; tambahkan 1 sebagai argumen kedua untuk menafsirkannya sebagai NTSTATUS.¹⁰

0:000> !error 5
Error code: (Win32) 0x5 (5) - アクセスが拒否されました。

0:000> !error 0xc0000005 1
Error code: (NTSTATUS) 0xc0000005 - <アクセス違反>

Pada crash dump, !analyze -v menampilkan exception code (NTSTATUS) secara otomatis, lalu dari situ makna dikonfirmasi dengan !error <code> 1.

flowchart TB
    accTitle: Alur konfirmasi exception code di WinDbg
    accDescr: Pada crash dump, perintah analyze menampilkan exception code secara otomatis, lalu kode itu diteruskan ke ekstensi error dengan argumen kedua 1 untuk mengonfirmasi makna sebagai NTSTATUS
    dump["Buka crash dump"] --> an["Jalankan !analyze -v"]
    an --> exc["Exception code ditampilkan"]
    exc --> chk["Konfirmasi makna dengan !error kode 1"]

Gambar 19: Dalam analisis dump, exception code yang ditampilkan !analyze -v ditelusuri dengan !error plus flag 1.

8. Prosedur investigasi — dari penentuan lapis sampai pencocokan dengan konteks

Pengetahuan sejauh ini disusun menjadi prosedur investigasi kode error yang aktual.

1. Rapikan notasi. Jika desimal negatif, konversi ke 8 digit heksadesimal. Heksadesimal kurang dari 8 digit dibaca dengan zero-fill.
2. Tentukan lapis mana kodenya. Seperti tabel penentuan di bawah, beberapa digit terdepan hampir selalu cukup.
3. Uraikan dan keluarkan kode esensial. Jika 0x8007xxxx, 16 bit rendah; jika 0xDxxxxxxx, matikan bit N — operasi mekanis.
4. Tarik nama dan definisi dengan alat. Konfirmasi nama simbol dan pesan dengan salah satu dari err.exe, certutil, atau !error.
5. Cocokkan dengan konteks. Identifikasi aplikasi mana · operasi mana · API mana · gagal terhadap apa, lewat log aplikasi, event log, dan Procmon. Kode adalah “jenis kegagalan”; konteks adalah “lokasi penyebab”.

flowchart TB
    accTitle: Prosedur investigasi kode error
    accDescr: Pola investigasi: rapikan notasi ke heksadesimal, tentukan lapis dari beberapa digit terdepan, uraikan dan keluarkan kode esensial, tarik nama dan definisi dengan alat, lalu cocokkan dengan konteks
    fix["Rapikan notasi（negatif ke 8 digit heksadesimal）"] --> judge{"Beberapa digit terdepan?"}
    judge -->|Notasi desimal| d1["Baca sebagai error Win32"]
    judge -->|0x8007| d2["Ubah 16 bit rendah ke desimal"]
    judge -->|0xC| d3["Baca sebagai NTSTATUS"]
    judge -->|0xD| d4["Matikan bit N lalu baca"]
    d1 --> tool["Tarik nama dan definisi dengan alat"]
    d2 --> tool
    d3 --> tool
    d4 --> tool
    tool --> ctx["Cocokkan dengan konteks（Procmon dll.）"]

Gambar 20: Pola investigasi. Rapikan notasi, tentukan lapis lalu uraikan, tarik nama, kemudian cocokkan dengan konteks.

Yang terutama efektif pada langkah 5 “pencocokan dengan konteks” adalah kolom Result Process Monitor. Meski aplikasi hanya menampilkan “0x80070002”, Procmon menunjukkan dalam satu baris “proses mana · path mana · NAME NOT FOUND yang dikembalikan”. Cara menelusuri sisi event log juga ada di “Pengantar Windows Event Log dan ETW”.

9. Salah baca yang sering — pola yang memutar jauh investigasi

Terakhir, pola salah baca yang muncul dalam konsultasi aktual.

Salah baca 1: Menganggap 0x80004005 “kode yang menunjukkan penyebab tertentu”

E_FAIL adalah “kegagalan yang tidak ditentukan”; nilai yang sama muncul di Windows Update, jaringan, maupun basis data. Mencoba perbaikan yang muncul dari pencarian kode ini secara acak hampir pasti memutar jauh. Jangan dari kode, melainkan persempit dari “aplikasi mana · operasi mana · log lain pada waktu yang sama”.⁶

Salah baca 2: Tidak menyadari desimal negatif adalah HRESULT

Kasus log “Terjadi error -2147467259” dicari apa adanya, atau dikacaukan sebagai “error minus?”. Jika negatif, ubah ke heksadesimal. Itu saja sudah terlihat 0x80004005 (E_FAIL), dan tersambung ke pengetahuan salah baca 1.

Salah baca 3: Menelusuri 0x8007xxxx sebagai 8 digit utuh, tanpa melihat error Win32 di bagian rendah

Esensi 0x80070005 adalah “5 = akses ditolak”. Lebih cepat sampai ke inti jika 16 bit rendah dikeluarkan, lalu dipikirkan “apa arti error Win32 5 dalam konteks operasi ini”, daripada mencari 8 digit secara keseluruhan.

Salah baca 4: Mengira “kode sama = penyebab sama”

Jika pernah “error 5 disebabkan perangkat lunak antivirus”, error 5 berikutnya mudah diloncat ke penanganan yang sama. Meski kodenya sama, jika API yang gagal dan sumber daya sasaran berbeda, penyebabnya lain. Konfirmasi arti kode dan identifikasi sasaran dengan Procmon atau sejenisnya harus dilakukan sebagai satu paket setiap kali.

Salah baca 5: Mengacaukan error Win32 5 dengan 0xC0000005, STOP code dengan NTSTATUS

Jika ERROR_ACCESS_DENIED dan STATUS_ACCESS_VIOLATION disamakan karena sama-sama “5”, investigasi menyimpang ke arah yang sama sekali berbeda: masalah hak versus bug program. Selain itu, STOP code layar biru adalah sistem terpisah dari NTSTATUS, sehingga menarik 0x9F dari tabel NTSTATUS tidak menghasilkan jawaban yang bermakna.¹⁴

flowchart TB
    accTitle: Arah investigasi error 5 dan 0xC0000005 berbeda
    accDescr: Error Win32 5 harus ditelusuri sebagai masalah hak, NTSTATUS 0xC0000005 sebagai bug program; menyamakannya membuat investigasi menyimpang
    a["Error Win32 5"] --> ad["Telusuri masalah hak"]
    b["NTSTATUS 0xC0000005"] --> bd["Telusuri bug program"]
    a -.-> memo["Kode tidak terkait dari sistem lain"]
    b -.-> memo

Gambar 21: Jangan disamakan hanya karena “5”. Error 5 menuju masalah hak; 0xC0000005 menuju bug program.

10. Ringkasan

• Kode error Windows adalah struktur tiga lapis: kode error Win32, HRESULT, dan NTSTATUS. Tentukan dulu lapis mana, pihak mana yang mengembalikan kodenya.
• Variasi notasi (desimal/heksadesimal/negatif) dapat dirapikan secara mekanis. Negatif diubah ke 8 digit heksadesimal, baru dibaca.
• HRESULT berstruktur bit S/R/C/N/X + Facility (11 bit) + Code (16 bit). 0x8007xxxx adalah pola terpenting: bungkus ulang error Win32. Ubah 16 bit rendah ke desimal untuk mengeluarkan kode esensial.
• Kode generik seperti 0x80004005 (E_FAIL) tidak menunjukkan penyebab. Keputusan untuk berhenti menggali kode dan beralih ke investigasi konteks justru dimungkinkan karena strukturnya diketahui.
• NTSTATUS dijumpai sebagai exception code crash atau kolom Result Procmon. 0xC0000005 adalah pelanggaran akses, tidak terkait error Win32 5. STOP code adalah sistem yang lagi-lagi berbeda.
• Di .NET, HRESULT dipetakan ke tipe exception, dan nilai asli tetap di Exception.HResult. Pada P/Invoke, pakai SetLastError=true dan Marshal.GetLastWin32Error sebagai satu paket.
• Alat penelusuran lengkap: certutil -error · net helpmsg (standar), err.exe (mesin pengembangan), one-liner PowerShell, !error WinDbg.
• Prosedurnya: “rapikan notasi → tentukan lapis → uraikan → tarik nama → cocokkan dengan konteks”. Yang diajarkan kode hanya sampai jenis kegagalan; lokasi penyebab diajarkan konteks.

Saat bertemu kode error yang tidak familiar berikutnya, lihat beberapa digit terdepan sebelum menempelkannya ke kotak pencarian. Jika 0x8007, 4 digit rendah; jika 0xC, NTSTATUS; jika negatif, ubah ke heksadesimal — penguraian 10 detik ini sangat memengaruhi waktu investigasi setelahnya.

Artikel terkait

• Membaca crash dump dengan WinDbg + SOS — pengantar analisis praktis setelah pengumpulan
• Pengantar pengumpulan crash dump Windows - WER/ProcDump/WinDbg
• Di mana catch dan log harus diletakkan dalam penanganan exception
• Panduan praktis Process Monitor (ProcMon) — mengidentifikasi “pengaturan tidak terbaca” dan “ACCESS DENIED” dalam 10 menit
• Pengantar Windows Event Log dan ETW — menempatkan log aplikasi bisnis pada mekanisme standar OS

Area konsultasi terkait

Di Komura Soft LLC, kami menangani investigasi gangguan yang berangkat dari kode error — “arti kode error ini tidak jelas”, “0x80070005 hanya muncul di lingkungan tertentu” — desain penanganan error aplikasi yang mencampur Win32 API, COM, dan .NET, serta identifikasi penyebab dengan crash dump dan Process Monitor. Konsultasi dari satu tangkapan layar dialog error pun tidak apa-apa.

• Pengembangan aplikasi Windows
• Investigasi bug dan analisis penyebab
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apa arti error 0x80004005?

0x80004005 adalah HRESULT E_FAIL, yang artinya "Unspecified failure" (kegagalan yang tidak ditentukan). Dengan kata lain, kode ini hanya menandai bahwa "terjadi kegagalan yang tidak dapat melaporkan alasan rinci"; bukan kode yang mewakili penyebab itu sendiri. Itulah sebabnya 0x80004005 yang sama bisa muncul di situasi yang tidak saling terkait — jaringan, Windows Update, VBA, driver basis data, dan lain-lain. Jika kode ini muncul, jangan menggali makna kodenya. Persempit penyebab dari konteks: aplikasi dan operasi mana yang menghasilkannya, plus informasi error lain di event log atau log rinci.

Apa kode error negatif seperti -2147467259?

Itu HRESULT 32-bit yang ditampilkan sebagai desimal bertanda. Saat gagal, bit paling signifikan HRESULT menjadi 1, sehingga tampilan sebagai bilangan bulat bertanda selalu negatif. Di PowerShell, '0x{0:X8}' -f -2147467259 mengembalikannya ke notasi heksadesimal (pada contoh ini 0x80004005 = E_FAIL). Jika di log atau pesan error skrip muncul angka negatif yang dimulai dengan -214…, langkah baku pertama adalah mengubahnya ke heksadesimal, baru kemudian menelusurinya.

Apa cara paling mudah untuk mencari arti kode error?

Tanpa instalasi tambahan, gunakan net helpmsg 5 di Command Prompt (untuk error Win32 dalam desimal) dan certutil -error 0x80070005. certutil juga menerima HRESULT heksadesimal, lalu menampilkan nama simbol dan teks pesan. Di PowerShell, [System.ComponentModel.Win32Exception]::new(5).Message mengambil pesan dalam bahasa sistem. Di mesin pengembangan, simpan alat pencarian resmi Microsoft err.exe (Microsoft Error Lookup Tool); alat ini menelusuri Win32, HRESULT, dan NTSTATUS sekaligus dan merinci definisi yang cocok.

Error seperti apa 0xC0000005?

Itu NTSTATUS STATUS_ACCESS_VIOLATION, yaitu pelanggaran akses (akses memori yang tidak sah). Kode ini paling sering muncul sebagai "Exception code" di event log atau crash dump saat aplikasi crash, dan menandai bug program seperti dereferensi pointer tidak valid atau akses ke memori yang sudah dibebaskan. Namanya mirip error Win32 5 (ERROR_ACCESS_DENIED = akses ditolak), tetapi itu kode yang tidak terkait dari sistem lain, jadi jangan dikacaukan. Cara andal untuk mengidentifikasi penyebab adalah mengambil crash dump lalu menganalisisnya di WinDbg.

Mengapa penyebabnya berbeda setiap kali, padahal kode errornya sama?

Karena kode error hanya menyatakan "jenis kegagalan"; "apa yang gagal dan mengapa" ditentukan oleh konteks pemanggilan. Error 5 (akses ditolak), misalnya, adalah kode yang sama untuk penyebab yang sama sekali berbeda: izin NTFS kurang, hak administrator tidak cukup, blokir perangkat lunak antivirus, dan seterusnya. Dalam situasi yang mirip, jika proses lain masih membuka file, kodenya berbeda (error 32 = pelanggaran berbagi), dan membaca kode dengan benar mengubah tempat yang perlu diperiksa. Error 2 (file tidak ditemukan) juga sering bukan file utama, melainkan DLL dependen atau file pengaturan. Setelah arti kodenya diketahui, memastikan API mana yang gagal terhadap sumber daya mana — misalnya dengan Process Monitor — adalah jalan pendek ke penyebab.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.