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 এবং আগস্ট ২০২৬ পর্যন্ত প্রকাশিত স্পেসিফিকেশন [MS-ERREF] ভিত্তিতে।

১. আগে উপসংহার

• Windows ত্রুটি কোড মূলত তিন ব্যবস্থা। Win32 ত্রুটি কোড (GetLastError যে ছোট দশমিক ফেরায়), HRESULT (COM থেকে ৩২-বিট কোড, 0x8 দিয়ে শুরু হেক্স বা ঋণাত্মক দশমিক), এবং NTSTATUS (কার্নেল-স্তরের কোড; ত্রুটি 0xC দিয়ে শুরু)।¹²³
• দশমিক ও হেক্সাডেসিমাল একই কোডের আলাদা নোটেশন। “ত্রুটি 5”, “0x5” এবং “0x80070005-এর নিচের ১৬ বিট” সব ERROR_ACCESS_DENIED (অ্যাক্সেস প্রত্যাখ্যাত) নির্দেশ করে।¹
• 0x8007xxxx হলো “মোড়া Win32 ত্রুটি”। এটি HRESULT FACILITY_WIN32 (7)-এ রাখা Win32 ত্রুটি কোড; নিচের ১৬ বিট দশমিকে রূপান্তর করলে অপরিহার্য কোড পাওয়া যায়। ত্রুটি কোড পড়ার সবচেয়ে গুরুত্বপূর্ণ ধরন এটি।⁴⁵
• 0x80004005 (E_FAIL) কারণ কোড নয়। এর অর্থ “Unspecified failure” এবং আর তথ্য রাখে না। এই কোড খোঁড়ার বদলে উৎস প্রসঙ্গ ও সঙ্গী লগ খুঁজুন।⁶
• ঋণাত্মক দশমিক (-2147467259 ও অনুরূপ) HRESULT। ৩২ বিটের সর্বোচ্চ তাৎপর্যের বিট (ব্যর্থতা বিট) সেট, তাই স্বাক্ষরিত প্রদর্শন ঋণাত্মক। হেক্সে রূপান্তর করে তারপর পড়ুন।²
• 0xC দিয়ে শুরু ৮-অঙ্কের মান 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 ত্রুটি-কোড অনুসন্ধানের ধরন “নোটেশন হেক্সে সারিবদ্ধ করুন → কোড কোন স্তরের তা বিচার করুন → ভেঙে অপরিহার্য কোড বের করুন → প্রসঙ্গের সঙ্গে পড়ুন”।

২. Windows-এ তিন ত্রুটি-কোড ব্যবস্থা

আগে সামগ্রিক মানচিত্র। Windows ত্রুটি কোড মূলত নিচের তিন ব্যবস্থায় ভাগ, যে স্তর ফেরায় তার অনুসারে।

ঐতিহাসিকভাবে তারা এই ক্রমে স্তূপ: MS-DOS ত্রুটি সংখ্যা উত্তরাধিকারী Win32 ত্রুটি কোড, NTSTATUS যা NT কার্নেল অভ্যন্তরে ব্যবহার করে, এবং HRESULT যা COM আসার সময় “সফলতা/ব্যর্থতা ও উৎস ৩২ বিটে প্যাক” করতে নকশা। বর্তমান 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）"]

চিত্র ১: স্তর জুড়ে রূপান্তর প্রবাহ। কার্নেল NTSTATUS Win32 ত্রুটি হয়, তারপর আরও HRESULT হিসেবে মোড়া হয়।

২.১. দশমিক ও হেক্সাডেসিমাল পরস্পর পড়তে অভ্যস্ত হোন

তিন ব্যবস্থা আলাদা করার আগে নোটেশনের দোদুল্যমানতা শোষণ করতে হয়। একই কোড পরিস্থিতি অনুসারে দশমিক বা হেক্স দেখায়।

