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

“Layar aplikasi menampilkan error 0x80004005. Apa artinya?” — Dalam konsultasi investigasi insiden, pertanyaan semacam ini klasik. Siapa pun yang menempelkan angka dari dialog error langsung ke mesin pencari dan 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, punya banyak teman.

Itu terjadi karena 0x80004005 (E_FAIL) adalah kode generik yang satu-satunya maknanya “kegagalan tidak ditentukan”. Kode yang sama dipakai di situasi tak terhitung, jadi mencari hanya berdasarkan kode tidak sampai ke penyebab. Di sisi lain, kode seperti 0x80070005, jika Anda tahu strukturnya, dapat diuraikan dalam beberapa detik sebelum mencari menjadi “nomor error Win32 5 = akses ditolak, dibungkus sebagai HRESULT”.

Kode error Windows, karena alasan historis, membentuk tiga lapis — kode error Win32, HRESULT, dan NTSTATUS — dan dikonversi lintas lapis. Setelah struktur itu ada di kepala, Anda dapat menilai sendiri “lapis mana, pihak mana yang mengembalikan kode ini” dan “apa kode esensialnya”, dan langkah pembuka investigasi menjadi jauh lebih cepat.

Ditujukan kepada staf IT usaha kecil dan menengah serta pengembang aplikasi Windows, artikel ini menata cara membedakan dan menguraikan ketiga sistem kode error, hubungan dengan pengecualian .NET, dan pencarian praktis dengan err.exe serta PowerShell — berpijak pada Microsoft Learn dan spesifikasi terbitan [MS-ERREF] per Agustus 2026.

1. Kesimpulan dulu

• Kode error Windows terutama tiga sistem. Kode error Win32 (desimal kecil yang dikembalikan GetLastError), HRESULT (kode 32-bit sejak COM, hex 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 0x80070005” semuanya merujuk ERROR_ACCESS_DENIED (akses ditolak).¹
• 0x8007xxxx adalah “error Win32 yang dibungkus”. Itu kode error Win32 yang disimpan di HRESULT FACILITY_WIN32 (7); konversi 16 bit rendah ke desimal dan Anda punya kode esensial. 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 dari 32 bit (bit kegagalan) disetel, jadi tampilan bertanda negatif. Konversi ke hex lalu baca.²
• Nilai 8 digit yang dimulai 0xC adalah NTSTATUS. 0xC0000005 (pelanggaran akses) dan 0xC0000135 (DLL tidak ditemukan) terus muncul di event log dan dump saat crash. Mereka tidak terkait dengan nomor error Win32 5.⁷
• Kode yang sama mengubah makna bersama konteks. Penyebab error 5 mencakup ACL, elevasi, antivirus, file yang ditahan, dan lainnya, dan “file tidak ditemukan” error 2 sering DLL dependen. Selalu baca makna kode bersama API mana yang gagal terhadap apa.¹
• Alat konversi dan pencarian adalah standar. certutil -error dan net helpmsg built-in di Windows; Win32Exception PowerShell mengambil pesan; di mesin pengembangan err.exe (Microsoft Error Lookup Tool); dalam analisis dump !error WinDbg.⁸⁹¹⁰
• Di .NET, HRESULT dipetakan ke tipe pengecualian. HRESULT yang dikenal pergi ke 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 hex → nilai lapis mana kodenya → uraikan dan keluarkan kode esensial → baca bersama konteks”.

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 mereka bertumpuk dalam urutan ini: kode error Win32 yang mewarisi nomor error MS-DOS, NTSTATUS yang dipakai kernel NT secara internal, dan HRESULT yang dirancang saat pengenalan COM untuk “mengemas sukses/gagal dan asal ke 32 bit”. Di Windows sekarang, alur konversi sehari-hari: kernel mengembalikan NTSTATUS, subsistem Win32 mengonversinya ke 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, dan 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| hr["HRESULT（0x8007xxxx）"]

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

2.1. Biasakan membaca desimal dan heksadesimal secara bergantian

Sebelum membedakan ketiga sistem, Anda perlu menyerap goyangan notasi. Kode yang sama ditampilkan sebagai desimal atau hex 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.

# Decimal → hex
'0x{0:X8}' -f 1223          # 0x000004C1
'0x{0:X8}' -f -2147024891   # 0x80070005 (negative = HRESULT to hex)

# Hex → decimal
0x4C1                        # 1223

Ketika Anda melihat desimal negatif yang dimulai “-214…”, secara refleks konversi ke hex. Itu saja memotong banyak tersesat di pintu masuk investigasi.

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

Gambar 2: Desimal, hex, 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 dengan 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 Anda menyelipkan panggilan API lain (fungsi logging, misalnya) 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 lalu 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 App
    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 bendera FORMAT_MESSAGE_FROM_SYSTEM.¹

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

void PrintLastError(const wchar_t* apiName)
{
    DWORD code = GetLastError();   // Call immediately after failure (do not insert another API)
    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);
}

