Windows error codes पढ़ना — Win32, HRESULT और NTSTATUS की तीन-layer structure

“ऐप स्क्रीन पर error 0x80004005 आई। इसका क्या अर्थ है?” — incident investigation परामर्शों में इस तरह का प्रश्न क्लासिक है। जिसने error dialog से संख्या सीधे search engine में चिपकाई और unrelated लेखों की बाढ़ मिली — Windows Update failure, shared folder जो जुड़ता नहीं, VBA runtime error, database connection failure — और और अधिक उलझ गया, उसके साथ बहुत लोग हैं।

ऐसा इसलिए होता है क्योंकि 0x80004005 (E_FAIL) एक generic code है जिसका एकमात्र अर्थ “Unspecified failure” है। वही code अनगिनत स्थितियों में लगता है, इसलिए केवल code से search कारण तक नहीं पहुँचती। दूसरी ओर, 0x80070005 जैसा code, यदि structure पता हो, search से पहले कुछ सेकंड में “Win32 error number 5 = Access Denied, HRESULT के रूप में wrapped” में decompose हो सकता है।

Windows error codes, ऐतिहासिक कारणों से, तीन layers बनाते हैं — Win32 error codes, HRESULT और NTSTATUS — और layers पार करके convert होते हैं। जब यह structure सिर में हो, आप स्वयं तय कर सकते हैं “किस layer, किस पक्ष ने यह code लौटाया” और “आवश्यक code क्या है”, और investigation की शुरुआती चाल बहुत तेज़ हो जाती है।

छोटे और मध्यम व्यवसायों के IT कर्मचारियों तथा Windows ऐप developers के लिए, यह लेख तीन error-code प्रणालियों को अलग और decompose करना, .NET exceptions से संबंध, तथा err.exe और PowerShell से व्यावहारिक lookup व्यवस्थित करता है — Microsoft Learn और अगस्त 2026 तक प्रकाशित specification [MS-ERREF] पर आधारित।

1. निष्कर्ष पहले

• Windows error codes मुख्यतः तीन प्रणालियाँ हैं। Win32 error codes (GetLastError जो छोटा decimal लौटाता है), HRESULT (COM से 32-bit code, 0x8 से शुरू hex या negative decimal), और NTSTATUS (kernel-layer code; errors 0xC से शुरू)।¹²³
• Decimal और hexadecimal एक ही code की अलग notation हैं। “Error 5”, “0x5” और “0x80070005 के निचले 16 bits” सभी ERROR_ACCESS_DENIED (Access Denied) को दर्शाते हैं।¹
• 0x8007xxxx “wrapped Win32 error” है। यह HRESULT FACILITY_WIN32 (7) में संग्रहीत Win32 error code है; निचले 16 bits decimal में बदलें तो आवश्यक code मिलता है। Error codes पढ़ने का यह सबसे महत्वपूर्ण पैटर्न है।⁴⁵
• 0x80004005 (E_FAIL) कारण code नहीं है। इसका अर्थ “Unspecified failure” है और अधिक जानकारी नहीं रखता। इस code में खोदने के बजाय original context और साथ के logs देखें।⁶
• Negative decimal (-2147467259 और जैसे) HRESULT है। 32 bits का most significant bit (failure bit) set है, इसलिए signed display negative है। इसे hex में बदलकर फिर पढ़ें।²
• 0xC से शुरू 8-digit मान NTSTATUS है। 0xC0000005 (access violation) और 0xC0000135 (DLL not found) crash समय event log और dump में लगातार आते हैं। वे Win32 error number 5 से unrelated हैं।⁷
• एक ही code context के साथ अर्थ बदलता है। Error 5 का कारण ACL, elevation, antivirus, locked file और अधिक तक फैला है, और error 2 की “file not found” अक्सर dependent DLL होती है। Code का अर्थ हमेशा किस API ने किसके विरुद्ध fail हुआ, उसके साथ पढ़ें।¹
• Conversion और lookup tools मानक हैं। certutil -error और net helpmsg Windows में बने हैं; PowerShell का Win32Exception message लाता है; development machine पर err.exe (Microsoft Error Lookup Tool); dump analysis में WinDbg का !error।⁸⁹¹⁰
• .NET में HRESULT exception type पर map होता है। ज्ञात HRESULT संबंधित type पर जाता है (E_ACCESSDENIED → UnauthorizedAccessException आदि); अज्ञात COMException बनता है; original मान Exception.HResult में रहता है।¹¹

एक वाक्य में, Windows error-code investigation का पैटर्न है “notation को hex पर align करें → तय करें code किस layer का है → decompose कर आवश्यक code निकालें → context के साथ पढ़ें”।

2. Windows में तीन error-code प्रणालियाँ हैं

पहले, समग्र map। Windows error codes मुख्यतः निम्न तीन प्रणालियों में बँटते हैं, लौटाने वाली layer के अनुसार।

ऐतिहासिक रूप से वे इस क्रम में ढेर हुए: MS-DOS error numbers विरासत में लेने वाले Win32 error codes, NTSTATUS जो NT kernel internally इस्तेमाल करता है, और HRESULT जो COM के आगमन पर “success/failure और origin को 32 bits में pack” करने के लिए बनाया गया। वर्तमान Windows पर conversion प्रवाह रोज़मर्रा है: kernel NTSTATUS लौटाता है, Win32 subsystem उसे Win32 error code में बदलती है, और COM layer उसे आगे HRESULT के रूप में wrap करती है।¹²⁴

flowchart TB
    accTitle: तीन प्रणालियों के आर-पार conversion प्रवाह
    accDescr: Win32 subsystem kernel द्वारा लौटाए NTSTATUS को Win32 error code में बदलती है, और COM layer उसे आगे HRESULT के रूप में wrap करती है
    kernel["Kernel और drivers"] --> nt["NTSTATUS（errors 0xC…）"]
    nt -->|Win32 subsystem बदलती है| win["Win32 error code（5 आदि）"]
    win -->|COM layer wrap करती है| hr["HRESULT（0x8007xxxx）"]

