Windows त्रुटि कोड पढ़ना — Win32, HRESULT और NTSTATUS की तीन-परत संरचना

“ऐप स्क्रीन पर त्रुटि 0x80004005 आई। इसका क्या अर्थ है?” — घटना-जाँच परामर्शों में इस तरह का प्रश्न क्लासिक है। जिसने त्रुटि संवाद से संख्या सीधे खोज इंजन में चिपकाई और असंबंधित लेखों की बाढ़ मिली — Windows Update विफलता, साझा फ़ोल्डर जो जुड़ता नहीं, VBA रनटाइम त्रुटि, डेटाबेस कनेक्शन विफलता — और और अधिक उलझ गया, उसके साथ बहुत लोग हैं।

ऐसा इसलिए होता है क्योंकि 0x80004005 (E_FAIL) एक सामान्य कोड है जिसका एकमात्र अर्थ “अनिर्दिष्ट विफलता” है। वही कोड अनगिनत स्थितियों में लगता है, इसलिए केवल कोड से खोज कारण तक नहीं पहुँचती। दूसरी ओर, 0x80070005 जैसा कोड, यदि संरचना पता हो, खोज से पहले कुछ सेकंड में “Win32 त्रुटि संख्या 5 = पहुँच अस्वीकृत, HRESULT के रूप में लपेटा” में विघटित हो सकता है।

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

छोटे और मध्यम व्यवसायों के आईटी कर्मचारियों तथा Windows ऐप डेवलपरों के लिए, यह लेख तीन त्रुटि-कोड प्रणालियों को अलग और विघटित करना, .NET अपवादों से संबंध, तथा err.exe और PowerShell से व्यावहारिक खोज व्यवस्थित करता है — Microsoft Learn और अगस्त 2026 तक प्रकाशित विनिर्देश [MS-ERREF] पर आधारित।

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

• Windows त्रुटि कोड मुख्यतः तीन प्रणालियाँ हैं। Win32 त्रुटि कोड (GetLastError जो छोटा दशमलव लौटाता है), HRESULT (COM से 32-बिट कोड, 0x8 से शुरू हेक्स या ऋणात्मक दशमलव), और NTSTATUS (कर्नेल-परत कोड; त्रुटियाँ 0xC से शुरू)।¹²³
• दशमलव और हेक्साडेसिमल एक ही कोड की अलग नोटेशन हैं। “त्रुटि 5”, “0x5” और “0x80070005 के निचले 16 बिट” सभी ERROR_ACCESS_DENIED (पहुँच अस्वीकृत) को दर्शाते हैं।¹
• 0x8007xxxx “लपेटा हुआ Win32 त्रुटि” है। यह HRESULT FACILITY_WIN32 (7) में संग्रहीत Win32 त्रुटि कोड है; निचले 16 बिट दशमलव में बदलें तो आवश्यक कोड मिलता है। त्रुटि कोड पढ़ने का यह सबसे महत्वपूर्ण पैटर्न है।⁴⁵
• 0x80004005 (E_FAIL) कारण कोड नहीं है। इसका अर्थ “Unspecified failure” है और अधिक जानकारी नहीं रखता। इस कोड में खोदने के बजाय मूल संदर्भ और साथ के लॉग देखें।⁶
• ऋणात्मक दशमलव (-2147467259 और जैसे) HRESULT है। 32 बिट का सबसे महत्वपूर्ण बिट (विफलता बिट) सेट है, इसलिए हस्ताक्षरित प्रदर्शन ऋणात्मक है। इसे हेक्स में बदलकर फिर पढ़ें।²
• 0xC से शुरू 8-अंक मान NTSTATUS है। 0xC0000005 (एक्सेस उल्लंघन) और 0xC0000135 (DLL नहीं मिली) क्रैश समय इवेंट लॉग और डंप में लगातार आते हैं। वे Win32 त्रुटि संख्या 5 से असंबंधित हैं।⁷
• एक ही कोड संदर्भ के साथ अर्थ बदलता है। त्रुटि 5 का कारण ACL, उन्नयन, एंटीवायरस, पकड़ी गई फ़ाइल और अधिक तक फैला है, और त्रुटि 2 की “फ़ाइल नहीं मिली” अक्सर आश्रित DLL होती है। कोड का अर्थ हमेशा किस API ने किसके विरुद्ध विफल हुआ, उसके साथ पढ़ें।¹
• रूपांतरण और खोज उपकरण मानक हैं। certutil -error और net helpmsg Windows में बने हैं; PowerShell का Win32Exception संदेश लाता है; विकास मशीन पर err.exe (Microsoft Error Lookup Tool); डंप विश्लेषण में WinDbg का !error।⁸⁹¹⁰
• .NET में HRESULT अपवाद प्रकार पर मैप होता है। ज्ञात HRESULT संबंधित प्रकार पर जाता है (E_ACCESSDENIED → UnauthorizedAccessException आदि); अज्ञात COMException बनता है; मूल मान Exception.HResult में रहता है।¹¹

एक वाक्य में, Windows त्रुटि-कोड जाँच का पैटर्न है “नोटेशन को हेक्स पर संरेखित करें → तय करें कोड किस परत का है → विघटित कर आवश्यक कोड निकालें → संदर्भ के साथ पढ़ें”।