• “ত্রুটি 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-এর নিচের ১৬ বিট সব একই ERROR_ACCESS_DENIED নির্দেশ করে
    d["দশমিক নোটেশন: ত্রুটি 5"] --> same["ERROR_ACCESS_DENIED"]
    h["হেক্স নোটেশন: 0x5"] --> same
    l["0x80070005-এর নিচের ১৬ বিট"] --> same
    same -.-> memo["আলাদা নোটেশন, একই কোড"]

চিত্র ২: দশমিক, হেক্স ও HRESULT-এর নিচের ১৬ বিট একই কোডের কেবল আলাদা নোটেশন।

৩. Win32 ত্রুটি কোড — GetLastError ও FORMAT_MESSAGE

৩.১. মৌলিক 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 ঢোকানো ওভাররাইট করতে পারে

চিত্র ৩: ব্যর্থতার পরপর 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["দশমিক, হেক্স ও পাঠ একসঙ্গে লিখুন"]

চিত্র ৪: FormatMessage দিয়ে ত্রুটি কোডকে বার্তা স্ট্রিং করুন, এবং লগে দশমিক, হেক্স ও পাঠ একসঙ্গে রাখুন।

৩.২. মাঠে নিয়ত আসা প্রতিনিধি কোড

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 থেকে আলাদা"]

চিত্র ৫: ত্রুটি 998 Win32 স্তরে রূপান্তরিত NTSTATUS অ্যাক্সেস লঙ্ঘন, অ্যাক্সেস-প্রত্যাখ্যাত 5 থেকে আলাদা জিনিস।

৩.৩. একই কোড প্রসঙ্গে অর্থ বদলায়

প্রতিনিধি কোডের সারণি মুখস্থ করার চেয়ে গুরুত্বপূর্ণ অনুভূতি যে ত্রুটি কোড কেবল “ব্যর্থতার ধরন” বলে।

• ত্রুটি 5 (অ্যাক্সেস প্রত্যাখ্যাত): কারণের প্রার্থী বিস্তৃত — অপর্যাপ্ত NTFS ACL, অ্যাডমিনিস্ট্রেটর সুবিধা ছাড়া সুরক্ষিত এলাকায় লেখা, অ্যান্টিভাইরাস বা AppLocker ব্লক, সার্ভিস অ্যাকাউন্টের অপর্যাপ্ত সুবিধা ইত্যাদি।
• ত্রুটি 2 (ফাইল পাওয়া যায়নি): অবশ্যই ব্যবহারকারীর নির্দিষ্ট ফাইল নয়। EXE অন্তর্নিহিতভাবে লোড করতে চেষ্টা করা নির্ভরশীল DLL, রেজিস্ট্রি রিডাইরেকশন (৩২-বিট/৬৪-বিট) কারণে ভুল জায়গায় দেখা সেটিংস ফাইল, যে পথের পরিবেশ-চলক সম্প্রসারণ ব্যর্থ — “কোন ফাইল” পাওয়া যায়নি কোড থেকে দেখা যায় না।
• ত্রুটি 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

চিত্র ৬: কোড কেবল “ব্যর্থতার ধরন” বলে। ত্রুটি 5-এর কয়েকটি কারণ প্রার্থী আছে, এবং লক্ষ্য শনাক্ত করা প্রয়োজন।

যে সরঞ্জাম মাপে “কোন API, কোন অবজেক্ট নামের বিরুদ্ধে, কোন ফল ফিরিয়েছে” তা Process Monitor। ব্যবহার বিস্তারিত “Process Monitor (ProcMon)-এর ব্যবহারিক নির্দেশিকা“-এ। ত্রুটি কোডের অর্থ খোঁজা ও ব্যর্থ লক্ষ্য শনাক্ত করা একই গাড়ির দুই চাকা।

৪. HRESULT — ৩২ বিটে প্যাক করা কাঠামো পড়া

৪.১. বিট বিন্যাস

HRESULT এমন ফরম্যাট যা সফলতা/ব্যর্থতা, উৎস ও বিস্তারিত কোড এক ৩২-বিট মানে প্যাক করে। প্রকাশিত স্পেসিফিকেশন [MS-ERREF] নিচের বিন্যাসে সংজ্ঞায়িত করে।²