Meninggalkan baik desimal maupun hex dan teks pesan di log aplikasi Anda, seperti ini, membuat investigasi kemudian selangkah lebih cepat.

flowchart TB
    accTitle: Cari pesan dari kode dan tinggalkan di log
    accDescr: Berikan bendera FORMAT_MESSAGE_FROM_SYSTEM ke FormatMessage untuk mendapatkan string pesan kode error, dan tinggalkan desimal, hex, serta teks 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, hex, dan teks bersama"]

Gambar 4: Konversi kode error ke string pesan dengan FormatMessage, dan tinggalkan desimal, hex, serta teks bersama di log.

3.2. Kode representatif yang terus muncul di lapangan

Kode error Win32 didefinisikan di rentang 0–15999, dan Microsoft Learn punya daftar lengkap.¹ Di antaranya, wajah yang Anda temui berulang dalam investigasi insiden adalah berikut.

Dari ini, 998 (ERROR_NOACCESS) bukan “akses ditolak” melainkan ungkapan Win32 dari pelanggaran akses memori, bentuk NTSTATUS STATUS_ACCESS_VIOLATION yang dibahas nanti setelah konversi ke lapis Win32. Waspadai kekacauan dengan nomor 5. Juga, 1223 (ERROR_CANCELLED) adalah kode yang muncul ketika pengguna memilih “Tidak” di dialog elevasi UAC, misalnya — lebih “dibatalkan” daripada error.

flowchart TB
    accTitle: Error 998 dan 5 adalah hal berbeda
    accDescr: 998 adalah pelanggaran akses memori, pelanggaran akses NTSTATUS yang dikonversi ke lapis Win32, dan berbeda makna dari 5 yang mewakili 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 izin. Hal berbeda dari 998"]

Gambar 5: Error 998 adalah pelanggaran akses NTSTATUS yang dikonversi ke lapis Win32, hal berbeda dari akses-ditolak 5.

3.3. Kode yang sama mengubah makna bersama konteks

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

• Error 5 (akses ditolak): kandidat penyebab luas — ACL NTFS kurang, menulis area terlindung tanpa hak administrator, blok antivirus atau AppLocker, hak akun layanan kurang, dan seterusnya.
• Error 2 (file tidak ditemukan): tidak selalu file yang ditentukan pengguna. DLL dependen yang coba dimuat EXE secara implisit, file pengaturan yang terlihat di tempat salah karena pengalihan registri (32-bit/64-bit), jalur yang perluasan variabel lingkungannya gagal — “file mana” yang tidak ditemukan tidak terlihat dari kode.
• Error 32 (pelanggaran berbagi): “proses mana yang menahannya” adalah pertanyaan sebenarnya, tetapi kodenya tidak memberi tahu itu.

flowchart TB
    accTitle: Penyebab error 5 diputuskan oleh konteks
    accDescr: Bahkan akses ditolak yang sama punya beberapa kandidat penyebab seperti ACL kurang atau hak administrator tidak ada, dan Anda perlu mengidentifikasi API mana yang gagal terhadap apa
    e5["Error 5（akses ditolak）"] --> c1["ACL kurang"]
    e5 --> c2["Tanpa hak administrator"]
    e5 --> c3["Blok produk keamanan"]
    e5 --> c4["Hak layanan rendah"]
    c1 --> next["Procmon: target yang gagal"]
    c2 --> next
    c3 --> next
    c4 --> next

Gambar 6: Kode hanya memberi tahu “jenis kegagalan”. Error 5 punya beberapa kandidat penyebab, dan mengidentifikasi target diperlukan.

Alat yang mengukur “API mana, terhadap nama objek mana, mengembalikan hasil mana” adalah Process Monitor. Cara memakainya dibahas rinci di “Panduan praktis Process Monitor (ProcMon)”. Mencari makna kode error dan mengidentifikasi target yang gagal adalah dua roda gerobak yang sama.

4. HRESULT — Membaca struktur yang dikemas ke 32 bit

4.1. Tata letak bit

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

Bit S paling signifikan adalah 1, yaitu HRESULT yang notasi hex-nya dimulai di 0x8 atau di atas adalah kegagalan. Menampilkannya sebagai bilangan bulat 32-bit bertanda membuatnya negatif — itulah identitas “-214…” yang disebut sebelumnya.

flowchart TB
    accTitle: Hubungan bit S dan tampilan negatif
    accDescr: HRESULT gagal punya bit S paling signifikan disetel ke 1, jadi di hex dimulai di 0x8 atau di atas, dan sebagai bilangan bulat 32-bit bertanda ia negatif
    s["Bit S = 1（gagal）"] --> hex["Hex dimulai di 0x8 atau di atas"]
    hex --> neg["Tampilan bertanda negatif"]
    neg --> back["Saat melihat negatif, konversi ke hex dan baca"]

Gambar 7: HRESULT gagal dimulai di 0x8 atau di atas karena bit S adalah 1, dan tampilan bertanda negatif.

Nilai Facility representatif sebagai berikut.⁵