2. Windows में तीन त्रुटि-कोड प्रणालियाँ हैं

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

ऐतिहासिक रूप से वे इस क्रम में ढेर हुए: MS-DOS त्रुटि संख्याएँ विरासत में लेने वाले Win32 त्रुटि कोड, NTSTATUS जो NT कर्नेल आंतरिक रूप से इस्तेमाल करता है, और HRESULT जो COM के आगमन पर “सफलता/विफलता और मूल को 32 बिट में पैक” करने के लिए बनाया गया। वर्तमान Windows पर रूपांतरण प्रवाह रोज़मर्रा है: कर्नेल NTSTATUS लौटाता है, Win32 उपप्रणाली उसे Win32 त्रुटि कोड में बदलती है, और COM परत उसे आगे HRESULT के रूप में लपेटती है।¹²⁴

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

चित्र 1: परतों के आर-पार रूपांतरण प्रवाह। कर्नेल NTSTATUS Win32 त्रुटि बनता है, और आगे HRESULT के रूप में लपेटा जाता है।

2.1. दशमलव और हेक्साडेसिमल को परस्पर पढ़ने की आदत डालें

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

• “त्रुटि 5”, “त्रुटि कोड: 0x5” → वही ERROR_ACCESS_DENIED
• “त्रुटि 1223”, “0x4C1” → वही ERROR_CANCELLED
• “0x80070005”, “-2147024891” → वही HRESULT

PowerShell में रूपांतरण एक पंक्ति है।

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

# Hex → decimal
0x4C1                        # 1223

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

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

चित्र 2: दशमलव, हेक्स और HRESULT के निचले 16 बिट एक ही कोड की केवल अलग नोटेशन हैं।

3. Win32 त्रुटि कोड — GetLastError और FORMAT_MESSAGE

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

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

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

1. विफलता के तुरंत बाद पढ़ें। यदि बीच में कोई अन्य API कॉल (उदाहरण लॉगिंग फ़ंक्शन) डालें, वह कॉल last-error code अधिलेखित कर सकती है।
2. सफलता पर मान पर भरोसा न करें। कुछ API सफलता पर last-error code 0 कर देते हैं; कुछ छूते नहीं। नियम है वापसी मान से विफलता पुष्टि कर फिर पढ़ना।

sequenceDiagram
    accTitle: विफलता के तुरंत बाद GetLastError पढ़ें
    accDescr: वापसी मान से विफलता पुष्टि के बाद, बिना अन्य API कॉल डाले तुरंत GetLastError से last-error code लें
    participant app as App
    participant api as Win32 API
    app->>api: CreateFile कॉल
    api-->>app: विफलता वापसी मान
    app->>api: GetLastError
    api-->>app: कोड 5
    Note over app: बीच में अन्य API डालना अधिलेखित कर सकता है

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

कोड से संदेश स्ट्रिंग पाने के लिए FORMAT_MESSAGE_FROM_SYSTEM फ़्लैग के साथ 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);
}

अपने ऐप के लॉग में दशमलव, हेक्स और संदेश पाठ तीनों छोड़ना, ऐसे, बाद की जाँच एक कदम तेज़ करता है।

flowchart TB
    accTitle: कोड से संदेश खोजें और लॉग में छोड़ें
    accDescr: FormatMessage को FORMAT_MESSAGE_FROM_SYSTEM फ़्लैग दें ताकि त्रुटि कोड की संदेश स्ट्रिंग मिले, और लॉग में दशमलव, हेक्स तथा पाठ छोड़ें
    code["त्रुटि कोड（उदाहरण: 5）"] --> fm["FormatMessage से स्ट्रिंग लें"]
    fm --> msg["संदेश पाठ"]
    msg --> log["लॉग में लिखें"]
    log -.-> both["दशमलव, हेक्स और पाठ साथ लिखें"]

चित्र 4: FormatMessage से त्रुटि कोड को संदेश स्ट्रिंग में बदलें, और लॉग में दशमलव, हेक्स तथा पाठ साथ छोड़ें।

3.2. क्षेत्र में लगातार आने वाले प्रतिनिधि कोड

Win32 त्रुटि कोड 0–15999 सीमा में परिभाषित हैं, और Microsoft Learn की पूरी सूची है।¹ उनमें, घटना जाँच में बार-बार मिलने वाले चेहरे निम्न हैं।

इनमें से 998 (ERROR_NOACCESS) “पहुँच अस्वीकृत” नहीं बल्कि मेमोरी एक्सेस उल्लंघन का Win32 अभिव्यक्ति है, बाद में चर्चित NTSTATUS STATUS_ACCESS_VIOLATION का Win32 परत पर रूपांतरण के बाद का आकार। संख्या 5 से भ्रम से सावधान रहें। साथ ही, 1223 (ERROR_CANCELLED) वह कोड है जो उदाहरण के लिए UAC उन्नयन संवाद पर उपयोगकर्ता “नहीं” चुनने पर आता है — त्रुटि से अधिक “रद्द हुआ”।