সর্বোচ্চ তাৎপর্যের S বিট 1, অর্থাৎ যে HRESULT-এর হেক্স নোটেশন 0x8 বা উপরে শুরু সেটি ব্যর্থতা। স্বাক্ষরিত ৩২-বিট পূর্ণসংখ্যা হিসেবে দেখালে ঋণাত্মক — সেটাই আগে বলা “-214…”-এর পরিচয়।

flowchart TB
    accTitle: S বিট ও ঋণাত্মক প্রদর্শনের সম্পর্ক
    accDescr: ব্যর্থতা HRESULT-এর সর্বোচ্চ তাৎপর্যের S বিট 1, তাই হেক্সে 0x8 বা উপরে শুরু, আর স্বাক্ষরিত ৩২-বিট পূর্ণসংখ্যা হিসেবে ঋণাত্মক
    s["S বিট = 1（ব্যর্থতা）"] --> hex["হেক্স 0x8 বা উপরে শুরু"]
    hex --> neg["স্বাক্ষরিত প্রদর্শন ঋণাত্মক"]
    neg --> back["ঋণাত্মক দেখলে হেক্সে রূপান্তর করে পড়ুন"]

চিত্র ৭: ব্যর্থতা HRESULT 0x8 বা উপরে শুরু কারণ S বিট 1, আর স্বাক্ষরিত প্রদর্শন ঋণাত্মক।

প্রতিনিধি Facility মান নিচেরগুলো।⁵

৪.২. 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"]

চিত্র ৮: একই “ব্যর্থতা” ভাঙনের পর তথ্যের পরিমাণ আলাদা রাখে। 0x80070005-কে Win32 ত্রুটি সংখ্যা 5 পর্যন্ত হাঁটানো যায়।

৪.৩. সবচেয়ে গুরুত্বপূর্ণ ধরন: 0x8007xxxx = HRESULT_FROM_WIN32

নিচের স্তর থেকে, যা কেবল Win32 ত্রুটি কোড ফেরাতে পারে, উপরের স্তরে যা HRESULT ফেরায় (COM মেথড বা .NET রানটাইম), ব্যর্থতা পৌঁছাতে winerror.h ম্যাক্রো HRESULT_FROM_WIN32 দেয়।⁴ আচরণ “Win32 ত্রুটি কোড নিচের ১৬ বিটে রাখুন, Facility-কে FACILITY_WIN32 (7) করুন, এবং S বিট 1 করুন”।

flowchart TB
    accTitle: HRESULT_FROM_WIN32 কীভাবে কাজ করে
    accDescr: Win32 ত্রুটি কোড নিচের ১৬ বিটে রাখুন, Facility 7 ও S বিট 1 করুন, এবং 0x8007xxxx HRESULT জোড় করুন
    win["Win32 ত্রুটি কোড（উদাহরণ: 5）"] --> low["নিচের ১৬ বিটে রাখুন"]
    low --> fac["Facility 7 করুন"]
    fac --> sbit["S বিট 1 করুন"]
    sbit --> hr["0x80070005"]

চিত্র ৯: HRESULT_FROM_WIN32 Win32 ত্রুটি নিচের ১৬ বিটে রাখে এবং 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-এ নিচের ১৬ বিট নিন।

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

দ্বিতীয় উদাহরণের মতো WinINet ও WinHTTP ত্রুটি (১২০০০-এর কোড সীমা)ও Win32 ত্রুটি-কোড স্থানে সংজ্ঞায়িত¹, তাই নেটওয়ার্কিং 0x8007xxxx একই পদ্ধতিতে ভাঙে। “0x8007 দেখলে নিচের ৪ অঙ্ক দশমিকে রূপান্তর করুন” পেশির স্মৃতিতে আনা এই নিবন্ধের নম্বর-এক ব্যবহারিক দক্ষতা যা আপনি সঙ্গে নিন।