चित्र 1: Layers के आर-पार conversion प्रवाह। Kernel NTSTATUS Win32 error बनता है, और आगे HRESULT के रूप में wrapped होता है।

2.1. Decimal और hexadecimal को परस्पर पढ़ने की आदत डालें

तीन प्रणालियों को अलग करने से पहले notation की डगमगाहट सोखनी होगी। वही code स्थिति के अनुसार decimal या hex दिखता है।

• “Error 5”, “error code: 0x5” → वही ERROR_ACCESS_DENIED
• “Error 1223”, “0x4C1” → वही ERROR_CANCELLED
• “0x80070005”, “-2147024891” → वही HRESULT

PowerShell में conversion एक पंक्ति है।

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

# Hex → decimal
0x4C1                        # 1223

जब “-214…” से शुरू negative decimal दिखे, उसे reversibly hex में बदलें। अकेले यही investigation के प्रवेश पर बहुत भटकना काटता है।

flowchart TB
    accTitle: एक ही code के तीन रूप
    accDescr: Decimal error 5, hex 0x5, और 0x80070005 के निचले 16 bits सभी उसी ERROR_ACCESS_DENIED को दर्शाते हैं
    d["Decimal notation: error 5"] --> same["ERROR_ACCESS_DENIED"]
    h["Hex notation: 0x5"] --> same
    l["0x80070005 के निचले 16 bits"] --> same
    same -.-> memo["अलग notation, वही code"]

चित्र 2: Decimal, hex और HRESULT के निचले 16 bits एक ही code की केवल अलग notation हैं।

3. Win32 error codes — GetLastError और FORMAT_MESSAGE

3.1. मूल GetLastError व्यवहार

CreateFile और RegOpenKeyEx जैसे कई Win32 API failure return value (FALSE, NULL, INVALID_HANDLE_VALUE आदि) से दर्शाते हैं, और विस्तृत error code per-thread रखे “last-error code” में संग्रहीत करते हैं। Caller failure पुष्टि के तुरंत बाद GetLastError से उसे लेता है।¹³

दो व्यावहारिक चेतावनियाँ हैं।¹³

1. Failure के तुरंत बाद पढ़ें। यदि बीच में कोई अन्य API call (उदाहरण logging function) डालें, वह call last-error code overwrite कर सकती है।
2. Success पर मान पर भरोसा न करें। कुछ API success पर last-error code 0 कर देते हैं; कुछ छूते नहीं। नियम है return value से failure पुष्टि कर फिर पढ़ना।

sequenceDiagram
    accTitle: Failure के तुरंत बाद GetLastError पढ़ें
    accDescr: Return value से failure पुष्टि के बाद, बिना अन्य API call डाले तुरंत GetLastError से last-error code लें
    participant app as App
    participant api as Win32 API
    app->>api: CreateFile call
    api-->>app: Failure return value
    app->>api: GetLastError
    api-->>app: Code 5
    Note over app: बीच में अन्य API डालना overwrite कर सकता है

चित्र 3: Failure के तुरंत बाद last-error code पढ़ें। बीच में अन्य API call डालना उसे overwrite कर सकता है।

Code से message string पाने के लिए FORMAT_MESSAGE_FROM_SYSTEM flag के साथ FormatMessage इस्तेमाल करें।¹

#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);
}

अपने ऐप के logs में decimal, hex और message text तीनों छोड़ना, ऐसे, बाद की investigation एक कदम तेज़ करता है।

flowchart TB
    accTitle: Code से message खोजें और log में छोड़ें
    accDescr: FormatMessage को FORMAT_MESSAGE_FROM_SYSTEM flag दें ताकि error code की message string मिले, और log में decimal, hex तथा text छोड़ें
    code["Error code（उदाहरण: 5）"] --> fm["FormatMessage से string लें"]
    fm --> msg["Message text"]
    msg --> log["Log में लिखें"]
    log -.-> both["Decimal, hex और text साथ लिखें"]

चित्र 4: FormatMessage से error code को message string में बदलें, और log में decimal, hex तथा text साथ छोड़ें।

3.2. क्षेत्र में लगातार आने वाले representative codes

Win32 error codes 0–15999 range में defined हैं, और Microsoft Learn की पूरी list है।¹ उनमें, incident investigation में बार-बार मिलने वाले चेहरे निम्न हैं।

इनमें से 998 (ERROR_NOACCESS) “Access Denied” नहीं बल्कि memory access violation का Win32 अभिव्यक्ति है, बाद में चर्चित NTSTATUS STATUS_ACCESS_VIOLATION का Win32 layer पर conversion के बाद का आकार। संख्या 5 से भ्रम से सावधान रहें। साथ ही, 1223 (ERROR_CANCELLED) वह code है जो उदाहरण के लिए UAC elevation dialog पर user “नहीं” चुनने पर आता है — error से अधिक “cancelled”।

flowchart TB
    accTitle: Error 998 और 5 अलग चीज़ें हैं
    accDescr: 998 memory access violation है, Win32 layer पर converted NTSTATUS access violation, और Access Denied दर्शाने वाले 5 से अर्थ में भिन्न
    nt["NTSTATUS 0xC0000005"] -->|Win32 layer पर converted| e998["Error 998（ERROR_NOACCESS）"]
    e998 -.-> m1["अर्थ memory access violation है"]
    e5["Error 5（Access Denied）"] -.-> m2["Permission समस्या। 998 से अलग चीज़"]