flowchart TB
    accTitle: त्रुटि 998 और 5 अलग चीज़ें हैं
    accDescr: 998 मेमोरी एक्सेस उल्लंघन है, Win32 परत पर परिवर्तित NTSTATUS एक्सेस उल्लंघन, और पहुँच अस्वीकृत दर्शाने वाले 5 से अर्थ में भिन्न
    nt["NTSTATUS 0xC0000005"] -->|Win32 परत पर परिवर्तित| e998["त्रुटि 998（ERROR_NOACCESS）"]
    e998 -.-> m1["अर्थ मेमोरी एक्सेस उल्लंघन है"]
    e5["त्रुटि 5（पहुँच अस्वीकृत）"] -.-> m2["अनुमति समस्या। 998 से अलग चीज़"]

चित्र 5: त्रुटि 998 Win32 परत पर परिवर्तित NTSTATUS एक्सेस उल्लंघन है, पहुँच-अस्वीकृत 5 से अलग चीज़।

3.3. एक ही कोड संदर्भ के साथ अर्थ बदलता है

प्रतिनिधि कोड की तालिका रटने से अधिक महत्वपूर्ण यह भाव है कि त्रुटि कोड केवल “विफलता का प्रकार” बताता है।

• त्रुटि 5 (पहुँच अस्वीकृत): कारण के उम्मीदवार व्यापक हैं — अपर्याप्त NTFS ACL, व्यवस्थापक विशेषाधिकार के बिना सुरक्षित क्षेत्र लिखना, एंटीवायरस या AppLocker ब्लॉक, सेवा खाते के अपर्याप्त विशेषाधिकार, इत्यादि।
• त्रुटि 2 (फ़ाइल नहीं मिली): जरूरी नहीं कि उपयोगकर्ता द्वारा निर्दिष्ट फ़ाइल हो। वह आश्रित DLL जिसे EXE ने अंतर्निहित रूप से लोड करने की कोशिश की, रजिस्ट्री पुनर्निर्देशन (32-बिट/64-बिट) के कारण गलत जगह दिखी सेटिंग फ़ाइल, वह पथ जिसका पर्यावरण-चर विस्तार विफल हुआ — “कौन-सी फ़ाइल” नहीं मिली, कोड से नहीं दिखता।
• त्रुटि 32 (साझाकरण उल्लंघन): “कौन-सी प्रक्रिया पकड़े है” असली प्रश्न है, पर कोड वह नहीं बताता।

flowchart TB
    accTitle: त्रुटि 5 का कारण संदर्भ तय करता है
    accDescr: एक ही पहुँच अस्वीकृत के भी कई कारण उम्मीदवार हैं जैसे अपर्याप्त ACL या व्यवस्थापक विशेषाधिकार की कमी, और पहचानना होगा कौन-सा API किसके विरुद्ध विफल हुआ
    e5["त्रुटि 5（पहुँच अस्वीकृत）"] --> c1["अपर्याप्त ACL"]
    e5 --> c2["व्यवस्थापक अधिकार नहीं"]
    e5 --> c3["सुरक्षा-उत्पाद ब्लॉक"]
    e5 --> c4["सेवा विशेषाधिकार कम"]
    c1 --> next["Procmon: विफल लक्ष्य"]
    c2 --> next
    c3 --> next
    c4 --> next

चित्र 6: कोड केवल “विफलता का प्रकार” बताता है। त्रुटि 5 के कई कारण उम्मीदवार हैं, और लक्ष्य पहचानना आवश्यक है।

वह उपकरण जो मापता है “कौन-सा API, किस ऑब्जेक्ट नाम के विरुद्ध, कौन-सा परिणाम लौटाया” Process Monitor है। उसका उपयोग विस्तार से “Process Monitor (ProcMon) की व्यावहारिक मार्गदर्शिका” में है। त्रुटि कोड का अर्थ खोजना और विफल लक्ष्य पहचानना एक ही गाड़ी के दो पहिए हैं।

4. HRESULT — 32 बिट में पैक संरचना पढ़ना

4.1. बिट लेआउट

HRESULT वह प्रारूप है जो सफलता/विफलता, मूल और विवरण कोड को एक 32-बिट मान में पैक करता है। प्रकाशित विनिर्देश [MS-ERREF] इसे निम्न लेआउट से परिभाषित करता है।²

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

flowchart TB
    accTitle: S बिट और ऋणात्मक प्रदर्शन का संबंध
    accDescr: विफलता HRESULT का सबसे महत्वपूर्ण S बिट 1 है, इसलिए हेक्स में 0x8 या ऊपर से शुरू होता है, और हस्ताक्षरित 32-बिट पूर्णांक के रूप में ऋणात्मक है
    s["S बिट = 1（विफलता）"] --> hex["हेक्स 0x8 या ऊपर से शुरू"]
    hex --> neg["हस्ताक्षरित प्रदर्शन ऋणात्मक"]
    neg --> back["ऋणात्मक दिखे तो हेक्स में बदलकर पढ़ें"]

चित्र 7: विफलता HRESULT 0x8 या ऊपर से शुरू होता है क्योंकि S बिट 1 है, और हस्ताक्षरित प्रदर्शन ऋणात्मक है।

प्रतिनिधि Facility मान निम्न हैं।⁵

4.2. 0x80004005 और 0x80070005 विघटित करना

वास्तव में विघटित करें।