0x8004xxxx (FACILITY_ITF)-এর জন্য উল্টো সতর্কতা আছে। FACILITY_ITF কোডের অর্থ সংজ্ঞায়িতকারী পক্ষ প্রতি ইন্টারফেসে আলাদা, তাই একই ৩২-বিট মান ফেরানো পক্ষ আলাদা হলে অন্য কিছু বোঝাতে পারে।⁵ অপরিচিত 0x8004xxxx সাধারণ খোঁজায় নয়, ফেরানো কম্পোনেন্টের ডকুমেন্টেশনে (লাইব্রেরি, ড্রাইভার SDK, সার্ভার পণ্য) খুঁজুন।

flowchart TB
    accTitle: 0x8007 ও 0x8004-এর মধ্যে খোঁজা কীভাবে বদলায়
    accDescr: FACILITY_WIN32 0x8007xxxx নিচের ১৬ বিট যান্ত্রিক ভাঙনে পড়া যায়, কিন্তু FACILITY_ITF 0x8004xxxx-এর অর্থ-সংজ্ঞায়ক পক্ষ প্রতি ইন্টারফেসে আলাদা, তাই ফেরানো কম্পোনেন্টের উপকরণে খুঁজুন
    hr{"Facility কী?"} -->|7, WIN32| w["নিচের ১৬ বিট দশমিক করুন"]
    hr -->|4, ITF| i["অর্থ ফেরানো পক্ষ অনুসারে ভিন্ন"]
    w --> ww["Win32 ত্রুটি হিসেবে পড়ুন"]
    i --> ii["ফেরানো পক্ষের উপকরণে খুঁজুন"]

চিত্র ১০: 0x8007xxxx যান্ত্রিকভাবে ভাঙা যায়; 0x8004xxxx ফেরানো কম্পোনেন্টের উপকরণে খোঁজা হয়।

৫. NTSTATUS — কার্নেল-স্তরের কোড ও ক্র্যাশের জগৎ

৫.১. বিন্যাস ও Severity

NTSTATUS ৩২-বিট কোড যা কার্নেল, ডিভাইস ড্রাইভার ও ntdll নেটিভ API ব্যবহার করে, এবং এর বিন্যাস HRESULT-এর মতো কিন্তু একই নয়।³

Severity ২ বিট হওয়ায় ধরন অগ্রণী হেক্স অঙ্ক থেকে পড়া যায়। 0xC… ত্রুটি (11), 0x8… সতর্কতা (10), 0x4… তথ্যমূলক (01), 0x0–0x3… সফলতা। ব্রেকপয়েন্ট ব্যতিক্রম 0x80000003 (STATUS_BREAKPOINT) “সতর্কতা, ত্রুটি নয়”-এর প্রতিনিধি উদাহরণ।³⁷

flowchart TB
    accTitle: NTSTATUS অগ্রণী অঙ্ক থেকে ধরন পড়া যায়
    accDescr: Severity ২ বিট হওয়ায় NTSTATUS ত্রুটি পড়া যায় যদি অগ্রণী হেক্স অঙ্ক 0xC হয়, সতর্কতা যদি 0x8, তথ্যমূলক যদি 0x4, এবং সফলতা যদি 0x0 থেকে 0x3
    head{"অগ্রণী হেক্স অঙ্ক?"} -->|0xC| e["ত্রুটি"]
    head -->|0x8| w["সতর্কতা"]
    head -->|0x4| i["তথ্যমূলক"]
    head -->|0x0–0x3| s["সফলতা"]
    w -.-> ex["উদাহরণ: 0x80000003 সতর্কতা"]

চিত্র ১১: NTSTATUS অগ্রণী হেক্স অঙ্ক থেকে ধরন পড়া যায়। 0x80000003 “সতর্কতা, ত্রুটি নয়”।

৫.২. কোথায় দেখা — ব্যতিক্রম কোড, 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"]

চিত্র ১২: ইভেন্ট-লগ ব্যতিক্রম কোড NTSTATUS; নীল-পর্দা STOP কোড আলাদা ব্যবস্থা। ভুল সারণিতে খুঁজবেন না।