चित्र 5: Error 998 Win32 layer पर converted NTSTATUS access violation है, Access Denied 5 से अलग चीज़।

3.3. एक ही code context के साथ अर्थ बदलता है

Representative codes की तालिका रटने से अधिक महत्वपूर्ण यह भाव है कि error code केवल “failure का type” बताता है।

• Error 5 (Access Denied): कारण के उम्मीदवार व्यापक हैं — insufficient NTFS ACL, admin privilege के बिना protected area लिखना, antivirus या AppLocker block, service account के insufficient privileges, इत्यादि।
• Error 2 (file not found): जरूरी नहीं कि user द्वारा निर्दिष्ट file हो। वह dependent DLL जिसे EXE ने implicitly load करने की कोशिश की, registry redirection (32-bit/64-bit) के कारण गलत जगह दिखी settings file, वह path जिसका environment-variable expansion fail हुआ — “कौन-सी file” नहीं मिली, code से नहीं दिखता।
• Error 32 (sharing violation): “कौन-सी process पकड़े है” असली प्रश्न है, पर code वह नहीं बताता।

flowchart TB
    accTitle: Error 5 का कारण context तय करता है
    accDescr: एक ही Access Denied के भी कई कारण उम्मीदवार हैं जैसे insufficient ACL या admin privilege की कमी, और पहचानना होगा कौन-सा API किसके विरुद्ध fail हुआ
    e5["Error 5（Access Denied）"] --> c1["Insufficient ACL"]
    e5 --> c2["Admin rights नहीं"]
    e5 --> c3["Security-product block"]
    e5 --> c4["Service privilege कम"]
    c1 --> next["Procmon: failed target"]
    c2 --> next
    c3 --> next
    c4 --> next

चित्र 6: Code केवल “failure का type” बताता है। Error 5 के कई कारण उम्मीदवार हैं, और लक्ष्य पहचानना आवश्यक है।

वह tool जो मापता है “कौन-सा API, किस object नाम के विरुद्ध, कौन-सा result लौटाया” Process Monitor है। उसका उपयोग विस्तार से “Process Monitor (ProcMon) की व्यावहारिक guide” में है। Error code का अर्थ खोजना और failed target पहचानना एक ही गाड़ी के दो पहिए हैं।

4. HRESULT — 32 bits में packed structure पढ़ना

4.1. Bit layout

HRESULT वह format है जो success/failure, origin और detail code को एक 32-bit मान में pack करता है। प्रकाशित specification [MS-ERREF] इसे निम्न layout से define करता है।²

सबसे महत्वपूर्ण S bit 1 है, अर्थात वह HRESULT जिसकी hex notation 0x8 या ऊपर से शुरू होती है failure है। उसे signed 32-bit integer के रूप में दिखाना negative बनाता है — वही पहले बताए “-214…” की पहचान है।

flowchart TB
    accTitle: S bit और negative display का संबंध
    accDescr: Failure HRESULT का most significant S bit 1 है, इसलिए hex में 0x8 या ऊपर से शुरू होता है, और signed 32-bit integer के रूप में negative है
    s["S bit = 1（failure）"] --> hex["Hex 0x8 या ऊपर से शुरू"]
    hex --> neg["Signed display negative"]
    neg --> back["Negative दिखे तो hex में बदलकर पढ़ें"]

चित्र 7: Failure HRESULT 0x8 या ऊपर से शुरू होता है क्योंकि S bit 1 है, और signed display negative है।

Representative Facility मान निम्न हैं।⁵

4.2. 0x80004005 और 0x80070005 decompose करना

वास्तव में decompose करें।

0x80004005 के लिए: S=1 (failure), Facility=(0x80004005 » 16) & 0x7FF = 0 (FACILITY_NULL), Code=0x4005। Generic FACILITY_NULL code, E_FAIL “Unspecified failure” के रूप में defined।⁶ अर्थात यह code केवल अर्थ “विस्तार न बता सकने वाली failure” रखता है। 0x80004005 दिखे तो वहीं code स्वयं में खोदना बंद करें, और investigation का भार “किस component ने लौटाया” तथा “इसी समय event log या ऐप log में विस्तार है क्या” पर shift करें।

0x80070005 के लिए: S=1, Facility=7 (FACILITY_WIN32), Code=0x0005=5। दिखता है कि यह Win32 error number 5 (ERROR_ACCESS_DENIED) HRESULT के रूप में wrapped है। Alias E_ACCESSDENIED सारतः यही मान है।⁶

एक ही “Access Denied” के लिए भी, 0x80070005 Win32 layer पर हुई ठोस failure का wrap है, और जानकारी की मात्रा 0x80004005 से पूरी तरह अलग है।

flowchart TB
    accTitle: 0x80004005 और 0x80070005 का decomposition
    accDescr: 0x80004005 generic FACILITY_NULL code E_FAIL है, विस्तार नहीं रखता, और context investigation पर जाना चाहिए; 0x80070005 FACILITY_WIN32 है और Win32 error number 5, Access Denied, के wrap के रूप में पढ़ा जा सकता है
    a["0x80004005"] --> af["Facility=0（FACILITY_NULL）"]
    af --> ac["Code=0x4005 → E_FAIL"]
    ac --> ax["Unspecified failure। Context investigation पर आगे"]
    b["0x80070005"] --> bf["Facility=7（FACILITY_WIN32）"]
    bf --> bc["Code=0x0005 → 5"]
    bc --> bx["ERROR_ACCESS_DENIED"]

चित्र 8: एक ही “failure” decomposition के बाद जानकारी की मात्रा अलग रखती है। 0x80070005 को Win32 error number 5 तक चलाया जा सकता है।

4.3. सबसे महत्वपूर्ण पैटर्न: 0x8007xxxx = HRESULT_FROM_WIN32