0x80004005 के लिए: S=1 (विफलता), Facility=(0x80004005 » 16) & 0x7FF = 0 (FACILITY_NULL), Code=0x4005। सामान्य FACILITY_NULL कोड, E_FAIL “Unspecified failure” के रूप में परिभाषित।⁶ अर्थात यह कोड केवल अर्थ “विस्तार न बता सकने वाली विफलता” रखता है। 0x80004005 दिखे तो वहीं कोड स्वयं में खोदना बंद करें, और जाँच का भार “किस घटक ने लौटाया” तथा “इसी समय इवेंट लॉग या ऐप लॉग में विस्तार है क्या” पर शिफ्ट करें।

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

एक ही “पहुँच अस्वीकृत” के लिए भी, 0x80070005 Win32 परत पर हुई ठोस विफलता का लपेट है, और जानकारी की मात्रा 0x80004005 से पूरी तरह अलग है।

flowchart TB
    accTitle: 0x80004005 और 0x80070005 का विघटन
    accDescr: 0x80004005 सामान्य FACILITY_NULL कोड E_FAIL है, विस्तार नहीं रखता, और संदर्भ जाँच पर जाना चाहिए; 0x80070005 FACILITY_WIN32 है और Win32 त्रुटि संख्या 5, पहुँच अस्वीकृत, के लपेट के रूप में पढ़ा जा सकता है
    a["0x80004005"] --> af["Facility=0（FACILITY_NULL）"]
    af --> ac["Code=0x4005 → E_FAIL"]
    ac --> ax["अनिर्दिष्ट विफलता। संदर्भ जाँच पर आगे"]
    b["0x80070005"] --> bf["Facility=7（FACILITY_WIN32）"]
    bf --> bc["Code=0x0005 → 5"]
    bc --> bx["ERROR_ACCESS_DENIED"]

चित्र 8: एक ही “विफलता” विघटन के बाद जानकारी की मात्रा अलग रखती है। 0x80070005 को Win32 त्रुटि संख्या 5 तक चलाया जा सकता है।

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

निचली परत से, जो केवल Win32 त्रुटि कोड लौटा सकती है, ऊपरी परत तक जो HRESULT लौटाती है (COM विधि या .NET रनटाइम), विफलता पहुँचाने के लिए winerror.h मैक्रो HRESULT_FROM_WIN32 देता है।⁴ व्यवहार है “Win32 त्रुटि कोड निचले 16 बिट में रखें, Facility को FACILITY_WIN32 (7) करें, और S बिट 1 करें”।

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

चित्र 9: HRESULT_FROM_WIN32 Win32 त्रुटि निचले 16 बिट में रखता है और Facility=7 तथा 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)

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

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

दूसरे उदाहरण की तरह, WinINet और WinHTTP त्रुटियाँ (12000 वाले) भी Win32 त्रुटि-कोड स्थान में परिभाषित हैं¹, इसलिए नेटवर्किंग 0x8007xxxx उसी प्रक्रिया से विघटित होता है। “0x8007 दिखे तो निचले 4 अंक दशमलव में बदलें” को मांसपेशी स्मृति में लाना इस लेख का नंबर-एक व्यावहारिक कौशल है जो आप साथ ले जाएँ।

0x8004xxxx (FACILITY_ITF) के लिए उलटी चेतावनी है। FACILITY_ITF कोड का अर्थ परिभाषित करने वाला पक्ष प्रति इंटरफ़ेस अलग होता है, इसलिए वही 32-बिट मान लौटाने वाला पक्ष अलग हो तो कुछ और मतलब कर सकता है।⁵ अपरिचित 0x8004xxxx सामान्य खोज में नहीं, बल्कि लौटाने वाले घटक के दस्तावेज़ (लाइब्रेरी, ड्राइवर SDK, सर्वर उत्पाद) में खोजें।

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

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

5. NTSTATUS — कर्नेल-परत कोड और क्रैश की दुनिया

5.1. लेआउट और Severity

NTSTATUS 32-बिट कोड है जिसे कर्नेल, डिवाइस ड्राइवर और ntdll नेटिव API इस्तेमाल करते हैं, और उसका लेआउट HRESULT के समान है बिना वही हुए।³

Severity 2 बिट होने से प्रकार अग्रणी हेक्स अंक से पढ़ा जा सकता है। 0xC… त्रुटि (11) है, 0x8… चेतावनी (10), 0x4… सूचनात्मक (01), 0x0–0x3… सफलता। ब्रेकपॉइंट अपवाद 0x80000003 (STATUS_BREAKPOINT) “चेतावनी, त्रुटि नहीं” का प्रतिनिधि उदाहरण है।³⁷

flowchart TB
    accTitle: NTSTATUS अग्रणी अंक से प्रकार पढ़ा जाता है
    accDescr: Severity 2 बिट होने से NTSTATUS त्रुटि पढ़ा जाता है यदि अग्रणी हेक्स अंक 0xC हो, चेतावनी यदि 0x8, सूचनात्मक यदि 0x4, और सफलता यदि 0x0 से 0x3
    head{"अग्रणी हेक्स अंक है?"} -->|0xC| e["त्रुटि"]
    head -->|0x8| w["चेतावनी"]
    head -->|0x4| i["सूचनात्मक"]
    head -->|0x0–0x3| s["सफलता"]
    w -.-> ex["उदाहरण: 0x80000003 चेतावनी है"]

चित्र 11: NTSTATUS अग्रणी हेक्स अंक से प्रकार पढ़ा जाता है। 0x80000003 “चेतावनी, त्रुटि नहीं” है।