4.2. Menguraikan 0x80004005 dan 0x80070005

Mari uraikan mereka sungguhan.

Untuk 0x80004005: S=1 (gagal), Facility=(0x80004005 » 16) & 0x7FF = 0 (FACILITY_NULL), Code=0x4005. Kode FACILITY_NULL generik, didefinisikan sebagai E_FAIL “Unspecified failure”.⁶ Dengan kata lain kode ini hanya membawa makna “kegagalan yang tidak dapat melaporkan rinci”. Ketika Anda melihat 0x80004005, berhentilah menggali kodenya sendiri di situ, dan pindahkan bobot investigasi ke “komponen mana yang mengembalikannya” dan “apakah ada rinci di event log atau log aplikasi pada saat yang sama”.

Untuk 0x80070005: S=1, Facility=7 (FACILITY_WIN32), Code=0x0005=5. Anda dapat melihat bahwa itu nomor error Win32 5 (ERROR_ACCESS_DENIED) yang dibungkus sebagai HRESULT. Alias E_ACCESSDENIED pada dasarnya nilai ini.⁶

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

flowchart TB
    accTitle: Uraian 0x80004005 dan 0x80070005
    accDescr: 0x80004005 adalah kode FACILITY_NULL generik E_FAIL, tidak membawa rinci, dan harus beralih ke investigasi konteks; 0x80070005 adalah FACILITY_WIN32 dan dapat dibaca sebagai bungkus nomor error Win32 5, akses ditolak
    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: Bahkan “kegagalan” yang sama punya jumlah informasi berbeda setelah diuraikan. 0x80070005 dapat dijalan ke nomor error Win32 5.

4.3. Pola paling penting: 0x8007xxxx = HRESULT_FROM_WIN32

Untuk menyampaikan kegagalan dari lapis bawah yang hanya dapat mengembalikan kode error Win32 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), dan setel bit S ke 1”.

flowchart TB
    accTitle: Cara kerja HRESULT_FROM_WIN32
    accDescr: Simpan kode error Win32 di 16 bit rendah, setel Facility ke 7 dan bit S ke 1, dan rakit 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 dan menyetel Facility=7 serta 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)

Untuk membaca arah sebaliknya, ambil 16 bit rendah di PowerShell.

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

Seperti pada contoh kedua, error WinINet dan WinHTTP (ribuan 12000) juga didefinisikan di ruang kode error Win32¹, jadi 0x8007xxxx jaringan dapat diuraikan dengan prosedur yang sama. Memasukkan “ketika Anda melihat 0x8007, konversi 4 digit rendah ke desimal” ke memori otot adalah keterampilan praktis nomor satu yang ingin artikel ini Anda bawa pulang.

Ada peringatan sebaliknya untuk 0x8004xxxx (FACILITY_ITF). Kode FACILITY_ITF punya pihak yang mendefinisikan makna berbeda per antarmuka, jadi nilai 32-bit yang sama dapat berarti sesuatu lain jika pihak yang mengembalikannya berbeda.⁵ Untuk 0x8004xxxx yang tidak akrab, cari bukan di pencarian generik melainkan di dokumentasi komponen yang mengembalikannya (pustaka, SDK driver, produk server).

flowchart TB
    accTitle: Cara mencari berubah antara 0x8007 dan 0x8004
    accDescr: FACILITY_WIN32 0x8007xxxx dapat dibaca dengan menguraikan 16 bit rendah secara mekanis, tetapi FACILITY_ITF 0x8004xxxx punya pihak yang mendefinisikan makna berbeda per antarmuka, jadi cari di bahan komponen yang mengembalikan
    hr{"Facility adalah?"} -->|7, WIN32| w["Konversi 16 bit rendah ke desimal"]
    hr -->|4, ITF| i["Makna berbeda menurut pihak yang mengembalikan"]
    w --> ww["Baca sebagai error Win32"]
    i --> ii["Cari di bahan pihak yang mengembalikan"]

Gambar 10: 0x8007xxxx dapat diuraikan secara mekanis; 0x8004xxxx dicari di bahan komponen yang mengembalikan.

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, dan tata letaknya mirip HRESULT tanpa sama.³

Karena severity 2 bit, Anda dapat membaca jenis dari digit hex depan. 0xC… adalah error (11), 0x8… peringatan (10), 0x4… informasional (01), 0x0–0x3… sukses. Pengecualian breakpoint 0x80000003 (STATUS_BREAKPOINT) adalah contoh representatif “peringatan, bukan error”.³⁷

flowchart TB
    accTitle: NTSTATUS dapat dibaca jenisnya dari digit depan
    accDescr: Karena severity 2 bit, NTSTATUS dapat dibaca sebagai error jika digit hex depan 0xC, peringatan jika 0x8, informasional jika 0x4, dan sukses jika 0x0 sampai 0x3
    head{"Digit hex depan adalah?"} -->|0xC| e["Galat"]
    head -->|0x8| w["Peringatan"]
    head -->|0x4| i["Informasional"]
    head -->|0x0–0x3| s["Sukses"]
    w -.-> ex["Contoh: 0x80000003 adalah peringatan"]