ব্যতিক্রম কোডের বাইরের অনুসন্ধান, অর্থাৎ ক্র্যাশ ডাম্প ধরা ও বিশ্লেষণ, “Windows ক্র্যাশ ডাম্প সংগ্রহের ভূমিকা” ও “WinDbg + SOS দিয়ে ক্র্যাশ ডাম্প পড়া“-এ আছে।

৫.৩. 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 যদি সংগতি সংজ্ঞায়িত না হয়"]

চিত্র ১৩: NTSTATUS সেতু দুটি। 0xD শুরু N বিট খোলার পর NTSTATUS হিসেবে পড়া হয়।

৬. COM ও .NET — ত্রুটি কোড ব্যতিক্রমে কীভাবে ম্যাপ হয়

৬.১. COM শৈলী — HRESULT + IErrorInfo

COM মেথড মৌলিকভাবে HRESULT ফেরায়, কিন্তু ৩২ বিটে কী প্যাক হয় তার সীমা আছে, তাই পরিপূরক হিসেবে IErrorInfo প্রক্রিয়া ত্রুটি বর্ণনা স্ট্রিং ও উৎস আলাদা পৌঁছাতে পারে। C++-এ কম্পাইলার-সমর্থিত _com_error ক্লাস HRESULT ও IErrorInfo একসঙ্গে সামলায়। যে অ্যাপের ত্রুটি ডায়ালগ “কোড + বর্ণনা” দেখায় সে প্রায়ই বর্ণনা এই প্রক্রিয়ায় আনে।

flowchart TB
    accTitle: IErrorInfo যা HRESULT-এর পরিপূরক
    accDescr: ৩২-বিট HRESULT-এ কী প্যাক হয় তার সীমা আছে, তাই ত্রুটি বর্ণনা স্ট্রিং ও উৎস IErrorInfo দিয়ে আলাদা পৌঁছায়, আর C++-এ _com_error ক্লাস দুটো একসঙ্গে সামলায়
    hr["HRESULT（কেবল ৩২ বিট）"] --> lim["প্যাক হওয়ার সীমা আছে"]
    lim --> ei["IErrorInfo বর্ণনা আনে"]
    ei --> ce["_com_error তাদের একসঙ্গে সামলায়"]
    ce -.-> dlg["ডায়ালগের কোড + বর্ণনা"]

চিত্র ১৪: ৩২-বিট HRESULT-এ না-মাপা বর্ণনা স্ট্রিং IErrorInfo আলাদা আনে।

৬.২. .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

চিত্র ১৫: .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
}

৬.৩. 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["রানটাইম ওভাররাইট করে এবং ভুল"]

চিত্র ১৬: 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 ও লগিং কোথায় রাখবেন?“-এ আছে।

৭. অনুশীলনে রূপান্তর ও অনুসন্ধান সরঞ্জাম — কপি-পেস্ট দ্রুত তথ্যসূত্র

৭.১. 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["প্রসঙ্গে বিশ্বাসযোগ্য প্রার্থী বেছে নিন"]

চিত্র ১৭: err.exe হেডার-পেরোনো খোঁজ, তাই কয়েক প্রার্থী আসতে পারে, আর বিশ্বাসযোগ্য প্রসঙ্গে বেছে নেওয়া হয়।

৭.২. 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["হেক্স ও দশমিক দুটোই গ্রহণ"]

চিত্র ১৮: মানক কমান্ডে কীভাবে বেছে নেবেন। দশমিক Win32 ত্রুটি net helpmsg; হেক্স থাকলে certutil -error।

৭.৩. 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

৭.৪. 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 দিয়ে অর্থ নিশ্চিত করুন"]

চিত্র ১৯: ডাম্প বিশ্লেষণে !analyze -v যে ব্যতিক্রম কোড দেখিয়েছে তা !error ও পতাকা 1 দিয়ে খুঁজুন।

৮. অনুসন্ধান পদ্ধতি — স্তর বিচার থেকে প্রসঙ্গের সঙ্গে মিল

এখন পর্যন্ত জ্ঞানকে সত্যি ত্রুটি কোড অনুসন্ধানের পদ্ধতিতে জোড় করুন।