निचली layer से, जो केवल Win32 error code लौटा सकती है, ऊपरी layer तक जो HRESULT लौटाती है (COM method या .NET runtime), failure पहुँचाने के लिए winerror.h macro HRESULT_FROM_WIN32 देता है।⁴ व्यवहार है “Win32 error code निचले 16 bits में रखें, Facility को FACILITY_WIN32 (7) करें, और S bit 1 करें”।

flowchart TB
    accTitle: HRESULT_FROM_WIN32 कैसे काम करता है
    accDescr: Win32 error code निचले 16 bits में रखें, Facility 7 और S bit 1 करें, और 0x8007xxxx HRESULT जोड़ें
    win["Win32 error code（उदाहरण: 5）"] --> low["निचले 16 bits में रखें"]
    low --> fac["Facility 7 करें"]
    fac --> sbit["S bit 1 करें"]
    sbit --> hr["0x80070005"]

चित्र 9: HRESULT_FROM_WIN32 Win32 error निचले 16 bits में रखता है और Facility=7 तथा S bit set करता है।

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)

दूसरी दिशा पढ़ने के लिए PowerShell में निचले 16 bits लें।

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

दूसरे उदाहरण की तरह, WinINet और WinHTTP errors (12000 वाले) भी Win32 error-code space में defined हैं¹, इसलिए networking 0x8007xxxx उसी प्रक्रिया से decompose होता है। “0x8007 दिखे तो निचले 4 digits decimal में बदलें” को muscle memory में लाना इस लेख का नंबर-एक व्यावहारिक कौशल है जो आप साथ ले जाएँ।

0x8004xxxx (FACILITY_ITF) के लिए उलटी चेतावनी है। FACILITY_ITF code का अर्थ define करने वाला पक्ष per-interface अलग होता है, इसलिए वही 32-bit मान लौटाने वाला पक्ष अलग हो तो कुछ और मतलब कर सकता है।⁵ अपरिचित 0x8004xxxx सामान्य search में नहीं, बल्कि लौटाने वाले component के दस्तावेज़ (library, driver SDK, server product) में खोजें।

flowchart TB
    accTitle: 0x8007 और 0x8004 के बीच search कैसे बदलती है
    accDescr: FACILITY_WIN32 0x8007xxxx निचले 16 bits यांत्रिक decomposition से पढ़ा जाता है, पर FACILITY_ITF 0x8004xxxx का अर्थ-परिभाषक पक्ष per-interface अलग है, इसलिए लौटाने वाले component की सामग्री में खोजें
    hr{"Facility है?"} -->|7, WIN32| w["निचले 16 bits decimal करें"]
    hr -->|4, ITF| i["अर्थ लौटाने वाले पक्ष से भिन्न"]
    w --> ww["Win32 error के रूप में पढ़ें"]
    i --> ii["लौटाने वाले पक्ष की सामग्री में खोजें"]

चित्र 10: 0x8007xxxx यांत्रिक रूप से decompose होता है; 0x8004xxxx लौटाने वाले component की सामग्री में खोजा जाता है।

5. NTSTATUS — kernel-layer codes और crash की दुनिया

5.1. Layout और Severity

NTSTATUS 32-bit code है जिसे kernel, device drivers और ntdll native API इस्तेमाल करते हैं, और उसका layout HRESULT के समान है बिना वही हुए।³

Severity 2 bits होने से type अग्रणी hex digit से पढ़ा जा सकता है। 0xC… error (11) है, 0x8… warning (10), 0x4… informational (01), 0x0–0x3… success। Breakpoint exception 0x80000003 (STATUS_BREAKPOINT) “warning, error नहीं” का representative उदाहरण है।³⁷

flowchart TB
    accTitle: NTSTATUS अग्रणी digit से type पढ़ा जाता है
    accDescr: Severity 2 bits होने से NTSTATUS error पढ़ा जाता है यदि अग्रणी hex digit 0xC हो, warning यदि 0x8, informational यदि 0x4, और success यदि 0x0 से 0x3
    head{"अग्रणी hex digit है?"} -->|0xC| e["Error"]
    head -->|0x8| w["Warning"]
    head -->|0x4| i["Informational"]
    head -->|0x0–0x3| s["Success"]
    w -.-> ex["उदाहरण: 0x80000003 warning है"]

चित्र 11: NTSTATUS अग्रणी hex digit से type पढ़ा जाता है। 0x80000003 “warning, error नहीं” है।

5.2. कहाँ मिलता है — exception codes, STOP codes और event log

जिन स्थितियों में IT कर्मचारी और developers NTSTATUS से मिलते हैं वे मुख्यतः crash-संबंधी हैं।

• ऐप-crash exception code: Event log के “Application Error (event ID 1000)” में दर्ज “Exception code: 0xc0000005” NTSTATUS है। Representative मान निम्न हैं।⁷

• Blue-screen STOP codes: एक नज़र में समान लगते हैं, पर STOP codes (bug check codes) NTSTATUS से अलग अपनी संख्या प्रणाली है, जैसे 0x0000009F (DRIVER_POWER_STATE_FAILURE), और dedicated reference है।¹⁴ केवल भेद याद रखना “0xC0000005 NTSTATUS है; STOP 0x9F bug check code है और NTSTATUS तालिका में न खोजें” पर्याप्त है।
• Process Monitor का Result column: Procmon के Result column में NAME NOT FOUND और ACCESS DENIED kernel द्वारा लौटाए NTSTATUS के display नाम हैं (STATUS_OBJECT_NAME_NOT_FOUND, STATUS_ACCESS_DENIED)। यह वह जगह भी है जहाँ layer-consistency महसूस होती है: file-I/O failure को NTSTATUS शब्दावली में देखना और उस failure का Win32 error में बदलकर ऐप तक पहुँचना।

