Windows 10: How to read output from WinDBG of dump file to determine root cause of recent crash?

AlexOnDAX_1 · May 31, 2019

I somewhat frequently have random crashes at night when I'm not using my PC that are unrelated to Windows Update. I check the event log and it's "WER-SystemErrorReporting" - 1001 rebooting from a bugcheck. I built the PC myself and it's 6 months old with all brand new top of the line components...no overclocking, vanilla config.

Using WinDBG with the command `!analyize -v` I'm not able to make heads or tails of the output. It looks like a kernel crash with an invalid pointer. My gut tells me it might be related to my graphics card...but not sure.

Here is a link to the minidump and the output is below: https://1drv.ms/u/s!Apb-0nSp-ptA9V5HgQTPgmtoeVeZ

Microsoft (R) Windows Debugger Version 10.0.18869.1002 AMD64

Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]

Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.

************* Path validation summary **************

Response Time (ms) Location

Deferred srv*

Symbol search path is: srv*

Executable search path is:

Windows 10 Kernel Version 18362 MP (32 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 18362.1.amd64fre.19h1_release.190318-1202

Machine Name:

Kernel base = 0xfffff800`64e00000 PsLoadedModuleList = 0xfffff800`652432b0

Debug session time: Thu May 30 21:14:15.127 2019 (UTC - 7:00)

System Uptime: 0 days 11:33:17.796

Loading Kernel Symbols

...............................................................

........Page 20434b9 not present in the dump file. Type ".hh dbgerr004" for details

........................................................

................................................................

......................

Loading User Symbols

Loading unloaded module list

..............

For analysis of this file, run !analyze -v

nt!KeBugCheckEx:

fffff800`64fbc8a0 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffff800`69b00c70=00000000000001ca

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

SYNTHETIC_WATCHDOG_TIMEOUT (1ca)

A system wide watchdog has expired. This indicates that the system

is hung and not processing timer ticks.

Arguments:

Arg1: 000000001b39cd12, The time since the watchdog was last reset, in interrupt time.

Arg2: 00000061186695e2, The current interrupt time.

Arg3: 000000611869a42e, The current QPC timestamp.

Arg4: 0000000000000004, The index of the clock processor.

Debugging Details:

------------------

KEY_VALUES_STRING: 1

Key : Analysis.CPU.Sec

Value: 7

Key : Analysis.Elapsed.Sec

Value: 9

Key : Analysis.Memory.CommitPeak.Mb

Value: 77

PROCESSES_ANALYSIS: 1

SERVICE_ANALYSIS: 1

STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1

DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING: 18362.1.amd64fre.19h1_release.190318-1202

SYSTEM_PRODUCT_NAME: To Be Filled By O.E.M.

SYSTEM_SKU: To Be Filled By O.E.M.

SYSTEM_VERSION: To Be Filled By O.E.M.

BIOS_VENDOR: American Megatrends Inc.

BIOS_VERSION: P3.30

BIOS_DATE: 08/14/2018

BASEBOARD_MANUFACTURER: ASRock

BASEBOARD_PRODUCT: X399 Taichi

BASEBOARD_VERSION:

DUMP_TYPE: 1

BUGCHECK_P1: 1b39cd12

BUGCHECK_P2: 61186695e2

BUGCHECK_P3: 611869a42e

BUGCHECK_P4: 4

CPU_COUNT: 20

CPU_MHZ: da5

CPU_VENDOR: AuthenticAMD

CPU_FAMILY: 17

CPU_MODEL: 8

CPU_STEPPING: 2

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x1CA

PROCESS_NAME: System

CURRENT_IRQL: f

ANALYSIS_SESSION_HOST: MyComputerName

ANALYSIS_SESSION_TIME: 05-31-2019 08:50:54.0461

ANALYSIS_VERSION: 10.0.18869.1002 amd64fre

BAD_STACK_POINTER: fffff80069b00c68

LAST_CONTROL_TRANSFER: from fffff800658e6315 to fffff80064fbc8a0

STACK_TEXT:

fffff800`69b00c68 fffff800`658e6315 : 00000000`000001ca 00000000`1b39cd12 00000061`186695e2 00000061`1869a42e : nt!KeBugCheckEx

fffff800`69b00c70 fffff800`658d039a : 00000061`1869a42e 00000000`00000001 fffff800`65150614 00000000`00000082 : hal!HalpWatchdogCheckPreResetNMI+0xd5

fffff800`69b00cb0 fffff800`650a1e8b : 00000000`00000001 00000061`18483c1b fffff800`62eae180 fffff800`650b2f10 : hal!HalpPreprocessNmi+0x114ea

fffff800`69b00ce0 fffff800`64fc7d42 : 00000000`00000001 fffff800`69b00ef0 00000000`00000000 00000000`00000000 : nt!KiProcessNMI+0xcb

fffff800`69b00d30 fffff800`64fc7b11 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxNmiInterrupt+0x82

fffff800`69b00e70 fffff800`65100bce : 00000000`00000000 00008494`9de72f0a 00000000`00000000 00000061`18483c1b : nt!KiNmiInterrupt+0x211

fffff800`69ae77a0 fffff800`64e21cdc : fffff800`65100bf0 00000000`00000000 ffff998b`cc41d060 00000000`00000071 : nt!PpmIdleGuestExecute+0x1e

fffff800`69ae77e0 fffff800`64e2142e : 00000000`00000003 00000000`00000002 00000000`00000001 00000000`00000000 : nt!PpmIdleExecuteTransition+0x70c

fffff800`69ae7b00 fffff800`64fc0328 : 00000000`00000000 fffff800`62eae180 ffff998b`c833e040 00000000`00001784 : nt!PoIdle+0x36e

fffff800`69ae7c60 00000000`00000000 : fffff800`69ae8000 fffff800`69ae2000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x48

THREAD_SHA1_HASH_MOD_FUNC: cb522721ccf98392c0a19a23914952c2ac4c66ec

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 820b90a5d7e9eccb2fa0a02e4a9162d0c9225d80

THREAD_SHA1_HASH_MOD: 77e3653e8f322fbd447ccc02351d9fed3c4e96be

FOLLOWUP_IP:

nt!KiProcessNMI+cb

fffff800`650a1e8b 488b3dce801a00 mov rdi,qword ptr [nt!KiNmiCallbackListHead (fffff800`65249f60)]