1. নোটেশন স্বাভাবিক করুন। ঋণাত্মক দশমিক হলে ৮-অঙ্কের হেক্সে রূপান্তর করুন। ৮ অঙ্কের চেয়ে ছোট হেক্স শূন্য-প্যাড করে পড়ুন।
2. বিচার করুন কোড কোন স্তরের। নিচের বিচার সারণির মতো অগ্রণী কয়েক অঙ্ক প্রায় স্থির করে।
3. ভেঙে অপরিহার্য কোড বের করুন। যান্ত্রিক কাজ: 0x8007xxxx হলে নিচের ১৬ বিট, 0xDxxxxxxx হলে N বিট খুলুন।
4. সরঞ্জাম দিয়ে নাম ও সংজ্ঞা খুঁজুন। err.exe, certutil বা !error দিয়ে প্রতীক নাম ও বার্তা নিশ্চিত করুন।
5. প্রসঙ্গের সঙ্গে মিল করুন। অ্যাপ লগ, ইভেন্ট লগ ও Procmon থেকে শনাক্ত করুন কোন অ্যাপ, কোন অপারেশন, কোন API কীসের বিরুদ্ধে ব্যর্থ হয়েছে। কোড “ব্যর্থতার ধরন”; প্রসঙ্গ “কারণের জায়গা”।

flowchart TB
    accTitle: ত্রুটি কোড অনুসন্ধানের পদ্ধতি
    accDescr: নোটেশন হেক্সে সারিবদ্ধ করা, অগ্রণী অঙ্ক থেকে স্তর বিচার, ভেঙে অপরিহার্য কোড বের করা, সরঞ্জাম দিয়ে নাম ও সংজ্ঞা খোঁজা, তারপর প্রসঙ্গের সঙ্গে মিলের অনুসন্ধান ধরন
    fix["হেক্সে স্বাভাবিক করুন"] --> judge{"অগ্রণী অঙ্ক?"}
    judge -->|দশমিক| d1["Win32 ত্রুটি হিসেবে পড়ুন"]
    judge -->|0x8007| d2["নিচের ১৬ বিট → দশমিক"]
    judge -->|0xC| d3["NTSTATUS হিসেবে পড়ুন"]
    judge -->|0xD| d4["N বিট খুলে পড়ুন"]
    d1 --> tool["নাম/সংজ্ঞা খুঁজুন"]
    d2 --> tool
    d3 --> tool
    d4 --> tool
    tool --> ctx["প্রসঙ্গ মিল（Procmon）"]

চিত্র ২০: অনুসন্ধান ধরন। নোটেশন স্বাভাবিক করুন, স্তর বিচার করে ভাঙুন, নাম খুঁজুন, তারপর প্রসঙ্গের সঙ্গে মিল করুন।

ধাপ ৫-এর “প্রসঙ্গের সঙ্গে মিল”-এ বিশেষ কার্যকর Process Monitor-এর Result কলাম। অ্যাপ কেবল “0x80070002” দেখালেও Procmon এক সারিতে বলে “কোন প্রক্রিয়া, কোন পথের বিরুদ্ধে, NAME NOT FOUND ফিরেছে”। ইভেন্ট-লগ দিকে খোঁজার জন্য “Windows Event Log ও ETW-এর ভূমিকা“-ও দেখুন।

৯. সাধারণ ভুল পাঠ — ধরন যা অনুসন্ধান দীর্ঘ পথে পাঠায়

শেষে বাস্তব পরামর্শে দেখা ভুল-পাঠ ধরন।

ভুল পাঠ ১: ভাবা 0x80004005 “নির্দিষ্ট কারণ নির্দেশকারী কোড”

E_FAIL “Unspecified failure”, আর একই মান Windows Update, নেটওয়ার্কিং ও ডেটাবেসে আসে। এই কোডে খুঁজলে ওঠা প্রতিটি প্রতিকার চেষ্টা প্রায় নিশ্চিত দীর্ঘ পথ। কোড থেকে নয়, “কোন অ্যাপ, কোন অপারেশন, একই সময়ে অন্য লগ” থেকে সঙ্কুচিত করুন।⁶