Gambar 11: NTSTATUS dapat dibaca jenisnya dari digit hex depan. 0x80000003 adalah “peringatan, bukan error”.

5.2. Di mana Anda menemuinya — kode pengecualian, kode STOP, dan event log

Situasi di mana staf IT dan pengembang menemui NTSTATUS terutama terkait crash.

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

• Kode STOP layar biru: kelihatan mirip sekilas, tetapi kode STOP (bug check code) adalah sistem penomoran sendiri, terpisah dari NTSTATUS, seperti 0x0000009F (DRIVER_POWER_STATE_FAILURE), dan punya referensi khusus.¹⁴ Mengingat hanya pembedaan “0xC0000005 adalah NTSTATUS; STOP 0x9F adalah kode bug check dan Anda tidak boleh mencarinya di tabel NTSTATUS” sudah cukup.
• 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, STATUS_ACCESS_DENIED). Itu juga tempat Anda merasakan korespondensi lapis: mengamati kegagalan I/O file dalam kosakata NTSTATUS dan kegagalan itu dikonversi ke error Win32 lalu sampai ke aplikasi.

flowchart TB
    accTitle: Membedakan kode pengecualian dari kode STOP
    accDescr: Baca kode pengecualian event log sebagai NTSTATUS; cari kode STOP layar biru di referensi kode bug-check khusus, sistem lain
    q{"Di mana kode muncul?"} -->|Kode pengecualian| nt["Baca sebagai NTSTATUS"]
    q -->|Kode STOP| bc["Cari di tabel kode bug-check"]
    nt -.-> n1["Contoh: 0xC0000005"]
    bc -.-> b1["Contoh: 0x0000009F"]

Gambar 12: Kode pengecualian event log adalah NTSTATUS; kode STOP layar biru adalah sistem lain. Jangan mencari di tabel yang salah.

Investigasi di luar kode pengecualian, yaitu menangkap dan menganalisis crash dump, dibahas di “Pengantar pengumpulan crash dump Windows” dan “Membaca crash dump dengan WinDbg + SOS”.

5.3. Hubungan dengan HRESULT — bit N dan RtlNtStatusToDosError

Jembatan antara NTSTATUS dan dua lapis lain punya dua jalur.

1. Pemetaan ke ruang HRESULT: Menyetel bit N HRESULT (0x10000000) membawa nilai NTSTATUS ke ruang HRESULT apa adanya (makro HRESULT_FROM_NT di winerror.h). Memetakan 0xC0000005 menjadi 0xD0000005, misalnya. Ketika Anda melihat HRESULT yang dimulai 0xD, prosedur yang benar adalah mencopot bit N dan membacanya sebagai NTSTATUS.²
2. Konversi ke kode error Win32: RtlNtStatusToDosError ntdll mengonversi NTSTATUS ke kode error Win32 yang sesuai. Nilai tanpa korespondensi terdefinisi menjadi ERROR_MR_MID_NOT_FOUND.¹² Misalnya STATUS_ACCESS_VIOLATION (0xC0000005) dikonversi ke ERROR_NOACCESS (998), dan STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034) ke ERROR_FILE_NOT_FOUND (2). Berguna juga mengingat bahwa kosakata kaya kernel kadang dibulatkan ke pembedaan yang lebih kasar di lapis Win32.

flowchart TB
    accTitle: Dua jembatan dari NTSTATUS ke lapis lain
    accDescr: NTSTATUS diteruskan ke lapis lain dengan dua cara: dipetakan ke ruang HRESULT dengan menyetel bit N, dan dikonversi ke kode error Win32 oleh RtlNtStatusToDosError
    nt["NTSTATUS（0xC0000005）"] -->|Setel bit N| hr["HRESULT（0xD0000005）"]
    nt -->|RtlNtStatusToDosError| win["Error Win32 998（ERROR_NOACCESS）"]
    win -.-> memo["ERROR_MR_MID_NOT_FOUND jika korespondensi tidak didefinisikan"]

Gambar 13: Ada dua jembatan NTSTATUS. Awal 0xD dibaca sebagai NTSTATUS setelah bit N dicopot.

6. COM dan .NET — Bagaimana kode error dipetakan ke pengecualian

6.1. Gaya COM — HRESULT + IErrorInfo

Metode COM pada dasarnya mengembalikan HRESULT, tetapi ada batas apa yang dapat dikemas ke 32 bit, jadi sebagai pelengkap mekanisme IErrorInfo dapat menyampaikan string deskripsi error dan asal secara terpisah. Di C++, kelas _com_error yang didukung kompiler menangani HRESULT dan IErrorInfo bersama. Aplikasi yang dialog error-nya menampilkan “kode + deskripsi” sering membawa deskripsi lewat mekanisme ini.

