{"componentChunkName":"component---src-templates-post-template-js","path":"/magical-windbg-vol1-06-en","result":{"data":{"markdownRemark":{"id":"f7519ccd-31fc-5be6-a2ff-cc881cd8a94a","html":"
\n

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

\n
\n

In Chapters 4 and 5, we investigated the causes of process and system crashes using application crash dumps and full memory dumps.

\n

As we have seen in the chapters so far, dump files normally contain information about the exception that caused the crash when the dump was created.

\n

For that reason, by looking at the exception information recorded at dump creation with commands such as !analyze -v, it is relatively easy to identify the direct cause of a crash (the exception).

\n

However, when you investigate the cause of a problem other than a crash from a dump file, the exception information collected when the dump was created is no longer helpful, so the analysis becomes a little more difficult.

\n

In Chapters 6 and 7, we will use a user-mode application memory leak as an example of investigating a non-crash problem from a dump file.

\n

In this chapter, we will analyze a process dump from an application that is causing a memory leak.

\n\n

Table of contents

\n\n

Reproducing the memory leak issue

\n

First, let’s trigger the memory leak so that we can obtain the process dump to analyze.

\n

As in the previous chapters, we will use D4C.exe to reproduce the problem.

\n

Start D4C.exe, then enter 2 at the first menu to begin reproducing the memory leak issue.

\n

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

\n

In Process Explorer, you can see the size in the [Private Bytes] column for the D4C.exe row steadily increasing over time.

\n

On the [Performance] tab in Task Manager, you can also confirm that the amount of committed virtual memory is increasing.

\n

You can investigate a process’s memory consumption with many tools besides Process Explorer and Task Manager, such as Resource Monitor, VMMap, and Process Hacker.

\n

So when you suspect a memory leak, it is a good idea to use whichever tool fits your environment and preferences.

\n

Obtaining a process dump

\n

Now that we have reproduced the application’s memory leak issue with D4C.exe, the next step is to obtain a process dump for analysis.

\n

For problems such as memory leaks that do not involve an application crash, an application crash dump is not generated automatically as in Chapter 4.

\n

Therefore, you need to use a tool of your choice to capture a process dump file while the problem is occurring.

\n

There are many tools that can capture process dump files, but in this book we will use Process Explorer and Procdump, both included in Sysinternals.

\n

First, let’s obtain a dump file with Process Explorer.

\n

Just as when we checked the process’s memory usage earlier, launch Process Explorer with administrator privileges.

\n

Next, right-click the D4C.exe row in the process list and click [Create Dump] > [Create Full Dump...].

\n

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

\n

A File Explorer window will open, so save the dump file to any folder you like.

\n

If the full process dump is captured successfully, a dump file will be created in the specified folder with nearly the same size as the process memory size you saw in Process Explorer’s [Private Bytes] column.

\n

When you capture a dump with Process Explorer, the D4C.exe application is not terminated, so press [Ctrl+C] to stop the application manually.

\n

Now we have obtained a process dump for analysis, but you can also capture an equivalent dump file with Procdump.

\n

Using Procdump is very simple.

\n

To capture a process dump of D4C.exe, run the following command in an elevated Command Prompt.

\n
procdump.exe -ma -w D4C.exe
\n

When you run the command above, a process dump is created in the current folder.

\n

The -ma option specifies that the dump type to capture is a full dump.

\n

The -w option specifies the name of the process for which the dump file should be captured.

\n

Although we will not use it in this book, when you capture an application process dump with Procdump, you can define dump collection conditions in detail, such as an application hang or thresholds for CPU usage and memory size.

\n

So if the timing or reproduction conditions of the problem are unclear, you can use Procdump to capture a process dump under whatever conditions you need and smoothly obtain the dump file required for the investigation.

\n

For a list of Procdump options, refer to the published documentation.

\n
\n

ProcDump:

\n

https://learn.microsoft.com/ja-jp/sysinternals/downloads/procdump

\n
\n

Examining the exception code in the process dump

\n

Now that we have the process dump for analysis, let’s start investigating the memory leak issue.

\n

As in Chapter 4, we will begin by loading the process dump in WinDbg and examining the exception code.

\n

It does not matter whether you use the dump file captured with Process Explorer or the one captured with Procdump.

\n

As shown below, the exception information you can obtain from either kind of process dump with the .exr -1 command is the same.

\n
# Exception code from a process dump captured with Process Explorer\n0:000> .exr -1\nExceptionAddress: 0000000000000000\n   ExceptionCode: 80000003 (Break instruction exception)\n  ExceptionFlags: 00000000\nNumberParameters: 0\n\n# Exception code from a process dump captured with Procdump\n0:000> .exr -1\nExceptionAddress: 0000000000000000\n   ExceptionCode: 80000003 (Break instruction exception)\n  ExceptionFlags: 00000000\nNumberParameters: 0
\n

From this, we can see that the exception code recorded in the captured process dump is 0x80000003.

\n

If you refer to the official documentation2, you can see that this exception code relates to breakpoint detection.

\n

Also, as the output of the .exr -1 command itself says, Break instruction exception, we can tell that this exception is related to a breakpoint.

\n

Of course, D4C.exe does not have a hardcoded breakpoint.

\n

In other words, we can conclude that this exception was forcibly raised by Process Explorer or Procdump in order to generate the dump file.

\n

In this way, when you generate a dump file to investigate a problem that does not involve a crash, the tool intentionally raises an exception.

\n

Therefore, when you analyze a dump file for a non-crash problem such as the memory leak issue in this chapter, you need to keep in mind that the exception information you can obtain with .exr -1 and !analyze -v is not useful.

\n

Preparation before investigating the memory leak in the dump file

\n

So if the exception information in the dump file is not useful, how should we proceed with the analysis?

\n

In general, before analyzing a dump file, it is important to narrow down the likely source of the problem to some extent.

\n

For example, in this case we assume that, before analyzing the dump file, we have already identified with Process Explorer, Task Manager, or Resource Monitor that D4C.exe is experiencing a memory leak.

\n

Also, before analyzing the dump file, it is helpful to identify exactly which region of the memory allocated to the D4C.exe process is ballooning.

\n

For each section allocated in a user-mode process’s virtual address space, Sysinternals VMMap lets you confirm that they are classified as follows.3

\n\n

The Image region is allocated to map executable images and similar content.

\n

The Mapped File region is allocated for data files mapped into memory.

\n

The Shareable region contains sharable memory that is not mapped into the Image or Mapped File regions.

\n

The Heap region is the memory area used for heaps owned by the process. (Managed Heap is allocated by the CLR, so nothing is shown for processes that do not use .NET.)

\n

In general, when a user-mode application suffers a memory leak, the size of this Heap region increases.

\n

The Stack region is the area for the stack owned by each executing thread in the process, and the Private Data region is used for memory allocations other than stacks and heaps.

\n

The following is the result of inspecting the D4C.exe process with VMMap before the application’s memory leak occurs.

\n

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

\n

If you need to check the process’s memory usage from the dump file in WinDbg, you can use the !address extension.

\n

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

\n

Running !heap -a confirms that the heap at 0x1f1adb90000 we identified with !heap -S contains 84 segments. (Each line beginning with Segment at corresponds to one segment.)

\n

On Windows systems, NT Heap is managed by the ntdll!_HEAP structure.9

\n

Let’s run dt ntdll!_HEAP in WinDbg after loading the process dump and inspect the structure information for ntdll!_HEAP.

\n
0:000> dt ntdll!_HEAP\n  +0x000 Segment          : _HEAP_SEGMENT\n  +0x000 Entry            : _HEAP_ENTRY\n  +0x010 SegmentSignature : Uint4B\n  +0x014 SegmentFlags     : Uint4B\n  +0x018 SegmentListEntry : _LIST_ENTRY\n  +0x028 Heap             : Ptr64 _HEAP\n  +0x030 BaseAddress      : Ptr64 Void\n  +0x038 NumberOfPages    : Uint4B\n  +0x040 FirstEntry       : Ptr64 _HEAP_ENTRY\n  +0x048 LastValidEntry   : Ptr64 _HEAP_ENTRY\n{{ omitted }}
\n

As shown above, the ntdll!_HEAP structure starts with the ntdll!_HEAP_SEGMENT and ntdll!_HEAP_ENTRY structures.

\n

Next, let’s inspect the information for the ntdll!_HEAP_SEGMENT and ntdll!_HEAP_ENTRY structures.

\n
# Dump structure information for ntdll!_HEAP_SEGMENT\n0:000> dt ntdll!_HEAP_SEGMENT\n +0x000 Entry            : _HEAP_ENTRY\n +0x010 SegmentSignature : Uint4B\n +0x014 SegmentFlags     : Uint4B\n +0x018 SegmentListEntry : _LIST_ENTRY\n +0x028 Heap             : Ptr64 _HEAP\n +0x030 BaseAddress      : Ptr64 Void\n +0x038 NumberOfPages    : Uint4B\n +0x040 FirstEntry       : Ptr64 _HEAP_ENTRY\n +0x048 LastValidEntry   : Ptr64 _HEAP_ENTRY\n +0x050 NumberOfUnCommittedPages : Uint4B\n +0x054 NumberOfUnCommittedRanges : Uint4B\n +0x058 SegmentAllocatorBackTraceIndex : Uint2B\n +0x05a Reserved         : Uint2B\n +0x060 UCRSegmentList   : _LIST_ENTRY\n\n# Dump structure information for ntdll!_HEAP_ENTRY\n0:000> dt ntdll!_HEAP_ENTRY \n +0x000 UnpackedEntry    : _HEAP_UNPACKED_ENTRY\n +0x000 PreviousBlockPrivateData : Ptr64 Void\n +0x008 Size             : Uint2B\n +0x00a Flags            : UChar\n +0x00b SmallTagIndex    : UChar\n +0x008 SubSegmentCode   : Uint4B\n +0x00c PreviousSize     : Uint2B\n +0x00e SegmentOffset    : UChar\n +0x00e LFHFlags         : UChar\n +0x00f UnusedBytes      : UChar\n +0x008 CompactHeader    : Uint8B\n +0x000 ExtendedEntry    : _HEAP_EXTENDED_ENTRY\n +0x000 Reserved         : Ptr64 Void\n +0x008 FunctionIndex    : Uint2B\n +0x00a ContextValue     : Uint2B\n +0x008 InterceptorValue : Uint4B\n +0x00c UnusedBytesLength : Uint2B\n +0x00e EntryOffset      : UChar\n +0x00f ExtendedBlockSignature : UChar\n +0x000 ReservedForAlignment : Ptr64 Void\n +0x008 Code1            : Uint4B\n +0x00c Code2            : Uint2B\n +0x00e Code3            : UChar\n +0x00f Code4            : UChar\n +0x00c Code234          : Uint4B\n +0x008 AgregateCode     : Uint8B
\n

From the information above, we can see that the ntdll!_HEAP structure is composed of ntdll!_HEAP_SEGMENT structures that include ntdll!_HEAP_ENTRY structures.

\n

On Windows XP and earlier, you can traverse the ntdll!_HEAP_ENTRY structures inside a specific heap segment in a process by repeatedly advancing by the Size value of ntdll!_HEAP_ENTRY multiplied by 8.10

\n

However, this method cannot be used on Vista and later, because ASLR randomizes the process heap.11

\n

Therefore, to traverse the ntdll!_HEAP_ENTRY structures inside a heap segment, we will use the !heap extension.

\n

First, we specified 0x1f1adb90000, the address of the heap that has ballooned this time, and retrieved the information inside that heap with the !heap -a 0x1f1adb90000 command. (You can get equivalent output by using the heap ID and running !heap -a 1.)

\n

The output of this command is extremely long, so as needed, it is a good idea to enable output to a file with the .logopen command. (The .logopen command is described in this book’s “Appendix A: WinDbg Tips”.)

\n

When we actually ran !heap -a 0x1f1adb90000 in WinDbg with the process dump loaded, we were able to enumerate the 84 heap segments in this heap and the heap entries within them.

\n

The following is an excerpt showing only the output for the 84th heap segment and the heap entries inside it.

\n
# Excerpt showing only the output for the 84th heap segment and its heap entries\nSegment83 at fbec0000:\n  Flags:           00000000\n  Base:            1f1fbec0000\n  First Entry:     fbec0070\n  Last Entry:      1f1fce8f000\n  Total Pages:     00000fcf\n  Total UnCommit:  00000b5b\n  Largest UnCommit:00000000\n  UnCommitted Ranges: (1)\n\nHeap entries for Segment83 in Heap 000001f1adb90000\n  address: psize . size  flags   state (requested size)\n  000001f1fbec0000: 00000 . 00070 [101] - busy (6f)\n  000001f1fbec0070: 00070 . 41f90 [101] - busy (41f80) Internal \n  000001f1fbf02000: 41f90 . 42010 [101] - busy (41ff0) Internal \n  000001f1fbf44010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fbf86000: 41ff0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fbfc8010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fc00a000: 41ff0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fc04c010: 42010 . 00400 [101] - busy (3f0) Internal \n  000001f1fc04c410: 00400 . 41bf0 [101] - busy (41be0) Internal \n  000001f1fc08e000: 41bf0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fc0d0010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fc112000: 41ff0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fc154010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fc196000: 41ff0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fc1d8010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fc21a000: 41ff0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fc25c010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fc29e000: 41ff0 . 42010 [101] - busy (41ff0) Internal \n  000001f1fc2e0010: 42010 . 41ff0 [101] - busy (41fe0) Internal \n  000001f1fc322000: 41ff0 . 11fc0 [100]\n  000001f1fc333fc0: 11fc0 . 00040 [111] - busy (3d)\n  000001f1fc334000:      00b5b000      - uncommitted bytes.
\n

When a program writes information into heap memory allocated by the process, the written data is recorded in the memory region after the header of each heap entry.12

\n

If we actually specify the addresses of several heap entries identified with !heap -a 0x1f1adb90000 and dump around 0x100 bytes of memory, we can confirm that the string ==> Allocated addr: <Address> is written in each heap entry as shown below.

\n

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

\n

Identifying the code responsible for the memory leak

\n

By analyzing the allocated heap regions from the dump file, we identified that the memory leak is very likely occurring because heap regions containing the string ==> Allocated addr: <Address> have not been freed.

\n

For issues such as memory leaks, unless allocations occur extremely intermittently, it is rare for the call stack at the time the dump file is captured to contain useful information.

\n

So in many cases, live debugging, inspecting the source code, or reverse-engineering the application is more efficient than analyzing the dump file.

\n

That said, in this book we will try, as much as possible, to identify the code responsible for the memory leak by analyzing the dump file.

\n

First, with the process dump file loaded in WinDbg, run the k command to output a stack backtrace.

\n
0:000> k\n # Child-SP          RetAddr               Call Site\n00 0000003d`d1eff6e8 00007ffa`382d30ce     ntdll!NtWaitForSingleObject+0x14\n01 0000003d`d1eff6f0 00007ff6`dfe213b9     KERNELBASE!WaitForSingleObjectEx+0x8e\n02 0000003d`d1eff790 00007ff6`dfe21a40     D4C+0x13b9\n03 0000003d`d1effa50 00007ffa`38b17344     D4C+0x1a40\n04 0000003d`d1effa90 00007ffa`3a9c26b1     kernel32!BaseThreadInitThunk+0x14\n05 0000003d`d1effac0 00000000`00000000     ntdll!RtlUserThreadStart+0x21
\n

Unfortunately, calls to functions such as HeapAlloc, which are used for heap allocation, were not recorded in this stack backtrace.

\n

However, although we did not deal with this in Chapters 4 and 5, many ordinary applications run as multi-threaded programs.

\n

The information you get by running the k command after loading a process dump into WinDbg is only the stack backtrace of the process’s main thread, so just to be safe, let’s investigate the stack backtraces of the other threads as well.

\n

Threads running inside a user-mode process can be enumerated with the !threads extension.13

\n

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

\n

Analyzing what each thread is doing

\n

By this point in the investigation, we have identified the following information about the D4C.exe memory leak issue.

\n\n

From here, we will identify the code that is actually causing the process’s heap region to balloon and triggering the memory leak.

\n

However, unlike the crash analyses we have performed so far, a dump file captured by the user at an arbitrary timing does not necessarily contain convenient information about the execution of the code that caused the problem.

\n

This is because the information contained in a dump file is, after all, nothing more than the state of memory at the moment the dump was captured.

\n

In such cases, if you want to identify the code that writes to the heap region, it is often more effective to do live debugging or source-code analysis, or to use a decompiler such as Ghidra, which we used in Chapters 4 and 5.

\n

There are multiple possible ways to identify the code that writes to the heap region, but in this book we will proceed with the following approach.

\n
    \n
  1. Identify the offset in the application’s data region where the string ==> Allocated addr: is hardcoded.
    2. \n
  2. Use a decompiler to identify the code that references the data at the offset found in step 1, and thereby identify the code that writes the string ==> Allocated addr: <Address> into memory.
    3. \n
\n

As we confirmed in the sections above, the memory inside the heap regions allocated this time contains the string ==> Allocated addr: <Address>, and the ==> Allocated addr: part was the same in every heap region.

\n

In other words, unless the program is obfuscated, it is reasonable to assume that the text ==> Allocated addr: is hardcoded in the program.

\n

Data such as text hardcoded in a program is typically placed in the .rdata region (initialized read-only data) of the running process.15

\n

So first, in WinDbg with the process dump file loaded, we will scan the .rdata region to identify the address where the text ==> Allocated addr: is hardcoded.

\n

To scan the .rdata region, we first need to identify the target address range, so let’s display the section header information for D4C.exe with the !dh -s command.

\n
0:000> !dh -s !D4C\n\nSECTION HEADER #1\n .text name\n  15EC virtual size\n  1000 virtual address\n  1600 size of raw data\n   400 file pointer to raw data\n     0 file pointer to relocation table\n     0 file pointer to line numbers\n     0 number of relocations\n     0 number of line numbers\n60000020 flags\n       Code\n       (no align specified)\n       Execute Read\n\nSECTION HEADER #2\n.rdata name\n  343A virtual size\n  3000 virtual address\n  3600 size of raw data\n  1A00 file pointer to raw data\n     0 file pointer to relocation table\n     0 file pointer to line numbers\n     0 number of relocations\n     0 number of line numbers\n40000040 flags\n       Initialized Data\n       (no align specified)\n       Read Only\n\n{{ omitted }}\n\nSECTION HEADER #3\n .data name\n   638 virtual size\n  7000 virtual address\n   200 size of raw data\n  5000 file pointer to raw data\n     0 file pointer to relocation table\n     0 file pointer to line numbers\n     0 number of relocations\n     0 number of line numbers\nC0000040 flags\n       Initialized Data\n       (no align specified)\n       Read Write\n\n{{ omitted }}
\n

When we ran !dh -s !D4C in WinDbg with this process dump loaded, we found, as shown above, that the .rdata section had a virtual address of 0x3000 and an aligned size of 0x3600.

\n

In other words, we can conclude that the .rdata section in this process dump exists in the range starting at !D4C+0x3000 (the address obtained by adding 0x3000 to the image base address of D4C.exe) and extending for 0x3600 bytes.

\n

Now that we know the address range of the .rdata section, next let’s use the s command to search for text within that range.16

\n

When using the s command to search for ASCII text within a specified address range, run s -a <search start address> L<search size> \"<ASCII text to search for>\".\n(-a specifies that the search target is an ASCII string. If you want to search for a Unicode string, use the -u option.)

\n

To search for the text ==> Allocated addr: in the .rdata section inside the D4C.exe process, run s -a !D4C+0x3000 L0x3600 \"==> Allocated addr:\".

\n

When we actually ran that command, we confirmed that the target string was defined at address 0x7ff6dfe236b0, as shown below.

\n
0:000> s -a !D4C+0x3000 L0x3600 \"==> Allocated addr:\" \n00007ff6`dfe236b0  3d 3d 3e 20 41 6c 6c 6f-63 61 74 65 64 20 61 64  ==> Allocated ad
\n

The output of the s command above did not show the full text that was defined, so next let’s use the da command to display the text stored at that address.17

\n
0:000> da 00007ff6dfe236b0\n00007ff6`dfe236b0  \"==> Allocated addr: 0x%08x.\"
\n

This confirms that the hardcoded text ==> Allocated addr: 0x%08x. exists at address 0x7ff6dfe236b0.

\n

Finally, we will identify the relative virtual address (RVA) where this text is hardcoded.

\n

You can identify the RVA by subtracting the image base address of D4C.exe from the address 0x7ff6dfe236b0, where this text is hardcoded.

\n
0:000> ? 0x7ff6dfe236b0 - !D4C\nEvaluate expression: 14000 = 00000000`000036b0
\n

By calculating the address with the command above, we can identify that the RVA where the target text is defined is 0x36b0.

\n

Now that we know the offset where the string ==> Allocated addr: is hardcoded, we will continue by using the Ghidra decompiler to identify the code that writes this text to the heap region.

\n

After launching Ghidra and loading D4C.exe using the same procedure as in Chapters 4 and 5, press [g] on the keyboard to open the GoTo window.

\n

Next, enter the value obtained by adding the offset 0x36b0 we identified earlier to the default image base address 0x140000000 that Ghidra uses when loading D4C.exe, and click [OK].

\n

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

\n

As a result of decompiling the code around this address in Ghidra, we obtained the following pseudocode.

\n
while( true ) {\n   _Dst = (char *)malloc((longlong)(int)param_1);\n   if (_Dst == (char *)0x0) break;\n      printf(\"Count: %d\\n\",(ulonglong)uVar2,param_3,param_4);\n\n   param_4 = (ulonglong)_Dst & 0xffffffff;\n   _SizeInBytes = (ulonglong)(int)(param_1 - 1)\n\n   pcVar3 = \"==> Allocated addr: 0x%08x\\n\";\n   FUN_140001540(local_1030,_SizeInBytes,\"==> Allocated addr: 0x%08x\\n\",param_4);\n\n   printf(&DAT_1400036cc,local_1030,pcVar3,param_4);\n   printf(\"==> Total allocated size: 0x%08x\\n\",(ulonglong)uVar1,pcVar3,param_4);\n\n   param_3 = local_1030;\n   strcpy_s(_Dst,_SizeInBytes,param_3);\n\n   if (0x1fffffff < (int)uVar1) {\n      printf(\"==> Slow Down...\\n\",_SizeInBytes,param_3,param_4);\n      Sleep(1000);\n   }\n\n   uVar2 = uVar2 + 1;\n   uVar1 = uVar1 + param_1;\n}
\n

By analyzing this pseudocode, we can see that inside the while loop, the program repeatedly allocates heap memory with the malloc function and writes to it with the strcpy_s function, yet no code is defined to free the allocated heap.

\n

With that, we have identified the code responsible for the user-mode memory leak in D4C.exe.

\n

Summary of Chapter 6

\n

In this chapter, as an example of investigating the cause of a non-crash problem from a dump file, we analyzed a user-mode application memory leak issue.

\n

In Chapter 7, the final chapter of this book, we will investigate the same memory leak issue covered in this chapter, this time from a full system memory dump.

\n

Even though we casually refer to both of them as “dump files,” the analysis methods and investigative approach differ greatly between a user-mode process dump and a full system memory dump.

\n

Compared with the crash-dump analysis covered in Chapters 4 and 5, this chapter may have felt a little more difficult, but I think investigating problems like this is one of the real pleasures of dump analysis, so I hope you will enjoy reading through to the very end.

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

    Virtual memory and physical memory https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/virtual-and-physical-memory

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

    Bug Check 0x8E: KERNEL_MODE_EXCEPTION_NOT_HANDLED https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/bug-check-0x8e—kernel-mode-exception-not-handled

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

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

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

    HeapCreate function https://learn.microsoft.com/ja-jp/windows/win32/api/heapapi/nf-heapapi-heapcreate

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

    HeapAlloc function https://learn.microsoft.com/ja-jp/windows/win32/api/heapapi/nf-heapapi-heapalloc

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

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

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

    !heap extension https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-heap

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

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

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

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

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

    Advanced Windows Debugging, 1st Edition, p.276 (by Mario Hewardt, Daniel Pravat / Addison-Wesley Professional / 2007)

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

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

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

    Windows Dump no Gokui: When an Error Occurs, Start with Dump Analysis!, p.120 (by 上原 祥市 / ASCII Media Works / 2008)

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

    !threads extension https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-thread

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

    !runaway extension https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-runaway

    \n↩\n
    15. \n
  15. \n

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

    \n↩\n
    16. \n
  16. \n

    s (search memory) https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/s—search-memory-

    \n↩\n
    17. \n
  17. \n

    d, da, db, dc, dd, dD, df, dp, dq, du, dw, dyb, dyd (display memory) https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/d—da—db—dc—dd—dd—df—dp—dq—du—dw—dw—dyb—dyd—display-memor

    \n↩\n
    18. \n
\n
","fields":{"slug":"/magical-windbg-vol1-06-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 6: Investigating a User-Mode Application Memory Leak from a Process Dump]","socialImage":{"publicURL":"/static/2dbf3e09d59db889dc9dc41adcc8e827/magical-windbg-vol1.png"}}}},"pageContext":{"slug":"/magical-windbg-vol1-06-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}