ভুল পাঠ ২: না খেয়াল করা যে ঋণাত্মক দশমিক HRESULT

লগ যা বলে “Error -2147467259 occurred” যেমন আছে খোঁজা, বা “মাইনাস ত্রুটি?”-এ বিভ্রান্ত হওয়া। ঋণাত্মক দেখলে হেক্সে রূপান্তর করুন। একা এটি বলে এটি 0x80004005 (E_FAIL), এবং ভুল পাঠ ১-এর জ্ঞানের সঙ্গে জোড়ে।

ভুল পাঠ ৩: 0x8007xxxx-এর পুরো ৮ অঙ্ক খোঁজা এবং নিচের Win32 ত্রুটি না দেখা

0x80070005-এর সার “5 = অ্যাক্সেস প্রত্যাখ্যাত”। নিচের ১৬ বিট বের করার পর “এই অপারেশনের প্রসঙ্গে Win32 ত্রুটি 5 কী বোঝায়” ভাবা পুরো ৮ অঙ্ক খোঁজার চেয়ে দ্রুত অন্তরে পৌঁছায়।

ভুল পাঠ ৪: ধরা “একই কোড = একই কারণ”

একবার “ত্রুটি 5 অ্যান্টিভাইরাস থেকে হয়েছিল” থাকলে পরের ত্রুটি 5-এ একই প্রতিকারে লাফানোর প্রবণতা হয়। একই কোডেও ব্যর্থ API ও লক্ষ্য রিসোর্স আলাদা হলে কারণ আলাদা জিনিস। কোডের অর্থ নিশ্চিত করা ও Procmon বা অনুরূপ দিয়ে লক্ষ্য শনাক্ত করা প্রতিবার এক সেট।

ভুল পাঠ ৫: 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

চিত্র ২১: “5” সংযোগের কারণে তাদের একই ভাবার না। ত্রুটি 5 অনুমতি সমস্যার দিকে যায়; 0xC0000005 প্রোগ্রাম বাগের দিকে।

১০. সারসংক্ষেপ

• Windows ত্রুটি কোড Win32 ত্রুটি কোড, HRESULT ও NTSTATUS-এর তিন-স্তর কাঠামো। আগে বিচার করুন কোন স্তর, কোন পক্ষ কোড ফিরিয়েছে।
• নোটেশনের দোদুল্যমানতা (দশমিক / হেক্স / ঋণাত্মক) যান্ত্রিকভাবে সারিবদ্ধ হয়। ঋণাত্মককে ৮-অঙ্কের হেক্সে রূপান্তর করে তারপর পড়ুন।
• HRESULT S/R/C/N/X বিট + Facility (১১ বিট) + Code (১৬ বিট)-এর কাঠামো, আর 0x8007xxxx সবচেয়ে গুরুত্বপূর্ণ ধরন, মোড়া Win32 ত্রুটি। নিচের ১৬ বিট দশমিক করে অপরিহার্য কোড বের করুন।
• 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 হলে নিচের ৪ অঙ্ক, 0xC হলে NTSTATUS, ঋণাত্মক হলে হেক্সে রূপান্তর — এই ১০-সেকেন্ড ভাঙন পরের অনুসন্ধান সময় অনেকটা স্থির করে।

সম্পর্কিত নিবন্ধ

• WinDbg + SOS দিয়ে ক্র্যাশ ডাম্প পড়া — সংগ্রহের পর বিশ্লেষণের ব্যবহারিক গাইড
• Windows ক্র্যাশ ডাম্প সংগ্রহের ভূমিকা - WER/ProcDump/WinDbg
• এক্সেপশন হ্যান্ডলিংয়ে catch ও লগিং কোথায় রাখবেন?
• Process Monitor (ProcMon)-এর ব্যবহারিক নির্দেশিকা — ১০ মিনিটে “সেটিং প্রয়োগ হয়নি” ও “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-এর মতো ঋণাত্মক ত্রুটি কোড কী?

এটি ৩২-বিট 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 সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।