flowchart TB
    accTitle: IErrorInfo yang melengkapi HRESULT
    accDescr: Ada batas apa yang dapat dikemas ke HRESULT 32-bit, jadi string deskripsi error dan asal disampaikan terpisah dengan IErrorInfo, dan di C++ kelas _com_error menangani keduanya bersama
    hr["HRESULT（hanya 32 bit）"] --> lim["Ada batas apa yang dikemas"]
    lim --> ei["IErrorInfo membawa deskripsi"]
    ei --> ce["_com_error menanganinya bersama"]
    ce -.-> dlg["Kode + deskripsi dialog"]

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

6.2. Gaya .NET — dari HRESULT ke tipe pengecualian

Ketika runtime .NET menerima kegagalan HRESULT di COM interop, ia mengonversinya ke pengecualian. HRESULT yang dikenal dipetakan ke tipe pengecualian yang sesuai; yang tidak dikenal menjadi COMException.¹¹

flowchart TB
    accTitle: Pemetaan dari HRESULT ke pengecualian .NET
    accDescr: HRESULT gagal yang diterima di COM interop dikonversi ke tipe pengecualian yang sesuai jika dikenal, atau ke COMException jika tidak, dan dalam kedua kasus nilai asli disimpan di Exception.HResult
    hr["HRESULT gagal"] --> known{"Pemetaan dikenal?"}
    known -->|Yes| typed["Konversi ke tipe pengecualian yang sesuai"]
    known -->|No| comex["Konversi ke COMException"]
    typed --> keep["Nilai asli disimpan di Exception.HResult"]
    comex --> keep

Gambar 15: .NET memetakan HRESULT ke tipe pengecualian, dan nilai asli tetap di Exception.HResult pada setiap pengecualian.

Pada setiap pengecualian, HRESULT asli disimpan di properti Exception.HResult. Percabangan dalam penanganan pengecualian I/O file seperti “coba lagi hanya pada pelanggaran berbagi” 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)
    // Another process is holding the file — wait a little and retry, for example
}

6.3. P/Invoke dan GetLastError

Ketika Anda memanggil API Win32 langsung lewat P/Invoke, tentukan SetLastError = true pada DllImport (atau LibraryImport), lalu ambil dengan Marshal.GetLastWin32Error (dari .NET 6, setara GetLastPInvokeError). Mendefinisikan GetLastError sendiri sebagai P/Invoke dan memanggilnya tidak akurat, karena panggilan API di dalam runtime dapat menimpa nilainya.¹⁵

flowchart TB
    accTitle: Mengambil error terakhir di P/Invoke
    accDescr: Menentukan SetLastError sebagai true dan mengambil dengan Marshal.GetLastWin32Error benar; memanggil GetLastError langsung lewat P/Invoke tidak akurat karena penimpaan runtime
    pi["Panggil API Win32 lewat P/Invoke"] --> ok["Tentukan SetLastError=true"]
    ok --> get["Ambil dengan GetLastWin32Error"]
    pi --> ng["Definisi yang memanggil GetLastError langsung"]
    ng --> bad["Runtime menimpa dan tidak akurat"]

Gambar 16: Di P/Invoke, pakai SetLastError=true dan Marshal.GetLastWin32Error sebagai satu set. Memanggil GetLastError 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);

// Receive the return value as SafeFileHandle, not IntPtr, and close it reliably with using
// (leaving it as IntPtr leaks a kernel handle)
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();              // Example: 5
    var message = new Win32Exception(code).Message;       // Example: Access is denied.
    logger.LogError("CreateFileW failed: {Code} (0x{Code:X8}) {Message}",
        code, code, message);
}

Win32Exception mencari string pesan OS dari kode error Win32, jadi Anda dapat memakainya apa adanya untuk meninggalkan baik kode maupun pesan di log. Pertanyaan desain di lapis mana menangkap pengecualian dan bagaimana meninggalkannya di log dibahas di “Di mana catch dan logging harus diletakkan dalam penanganan pengecualian?”.

7. Alat konversi dan investigasi dalam praktik — referensi cepat salin-tempel

7.1. err.exe (Microsoft Error Lookup Tool)

Alat pencarian error mandiri yang didistribusikan Microsoft. Ia menelusuri banyak file header seperti winerror.h dan ntstatus.h serta merinci definisi dan pesan yang cocok dengan kode yang ditentukan.⁸

err 0x80070005
err 5
err 0xC0000005

Satu angka dapat mengenai di beberapa header (misalnya “5” cocok dengan definisi di berbagai tempat selain Win32 ERROR_ACCESS_DENIED), jadi kandidat mana yang masuk akal harus dipilih menurut konteks. Nama file unduhan berversi (Err_6.4.5.exe pada saat penulisan), dan perhatikan juga bahwa definisi kode didasarkan pada header saat dibundel.⁸

flowchart TB
    accTitle: Pilih hasil pencarian err.exe menurut konteks
    accDescr: err.exe menelusuri banyak file header dan merinci definisi yang cocok, jadi ketika beberapa kandidat muncul untuk angka yang sama, pilih yang masuk akal menurut konteks
    in["Masukkan err 5"] --> scan["Telusuri banyak header"]
    scan --> hits["Beberapa definisi mengenai"]
    hits --> pick["Pilih kandidat masuk akal menurut konteks"]