flowchart TB
    accTitle: Exception code को STOP code से अलग करना
    accDescr: Event-log exception code NTSTATUS के रूप में पढ़ें; blue-screen STOP code dedicated bug-check-code reference में खोजें, अलग प्रणाली
    q{"Code कहाँ दिखाई दिया?"} -->|Exception code| nt["NTSTATUS के रूप में पढ़ें"]
    q -->|STOP code| bc["Bug-check-code तालिका में खोजें"]
    nt -.-> n1["उदाहरण: 0xC0000005"]
    bc -.-> b1["उदाहरण: 0x0000009F"]

चित्र 12: Event-log exception code NTSTATUS है; blue-screen STOP code अलग प्रणाली है। गलत तालिका में न खोजें।

Exception code से आगे की investigation, अर्थात crash dump पकड़ना और विश्लेषण, “Windows crash dump संग्रह का परिचय” और “WinDbg + SOS से crash dump पढ़ना” में है।

5.3. HRESULT से संबंध — N bit और RtlNtStatusToDosError

NTSTATUS और अन्य दो layers के बीच पुल के दो पथ हैं।

1. HRESULT space में map: HRESULT N bit (0x10000000) set करना NTSTATUS मान को HRESULT space में ज्यों का त्यों लाता है (winerror.h का HRESULT_FROM_NT macro)। 0xC0000005 map करना उदाहरण के लिए 0xD0000005 बनता है। 0xD से शुरू HRESULT दिखे तो सही प्रक्रिया N bit उतारकर NTSTATUS के रूप में पढ़ना है।²
2. Win32 error code में conversion: ntdll का RtlNtStatusToDosError NTSTATUS को संबंधित Win32 error code में बदलता है। बिना defined mapping वाला मान ERROR_MR_MID_NOT_FOUND बनता है।¹² उदाहरण के लिए STATUS_ACCESS_VIOLATION (0xC0000005) ERROR_NOACCESS (998) में बदलता है, और STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034) ERROR_FILE_NOT_FOUND (2) में। यह भी याद रखना उपयोगी है कि kernel की समृद्ध शब्दावली Win32 layer पर कभी-कभी मोटे भेद तक गोल होती है।

flowchart TB
    accTitle: NTSTATUS से अन्य layers तक दो पुल
    accDescr: NTSTATUS अन्य layers तक दो तरह जाता है: N bit set कर HRESULT space में map, और RtlNtStatusToDosError से Win32 error code में conversion
    nt["NTSTATUS（0xC0000005）"] -->|N bit set करें| hr["HRESULT（0xD0000005）"]
    nt -->|RtlNtStatusToDosError| win["Win32 error 998（ERROR_NOACCESS）"]
    win -.-> memo["ERROR_MR_MID_NOT_FOUND यदि mapping defined नहीं"]

चित्र 13: NTSTATUS पुल दो हैं। 0xD शुरुआत N bit उतारने के बाद NTSTATUS के रूप में पढ़ी जाती है।

6. COM और .NET — error code exception पर कैसे map होता है

6.1. COM शैली — HRESULT + IErrorInfo

COM method मूलतः HRESULT लौटाती है, पर 32 bits में क्या pack हो इसकी सीमा है, इसलिए पूरक के रूप में IErrorInfo mechanism error विवरण string और origin अलग से पहुँचा सकता है। C++ में compiler-supported _com_error class HRESULT और IErrorInfo दोनों संभालता है। वह ऐप जिसका error dialog “code + विवरण” दिखाता है अक्सर विवरण इसी mechanism से लाता है।

flowchart TB
    accTitle: IErrorInfo जो HRESULT का पूरक है
    accDescr: 32-bit HRESULT में क्या pack हो इसकी सीमा है, इसलिए error विवरण string और origin IErrorInfo से अलग पहुँचते हैं, और C++ में _com_error class दोनों साथ संभालता है
    hr["HRESULT（केवल 32 bits）"] --> lim["Pack होने की सीमा है"]
    lim --> ei["IErrorInfo विवरण लाता है"]
    ei --> ce["_com_error उन्हें साथ संभालता है"]
    ce -.-> dlg["Dialog का code + विवरण"]

चित्र 14: 32-bit HRESULT में न समाई विवरण string IErrorInfo अलग लाता है।

6.2. .NET शैली — HRESULT से exception type तक

जब .NET runtime COM interop में HRESULT failure पाता है, वह उसे exception में बदलता है। ज्ञात HRESULT संबंधित exception type पर map होता है; अज्ञात COMException बनता है।¹¹

flowchart TB
    accTitle: HRESULT से .NET exception पर map
    accDescr: COM interop में मिली failure HRESULT ज्ञात हो तो संबंधित exception type में बदलती है, अज्ञात हो तो COMException, और दोनों में original मान Exception.HResult में रहता है
    hr["Failure HRESULT"] --> known{"ज्ञात map?"}
    known -->|Yes| typed["संबंधित exception type में बदलें"]
    known -->|No| comex["COMException में बदलें"]
    typed --> keep["Original मान Exception.HResult में रहता है"]
    comex --> keep

चित्र 15: .NET HRESULT को exception type पर map करता है, और प्रत्येक exception पर original मान Exception.HResult में रहता है।

प्रत्येक exception पर original HRESULT Exception.HResult property में रहता है। File-I/O exception handling में “केवल sharing violation पर retry” जैसी शाखा इस मान से लिखी जा सकती है।

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 और GetLastError

जब P/Invoke से सीधे Win32 API call करें, DllImport (या LibraryImport) पर SetLastError = true specify करें, फिर Marshal.GetLastWin32Error से लें (.NET 6 से समकक्ष GetLastPInvokeError)। GetLastError स्वयं को P/Invoke के रूप में define कर call करना गलत है, क्योंकि runtime के अंदर API call मान overwrite कर सकती है।¹⁵