5.2. कहाँ मिलता है — अपवाद कोड, STOP कोड और इवेंट लॉग

जिन स्थितियों में आईटी कर्मचारी और डेवलपर NTSTATUS से मिलते हैं वे मुख्यतः क्रैश-संबंधी हैं।

• ऐप-क्रैश अपवाद कोड: इवेंट लॉग के “Application Error (event ID 1000)” में दर्ज “Exception code: 0xc0000005” NTSTATUS है। प्रतिनिधि मान निम्न हैं।⁷

• ब्लू-स्क्रीन STOP कोड: एक नज़र में समान लगते हैं, पर STOP कोड (बग चेक कोड) NTSTATUS से अलग अपनी संख्या प्रणाली है, जैसे 0x0000009F (DRIVER_POWER_STATE_FAILURE), और समर्पित संदर्भ है।¹⁴ केवल भेद याद रखना “0xC0000005 NTSTATUS है; STOP 0x9F बग चेक कोड है और NTSTATUS तालिका में न खोजें” पर्याप्त है।
• Process Monitor का Result स्तंभ: Procmon के Result स्तंभ में NAME NOT FOUND और ACCESS DENIED कर्नेल द्वारा लौटाए NTSTATUS के प्रदर्शन नाम हैं (STATUS_OBJECT_NAME_NOT_FOUND, STATUS_ACCESS_DENIED)। यह वह जगह भी है जहाँ परत-संगति महसूस होती है: फ़ाइल-I/O विफलता को NTSTATUS शब्दावली में देखना और उस विफलता का Win32 त्रुटि में बदलकर ऐप तक पहुँचना।

flowchart TB
    accTitle: अपवाद कोड को STOP कोड से अलग करना
    accDescr: इवेंट-लॉग अपवाद कोड NTSTATUS के रूप में पढ़ें; ब्लू-स्क्रीन STOP कोड समर्पित बग-चेक-कोड संदर्भ में खोजें, अलग प्रणाली
    q{"कोड कहाँ दिखाई दिया?"} -->|अपवाद कोड| nt["NTSTATUS के रूप में पढ़ें"]
    q -->|STOP कोड| bc["बग-चेक-कोड तालिका में खोजें"]
    nt -.-> n1["उदाहरण: 0xC0000005"]
    bc -.-> b1["उदाहरण: 0x0000009F"]

चित्र 12: इवेंट-लॉग अपवाद कोड NTSTATUS है; ब्लू-स्क्रीन STOP कोड अलग प्रणाली है। गलत तालिका में न खोजें।

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

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

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

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

flowchart TB
    accTitle: NTSTATUS से अन्य परतों तक दो पुल
    accDescr: NTSTATUS अन्य परतों तक दो तरह जाता है: N बिट सेट कर HRESULT स्थान में मैप, और RtlNtStatusToDosError से Win32 त्रुटि कोड में रूपांतरण
    nt["NTSTATUS（0xC0000005）"] -->|N बिट सेट करें| hr["HRESULT（0xD0000005）"]
    nt -->|RtlNtStatusToDosError| win["Win32 त्रुटि 998（ERROR_NOACCESS）"]
    win -.-> memo["ERROR_MR_MID_NOT_FOUND यदि संगति परिभाषित नहीं"]

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

6. COM और .NET — त्रुटि कोड अपवाद पर कैसे मैप होता है

6.1. COM शैली — HRESULT + IErrorInfo

COM विधि मूलतः HRESULT लौटाती है, पर 32 बिट में क्या पैक हो इसकी सीमा है, इसलिए पूरक के रूप में IErrorInfo तंत्र त्रुटि विवरण स्ट्रिंग और मूल अलग से पहुँचा सकता है। C++ में कंपाइलर-समर्थित _com_error वर्ग HRESULT और IErrorInfo दोनों संभालता है। वह ऐप जिसका त्रुटि संवाद “कोड + विवरण” दिखाता है अक्सर विवरण इसी तंत्र से लाता है।

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

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

6.2. .NET शैली — HRESULT से अपवाद प्रकार तक

जब .NET रनटाइम COM interop में HRESULT विफलता पाता है, वह उसे अपवाद में बदलता है। ज्ञात HRESULT संबंधित अपवाद प्रकार पर मैप होता है; अज्ञात COMException बनता है।¹¹

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

चित्र 15: .NET HRESULT को अपवाद प्रकार पर मैप करता है, और प्रत्येक अपवाद पर मूल मान Exception.HResult में रहता है।

प्रत्येक अपवाद पर मूल HRESULT Exception.HResult गुण में रहता है। फ़ाइल-I/O अपवाद हैंडलिंग में “केवल साझाकरण उल्लंघन पर पुनः प्रयास” जैसी शाखा इस मान से लिखी जा सकती है।

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 कॉल करें, DllImport (या LibraryImport) पर SetLastError = true निर्दिष्ट करें, फिर Marshal.GetLastWin32Error से लें (.NET 6 से समकक्ष GetLastPInvokeError)। GetLastError स्वयं को P/Invoke के रूप में परिभाषित कर कॉल करना गलत है, क्योंकि रनटाइम के अंदर API कॉल मान अधिलेखित कर सकती है।¹⁵