FAULT_INSTR_CODE: ce3d8b48

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!KiProcessNMI+cb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: cb

FAILURE_BUCKET_ID: 0x1CA_STACKPTR_ERROR_nt!KiProcessNMI

BUCKET_ID: 0x1CA_STACKPTR_ERROR_nt!KiProcessNMI

PRIMARY_PROBLEM_CLASS: 0x1CA_STACKPTR_ERROR_nt!KiProcessNMI

TARGET_TIME: 2019-05-31T04:14:15.000Z

OSBUILD: 18362

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: unknown_date

BUILDDATESTAMP_STR: 190318-1202

BUILDLAB_STR: 19h1_release

BUILDOSVER_STR: 10.0.18362.1.amd64fre.19h1_release.190318-1202

ANALYSIS_SESSION_ELAPSED_TIME: 25d3

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x1ca_stackptr_error_nt!kiprocessnmi

FAILURE_ID_HASH: {09a889cd-f940-6da5-9668-0c0c98a7d643}

Followup: MachineOwner

---------

:)

PeterNapoli · May 31, 2019

Windows 10 - Interpreting two BSOD Crash Mini Dump Files

After reinstalling Windows 10 stable release over the Windows 10 Insider Preview OS I had two separate BSOD crashes. I ran them both through WinDbg and have links to the plain text of the Windbg !analyze -v outputs.

BSOD Error Mini-Dump File #1 (Think it's something to do with Broadcom Driver) - Solutions?

Win 10 Crash Mini-Dump Output#1

BSOD Error Mini-Dump File #2 (This one is FREAKING ME OUT because it's saying something about memory corruption?!) - Cause?/Hardware?/Software? - because maybe I installed Windows 10 on top
of Windows 10 Insider (not a clean install)--- most importantly.... Solutions?!?

Win 10 Crash Mini-Dump File #2

Thank you all!

Brink · May 31, 2019

VulnScan - Automated Triage & Root Cause Analysis of Memory Corruption

The Microsoft Security Response Center (MSRC) receives reports about potential vulnerabilities in our products and it’s the job of our engineering team to assess the severity, impact, and root cause of these issues. In practice, a significant proportion of these reports turn out to be memory corruption issues. In order to root cause these issues, an MSRC security engineer typically needs to analyze the crash and try to understand what went wrong. This workflow isn’t unique to externally reported vulnerabilities; vulnerabilities that are discovered internally through fuzzing and variant investigation are also typically memory corruption issues and these need to be triaged and assessed for exploitability too.

For these reasons, MSRC has made significant investments over the course of many years to build tooling that helps us automate the root cause analysis process. VulnScan is a tool designed and developed by MSRC to help security engineers and developers determine the vulnerability type and root cause of memory corruption bugs. It is built on top of two internally developed tools: Debugging Tools for Windows (WinDbg) and Time Travel Debugging (TTD).

WinDbg is Microsoft's Windows debugger that has recently received a user interface makeover to make it even easier to use. You can find more information about the new WinDbg Preview version here.

Time Travel Debugging is an internally developed framework that records and replays execution of Windows applications. This technology was released during CPPCon 2017.

By leveraging WinDbg and TTD, VulnScan is able to automatically deduce the root cause of the most common types of memory corruption issues. Application Verifier’s mechanism called PageHeap is used to trigger an access violation closer to the root cause of the issue. The analysis starts from the crash location and progresses towards the root cause. Classes of memory corruption issues supported by VulnScan:
Click to expand...

Read more: VulnScan - Automated Triage and Root Cause Analysis of Memory Corruption Issues Defense

Arc · May 31, 2019

How do I read the .zip file given in the BSoD

You mean the zip created by the DM Log Collector?

There are three types of files in the zip.Those are .txt, .nfo and .dmp.

To open the zip itself, use either Windows Explorer or 7-zip.

To read the text files (.txt), use notepad.

To read the system information files (.nfo), use MSINFO32.

To read the crash dumps (.dmp), use Windbg.

Windows 10: How to read output from WinDBG of dump file to determine root cause of recent crash?

How to read output from WinDBG of dump file to determine root cause of recent crash?

How to read output from WinDBG of dump file to determine root cause of recent crash?

How to read output from WinDBG of dump file to determine root cause of recent crash?

How to read output from WinDBG of dump file to determine root cause of recent crash? - Similar Threads - read output WinDBG

Is there a way to identify the root cause of the BSOD when there's no crash dump file?

Is there a way to identify the root cause of the BSOD when there's no crash dump file?

Is there a way to identify the root cause of the BSOD when there's no crash dump file?

How to read output from WinDBG of dump file to determine root cause of recent crash?

How to read output from WinDBG of dump file to determine root cause of recent crash?

How to read output from WinDBG of dump file to determine root cause of recent crash?

Can't determine root cause of BSOD

Can't determine root cause of BSOD

Can't determine root cause of BSOD

Users found this page by searching for:

FAILURE_ID_HASH_STRING: km:0x1ca_stackptr_error_nt!kiprocessnmi FAILURE_ID_HASH: {09a889cd-f940-6da5-9668-0c0c98a7d643} Followup: MachineOwner

how to understand WinDbg output

windbg log file reading online