flowchart TB
    accTitle: P/Invoke में last error लेना
    accDescr: SetLastError true specify कर Marshal.GetLastWin32Error से लेना सही है; GetLastError सीधे P/Invoke करना runtime overwrite के कारण गलत
    pi["P/Invoke से Win32 API call"] --> ok["SetLastError=true specify करें"]
    ok --> get["GetLastWin32Error से लें"]
    pi --> ng["Definition जो GetLastError सीधे call करती है"]
    ng --> bad["Runtime overwrite करता है और गलत है"]

चित्र 16: P/Invoke में SetLastError=true और Marshal.GetLastWin32Error को set के रूप में इस्तेमाल करें। GetLastError सीधे call करना गलत है।

[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 Win32 error code से OS message string खोजता है, इसलिए code और message दोनों log में छोड़ने के लिए उसे ज्यों का त्यों इस्तेमाल कर सकते हैं। डिज़ाइन प्रश्न कि exception किस layer पर पकड़ें और log में कैसे छोड़ें “Exception handling में catch और logging कहाँ रखें?” में है।

7. अभ्यास में conversion और investigation tools — copy-paste quick reference

7.1. err.exe (Microsoft Error Lookup Tool)

Microsoft द्वारा वितरित स्वतंत्र error-lookup tool। यह winerror.h और ntstatus.h जैसे बड़ी संख्या में header files घूमता है और निर्दिष्ट code से मेल खाती definitions तथा messages list करता है।⁸

err 0x80070005
err 5
err 0xC0000005

एक संख्या कई headers में लग सकती है (उदाहरण “5” Win32 ERROR_ACCESS_DENIED के अलावा विभिन्न जगहों की definitions से मेल खाती है), इसलिए उम्मीदवारों में से कौन plausible है context से चुनना होगा। Download file नाम versioned है (लेखन समय Err_6.4.5.exe), और यह भी ध्यान दें कि code definitions bundle के समय के headers पर आधारित हैं।⁸

flowchart TB
    accTitle: err.exe search परिणाम context से चुनें
    accDescr: err.exe बड़ी संख्या में header files घूमता है और मेल खाती definitions list करता है, इसलिए एक ही संख्या पर कई उम्मीदवार आएँ तो context से plausible चुनें
    in["err 5 दर्ज करें"] --> scan["बड़ी संख्या में headers घूमें"]
    scan --> hits["कई definitions लगीं"]
    hits --> pick["Context से plausible उम्मीदवार चुनें"]

चित्र 17: err.exe header-पार search है, इसलिए कई उम्मीदवार आ सकते हैं, और plausible context से चुना जाता है।

7.2. Windows में बने commands

बिना extra install जो इस्तेमाल कर सकते हैं वे certutil और net helpmsg हैं। certutil का -error option error code के अनुरूप message text दिखाता है, और hexadecimal HRESULT या decimal स्वीकार करता है।⁹

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

net helpmsg केवल decimal में Win32 error code के लिए है, पर Hindi environment में message OS की localized language में लौटता है, इसलिए user को व्याख्या के लिए ज्यों का त्यों इस्तेमाल कर सकते हैं।

flowchart TB
    accTitle: मानक commands में कैसे चुनें
    accDescr: Decimal Win32 error code net helpmsg से खोजा जाता है; hex सहित codes, HRESULT सहित, certutil के -error option से
    q{"आपके पास code है?"} -->|Decimal Win32| net["net helpmsg"]
    q -->|Hex शामिल| cert["certutil -error"]
    net -.-> jp["Localized message लौटता है"]
    cert -.-> any["Hex और decimal दोनों स्वीकार"]

चित्र 18: मानक commands में कैसे चुनें। Decimal Win32 error net helpmsg है; यदि hex हो तो certutil -error।

7.3. PowerShell one-liner संग्रह

# 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. WinDbg का !error

Dump analysis के दौरान code खोजने के लिए WinDbg का !error extension तेज़ है। Default से Win32 error code के रूप में व्याख्या करता है; दूसरा argument 1 दें तो NTSTATUS के रूप में।¹⁰

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

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

Crash dump में !analyze -v स्वतः exception code (NTSTATUS) दिखाता है, इसलिए प्रवाह वहाँ से !error <code> 1 से अर्थ पुष्टि करना है।

flowchart TB
    accTitle: WinDbg में exception code पुष्टि का प्रवाह
    accDescr: Crash dump में analyze command स्वतः exception code दिखाता है; वह code error extension को दूसरे argument 1 के साथ दें और NTSTATUS के रूप में अर्थ पुष्टि करें
    dump["Crash dump खोलें"] --> an["!analyze -v चलाएँ"]
    an --> exc["Exception code दिखता है"]
    exc --> chk["!error code 1 से अर्थ पुष्टि करें"]

चित्र 19: Dump analysis में !analyze -v द्वारा दिखाए exception code को !error और flag 1 से खोजें।

8. Investigation प्रक्रिया — layer तय करने से context से मिलान तक

अब तक का ज्ञान वास्तव में error code जाँचने की प्रक्रिया में जोड़ें।

1. Notation normalize करें। यदि negative decimal हो तो 8-digit hex में बदलें। 8 digits से छोटे hex को zero-pad कर पढ़ें।
2. तय करें code किस layer का है। नीचे की निर्णय तालिका की तरह, अग्रणी कुछ digits लगभग तय करते हैं।
3. Decompose कर आवश्यक code निकालें। यांत्रिक संक्रिया: 0x8007xxxx हो तो निचले 16 bits, 0xDxxxxxxx हो तो N bit उतारें।
4. Tools से नाम और definition खोजें। err.exe, certutil या !error से symbol नाम और message पुष्टि करें।
5. Context से मिलान करें। ऐप logs, event log और Procmon से पहचानें किस ऐप, किस operation, किस API ने किसके विरुद्ध fail हुआ। Code “failure का type” है; context “कारण का स्थान” है।

flowchart TB
    accTitle: Error code जाँचने की प्रक्रिया
    accDescr: Notation को hex पर align करने, अग्रणी digits से layer तय करने, decompose कर आवश्यक code निकालने, tools से नाम और definition खोजने, फिर context से मिलान का investigation पैटर्न
    fix["Hex पर normalize करें"] --> judge{"अग्रणी digits?"}
    judge -->|Decimal| d1["Win32 error के रूप में पढ़ें"]
    judge -->|0x8007| d2["निचले 16 bits → decimal"]
    judge -->|0xC| d3["NTSTATUS के रूप में पढ़ें"]
    judge -->|0xD| d4["N bit उतारकर पढ़ें"]
    d1 --> tool["नाम/definition खोजें"]
    d2 --> tool
    d3 --> tool
    d4 --> tool
    tool --> ctx["Context मिलान（Procmon）"]

चित्र 20: Investigation पैटर्न। Notation normalize करें, layer तय कर decompose करें, नाम खोजें, फिर context से मिलान करें।

चरण 5 के “context से मिलान” में विशेष रूप से प्रभावी Process Monitor का Result column है। भले ऐप केवल “0x80070002” दिखाए, Procmon एक पंक्ति में बताता है “किस process, किस path के विरुद्ध, NAME NOT FOUND लौटा”। Event-log पक्ष पर search के लिए “Windows Event Log और ETW का परिचय” भी देखें।

9. आम गलत पाठ — पैटर्न जो investigation को लंबा रास्ता भेजते हैं

अंत में, वास्तविक परामर्शों में दिखने वाले गलत-पाठ पैटर्न।

गलत पाठ 1: सोचना 0x80004005 “विशिष्ट कारण दर्शाने वाला code” है

E_FAIL “Unspecified failure” है, और वही मान Windows Update, networking और database में आता है। इस code से खोजने पर आने वाले हर उपचार आज़माना लगभग निश्चित रूप से लंबा रास्ता है। Code से नहीं, बल्कि “किस ऐप, किस operation, उसी समय अन्य logs” से संकीर्ण करें।⁶

गलत पाठ 2: न ध्यान देना कि negative decimal HRESULT है

Log जो कहता है “Error -2147467259 occurred” को ज्यों का त्यों खोजना, या “minus error?” से उलझना। Negative दिखे तो hex में बदलें। अकेले यही बताता है कि यह 0x80004005 (E_FAIL) है, और गलत पाठ 1 के ज्ञान से जुड़ता है।

गलत पाठ 3: 0x8007xxxx के पूरे 8 digits खोजना और नीचे की Win32 error न देखना

0x80070005 का सार “5 = Access Denied” है। निचले 16 bits निकालने के बाद “इस operation के context में Win32 error 5 का क्या अर्थ” सोचना पूरे 8 digits खोजने से तेज़ core तक पहुँचता है।

गलत पाठ 4: मानना “वही code = वही कारण”

यदि एक बार “error 5 antivirus से हुई” हो, अगली error 5 पर उसी उपचार पर कूदने की प्रवृत्ति होती है। एक ही code पर भी, यदि failed API और लक्ष्य resource भिन्न हों, कारण अलग चीज़ है। Code का अर्थ पुष्टि करना और Procmon या समान से लक्ष्य पहचानना हर बार एक set हैं।

गलत पाठ 5: Win32 error 5 को 0xC0000005 से, और STOP code को NTSTATUS से भ्रमित करना

“5” कनेक्शन के कारण ERROR_ACCESS_DENIED और STATUS_ACCESS_VIOLATION को एक समान मानना investigation को पूरी तरह अलग दिशाएँ भेजता है — permission समस्या बनाम program bug। साथ ही, blue-screen STOP codes NTSTATUS से अलग प्रणाली है, इसलिए NTSTATUS तालिका में 0x9F खोजना अर्थपूर्ण उत्तर नहीं देता।¹⁴

flowchart TB
    accTitle: Error 5 और 0xC0000005 की investigation दिशाएँ अलग हैं
    accDescr: Win32 error 5 को permission समस्या के रूप में जाँचना चाहिए, और NTSTATUS 0xC0000005 को program bug; उन्हें एक समान मानना investigation दूसरी दिशा भेजता है
    a["Win32 error 5"] --> ad["Permission समस्या जाँचें"]
    b["NTSTATUS 0xC0000005"] --> bd["Program bug जाँचें"]
    a -.-> memo["अलग प्रणालियों के unrelated codes"]
    b -.-> memo

चित्र 21: “5” कनेक्शन के कारण उन्हें एक समान न मानें। Error 5 permission समस्या की ओर जाती है; 0xC0000005 program bug की ओर।

10. सारांश

• Windows error codes Win32 error codes, HRESULT और NTSTATUS की तीन-layer structure हैं। पहले तय करें किस layer, किस पक्ष ने code लौटाया।
• Notation डगमगाहट (decimal / hex / negative) यांत्रिक रूप से align हो सकती है। Negative को 8-digit hex में बदलकर फिर पढ़ें।
• HRESULT S/R/C/N/X bits + Facility (11 bits) + Code (16 bits) की structure है, और 0x8007xxxx सबसे महत्वपूर्ण पैटर्न है, wrapped Win32 error। निचले 16 bits decimal करें और आवश्यक code निकालें।
• 0x80004005 (E_FAIL) जैसा generic code कारण नहीं दर्शाता। Code में खोदना बंद कर context investigation पर switch का निर्णय ठीक इसलिए संभव है क्योंकि आप structure जानते हैं।
• NTSTATUS crash exception codes या Procmon के Result column में मिलता है। 0xC0000005 access violation है, Win32 error 5 से unrelated। STOP codes और एक प्रणाली है।
• .NET में HRESULT exception type पर map होता है, और original मान Exception.HResult में रहता है। P/Invoke में SetLastError=true और Marshal.GetLastWin32Error को set के रूप में इस्तेमाल करें।
• Lookup tools certutil -error और net helpmsg (मानक), err.exe (development machine), PowerShell one-liners, और WinDbg का !error हैं।
• प्रक्रिया है “notation normalize करें → layer तय करें → decompose करें → नाम खोजें → context से मिलान”। Code जो बताता है failure का type है; कारण का स्थान context बताता है।

अगली बार अपरिचित error code मिले तो search box में चिपकाने से पहले अग्रणी कुछ digits देखें। 0x8007 हो तो निचले 4 digits, 0xC हो तो NTSTATUS, negative हो तो hex में बदलें — यह 10-second decomposition बाद का investigation समय काफी हद तक तय करता है।

संबंधित लेख

• WinDbg + SOS से crash dump पढ़ना — संग्रह के बाद विश्लेषण की व्यावहारिक guide
• Windows crash dump संग्रह का परिचय - WER/ProcDump/WinDbg
• Exception handling में catch और logging कहाँ रखें?
• Process Monitor (ProcMon) की व्यावहारिक guide — 10 मिनट में “setting लागू नहीं” और “ACCESS DENIED” पिन करना
• Windows Event Log और ETW का परिचय — व्यावसायिक ऐप के logs OS के मानक mechanism पर रखना

संबंधित परामर्श क्षेत्र

KomuraSoft LLC error codes से शुरू होने वाली incident investigation संभालती है — “मुझे नहीं पता यह error code क्या मतलब रखता है”, “0x80070005 केवल विशिष्ट environment में आता है” —, Win32 API, COM और .NET मिलाती ऐप्स के लिए error-handling डिज़ाइन, तथा crash dump और Process Monitor से कारण पहचान। Error dialog के एक screenshot से परामर्श ठीक है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

Error 0x80004005 का क्या अर्थ है?

0x80004005 HRESULT E_FAIL है, और इसका अर्थ "Unspecified failure" (अनिर्दिष्ट failure) है। अर्थात यह केवल यह दर्शाता है कि "एक failure हुई जो विस्तृत कारण नहीं बता सकती"; यह कारण स्वयं का प्रतिनिधित्व करने वाला code नहीं है। वही 0x80004005 unrelated जगहों पर आता है — networking, Windows Update, VBA, database drivers — इसी कारण। जब यह code दिखे, code के अर्थ में न खोदें; कारण को उस context से संकीर्ण करें कि किस ऐप और किस operation ने इसे पैदा किया, तथा event log या detailed logs में बची अन्य error जानकारी से।

-2147467259 जैसा negative error code क्या है?

यह 32-bit HRESULT है जिसे signed decimal के रूप में दिखाया गया है। HRESULT failure पर most significant bit set करता है, इसलिए signed integer के रूप में यह हमेशा negative होता है। PowerShell में, '0x{0:X8}' -f -2147467259 इसे वापस hexadecimal में बदलता है (इस उदाहरण में 0x80004005 = E_FAIL)। जब log या script error message में -214… से शुरू होने वाली negative संख्या दिखे, मानक पहला कदम उसे hex में बदलकर फिर search करना है।

Error code का अर्थ खोजने का सबसे आसान तरीका क्या है?

बिना extra install के command prompt पर net helpmsg 5 (decimal में Win32 error के लिए) और certutil -error 0x80070005 इस्तेमाल कर सकते हैं। certutil hexadecimal HRESULT भी स्वीकार करता है और symbol नाम तथा message text दिखाता है। PowerShell में, [System.ComponentModel.Win32Exception]::new(5).Message localized message लाता है। Development machine पर Microsoft का आधिकारिक lookup tool err.exe (Microsoft Error Lookup Tool) रखें; यह Win32, HRESULT और NTSTATUS में search कर सकता है और मेल खाती definitions एक साथ list करता है।

0xC0000005 किस तरह की error है?

यह NTSTATUS STATUS_ACCESS_VIOLATION है, अर्थात access violation (invalid memory access)। यह वह code है जो ऐप crash होने पर event log या crash dump में "Exception code" के रूप में सबसे अधिक दिखता है, और invalid pointer के dereference या पहले से free की गई memory की access जैसी program bugs दर्शाता है। नाम Win32 error 5 (ERROR_ACCESS_DENIED = Access Denied) से मिलता-जुलता है, पर यह अलग प्रणाली का unrelated code है; उन्हें भ्रमित न करें। कारण पहचानने का विश्वसनीय तरीका crash dump पकड़ना और WinDbg में विश्लेषण करना है।

एक ही error code पर भी कारण हर बार अलग क्यों होता है?

क्योंकि error code केवल "किस तरह की failure" दर्शाता है, और "क्या fail हुआ और क्यों" calling context तय करता है। Error 5 (Access Denied), उदाहरण के लिए, पूरी तरह अलग कारणों के लिए वही code है — insufficient NTFS permissions, admin privilege की कमी, antivirus block, इत्यादि। समान स्थिति में, यदि कोई अन्य process file अभी भी खुली रखे तो अलग code मिलता है (error 32 = sharing violation), और code सही पढ़ना search की जगह बदल देता है। Error 2 (file not found) भी अक्सर मुख्य file नहीं बल्कि dependent DLL या settings file होती है। Code का अर्थ खोजने के बाद Process Monitor या समान से पुष्टि करना कि कौन-सा API किस resource के विरुद्ध fail हुआ, कारण तक का छोटा रास्ता है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।