Gambar 17: err.exe adalah pencarian lintas header, jadi beberapa kandidat dapat muncul, dan yang masuk akal dipilih menurut konteks.

7.2. Perintah built-in Windows

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

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

net helpmsg hanya untuk kode error Win32 dalam desimal, tetapi di lingkungan Indonesia pesannya kembali dalam bahasa yang dilokalkan OS, jadi Anda dapat memakainya apa adanya untuk penjelasan kepada pengguna.

flowchart TB
    accTitle: Cara memilih di antara perintah standar
    accDescr: Kode error Win32 desimal dicari dengan net helpmsg; kode yang mencakup hex, termasuk HRESULT, dicari dengan opsi -error certutil
    q{"Kode yang Anda punya adalah?"} -->|Win32 desimal| net["net helpmsg"]
    q -->|Mencakup hex| cert["certutil -error"]
    net -.-> jp["Pesan terlokalkan kembali"]
    cert -.-> any["Menerima hex dan desimal"]

Gambar 18: Cara memilih di antara perintah standar. Error Win32 desimal adalah net helpmsg; jika mencakup hex, certutil -error.

7.3. Kumpulan one-liner PowerShell

# Win32 error code → OS message string
[System.ComponentModel.Win32Exception]::new(5).Message
# → Access is denied.

# Negative decimal → hex notation (confirm the identity of an HRESULT)
'0x{0:X8}' -f -2147467259     # 0x80004005

# 0x8007xxxx → the Win32 error code in the low 16 bits
0x80070005 -band 0xFFFF        # 5

# HRESULT → confirm the exception .NET maps
[System.Runtime.InteropServices.Marshal]::GetExceptionForHR(-2147024891)
# → UnauthorizedAccessException (0x80070005)

# Win32 error code → HRESULT (reproduce the wrap)
'0x{0:X8}' -f (0x80070000 -bor 32)   # 0x80070020

7.4. !error WinDbg

Untuk mencari kode selama analisis dump, ekstensi !error WinDbg cepat. Secara default ia menafsirkan sebagai kode error Win32; berikan 1 sebagai argumen kedua dan ia menafsirkan sebagai NTSTATUS.¹⁰

0:000> !error 5
Error code: (Win32) 0x5 (5) - Access is denied.

0:000> !error 0xc0000005 1
Error code: (NTSTATUS) 0xc0000005 - <Access violation>

Di crash dump, !analyze -v secara otomatis menampilkan kode pengecualian (NTSTATUS), jadi alurnya mengonfirmasi makna dari situ dengan !error <code> 1.

flowchart TB
    accTitle: Alur mengonfirmasi kode pengecualian di WinDbg
    accDescr: Di crash dump perintah analyze secara otomatis menampilkan kode pengecualian; berikan kode itu ke ekstensi error dengan argumen kedua 1 dan konfirmasi makna sebagai NTSTATUS
    dump["Buka crash dump"] --> an["Jalankan !analyze -v"]
    an --> exc["Kode pengecualian ditampilkan"]
    exc --> chk["Konfirmasi makna dengan !error code 1"]

Gambar 19: Dalam analisis dump, cari kode pengecualian yang ditampilkan !analyze -v dengan !error dan bendera 1.

8. Prosedur investigasi — Dari menilai lapis hingga mencocokkan konteks

Susun pengetahuan sejauh ini menjadi prosedur untuk benar-benar menginvestigasi kode error.

1. Normalkan notasi. Jika desimal negatif, konversi ke hex 8 digit. Isi nol hex yang lebih pendek dari 8 digit dan baca.
2. Nilai lapis mana kodenya. Seperti di tabel penilaian di bawah, beberapa digit depan hampir memutuskannya.
3. Uraikan dan keluarkan kode esensial. Operasi mekanis: 16 bit rendah jika 0x8007xxxx, copot bit N jika 0xDxxxxxxx.
4. Cari nama dan definisi dengan alat. Konfirmasi nama simbol dan pesan dengan err.exe, certutil, atau !error.
5. Cocokkan dengan konteks. Identifikasi aplikasi mana, operasi mana, API mana, yang gagal terhadap apa, dari log aplikasi, event log, dan Procmon. Kode adalah “jenis kegagalan”; konteks adalah “tempat penyebab”.

flowchart TB
    accTitle: Prosedur menginvestigasi kode error
    accDescr: Pola investigasi menyelaraskan notasi ke hex, menilai lapis dari beberapa digit depan, menguraikan dan mengeluarkan kode esensial, mencari nama dan definisi dengan alat, lalu mencocokkan konteks
    fix["Normalkan ke hex"] --> judge{"Digit depan?"}
    judge -->|Desimal| d1["Baca sebagai error Win32"]
    judge -->|0x8007| d2["16 bit rendah → desimal"]
    judge -->|0xC| d3["Baca sebagai NTSTATUS"]
    judge -->|0xD| d4["Copot bit N dan baca"]
    d1 --> tool["Cari nama/definisi"]
    d2 --> tool
    d3 --> tool
    d4 --> tool
    tool --> ctx["Cocokkan konteks（Procmon）"]