flowchart TB
    accTitle: P/Invoke में अंतिम त्रुटि लेना
    accDescr: SetLastError true निर्दिष्ट कर Marshal.GetLastWin32Error से लेना सही है; GetLastError सीधे P/Invoke करना रनटाइम अधिलेखन के कारण गलत
    pi["P/Invoke से Win32 API कॉल"] --> ok["SetLastError=true निर्दिष्ट करें"]
    ok --> get["GetLastWin32Error से लें"]
    pi --> ng["परिभाषा जो GetLastError सीधे कॉल करती है"]
    ng --> bad["रनटाइम अधिलेखित करता है और गलत है"]

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

[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 त्रुटि कोड से OS संदेश स्ट्रिंग खोजता है, इसलिए कोड और संदेश दोनों लॉग में छोड़ने के लिए उसे ज्यों का त्यों इस्तेमाल कर सकते हैं। डिज़ाइन प्रश्न कि अपवाद किस परत पर पकड़ें और लॉग में कैसे छोड़ें “अपवाद हैंडलिंग में catch और लॉगिंग कहाँ रखें?” में है।

7. अभ्यास में रूपांतरण और जाँच उपकरण — कॉपी-पेस्ट त्वरित संदर्भ

7.1. err.exe (Microsoft Error Lookup Tool)

Microsoft द्वारा वितरित स्वतंत्र त्रुटि-खोज उपकरण। यह winerror.h और ntstatus.h जैसे बड़ी संख्या में हेडर फ़ाइलें घूमता है और निर्दिष्ट कोड से मेल खाती परिभाषाएँ तथा संदेश सूचीबद्ध करता है।⁸

err 0x80070005
err 5
err 0xC0000005

एक संख्या कई हेडर में लग सकती है (उदाहरण “5” Win32 ERROR_ACCESS_DENIED के अलावा विभिन्न जगहों की परिभाषाओं से मेल खाती है), इसलिए उम्मीदवारों में से कौन प्रशंसनीय है संदर्भ से चुनना होगा। डाउनलोड फ़ाइल नाम संस्करणित है (लेखन समय Err_6.4.5.exe), और यह भी ध्यान दें कि कोड परिभाषाएँ बंडल के समय के हेडर पर आधारित हैं।⁸

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

चित्र 17: err.exe हेडर-पार खोज है, इसलिए कई उम्मीदवार आ सकते हैं, और प्रशंसनीय संदर्भ से चुना जाता है।

7.2. Windows में बने कमांड

बिना अतिरिक्त इंस्टॉल जो इस्तेमाल कर सकते हैं वे certutil और net helpmsg हैं। certutil का -error विकल्प त्रुटि कोड के अनुरूप संदेश पाठ दिखाता है, और हेक्साडेसिमल HRESULT या दशमलव स्वीकार करता है।⁹

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

net helpmsg केवल दशमलव में Win32 त्रुटि कोड के लिए है, पर हिंदी वातावरण में संदेश OS की स्थानीयकृत भाषा में लौटता है, इसलिए उपयोगकर्ता को व्याख्या के लिए ज्यों का त्यों इस्तेमाल कर सकते हैं।

flowchart TB
    accTitle: मानक कमांड में कैसे चुनें
    accDescr: दशमलव Win32 त्रुटि कोड net helpmsg से खोजा जाता है; हेक्स सहित कोड, HRESULT सहित, certutil के -error विकल्प से
    q{"आपके पास कोड है?"} -->|दशमलव Win32| net["net helpmsg"]
    q -->|हेक्स शामिल| cert["certutil -error"]
    net -.-> jp["स्थानीयकृत संदेश लौटता है"]
    cert -.-> any["हेक्स और दशमलव दोनों स्वीकार"]

चित्र 18: मानक कमांड में कैसे चुनें। दशमलव Win32 त्रुटि net helpmsg है; यदि हेक्स हो तो certutil -error।

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

डंप विश्लेषण के दौरान कोड खोजने के लिए WinDbg का !error एक्सटेंशन तेज़ है। डिफ़ॉल्ट से Win32 त्रुटि कोड के रूप में व्याख्या करता है; दूसरा तर्क 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>

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

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

चित्र 19: डंप विश्लेषण में !analyze -v द्वारा दिखाए अपवाद कोड को !error और फ़्लैग 1 से खोजें।

8. जाँच प्रक्रिया — परत तय करने से संदर्भ से मिलान तक

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

1. नोटेशन सामान्य करें। यदि ऋणात्मक दशमलव हो तो 8-अंक हेक्स में बदलें। 8 अंक से छोटे हेक्स को शून्य-पैड कर पढ़ें।
2. तय करें कोड किस परत का है। नीचे की निर्णय तालिका की तरह, अग्रणी कुछ अंक लगभग तय करते हैं।
3. विघटित कर आवश्यक कोड निकालें। यांत्रिक संक्रिया: 0x8007xxxx हो तो निचले 16 बिट, 0xDxxxxxxx हो तो N बिट उतारें।
4. उपकरण से नाम और परिभाषा खोजें। err.exe, certutil या !error से प्रतीक नाम और संदेश पुष्टि करें।
5. संदर्भ से मिलान करें। ऐप लॉग, इवेंट लॉग और Procmon से पहचानें किस ऐप, किस संक्रिया, किस API ने किसके विरुद्ध विफल हुआ। कोड “विफलता का प्रकार” है; संदर्भ “कारण का स्थान” है।

flowchart TB
    accTitle: त्रुटि कोड जाँचने की प्रक्रिया
    accDescr: नोटेशन को हेक्स पर संरेखित करने, अग्रणी अंकों से परत तय करने, विघटित कर आवश्यक कोड निकालने, उपकरण से नाम और परिभाषा खोजने, फिर संदर्भ से मिलान का जाँच पैटर्न
    fix["हेक्स पर सामान्य करें"] --> judge{"अग्रणी अंक?"}
    judge -->|दशमलव| d1["Win32 त्रुटि के रूप में पढ़ें"]
    judge -->|0x8007| d2["निचले 16 बिट → दशमलव"]
    judge -->|0xC| d3["NTSTATUS के रूप में पढ़ें"]
    judge -->|0xD| d4["N बिट उतारकर पढ़ें"]
    d1 --> tool["नाम/परिभाषा खोजें"]
    d2 --> tool
    d3 --> tool
    d4 --> tool
    tool --> ctx["संदर्भ मिलान（Procmon）"]

चित्र 20: जाँच पैटर्न। नोटेशन सामान्य करें, परत तय कर विघटित करें, नाम खोजें, फिर संदर्भ से मिलान करें।

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

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

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

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

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

गलत पाठ 2: न ध्यान देना कि ऋणात्मक दशमलव HRESULT है

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

गलत पाठ 3: 0x8007xxxx के पूरे 8 अंक खोजना और नीचे की Win32 त्रुटि न देखना

0x80070005 का सार “5 = पहुँच अस्वीकृत” है। निचले 16 बिट निकालने के बाद “इस संक्रिया के संदर्भ में Win32 त्रुटि 5 का क्या अर्थ” सोचना पूरे 8 अंक खोजने से तेज़ कोर तक पहुँचता है।

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

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

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

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

flowchart TB
    accTitle: त्रुटि 5 और 0xC0000005 की जाँच दिशाएँ अलग हैं
    accDescr: Win32 त्रुटि 5 को अनुमति समस्या के रूप में जाँचना चाहिए, और NTSTATUS 0xC0000005 को प्रोग्राम बग; उन्हें एक समान मानना जाँच दूसरी दिशा भेजता है
    a["Win32 त्रुटि 5"] --> ad["अनुमति समस्या जाँचें"]
    b["NTSTATUS 0xC0000005"] --> bd["प्रोग्राम बग जाँचें"]
    a -.-> memo["अलग प्रणालियों के असंबंधित कोड"]
    b -.-> memo

चित्र 21: “5” कनेक्शन के कारण उन्हें एक समान न मानें। त्रुटि 5 अनुमति समस्या की ओर जाती है; 0xC0000005 प्रोग्राम बग की ओर।

10. सारांश

• Windows त्रुटि कोड Win32 त्रुटि कोड, HRESULT और NTSTATUS की तीन-परत संरचना हैं। पहले तय करें किस परत, किस पक्ष ने कोड लौटाया।
• नोटेशन डगमगाहट (दशमलव / हेक्स / ऋणात्मक) यांत्रिक रूप से संरेखित हो सकती है। ऋणात्मक को 8-अंक हेक्स में बदलकर फिर पढ़ें।
• HRESULT S/R/C/N/X बिट + Facility (11 बिट) + Code (16 बिट) की संरचना है, और 0x8007xxxx सबसे महत्वपूर्ण पैटर्न है, लपेटा Win32 त्रुटि। निचले 16 बिट दशमलव करें और आवश्यक कोड निकालें।
• 0x80004005 (E_FAIL) जैसा सामान्य कोड कारण नहीं दर्शाता। कोड में खोदना बंद कर संदर्भ जाँच पर स्विच का निर्णय ठीक इसलिए संभव है क्योंकि आप संरचना जानते हैं।
• NTSTATUS क्रैश अपवाद कोड या Procmon के Result स्तंभ में मिलता है। 0xC0000005 एक्सेस उल्लंघन है, Win32 त्रुटि 5 से असंबंधित। STOP कोड और एक प्रणाली है।
• .NET में HRESULT अपवाद प्रकार पर मैप होता है, और मूल मान Exception.HResult में रहता है। P/Invoke में SetLastError=true और Marshal.GetLastWin32Error को सेट के रूप में इस्तेमाल करें।
• खोज उपकरण certutil -error और net helpmsg (मानक), err.exe (विकास मशीन), PowerShell वन-लाइनर, और WinDbg का !error हैं।
• प्रक्रिया है “नोटेशन सामान्य करें → परत तय करें → विघटित करें → नाम खोजें → संदर्भ से मिलान”। कोड जो बताता है विफलता का प्रकार है; कारण का स्थान संदर्भ बताता है।

अगली बार अपरिचित त्रुटि कोड मिले तो खोज बॉक्स में चिपकाने से पहले अग्रणी कुछ अंक देखें। 0x8007 हो तो निचले 4 अंक, 0xC हो तो NTSTATUS, ऋणात्मक हो तो हेक्स में बदलें — यह 10-सेकंड विघटन बाद का जाँच समय काफी हद तक तय करता है।

संबंधित लेख

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

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

KomuraSoft LLC त्रुटि कोड से शुरू होने वाली घटना जाँच संभालती है — “मुझे नहीं पता यह त्रुटि कोड क्या मतलब रखता है”, “0x80070005 केवल विशिष्ट वातावरण में आता है” —, Win32 API, COM और .NET मिलाती ऐप्स के लिए त्रुटि-हैंडलिंग डिज़ाइन, तथा क्रैश डंप और Process Monitor से कारण पहचान। त्रुटि संवाद के एक स्क्रीनशॉट से परामर्श ठीक है।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

त्रुटि 0x80004005 का क्या अर्थ है?

0x80004005 HRESULT E_FAIL है, और इसका अर्थ "Unspecified failure" (अनिर्दिष्ट विफलता) है। अर्थात यह केवल यह दर्शाता है कि "एक विफलता हुई जो विस्तृत कारण नहीं बता सकती"; यह कारण स्वयं का प्रतिनिधित्व करने वाला कोड नहीं है। वही 0x80004005 असंबंधित जगहों पर आता है — नेटवर्किंग, Windows Update, VBA, डेटाबेस ड्राइवर — इसी कारण। जब यह कोड दिखे, कोड के अर्थ में न खोदें; कारण को उस संदर्भ से संकीर्ण करें कि किस ऐप और किस संक्रिया ने इसे पैदा किया, तथा इवेंट लॉग या विस्तृत लॉग में बची अन्य त्रुटि जानकारी से।

-2147467259 जैसा ऋणात्मक त्रुटि कोड क्या है?

यह 32-बिट HRESULT है जिसे हस्ताक्षरित दशमलव के रूप में दिखाया गया है। HRESULT विफलता पर सबसे महत्वपूर्ण बिट सेट करता है, इसलिए हस्ताक्षरित पूर्णांक के रूप में यह हमेशा ऋणात्मक होता है। PowerShell में, '0x{0:X8}' -f -2147467259 इसे वापस हेक्साडेसिमल में बदलता है (इस उदाहरण में 0x80004005 = E_FAIL)। जब लॉग या स्क्रिप्ट त्रुटि संदेश में -214… से शुरू होने वाली ऋणात्मक संख्या दिखे, मानक पहला कदम उसे हेक्स में बदलकर फिर खोजना है।

त्रुटि कोड का अर्थ खोजने का सबसे आसान तरीका क्या है?

बिना अतिरिक्त इंस्टॉल के कमांड प्रॉम्प्ट पर net helpmsg 5 (दशमलव में Win32 त्रुटि के लिए) और certutil -error 0x80070005 इस्तेमाल कर सकते हैं। certutil हेक्साडेसिमल HRESULT भी स्वीकार करता है और प्रतीक नाम तथा संदेश पाठ दिखाता है। PowerShell में, [System.ComponentModel.Win32Exception]::new(5).Message स्थानीयकृत संदेश लाता है। विकास मशीन पर Microsoft का आधिकारिक खोज उपकरण err.exe (Microsoft Error Lookup Tool) रखें; यह Win32, HRESULT और NTSTATUS में खोज सकता है और मेल खाती परिभाषाएँ एक साथ सूचीबद्ध करता है।

0xC0000005 किस तरह की त्रुटि है?

यह NTSTATUS STATUS_ACCESS_VIOLATION है, अर्थात एक्सेस उल्लंघन (अवैध मेमोरी एक्सेस)। यह वह कोड है जो ऐप क्रैश होने पर इवेंट लॉग या क्रैश डंप में "Exception code" के रूप में सबसे अधिक दिखता है, और अमान्य पॉइंटर के डीरेफरेंस या पहले से मुक्त मेमोरी की पहुँच जैसी प्रोग्राम बग दर्शाता है। नाम Win32 त्रुटि 5 (ERROR_ACCESS_DENIED = पहुँच अस्वीकृत) से मिलता-जुलता है, पर यह अलग प्रणाली का असंबंधित कोड है; उन्हें भ्रमित न करें। कारण पहचानने का विश्वसनीय तरीका क्रैश डंप पकड़ना और WinDbg में विश्लेषण करना है।

एक ही त्रुटि कोड पर भी कारण हर बार अलग क्यों होता है?

क्योंकि त्रुटि कोड केवल "किस तरह की विफलता" दर्शाता है, और "क्या विफल हुआ और क्यों" कॉलिंग संदर्भ तय करता है। त्रुटि 5 (पहुँच अस्वीकृत), उदाहरण के लिए, पूरी तरह अलग कारणों के लिए वही कोड है — अपर्याप्त NTFS अनुमतियाँ, व्यवस्थापक विशेषाधिकार की कमी, एंटीवायरस ब्लॉक, इत्यादि। समान स्थिति में, यदि कोई अन्य प्रक्रिया फ़ाइल अभी भी खुली रखे तो अलग कोड मिलता है (त्रुटि 32 = साझाकरण उल्लंघन), और कोड सही पढ़ना खोज की जगह बदल देता है। त्रुटि 2 (फ़ाइल नहीं मिली) भी अक्सर मुख्य फ़ाइल नहीं बल्कि आश्रित DLL या सेटिंग फ़ाइल होती है। कोड का अर्थ खोजने के बाद Process Monitor या समान से पुष्टि करना कि कौन-सा API किस संसाधन के विरुद्ध विफल हुआ, कारण तक का छोटा रास्ता है।

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

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

Go Komura

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

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