{"componentChunkName":"component---src-templates-post-template-js","path":"/magical-windbg-vol1-04-en","result":{"data":{"markdownRemark":{"id":"ec69b170-ca84-59e4-b262-a036cd1436c9","html":"
\n

This page has been machine-translated from the original page.

\n
\n

In this chapter, we will analyze a simple application crash dump with WinDbg.

\n\n

Table of contents

\n\n

Creating an application crash dump for analysis

\n

First, create an application crash dump for analysis.

\n

Launch D4C.exe, which you downloaded in Chapter 1, select menu item 1, and press Enter. D4C.exe will crash and a user-mode crash dump will be generated.

\n

\n \n \n \n \n \n \n \n \n

\n

In the Command window immediately after WinDbg starts, information labeled Path validation summary is displayed.

\n

Path validation summary contains useful information for analysis, so let’s look at a few items.

\n

First, in the first part below, you can see the current .sympath information and the OS version.

\n
Response                         Time (ms)     Location\nDeferred                                       srv*https://msdl.microsoft.com/download/symbols\nSymbol search path is: srv*https://msdl.microsoft.com/download/symbols\nExecutable search path is: \nWindows 10 Version 19045 MP (8 procs) Free x64\nProduct: WinNt, suite: SingleUserTS\nEdition build lab: 19041.1.amd64fre.vb_release.191206-1406
\n

Next, in the lines below, Debug session time shows when the process crash occurred, while System Uptime and Process Uptime show the system uptime and process uptime before the application crashed, respectively.

\n
Debug session time: Wed Sep 13 20:36:00.000 2023 (UTC + 9:00)\nSystem Uptime: 1 days 20:35:58.000\nProcess Uptime: 0 days 0:00:56.000
\n

The following lines also show the exception code that directly caused the application crash.

\n
This dump file has an exception of interest stored in it.\nThe stored exception information can be accessed via .ecxr.\n(2f10.598): Access violation - code c0000005 (first/second chance not available)\nFor analysis of this file, run !analyze -v\nntdll!NtWaitForMultipleObjects+0x14:\n00007fff`35fcd9a4 c3              ret
\n

From the information Access violation - code c0000005 (first/second chance not available) shown here, we can easily determine that the direct cause of the application crash was an access violation.

\n
\n

Access violation C0000005:

\n

https://learn.microsoft.com/ja-jp/shows/inside/c0000005

\n
\n

From here, we will identify the specific processing where the problem occurred.

\n

Analyzing the crash dump with the !analyze extension

\n

One of the commands I use most often when analyzing crash dumps in WinDbg is !analyze -v.

\n

This command uses the !analyze extension to display detailed information about the exception captured in the crash dump.

\n
\n

!analyze (WinDbg):

\n

https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-analyze

\n
\n

Commands beginning with an exclamation mark (!) usually mean commands that call debugger extensions.

\n

Debugger extensions can be used by loading DLLs prepared as modules separate from the debugger itself into WinDbg.

\n

WinDbg has several extensions loaded by default, and users can also create their own extensions and load them into the debugger.

\n

You can retrieve a list of the extensions currently loaded in WinDbg with the .chain command.

\n

When I actually run .chain in my environment, I get the following result.

\n
Extension DLL chain:\n\next: image 10.0.22621.1778, API 1.0.0, \n  [path: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\winext\\ext.dll]\n\nELFBinComposition: image 10.0.22621.1778, API 0.0.0, \n  [path: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\winext\\ELFBinComposition.dll]\n\ndbghelp: image 10.0.22621.1778, API 10.0.6, \n  [path: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\dbghelp.dll]\n\nexts: image 10.0.22621.1778, API 1.0.0, \n  [path: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\WINXP\\exts.dll]\n\nuext: image 10.0.22621.1778, API 1.0.0, \n  [path: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\winext\\uext.dll]\n\nntsdexts: image 10.0.22621.1778, API 1.0.0, \n  [path: C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\WINXP\\ntsdexts.dll]
\n

However, if you look at this list, you can see that there is no extension named analyze.

\n

This is because, strictly speaking, the !analyze extension is one of the features included in the ext extension that WinDbg loads by default.

\n

In WinDbg, you can call an extension module by executing either !<alias of extension module> or !<extension name>.<module name of extension module>.

\n

In other words, executing !ext.analyze gives the same output as executing !analyze.

\n

As an aside, you can list the modules included in the ext extension with !help or !ext.help.

\n

As shown below, you can confirm that, besides analyze, it also includes frequently used entries such as address.

\n
0:000> !ext.help\nanalyze [-v][level]        - Analyzes current exception or bugcheck (levels are 0..9)\nowner [symbol!module]      - Displays the Owner for current exception or bugcheck\ncomment                    - Displays the Dump's Comment(s)\n\nerror [errorcode]          - Displays Win32 or NTSTATUS error string\ngle [-all]                 - Displays the Last Error & Last Status of the current thread\n\naddress [address]          - Displays the address space layout\n        [-UsageType]       - Displays the address space regions of the given type\n\ncpuid [processor]          - Displays the CPU information for a specific or all CPUs\n\nexchain                    - Displays exception chain for the current thread\n\nfor_each_process <cmd>     - Executes command for each process\nfor_each_thread <cmd>      - Executes command for each thread\nfor_each_frame <cmd>       - Executes command for each frame in the current thread\nfor_each_local <cmd> $$<n> - Executes command for each local variable in the current frame,\n                             substituting the fixed-name alias $u<n> for each occurrence of $$<n>\n\nimggp <imagebase>          - Displays GP directory entry for 64-bit image\nimgreloc <imagebase>       - Relocates modules for an image\n\nstr <address>              - Displays ANSI_STRING or OEM_STRING\nustr <address>             - Displays UNICODE_STRING\n\nlist [-? | parameters]     - Displays lists\n\ncppexr <exraddress>        - Displays a C++ EXCEPTION_RECORD\nobja <address>             - Displays OBJECT_ATTRIBUTES[32|64]\nrtlavl <address>           - Displays RTL_AVL_TABLE\nstd_map <address>          - Displays a std::map<>
\n

Now that we have confirmed the extensions, let’s actually run the !analyze -v command and analyze the dump file.

\n

The output of !analyze -v is fairly long, so we will review it in parts.

\n

The first section displays environment information and information about the dump file.

\n
KEY_VALUES_STRING: 1\n\n  Key  : AV.Dereference\n  Value: NullPtr\n\n  Key  : AV.Fault\n  Value: Write\n\n  Key  : Analysis.CPU.mSec\n  Value: 561\n\n  Key  : Analysis.DebugAnalysisManager\n  Value: Create\n\n  Key  : Analysis.Elapsed.mSec\n  Value: 577\n\n  Key  : Analysis.Init.CPU.mSec\n  Value: 12827\n\n  Key  : Analysis.Init.Elapsed.mSec\n  Value: 85744066\n\n  Key  : Analysis.Memory.CommitPeak.Mb\n  Value: 84\n\n  Key  : Timeline.OS.Boot.DeltaSec\n  Value: 44\n\n  Key  : Timeline.Process.Start.DeltaSec\n  Value: 7\n\n  Key  : WER.OS.Branch\n  Value: vb_release\n\n  Key  : WER.OS.Timestamp\n  Value: 2019-12-06T14:06:00Z\n\n  Key  : WER.OS.Version\n  Value: 10.0.19041.1\n\nFILE_IN_CAB:  D4C.exe.9608.dmp\n\nNTGLOBALFLAG:  0\n\nPROCESS_BAM_CURRENT_THROTTLED: 0\n\nPROCESS_BAM_PREVIOUS_THROTTLED: 0\n\nAPPLICATION_VERIFIER_FLAGS:  0
\n

The next section shows the output of the .ecxr command, which displays the Register Context3 associated with the exception that occurred.

\n

This information does not need to be consulted for dumps collected manually to investigate issues such as memory leaks, but it is extremely important when investigating a crash dump like this one.

\n
CONTEXT:  (.ecxr)\nrax=0000000000000017 rbx=0000021b6cad2460 rcx=00007ff6abb95300\nrdx=000000bfc50ff948 rsi=00007ff6abb953f8 rdi=0000021b6cad7490\nrip=00007ff6abb91412 rsp=000000bfc50ff910 rbp=0000000000000000\n r8=000000bfc50fdd28  r9=0000021b6cad9477 r10=0000000000000000\nr11=000000bfc50ff810 r12=0000000000000000 r13=0000000000000000\nr14=0000000000000000 r15=0000000000000000\niopl=0         nv up ei pl nz na po nc\ncs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206\nD4C+0x1412:\n00007ff6`abb91412 41c706e8030000  mov     dword ptr [r14],3E8h ds:00000000`00000000=????????\nResetting default scope
\n

Looking at the .ecxr output above, we can see that the application crashed at the instruction at offset 0x1412.

\n

We can also see that the instruction that caused the crash was mov dword ptr [r14],3E8h.

\n
D4C+0x1412:\n00007ff6`abb91412 41c706e8030000  mov     dword ptr [r14],3E8h ds:00000000`00000000=????????
\n

This instruction stores the value 0x3E8 (1000) into a DWORD (32-bit) region at the pointer address held in the r14 register.

\n

However, as shown by r14=0000000000000000, the r14 register does not contain a valid pointer address.

\n

In other words, we can conclude that the application crashed with an access violation because it tried to store a value to a memory address that does not exist.

\n

At this point, we have already identified the detailed cause of the application crash, but this time we will continue analyzing the dump file as-is.

\n

The next section shows output equivalent to running the .exr -1 command.

\n

This command outputs information related to an exception that occurred in the system.

\n

If you specify -1 as the argument, it displays information for the most recent exception.4

\n
EXCEPTION_RECORD:  (.exr -1)\nExceptionAddress: 00007ff7f7481412 (D4C+0x0000000000001412)\n   ExceptionCode: c0000005 (Access violation)\n  ExceptionFlags: 00000000\nNumberParameters: 2\n   Parameter[0]: 0000000000000001\n   Parameter[1]: 0000000000000000\nAttempt to write to address 0000000000000000
\n

From the ExceptionAddress in the result above, we can see that the exception was c0000005 (Access violation) and that it occurred at offset 0x1412 in D4C.exe.

\n

Also, when the exception is c0000005 (Access violation), the two parameters displayed by .exr -1 have the following meanings.5

\n\n

In other words, from the result above, we can see that the access violation was caused by a write access to address 0x0.

\n

Let’s continue to the next section.

\n
PROCESS_NAME:  D4C.exe\n\nWRITE_ADDRESS:  0000000000000000 \n\nERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p ???? 0x%p ???????????????? %s ???????????????\n\nEXCEPTION_CODE_STR:  c0000005\n\nEXCEPTION_PARAMETER1:  0000000000000001\n\nEXCEPTION_PARAMETER2:  0000000000000000\n\nSTACK_TEXT:  \n00000065`1e9cf580 00007ff7`f7481a40 : {省略} : D4C+0x1412\n00000065`1e9cf840 00007fff`35e17344 : {省略} : D4C+0x1a40\n00000065`1e9cf880 00007fff`35f826b1 : {省略} : kernel32!BaseThreadInitThunk+0x14\n00000065`1e9cf8b0 00000000`00000000 : {省略} : ntdll!RtlUserThreadStart+0x21\n\nSTACK_COMMAND:  ~0s; .ecxr ; kb
\n

The information in the first half, like the output of .exr -1, shows the type of the most recent exception and the parameters at the time the exception occurred.

\n

The STACK_TEXT in the second half shows the stack backtrace up to the exception.

\n

This stack backtrace information is equivalent to the information you can obtain with the ~0s; .ecxr ; kb command.

\n

Breaking that command down, ~0s and .ecxr obtain the Register Context for the first thread, and then kb outputs a stack backtrace with arguments.

\n

In other words, for this crash dump, this output is equivalent to extracting from the stack backtrace shown by kb only the information up to just before the exception dispatcher (KiUserExceptionDispatch)6 is called.

\n

If you actually run the kb command in WinDbg, you can obtain the following information.

\n
0:000> kb\n# RetAddr               : Args to Child  : Call Site\n00 00007fff`33701be0    : {省略} : ntdll!NtWaitForMultipleObjects+0x14\n01 00007fff`33701ade    : {省略} : KERNELBASE!WaitForMultipleObjectsEx+0xf0\n02 00007fff`35e6f93a    : {省略} : KERNELBASE!WaitForMultipleObjects+0xe\n03 00007fff`35e6f376    : {省略} : kernel32!WerpReportFaultInternal+0x58a\n04 00007fff`337de099    : {省略} : kernel32!WerpReportFault+0xbe\n05 00007fff`35fd5330    : {省略} : KERNELBASE!UnhandledExceptionFilter+0x3d9\n06 00007fff`35fbc876    : {省略} : ntdll!RtlUserThreadStart$filt$0+0xa2\n07 00007fff`35fd221f    : {省略} : ntdll!_C_specific_handler+0x96\n08 00007fff`35f814b4    : {省略} : ntdll!RtlpExecuteHandlerForException+0xf\n09 00007fff`35fd0d2e    : {省略} : ntdll!RtlDispatchException+0x244\n0a 00007ff7`f7481412    : {省略} : ntdll!KiUserExceptionDispatcher+0x2e\n0b 00007ff7`f7481a40    : {省略} : D4C+0x1412\n0c 00007fff`35e17344    : {省略} : D4C+0x1a40\n0d 00007fff`35f826b1    : {省略} : kernel32!BaseThreadInitThunk+0x14\n0e 00000000`00000000    : {省略} : ntdll!RtlUserThreadStart+0x21
\n

If you read the stack backtrace above in order, you can follow the entire flow: execution starts at the RtlUserThreadStart function, which starts a user-mode thread in Windows, then offset 0x1412 is pushed onto the stack, and then the exception dispatcher and the WerpReportFault function that connects to the WER service are called, leading up to creation of the crash dump.7

\n

Next, let’s look at the last section of !analyze -v.

\n
SYMBOL_NAME:  D4C+1412\n\nMODULE_NAME: D4C\n\nIMAGE_NAME:  D4C.exe\n\nFAILURE_BUCKET_ID:  NULL_POINTER_WRITE_c0000005_D4C.exe!Unknown\n\nOS_VERSION:  10.0.19041.1\n\nBUILDLAB_STR:  vb_release\n\nOSPLATFORM_TYPE:  x64\n\nOSNAME:  Windows 10\n\nFAILURE_ID_HASH:  {3a8ea6b5-fbef-8da5-2baa-142fae4fc055}\n\nFollowup:     MachineOwner
\n

FAILURE_BUCKET_ID is one of the most important pieces of information when analyzing a dump file.

\n

When you load a crash dump file into the debugger, a signature called a BUCKET ID is generated to identify the type of crash.8 9

\n

In this dump file, FAILURE_BUCKET_ID is displayed as NULL_POINTER_WRITE_c0000005_D4C.exe!Unknown.

\n

This is another reason we can determine that the cause of the application crash was an access violation caused by writing to a NULL pointer.

\n

With that, we have now reviewed all output from the !analyze -v command.

\n

For a simple crash dump like this one, just reading the output of !analyze -v makes it easy to identify the cause of the application crash.

\n

Reading the instructions around the crash

\n

Although we have already identified the cause of the application crash from the output of !analyze -v, we will continue analyzing the dump file to obtain more detailed information.

\n

From the output of !analyze -v, we confirmed that the instruction where the application crash occurred was mov dword ptr [r14],3E8h at offset 0x1412.

\n

In this section, we will trace the processing immediately before the crash occurred.

\n

First, let’s call threads, included in the ext extension, to list the application’s threads.

\n

From the output below, we can see that this application has only one thread—the main thread—running.

\n
0:000> !threads\nIndexTIDTEBStackBaseStackLimit DeAlloc StackSize ThreadProc\n00000000000000000 0x000000651eac0000 0x000000651e9d0000 0x000000651e9cc0000x000000651e8d0000 0x00000000000040000x0\nTotal VM consumed by thread stacks 0x00004000
\n

From the result above, we can see that using the main thread as the analysis target is fine, so we display a stack backtrace with the Register Context of the exception specified by running ~0s; .ecxr ; k.

\n

Note that the Args to Child information obtained by the kb command is not very useful for x64 binaries because of the calling convention, so in the example below I display information using only the k command.

\n
0:000> ~0s; .ecxr ; k\n{省略}\nD4C+0x1412:\n00007ff7`f7481412 41c706e8030000  mov     dword ptr [r14],3E8h ds:00000000`00000000=????????\n  *** Stack trace for last set context - .thread/.cxr resets it\n # Child-SP          RetAddr               Call Site\n00 00000065`1e9cf580 00007ff7`f7481a40     D4C+0x1412\n01 00000065`1e9cf840 00007fff`35e17344     D4C+0x1a40\n02 00000065`1e9cf880 00007fff`35f826b1     kernel32!BaseThreadInitThunk+0x14\n03 00000065`1e9cf8b0 00000000`00000000     ntdll!RtlUserThreadStart+0x21
\n

In an application crash dump like this one, the topmost Call Site is usually the offset of the instruction that raised the exception.

\n

In the output for this dump file, the call immediately before the exception dispatcher is D4C+0x1412, so we can see that the crashing instruction is at offset 0x1412 in D4C.exe.

\n

We already confirmed from the output of .ecxr that this application crash was caused by an access violation at the instruction at offset 0x1412, but let’s also inspect the instructions around that offset just to be sure.

\n

You can inspect the instructions around a specific offset by using the Disassembly window opened with [Alt + 7].

\n

When you use the Disassembly window, enter !<module name>+offset in the Offset field at the top of the window.

\n

In other words, if you want to inspect the instruction at offset 0x1412 in D4C.exe, enter !D4C+0x1412 in the Offset field at the top of the window.

\n

\n \n \n \n \n \n \n \n \n

\n

For the analysis options that appear next, the default settings are fine, so click [Analyze] to start analyzing the program.

\n

\n \n \n \n \n \n \n \n \n

\n

After automatic analysis runs for a few dozen seconds to a few minutes, you will be able to inspect the decompiled result of the application in Ghidra.

\n

By default, the Ghidra analysis window is laid out as shown below.

\n

\n \n \n \n \n \n \n \n \n

\n

First, the Decompiler window on the right shows the result of decompiling application functions into pseudocode close to C.

\n

The Listing window in the center shows the disassembly of the application.

\n

The code displayed in the Listing window is basically the same disassembly you can inspect in WinDbg’s Disassembly window, but Ghidra automatically analyzes information such as the IAT and displays the results, so it often shows code that is easier to read than the disassembly you inspect in WinDbg.

\n

On the left side of the window, you can see windows for inspecting the program’s sections, symbol tree, and data types.

\n

To analyze the program, first let’s identify the main function, which is the first function executed by the program.

\n

When Windows executes a PE file (exe)13, the value of AddressOfEntryPoint embedded in the PE file header is the starting point of execution.

\n

Windows begins executing the program from the address specified by AddressOfEntryPoint, performs several initialization steps, and then runs the main function.

\n

You can identify the entry point specified by AddressOfEntryPoint by expanding the [Functions] tree in the Symbol Tree window on the left side of Ghidra’s analysis window and finding the entry function.

\n

\n \n ) {\n FUN_140001fa8(7);\n }\n else {\n {{ 省略 }}\n\n puVar7 = (undefined *)_get_initial_narrow_environment();\n puVar8 = (undefined8 *)__p___argv();\n uVar1 = *puVar8;\n puVar9 = (uint *)__p___argc();\n uVar10 = (ulonglong)*puVar9;\n unaff_EBX = FUN_140001070(uVar10,uVar1,puVar7,in_R9);\n\n {{ 省略 }}\n }\n }\n FUN_140001fa8(7);\n LAB_140001aa0:\n\n exit(unaff_EBX);\n}\n

The details of this code are outside the scope of this book, so I will not explain them in detail, but the function FUN_140001934() corresponds to the initialization process that runs when the application starts.14

\n

In particular, pay attention to the line unaff_EBX = FUN_140001070(uVar10,uVar1,puVar7,in_R9);, which takes _get_initial_narrow_environment, __p___argv, and __p___argc—symbol names identified under Ghidra 2.3’s default settings—as arguments.

\n

I could not find information about this in the official documentation, but if you search the web, including sites such as Stack Overflow, using those three values as clues, you can determine that they most likely correspond to the following processing that the Windows CRT uses to run the main function.

\n
static int __cdecl invoke_main()\n{\n    return main(__argc, __argv, _get_initial_narrow_environment());\n}
\n

In other words, we can conclude that the function FUN_140001070() called by the line unaff_EBX = FUN_140001070(uVar10,uVar1,puVar7,in_R9); inside FUN_140001934() corresponds to the main function of this program.

\n

If you actually jump to FUN_140001070() in Ghidra and check the Decompiler window, you can see code that includes strings such as Welcome. displayed on the console when the program starts, confirming that FUN_140001070() is the main function of D4C.exe.

\n

\n \n \n \n \n \n \n \n \n

\n

In Ghidra, you can rename a function to any name you want by right-clicking the function name and selecting [Rename Function].

\n

To make the analysis smoother, rename FUN_140001070() to main.

\n

You can also infer that FUN_1400014e0(\"Welcome.\\n\",param_2,param_3,param_4); and FUN_140001010(L\"\\n0. Setting: Full memory dump(You need reboot OS.)\\n\",param_2,param_3,param_4); are functions that output an ASCII string and a wide string to the console, respectively.

\n

Therefore, rename FUN_1400014e0() to printf and FUN_140001010() to wprintf.

\n

This already makes the decompiled output much easier to read.

\n

Finally, we will use Ghidra to determine the more detailed cause of the application crash.

\n

As we have already confirmed, this application crash occurred because, after selecting 1 in the first menu, the program attempted to write to an invalid address.

\n

So, let’s investigate the code at the point where the application crash occurred from the decompiled output of the main function.

\n

Looking at the information in the Decompiler window, we can see that the application crash occurred at the following code.

\n
else if (local_38 == 1) {\n  wprintf(L\"User Mode Trouble: Simple process crash.\\n\",pwVar9,NewState,param_4);\n  printf(\"OK, Start application.\\n\",pwVar9,NewState,param_4);\n\n  local_280 = 0;\n  pwVar9 = (wchar_t *)&local_280;\n  uRam0000000000000000 = 1000;\n\n  printf(&DAT_140005300,pwVar9,NewState,param_4);\n}
\n

If you actually select the write access uRam0000000000000000 = 1000;, the Listing window shows that the corresponding code is at offset 0x1412.

\n

\n \n \n \n \n \n \n \n \n

\n

This offset 0x1412 matches the offset we identified when analyzing the dump file in WinDbg.

\n

Furthermore, if you inspect Ghidra’s decompiled output, you can see that the destination address for the write refers to a hard-coded value of 0.

\n

\n \n \n \n \n \n \n \n \n

\n

With that, we have determined that the cause of the application crash investigated here was a memory access violation caused by the developer hard-coding 0 as the destination address for the value 1000.

\n

Summary of Chapter 4

\n

That concludes the analysis of a simple application crash dump.

\n

In real-world troubleshooting, you will almost never investigate a crash event that is this simple, but the basic analysis steps do not change very much.

\n

As long as the application crash dump has been generated correctly, you can investigate the type of exception that directly caused the crash and the offset of the instruction where the crash occurred from the dump file, regardless of the underlying root cause.

\n

Through this chapter, I hope you felt that dump file analysis, which may look complex at first glance, can actually make it possible to identify the cause quite easily if you just keep track of a few key checkpoints.

\n\n\n
\n
\n
    \n
  1. \n

    Windows Internals, 7th Edition, Part 2, p.564 (by Andrea Allievi, Mark E. Russinovich, Alex Ionescu, David A. Solomon / translated by 山内 和朗 / 日系 BP 社 / 2022)

    \n↩\n
    2. \n
  2. \n

    Windows Internals, 7th Edition, Part 1, p.534 (by Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich, David A. Solomon / translated by 山内 和朗 / 日系 BP 社 / 2018)

    \n↩\n
    3. \n
  3. \n

    Register Context https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/changing-contexts#register-context

    \n↩\n
    4. \n
  4. \n

    .exr Display Exception Record https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-exr—display-exception-record-

    \n↩\n
    5. \n
  5. \n

    Access violation C0000005 https://learn.microsoft.com/ja-jp/shows/inside/c0000005

    \n↩\n
    6. \n
  6. \n

    Windows Internals, 7th Edition, Part 2, p.91 (by Andrea Allievi, Mark E. Russinovich, Alex Ionescu, David A. Solomon / translated by 山内和朗 / 日系 BP 社 / 2022)

    \n↩\n
    7. \n
  7. \n

    Windows Internals, 7th Edition, Part 2, p.565 (by Andrea Allievi, Mark E. Russinovich, Alex Ionescu, David A. Solomon / translated by 山内和朗 / 日系 BP 社 / 2022)

    \n↩\n
    8. \n
  8. \n

    インサイド Windows 第 6 版 下, p.624 (by Mark E. Russinovich, David A. Solomon, Alex Ionescu / translated by 株式会社クイープ / 日系 BP 社 / 2013)

    \n↩\n
    9. \n
  9. \n

    Using the !analyze extension https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/using-the—analyze-extension

    \n↩\n
    10. \n
  10. \n

    u, ub, uu Unassemble https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/u—unassemble-

    \n↩\n
    11. \n
  11. \n

    ILSpy https://github.com/icsharpcode/ILSpy

    \n↩\n
    12. \n
  12. \n

    jadx https://github.com/skylot/jadx

    \n↩\n
    13. \n
  13. \n

    PE format https://learn.microsoft.com/ja-jp/windows/win32/debug/pe-format

    \n↩\n
    14. \n
  14. \n

    CRT initialization https://learn.microsoft.com/ja-jp/cpp/c-runtime-library/crt-initialization?view=msvc-170

    \n↩\n
    15. \n
\n
","fields":{"slug":"/magical-windbg-vol1-04-en","tagSlugs":["/tag/magical-win-dbg/","/tag/windows/","/tag/win-dbg/","/tag/english/"]},"frontmatter":{"date":"2023-11-15","description":"This is the web edition of Magical WinDbg - Enjoying Windows Dump Analysis and Troubleshooting by Feel - VOL.1, distributed at Tech Book Fest 15.","tags":["Magical WinDbg","Windows","WinDbg","English"],"title":"Magical WinDbg VOL.1 [Chapter 4: Analyzing Application Crash Dumps]","socialImage":{"publicURL":"/static/2dbf3e09d59db889dc9dc41adcc8e827/magical-windbg-vol1.png"}}}},"pageContext":{"slug":"/magical-windbg-vol1-04-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}