Gambar 20: Pola investigasi. Normalkan notasi, nilai lapis dan uraikan, cari nama, lalu cocokkan konteks.

Yang sangat efektif di langkah 5 “mencocokkan konteks” adalah kolom Result Process Monitor. Meski aplikasi hanya menampilkan “0x80070002”, Procmon memberi tahu dalam satu baris “proses mana, terhadap jalur mana, dikembalikan NAME NOT FOUND”. Untuk mencari di sisi event log, lihat juga “Pengantar Windows Event Log dan ETW”.

9. Salah baca umum — pola yang mengirim investigasi jalan memutar

Akhirnya, pola salah baca yang muncul dalam konsultasi nyata.

Salah baca 1: Mengira 0x80004005 “kode yang menunjukkan penyebab spesifik”

E_FAIL adalah “Unspecified failure”, dan nilai yang sama muncul di Windows Update, jaringan, dan basis data. Mencoba setiap perbaikan yang muncul ketika Anda mencari kode ini hampir pasti jalan memutar. Persempit bukan dari kode melainkan dari “aplikasi mana, operasi mana, log lain pada saat yang sama”.⁶

Salah baca 2: Tidak menyadari desimal negatif adalah HRESULT

Kasus mencari log yang berkata “Error -2147467259 occurred” apa adanya, atau bingung oleh “error minus?”. Ketika Anda melihat negatif, konversi ke hex. Itu saja memberi tahu bahwa itu 0x80004005 (E_FAIL), dan tersambung ke pengetahuan salah baca 1.

Salah baca 3: Mencari seluruh 8 digit 0x8007xxxx dan tidak melihat error Win32 di bawahnya

Esensi 0x80070005 adalah “5 = akses ditolak”. Berpikir tentang “apa arti error Win32 5 dalam konteks operasi ini” setelah mengeluarkan 16 bit rendah mencapai inti lebih cepat daripada mencari seluruh 8 digit.

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

Jika Anda pernah “error 5 disebabkan antivirus”, Anda cenderung meloncat ke perbaikan yang sama pada error 5 berikutnya. Meski kodenya sama, jika API yang gagal dan sumber daya target berbeda, penyebabnya hal lain. Mengonfirmasi makna kode dan mengidentifikasi target dengan Procmon atau sejenisnya adalah satu set, setiap kali.

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

Memperlakukan ERROR_ACCESS_DENIED dan STATUS_ACCESS_VIOLATION sebagai sama karena kaitan “5” mengirim investigasi ke arah yang sama sekali berbeda — masalah izin versus bug program. Juga, kode STOP layar biru adalah sistem lain dari NTSTATUS, jadi mencari 0x9F di tabel NTSTATUS tidak menghasilkan jawaban bermakna.¹⁴

flowchart TB
    accTitle: Error 5 dan 0xC0000005 punya arah investigasi berbeda
    accDescr: Error Win32 5 harus diinvestigasi sebagai masalah izin, dan NTSTATUS 0xC0000005 sebagai bug program; memperlakukan mereka sama mengirim investigasi ke arah lain
    a["Error Win32 5"] --> ad["Investigasi masalah izin"]
    b["NTSTATUS 0xC0000005"] --> bd["Investigasi bug program"]
    a -.-> memo["Kode tidak terkait dari sistem berbeda"]
    b -.-> memo

Gambar 21: Jangan perlakukan mereka sama karena kaitan “5”. Error 5 menuju masalah izin; 0xC0000005 menuju bug program.

10. Ringkasan

• Kode error Windows adalah struktur tiga lapis kode error Win32, HRESULT, dan NTSTATUS. Pertama nilai lapis mana, pihak mana yang mengembalikan kode.
• Goyangan notasi (desimal / hex / negatif) dapat diselaraskan secara mekanis. Konversi negatif ke hex 8 digit lalu baca.
• HRESULT adalah struktur bit S/R/C/N/X + Facility (11 bit) + Code (16 bit), dan 0x8007xxxx adalah pola paling penting, error Win32 yang dibungkus. Konversi 16 bit rendah ke desimal dan keluarkan kode esensial.
• Kode generik seperti 0x80004005 (E_FAIL) tidak menunjukkan penyebab. Penilaian berhenti menggali kode dan beralih ke investigasi konteks dimungkinkan justru karena Anda tahu strukturnya.
• Anda menemui NTSTATUS sebagai kode pengecualian crash atau di kolom Result Procmon. 0xC0000005 adalah pelanggaran akses, tidak terkait error Win32 5. Kode STOP adalah sistem lain lagi.
• Di .NET, HRESULT dipetakan ke tipe pengecualian, dan nilai asli tetap di Exception.HResult. Di P/Invoke, pakai SetLastError=true dan Marshal.GetLastWin32Error sebagai satu set.
• Alat pencarian adalah certutil -error dan net helpmsg (standar), err.exe (mesin pengembangan), one-liner PowerShell, dan !error WinDbg.
• Prosedurnya “normalkan notasi → nilai lapis → uraikan → cari nama → cocokkan konteks”. Yang kode beri tahu adalah jenis kegagalan; tempat penyebab adalah yang konteks beri tahu.

