{"componentChunkName":"component---src-templates-post-template-js","path":"/magical-windbg-vol1-07-en","result":{"data":{"markdownRemark":{"id":"187b0ad8-7bb9-581c-8669-0b8fd94185c8","html":"
\n

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

\n
\n

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

\n

Since the method of investigating the memory leak itself is the same as in Chapter 6, Chapter 7 focuses more on introducing techniques for extracting various kinds of information from a full memory dump.

\n

However, when analyzing a full memory dump that includes kernel-mode memory information, the available commands and their output differ from those used in user-mode process dump analysis, so I think you will be able to enjoy a different style of analysis here as well.

\n\n

Table of contents

\n\n

Obtaining a full system memory dump

\n

To obtain the full memory dump for analysis, just as in Chapter 6, start D4C.exe, choose menu item 2, and reproduce the application’s memory leak issue.

\n

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

\n

After the system reboots, a FULL_MEMORY.DMP file roughly the same size as the virtual machine’s physical memory will be created directly under the C:\\Windows folder.

\n

In this chapter, we will use this full memory dump to investigate the application’s memory leak issue.

\n

Incidentally, as mentioned in Chapter 1, the keyboard-crash configuration described in this book does not work when you are connected over RDP.

\n

If you can use a physical keyboard, you need to sign in directly to the local machine and cause the system crash by pressing the right Ctrl key while tapping the Space key twice.

\n

If you are using a Hyper-V virtual machine, you can also trigger the keyboard crash by signing in with Enhanced Session Mode disabled and then pressing the right Ctrl key while tapping the Space key twice.

\n

If you are using another kind of virtual machine, try using a software keyboard.

\n

If your environment does not allow you to perform a keyboard crash, you can also intentionally reproduce a system crash by using notmyfault.exe included in the SysinternalsSuite downloaded in Installing the Sysinternals utilities.

\n

Loading the full memory dump into WinDbg

\n

Once you have obtained the dump file for analysis, let’s load it right away into WinDbg running with administrator privileges.

\n

As in the previous chapters, when we run the !analyze -v command and inspect the Bug Check information contained in the dump file, it is displayed as MANUALLY_INITIATED_CRASH (e2)1, as shown below.

\n
0: kd> !analyze -v\n\nMANUALLY_INITIATED_CRASH (e2)\nThe user manually initiated this crash dump.\nArguments:\nArg1: 0000000000000000\nArg2: 0000000000000000\nArg3: 0000000000000000\nArg4: 0000000000000000
\n

This is the value recorded when a user intentionally causes a system crash through a kernel debugger or a keyboard operation.

\n

In other words, just like the process dump that was generated manually in Chapter 6, the exception context stored in this full memory dump is not useful for analyzing the memory leak issue.

\n

Therefore, when investigating problems other than crashes from a full memory dump, you first need to narrow down the appropriate analysis target and set the debugger context accordingly.

\n

So, in the following sections, we will comprehensively collect information from the full memory dump to identify the proper analysis target.

\n

A full memory dump contains information about every page currently held in the system’s physical memory, and by fully using the capabilities of WinDbg as a powerful debugger, you can retrieve virtually any information in the system from that full memory dump.

\n

Depending on the command you run, the output can be enormous, so it is a good idea to use the .logopen command to write the results to a file as needed.

\n

Collecting hardware information about the machine

\n

To begin with, let’s use the !sysinfo extension command2 to collect hardware information recorded in the dump file.

\n

The !sysinfo extension command has several options, but in this book we use !sysinfo cpuinfo to display CPU information and !sysinfo machineid to display machine information.

\n
# Display CPU information\n0: kd> !sysinfo cpuinfo\n[CPU Information]\n~MHz = REG_DWORD 1992\nComponent Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\nConfiguration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0\nIdentifier = REG_SZ Intel64 Family 6 Model 142 Stepping 10\nProcessorNameString = REG_SZ Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz\nUpdate Status = REG_DWORD 7\nVendorIdentifier = REG_SZ GenuineIntel\nMSR8B = REG_QWORD ea00000000\n\n# Display machine information\n0: kd> !sysinfo machineid\nMachine ID Information [From Smbios 3.0, DMIVersion 0, Size=3046]\nBiosMajorRelease = 1\nBiosMinorRelease = 43\nFirmwareMajorRelease = 1\nFirmwareMinorRelease = 10\nBiosVendor = LENOVO\nBiosVersion = N20ET58W (1.43 )\nBiosReleaseDate = 07/26/2021\nSystemManufacturer = LENOVO\nSystemProductName = 20KES0KB00\nSystemFamily = ThinkPad X280\nSystemVersion = ThinkPad X280\nSystemSKU = LENOVO_MT_20KE_BU_Think_FM_ThinkPad X280\nBaseBoardManufacturer = LENOVO\nBaseBoardProduct = 20KES0KB00\nBaseBoardVersion = Not Defined
\n

By running these commands, we were able to confirm, as shown above, that the machine on which the system crash occurred was a ThinkPad X280 equipped with an Intel i7-8550U.

\n

If you want to display even more detailed CPU information, you can use the !cpuinfo extension command3.

\n

When you run !cpuinfo without any options, information for all processors is displayed.

\n

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

\n

Because the Intel i7-8550U is a 4-core, 8-thread CPU, the output of !cpuinfo also has 8 lines.

\n

The values from 0 to 7 in the CP column represent each processor, and the MHz column represents the clock frequency.

\n

Collecting system information

\n

Next, we will collect OS system information from the full memory dump.

\n

Regarding OS system information, if you set the context to a process the user is running and execute the !peb command, you can refer to it through the user’s environment variable information contained in the PEB.

\n

In fact, from the full memory dump analyzed this time as well, we were able to retrieve information such as the computer name, the number of CPUs, the PATH environment variable, and the username, as shown below.

\n
0: kd> !peb\n{{ omitted }}\nEnvironment:  000001d5a58027f0\n  ...\n  COMPUTERNAME=THINKPAD-X280\n  ...\n  NUMBER_OF_PROCESSORS=8\n  OS=Windows_NT\n  Path=C:\\Program Files\\Common Files\\Oracle\\Java\\javapath;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\Program Files\\Intel\\WiFi\\bin\\;C:\\Program Files\\Common Files\\Intel\\WirelessCommon\\;C:\\WINDOWS\\ServiceProfiles\\NetworkService\\AppData\\Local\\Microsoft\\WindowsApps\n  ...\n  PROCESSOR_ARCHITECTURE=AMD64\n  PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 142 Stepping 10, GenuineIntel\n  ...\n  USERDOMAIN=THINKPAD-X280\n  USERDOMAIN_ROAMINGPROFILE=THINKPAD-X280\n  USERNAME=Win10\n  USERPROFILE=C:\\Users\\Win10
\n

In addition, you can also collect OS information and the computer name by using the !mex.ver and !mex.computername commands provided by the MEX extension4, which is introduced in “Appendix A: WinDbg Tips” in this book.

\n
# Check OS version information with the MEX extension\n0: kd> !mex.ver\nPlatform ID: 2\nMajor Version: 10\nMinor Version: 0\nWinXP: False\nWin2K3: False\nWin2k3SP1OrNewer: True\nVista: False\nVistaOrNewer: True\nWin7: False\nWin8: False\nBlue: False\n19041.1.amd64fre.vb_release.191206-1406\nBuild Number: 19041\nKernel Start Address: ffff800000000000\nSystem Version Build String: 19041.1.amd64fre.vb_release.191206-1406\n\n# Check the computer name with the MEX extension\n0: kd> !mex.computername\nComputer Name: THINKPAD-X280
\n

Exploring the system registry

\n

On Windows systems, OS settings, application settings, and various other kinds of information are stored in the registry.

\n

Therefore, by analyzing a full memory dump and exploring the registry hives, you can access most information related to the system and its configuration.

\n

To search the registry from a full memory dump in WinDbg, use the !reg extension command4a.

\n

For example, by executing commands in the following steps, you can use the !reg extension command to search a specified registry value in a full memory dump.

\n
    \n
  1. Use the !reg hivelist command to obtain the addresses of the registry hives in the system.
    2. \n
  2. Use the !reg openkeys <hive address> command to obtain the exact hive name and the address of the key control block (KCB).
    3. \n
  3. Use the !reg querykey <hive name> command to obtain address information for the subkeys.
    4. \n
  4. Use the !reg keyinfo <hive address> <subkey address> command to obtain the keys and registry values inside the subkey.
    5. \n
\n

Using these commands, let’s actually retrieve some registry information from the full memory dump that is the target of this analysis.

\n

First, enumerate the registry hive information in the system with the !reg hivelist command.

\n

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

\n

Although it may be difficult to read at this image scale, the seventh line of the output shows information for a hive whose FileName is emRoot\\System32\\Config\\SOFTWARE. (Because of the character limit, the FileName column shows only the last 32 characters of the path.)

\n

This matches the default path of the SOFTWARE hive, %SystemRoot%\\System32\\Config\\SOFTWARE.5

\n

In other words, when exploring the registry corresponding to HKEY_LOCAL_MACHINE\\SOFTWARE, we can see that we should use the address 0xffffa58428b62000 shown in the HiveAddr column on the seventh line.

\n

Next, use the SOFTWARE hive address we obtained and run the !reg openkeys ffffa58428b62000 command.

\n

The !reg openkeys command can also be run without arguments, but because the output becomes very large, we specify the address of the hive we want to analyze.

\n
0: kd> !reg openkeys ffffa58428b62000\n\nHive: \\REGISTRY\\MACHINE\\SOFTWARE\n===========================================================================================\nIndex 0:  00000000 kcb=ffffa5842b2d1d50 cell=00000020 f=002c0000 \\REGISTRY\\MACHINE\\SOFTWARE\nIndex 1:  f386608f kcb=ffffa584316e1d00 cell=017c4288 f=00200000 \\REGISTRY\\MACHINE\\SOFTWARE\\SYNAPTICS\\SYNTPENH\\ZONECONFIG\\DEFAULTS\\PALMCHECK GROUP\\2FVSCROLL ZONE\n 8a10ced9 kcb=ffffa5842d346350 cell=80008f90 f=00200000 \\REGISTRY\\MACHINE\\SOFTWARE\\MICROSOFT\\WINDOWS\\CURRENTVERSION\\APPMODEL\\STATEREPOSITORY\\CACHE\\PACKAGEEXTERNALLOCATION\nIndex 2:  5c8055db kcb=ffffa58433820390 cell=002a8cf8 f=00200000 \\REGISTRY\\MACHINE\\SOFTWARE\\CLASSES\\CLSID\\{896664F7-12E1-490F-8782-C0835AFD98FC}\\INSTANCE\n{{ omitted }}
\n

When you actually run this command, you can confirm, as shown above, that the first line of the output displays Hive: \\REGISTRY\\MACHINE\\SOFTWARE.

\n

Therefore, use this result to run the !reg querykey \\REGISTRY\\MACHINE\\SOFTWARE command. (If you are already comfortable with this kind of analysis, there is no problem running this command from the start.)

\n

The output of this command was as follows.

\n

At this point, you can see that the hive address 0xffffa58428b62000 identified so far, the key control block (KCB) address, and a list of subkeys together with their SubKeyAddr values are all displayed.

\n
0: kd> !reg querykey \\REGISTRY\\MACHINE\\SOFTWARE\n\nFound KCB = ffffa5842b2d1d50 :: \\REGISTRY\\MACHINE\\SOFTWARE\n\nHive         ffffa58428b62000\nKeyNode      0000022eaab61024\n\n[SubKeyAddr]         [SubKeyName]\n22eaab61174          Classes\n22eab25daec          Clients\n22eab5b2184          CVSM\n22eab5b244c          DefaultUserEnvironment\n22eab5b2624          Dolby\n22eab5b297c          Fortemedia\n22eab5b2b0c          Google\n22eab5b2dec          InstalledOptions\n22eab5b2e4c          Intel\n22eab5b7af4          JavaSoft\n22eab5b7b4c          Lenovo\n22eab5b8524          Microsoft\n22eac3103ac          Mozilla\n22eac310614          Nuance\n22eac31066c          ODBC\n22eac3106c4          OEM\n22eac310894          OpenSSH\n22eac31097c          Oracle\n22eac3109d4          Partner\n22eac310a2c          Policies\n22eac313854          Realtek\n22eac313d34          RegisteredApplications\n22eac3144bc          SRS Labs\n22eac31467c          Synaptics\n22eac32d2c4          Windows\n22eac32d31c          WOW6432Node\n\n Use '!reg keyinfo ffffa58428b62000 <SubKeyAddr>' to dump the subkey details\n\n[ValueType]         [ValueName]                   [ValueData]\n Key has no Values
\n

Now that we have the necessary information, use the !reg keyinfo <hive address> <subkey address> command to retrieve the keys and registry values inside a subkey.

\n

For example, to explore the Microsoft subkey whose SubKeyAddr is 0x22eab5b8524 inside the SOFTWARE hive, the command is !reg keyinfo ffffa58428b62000 22eab5b8524.

\n

When you actually run this command, the list of subkeys under HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft and their SubKeyAddr values are displayed as follows.

\n
0: kd> !reg keyinfo ffffa58428b62000 22eab5b8524\n\nKeyPath \\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\n\n[SubKeyAddr]         [SubKeyName]\n22eab5b8694          .NETFramework\n22eab5fc13c          AccountsControl\n22eab5fc19c          Active Setup\n22eab5ff7dc          ActiveSync\n22eab6009ac          ADs\n22eab600a04          Advanced INF Setup\n22eab600a6c          ALG\n22eab600ce4          AllUserInstallAgent\n22eab600e94          AMSI\n\n22eab79a0ec          Windows\n22eac107024          Windows Advanced Threat Protection\n22eac1073ac          Windows Defender\n22eac10bcf4          Windows Defender Security Center
\n

If you want to explore registry information at a deeper level, specify one of the SubKeyAddr values obtained above and issue the !reg keyinfo command again.

\n

For example, to retrieve information for the Windows Defender subkey whose SubKeyAddr is 0x22eac1073ac, run !reg keyinfo ffffa58428b62000 22eac1073ac.

\n

When you actually run this command, the upper part of the output shows the list of subkeys under HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows Defender, and the lower part shows the list of values present in this registry key.

\n

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

\n

Now that we have confirmed virtual memory resource consumption, let’s next investigate physical memory resource consumption.

\n

To investigate physical memory resource consumption, you can use the !memusage extension command7.

\n

The !memusage extension command outputs physical memory statistics by using information from the page frame number (PFN) database that Windows uses to manage physical memory.

\n

Because the output of the !memusage command is extremely large, this time we run !memusage 0x08, which displays only summary information.

\n
0: kd> !memusage 0x08\nloading PFN database\nloading (100% complete)\nCompiling memory usage data (99% Complete).\n          Zeroed:   319761 ( 1279044 kb)\n            Free:      460 (    1840 kb)\n         Standby:  1669387 ( 6677548 kb)\n        Modified:    50530 (  202120 kb)\n ModifiedNoWrite:        7 (      28 kb)\n    Active/Valid:  1118305 ( 4473220 kb)\n      Transition:  1002519 ( 4010076 kb)\n      SLIST/Temp:     6687 (   26748 kb)\n             Bad:        0 (       0 kb)\n         Unknown:        0 (       0 kb)\n           TOTAL:  4167656 (16670624 kb)\n\nDangling Yes Commit:      169 (     676 kb)\n Dangling No Commit:    50768 (  203072 kb)
\n

By running this command, you can obtain statistical information about the system’s physical memory usage as shown above.

\n

Each item in the output corresponds to information about the state of physical pages contained in the PFN database.

\n

A summary of some frequently referenced items is given below.8

\n\n

If you want to learn more about the PFN database, I recommend Windows Internals, 7th Edition, Part 1, which is listed in the references.

\n

Investigating information about running processes

\n

Next, we will collect information about processes running in the system.

\n

Information about running processes is used in a variety of situations, such as setting the appropriate process context and investigating problems like spikes in CPU usage.

\n

There are multiple ways to collect process information, but in this book I will introduce only some of them.

\n

First, let’s use the !process extension command9.

\n

When memory information from kernel space that includes EPROCESS structure data—such as a full system memory dump—is loaded into WinDbg, you can enumerate summary information for all processes in the system by running !process 0 0.

\n

The output of this command includes the addresses of EPROCESS structures and the process names, as shown below.

\n

Therefore, by using the EPROCESS structure address obtained from this command, you can change the process context or retrieve more detailed information about the target process.

\n
0: kd> !process 0 0\n\n**** NT ACTIVE PROCESS DUMP ****\nPROCESS ffffcb0c8a6bf080\n    SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000\n    DirBase: 001ad002  ObjectTable: ffffa58427e2e600  HandleCount: 3952.\n    Image: System\n\nPROCESS ffffcb0c8a71f080\n    SessionId: none  Cid: 007c    Peb: 00000000  ParentCid: 0004\n    DirBase: 007dc002  ObjectTable: ffffa58427e5c5c0  HandleCount:   0.\n    Image: Registry\n\n{{ omitted }}
\n

Also, if you have already identified the name of the process to investigate, you can search for the address of a specific process object (EPROCESS) by using !process 0 0 <process name>.

\n

When we actually specify D4C.exe and run the !process 0 0 D4C.exe command, we can identify that the process object for D4C.exe exists at address 0xffffcb0c950ea0c0. (We will use this address later.)

\n
0: kd> !process 0 0 D4C.exe\n\nPROCESS ffffcb0c950ea0c0\n    SessionId: 3  Cid: 0d40    Peb: 13c75e4000  ParentCid: 3758\n    DirBase: 27cd1f002  ObjectTable: ffffa5843cdd8c00  HandleCount:  51.\n    Image: D4C.exe
\n

Incidentally, you can also output information about a specific process by giving the address of its process object as the first argument to the !process command. (If 0 is specified, information about all active processes is displayed.)

\n

The second argument, meanwhile, is a flag that controls how much information is displayed, and when 0 is specified only minimal information is output.

\n

If you specify 7 for the second argument, on the other hand, you can display detailed information including threads associated with the process and their stack backtraces.

\n

Therefore, if you have already identified the name of the target process, you can collect more detailed information by running a command such as !process 0 7 D4C.exe.

\n

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

\n

Another very convenient command included in the MEX extension is !mex.commandline -a.

\n

This command can enumerate the command lines of all active processes in the system.

\n

By running this command, you can output the addresses of all processes and their command-line information, as shown below.

\n

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

\n

As mentioned above, by changing the process context, you can investigate detailed information about the process with commands such as !peb and lm, just as when analyzing a user-mode process dump.

\n

Investigating the stack backtrace of a specific process

\n

Now that we can enumerate system process information and change the debugger’s process context, next we will obtain stack backtrace information for a specific process.

\n

We already confirmed in the previous section that the !process 0 7 D4C.exe command can output stack backtraces for all threads in the process, but here we intentionally obtain the information using the k command.

\n

However, even if you set the debugger’s process context to D4C.exe by following the steps in the previous section, the k command, which outputs the stack backtrace for the current thread, does not output information about D4C.exe.

\n

This is because the k command depends on the debugger’s register context.11

\n

Therefore, we first change the debugger’s register context by using the .thread command12.

\n

To change the register context with the .thread command, you need to specify the address of the thread to switch to.

\n

There are several ways to find the threads of a process from a full system memory dump, but the method using the !process extension command introduced in the previous section is simple.

\n

To display thread information with the !process extension command, specify 2 for the optional Flag argument. (You can also use 7, which outputs all available information.)

\n

To retrieve thread information for the D4C.exe process with the !process extension command, run the !process 0 2 D4C.exe command.

\n

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

\n

This lets us identify that the three thread addresses associated with the D4C.exe process are 0xffffcb0c93f24080, 0xffffcb0c93d17080, and 0xffffcb0c95645080.

\n

Now, by setting the thread context with these three addresses, we can use the k command to inspect stack backtrace information for D4C.exe’s threads.

\n
# Set the first thread context and print the stack backtrace\n0: kd> .thread 0xffffcb0c93f24080; k\nImplicit thread is now ffffcb0c`93f24080\n  *** Stack trace for last set context - .thread/.cxr resets it\n # Child-SP          RetAddr               Call Site\n00 ffffef81`2c6ef5e0 fffff806`72e1bca0     nt!KiSwapContext+0x76\n01 ffffef81`2c6ef720 fffff806`72e1b1cf     nt!KiSwapThread+0x500\n02 ffffef81`2c6ef7d0 fffff806`72e1aa73     nt!KiCommitThreadWait+0x14f\n03 ffffef81`2c6ef870 fffff806`73201b11     nt!KeWaitForSingleObject+0x233\n04 ffffef81`2c6ef960 fffff806`73201a6a     nt!ObWaitForSingleObject+0x91\n{{ omitted }}\n\n# Set the second thread context and print the stack backtrace\n0: kd> .thread 0xffffcb0c93d17080; k\nImplicit thread is now ffffcb0c`93d17080\n  *** Stack trace for last set context - .thread/.cxr resets it\n # Child-SP          RetAddr               Call Site\n00 ffffef81`2c7476e0 fffff806`72e1bca0     nt!KiSwapContext+0x76\n01 ffffef81`2c747820 fffff806`72e1b1cf     nt!KiSwapThread+0x500\n02 ffffef81`2c7478d0 fffff806`72ef51a4     nt!KiCommitThreadWait+0x14f\n03 ffffef81`2c747970 fffff806`732b1d20     nt!KeWaitForAlertByThreadId+0xc4\n04 ffffef81`2c7479d0 fffff806`730105f5     nt!NtWaitForAlertByThreadId+0x30\n{{ omitted }}\n\n# Set the third thread context and print the stack backtrace\n0: kd> .thread 0xffffcb0c95645080; k\nImplicit thread is now ffffcb0c`95645080\n  *** Stack trace for last set context - .thread/.cxr resets it\n # Child-SP          RetAddr               Call Site\n00 ffffef81`2c847310 fffff806`72e1bca0     nt!KiSwapContext+0x76\n01 ffffef81`2c847450 fffff806`72e1b1cf     nt!KiSwapThread+0x500\n02 ffffef81`2c847500 fffff806`72e1aa73     nt!KiCommitThreadWait+0x14f\n03 ffffef81`2c8475a0 fffff806`72ff1494     nt!KeWaitForSingleObject+0x233\n04 ffffef81`2c847690 fffff806`732011ab     nt!IopWaitForSynchronousIoEvent+0x50\n{{ omitted }}
\n

Furthermore, by passing a thread object’s address as an argument to the !thread extension command13, you can display the target thread’s execution time and stack backtrace together without changing the thread context.

\n

Below is the output of running the !thread 0xffffcb0c93d17080 command.

\n

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

\n

From here, by using the Ghidra decompiler just as in Chapter 6 to investigate the code that writes to the heap, you can identify the location that caused the user-mode memory leak.

\n

Incidentally, although this book does not use them, when you investigate kernel-mode memory leak issues rather than user-mode ones, you inspect paged pool and nonpaged pool information with commands such as the !pool extension command14 and the !poolused extension command15.

\n

Summary of Chapter 7

\n

In Chapters 6 and 7, we analyzed memory leak issues in user-mode applications as examples of investigating the causes of problems that do not involve a crash from dump files.

\n

Unlike process dump analysis, when troubleshooting a specific process from a full system memory dump, you need to set the appropriate process context and register context in the debugger.

\n

I think this point can easily become a hurdle for people who are analyzing dump files for the first time, so I hope you will read this chapter while comparing it with the analysis in Chapter 6.

\n

Although this book dealt with memory leaks in user applications as a non-crash problem, there are many other kinds of problems like this.

\n

For example, spikes in CPU usage, process hangs, application deadlocks, handle leaks, and even depletion of the system’s memory pools can all be investigated by analyzing dump files.

\n

When you investigate these problems, you can enjoy dump file analysis with approaches that differ yet again from those used for crashes and memory leaks.

\n

Unfortunately, Vol.1 cannot cover these analysis methods, but if you want to learn Windows dump file analysis more deeply, I recommend reproducing various troubles with tools such as Crash Me from “Welcome to WinDbg.info” and NotMyFault, then obtaining and analyzing dump files.

\n
\n

Crash Me:

\n

http://windbg.info/

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

    Bug Check 0xE2:MANUALLY_INITIATED_CRASH https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/bug-check-0xe2—manually-initiated-crash

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

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

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

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

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

    MEX extension https://www.microsoft.com/en-us/download/details.aspx?id=53304

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

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

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

    Advanced Windows registry information for power users https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/performance/windows-registry-advanced-users

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

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

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

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

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

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

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

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

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

    !for_each_process extension command https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-for-each-process

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

    Displaying a stack backtrace with k, kb, kc, kd, kp, kP, and kv https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/k—kb—kc—kd—kp—kp—kv—display-stack-backtrace-

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

    Setting register context with .thread https://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/-thread—set-register-context-

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

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

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

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

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

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

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