Lain kali Anda menemui kode error yang tidak akrab, lihat beberapa digit depan sebelum menempelkannya ke kotak pencarian. 4 digit rendah jika 0x8007, NTSTATUS jika 0xC, konversi ke hex jika negatif — uraian 10 detik ini sebagian besar memutuskan waktu investigasi yang mengikuti.

Artikel terkait

• Membaca crash dump dengan WinDbg + SOS — panduan praktis analisis setelah pengumpulan
• Pengantar pengumpulan crash dump Windows - WER/ProcDump/WinDbg
• Di mana catch dan logging harus diletakkan dalam penanganan pengecualian?
• Panduan praktis Process Monitor (ProcMon) — menunjuk “pengaturan tidak diterapkan” dan “ACCESS DENIED” dalam 10 menit
• Pengantar Windows Event Log dan ETW — menaruh log aplikasi bisnis Anda pada mekanisme standar OS

Area konsultasi terkait

KomuraSoft LLC menangani investigasi insiden yang dimulai dari kode error — “saya tidak tahu apa arti kode error ini”, “0x80070005 hanya muncul di lingkungan tertentu” —, desain penanganan error untuk aplikasi yang mencampur Win32 API, COM, dan .NET, serta mengidentifikasi penyebab dengan crash dump dan Process Monitor. Konsultasi dari satu tangkapan layar dialog error sudah cukup.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• 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, dan artinya "Unspecified failure" (kegagalan tidak ditentukan). Dengan kata lain ia hanya menunjukkan bahwa "sebuah kegagalan terjadi yang tidak dapat melaporkan alasan rinci"; bukan kode yang mewakili penyebab itu sendiri. 0x80004005 yang sama muncul di tempat yang tidak terkait — jaringan, Windows Update, VBA, driver basis data — karena alasan ini. Ketika Anda melihat kode ini, jangan menggali makna kodenya; persempit penyebab dari konteks aplikasi dan operasi mana yang menghasilkannya, serta dari informasi error lain di event log atau log rinci.

Apa kode error negatif seperti -2147467259?

Itu HRESULT 32-bit yang ditampilkan sebagai desimal bertanda. HRESULT menyetel bit paling signifikan saat gagal, jadi sebagai bilangan bulat bertanda ia selalu negatif. Di PowerShell, '0x{0:X8}' -f -2147467259 mengubahnya kembali ke heksadesimal (dalam contoh ini 0x80004005 = E_FAIL). Ketika Anda melihat angka negatif yang dimulai dengan -214… di log atau pesan error skrip, langkah pertama yang baku adalah mengubahnya ke hex lalu mencarinya.

Apa cara termudah mencari makna kode error?

Tanpa instalasi tambahan Anda dapat memakai net helpmsg 5 di command prompt (untuk error Win32 dalam desimal) dan certutil -error 0x80070005. certutil juga menerima HRESULT heksadesimal dan menampilkan nama simbol serta teks pesan. Di PowerShell, [System.ComponentModel.Win32Exception]::new(5).Message mengambil pesan terlokalkan. Di mesin pengembangan, simpan alat pencarian resmi Microsoft err.exe (Microsoft Error Lookup Tool); ia dapat mencari di Win32, HRESULT, dan NTSTATUS serta merinci definisi yang cocok sekaligus.

Error macam apa 0xC0000005?

Itu NTSTATUS STATUS_ACCESS_VIOLATION, yaitu pelanggaran akses (akses memori ilegal). Itu kode yang paling sering Anda lihat sebagai "Exception code" di event log atau di crash dump saat aplikasi crash, dan menandakan 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 mengidentifikasi penyebab adalah menangkap crash dump dan menganalisisnya di WinDbg.

Mengapa penyebabnya berbeda setiap kali, meski kode errornya sama?

Karena kode error hanya mewakili "jenis kegagalan", dan "apa yang gagal serta mengapa" diputuskan oleh konteks pemanggilan. Error 5 (akses ditolak), misalnya, adalah kode yang sama untuk penyebab yang sama sekali berbeda — izin NTFS kurang, hak administrator tidak ada, blok antivirus, dan seterusnya. Dalam situasi serupa, jika proses lain masih membuka file Anda mendapat kode lain (error 32 = pelanggaran berbagi), dan membaca kode dengan benar mengubah ke mana Anda mencari. Error 2 (file tidak ditemukan) juga sering bukan file utama melainkan DLL dependen atau file pengaturan. Setelah Anda mencari makna kodenya, memastikan API mana yang gagal terhadap sumber daya mana dengan Process Monitor atau sejenisnya 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.