Windows 10: Install and Configure WinDBG for BSOD Analysis

Thanks Derek I shall have to get into that and what Martijn wanted I opened this dump three times and each time it got quicker because the initial opening of a dump takes ages - I hope this is what is needed.
Code: Microsoft (R) Windows Debugger Version 10.0.10586.567 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\John\AppData\Local\Temp\Temp1_DESKTOP-REO3G45-2016_06_30_152907_92.zip\062816-13671-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: srv* Executable search path is: Windows 10 Kernel Version 10586 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 10586.420.amd64fre.th2_release_sec.160527-1834 Machine Name: Kernel base = 0xfffff801`8ee07000 PsLoadedModuleList = 0xfffff801`8f0e5cf0 Debug session time: Wed Jun 29 07:25:01.179 2016 (UTC + 10:00) System Uptime: 0 days 0:00:49.988 Loading Kernel Symbols . Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. .............................................................. ................................................................ ............................................ Loading User Symbols Loading unloaded module list .......... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 50, {ffffcfffd8a8e950, 2, fffff80019aa31de, 2} Could not read faulting driver name Probably caused by : memory_corruption Followup: memory_corruption --------- 3: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffffcfffd8a8e950, memory referenced. Arg2: 0000000000000002, value 0 = read operation, 1 = write operation. Arg3: fffff80019aa31de, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000002, (reserved) Debugging Details: ------------------ Could not read faulting driver name DUMP_CLASS: 1 DUMP_QUALIFIER: 400 BUILD_VERSION_STRING: 10586.420.amd64fre.th2_release_sec.160527-1834 SYSTEM_MANUFACTURER: System manufacturer SYSTEM_PRODUCT_NAME: P5K3 Deluxe SYSTEM_SKU: To Be Filled By O.E.M. SYSTEM_VERSION: System Version BIOS_VENDOR: American Megatrends Inc. BIOS_VERSION: 1206 BIOS_DATE: 04/16/2009 BASEBOARD_MANUFACTURER: ASUSTeK Computer INC. BASEBOARD_PRODUCT: P5K3 Deluxe BASEBOARD_VERSION: Rev 1.xx DUMP_TYPE: 2 BUGCHECK_P1: ffffcfffd8a8e950 BUGCHECK_P2: 2 BUGCHECK_P3: fffff80019aa31de BUGCHECK_P4: 2 READ_ADDRESS: fffff8018f185520: Unable to get MiVisibleState ffffcfffd8a8e950 FAULTING_IP: dxgkrnl!DxgkDestroyAllocationHelper+ce fffff800`19aa31de 0f9280000000b8 setb byte ptr [rax-48000000h] MM_INTERNAL_CODE: 2 CPU_COUNT: 4 CPU_MHZ: 965 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: f CPU_STEPPING: 7 CPU_MICROCODE: 6,f,7,0 (F,M,S,R) SIG: 6A'00000000 (cache) 6A'00000000 (init) CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: CODE_CORRUPTION BUGCHECK_STR: AV PROCESS_NAME: LogonUI.exe CURRENT_IRQL: 0 ANALYSIS_SESSION_HOST: DESKTOP-9I73FSG ANALYSIS_SESSION_TIME: 07-07-2016 12:58:26.0804 ANALYSIS_VERSION: 10.0.10586.567 amd64fre TRAP_FRAME: ffffd00020a8e5b0 -- (.trap 0xffffd00020a8e5b0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=ffffd00020a8e950 rbx=0000000000000000 rcx=ffffd00020a8e950 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80019aa31de rsp=ffffd00020a8e740 rbp=ffffd00020a8e840 r8=0000000000000000 r9=0000000000000001 r10=0000000000000000 r11=fffff80019a323c3 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po cy dxgkrnl!DxgkDestroyAllocationHelper+0xce: fffff800`19aa31de 0f9280000000b8 setb byte ptr [rax-48000000h] ds:ffffcfff`d8a8e950=?? Resetting default scope LAST_CONTROL_TRANSFER: from fffff8018ef765c1 to fffff8018ef497a0 STACK_TEXT: ffffd000`20a8e358 fffff801`8ef765c1 : 00000000`00000050 ffffcfff`d8a8e950 00000000`00000002 ffffd000`20a8e5b0 : nt!KeBugCheckEx ffffd000`20a8e360 fffff801`8ee72621 : 00000000`00000002 00000000`00000000 ffffd000`20a8e5b0 ffffe000`4e1e6700 : nt! ?? ::FNODOBFM::`string'+0x1e3c1 ffffd000`20a8e450 fffff801`8ef52abc : ffffd000`50488180 00000000`00000001 ffffd000`5048eb40 ffffe000`4e1e6700 : nt!MmAccessFault+0x5f1 ffffd000`20a8e5b0 fffff800`19aa31de : ffffe000`4e523840 ffffd000`50488180 ffffd000`50494bc0 00000000`00000000 : nt!KiPageFault+0x13c ffffd000`20a8e740 fffff800`19b574b9 : 00000000`00000020 00000265`203ccf08 00000094`e937eb70 ffffc001`2f496d70 : dxgkrnl!DxgkDestroyAllocationHelper+0xce ffffd000`20a8eba0 fffff801`8ef540a3 : 00000000`00000020 00000000`00000020 00000000`00000000 00000265`203ccf08 : dxgkrnl!DxgkDestroyAllocation+0xd9 ffffd000`20a8ec40 00007ffd`9fcb4424 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000094`e937e8b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffd`9fcb4424 STACK_COMMAND: kb CHKIMG_EXTENSION: !chkimg -lo 50 -db !dxgkrnl 2 errors : !dxgkrnl (fffff80019aa31df-fffff80019aa33df) fffff80019aa31d0 04 00 00 45 8b fc 45 8d 75 02 41 83 fc 41 0f *92 ...E..E.u.A..A.. ... fffff80019aa33d0 38 ff 15 29 3d fd ff 85 c0 75 1b 48 8d 4e 38 *55 8..)=....u.H.N8U MODULE_NAME: memory_corruption IMAGE_NAME: memory_corruption FOLLOWUP_NAME: memory_corruption DEBUG_FLR_IMAGE_TIMESTAMP: 0 MEMORY_CORRUPTOR: STRIDE FAILURE_BUCKET_ID: MEMORY_CORRUPTION_STRIDE BUCKET_ID: MEMORY_CORRUPTION_STRIDE PRIMARY_PROBLEM_CLASS: MEMORY_CORRUPTION_STRIDE TARGET_TIME: 2016-06-28T21:25:01.000Z OSBUILD: 10586 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: 2016-05-28 13:59:07 BUILDDATESTAMP_STR: 160527-1834 BUILDLAB_STR: th2_release_sec BUILDOSVER_STR: 10.0.10586.420.amd64fre.th2_release_sec.160527-1834 ANALYSIS_SESSION_ELAPSED_TIME: 1e5b ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:memory_corruption_stride FAILURE_ID_HASH: {574dbc1b-92cb-fb09-cb7a-cacc1bb2c511} Followup: memory_corruption[/quote]

 

Yeah, that looks good. I think he thought you were having symbol errors instead of the zip file problem.

His suggestion to open various dumps was to get the symbol server building a cache, so that's a good thing anyway.

 

Ok mate I usually look at dumps of various captures too. It is just such a lot to take in.

 

I know it is a lot, that's just because it gets complex, but if you just focus on the basics I pointed out you'll at least have a good idea of what may be causing them.

 

Recently, when opening a dump. it hangs for a long time, like several minutes (3 to 5) here:

Code: Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [F:\Temp\Dumps\AK4774\083116-25609-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred SRV*G:\Symbols*Symbol information Symbol search path is: SRV*G:\Symbols*Symbol information Executable search path is: Windows 8 Kernel Version 14393 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 14393.82.amd64fre.rs1_release.160805-1735 Machine Name: Kernel base = 0xfffff800`d3c03000 PsLoadedModuleList = 0xfffff800`d3f08060 Debug session time: Wed Aug 31 00:09:55.374 2016 (UTC - 4:00) System Uptime: 0 days 15:22:08.115 Loading Kernel Symbols . Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. .............................................................. ................................................................ ................................................. Loading User Symbols[/quote] After that is shows:
Code: Loading unloaded module list .................................................. *** WARNING: Unable to verify timestamp for netr28ux.sys *** ERROR: Module load completed but symbols could not be loaded for netr28ux.sys ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 1000007E, {ffffffffc0000005, fffff80626d88d1f, ffffc781fd5642e8, ffffc781fd563b10}[/quote] and sites there for another few then I finally get:
Code: Probably caused by : netr28ux.sys ( netr28ux+1d8d1f ) Followup: MachineOwner[/quote] Over all take 5 to 10 minutes before I can start looking at a dump.

My Symbol folder, G:\Symbols is pretty well populated as it's 1.08GB in size and was setup initially on 3/231/2016.

Anyone have any ideas on how to fix this?

Edit: Just noticed it says Downloading symbols for [ntkrnlmp.pdb] at bottom left of windbg window and sits there for a long time. Is this a Windows Symbol Server problem?

Would downloading ad populating the folder with all Windows 10 symbols help this?

 

Hi Rich,

I have the same problem, but I can add that I may have some symbol corruption too because my symbol folder is more than 5GB where I lately frequently get the messages that certain Windows kernel files failed to load in the initialization part.

Why it takes this long could be because of new symbols that need to be downloaded with the 1607 version.

 

I have an issue with WinDBG being incredibly slow after installing a new version. Any help apreciated. Link to detailed thread I made here.

 

I downloaded all the Windows 10 symbols, 32 and 64 bit as .msi files and installed them.
Came out to 55.1GB on disk. Set that folder as the symbol file folder.
windbg still very, very slow.

My normal Symbol File Path is SRV*G:\Symbols*Symbol information.
I changed it to SRV*G:\Symbols and windbg ran fast. Dump loaded and got to the

Followup: memory_corruption
---------

part in 3-5 seconds. Problem is definitely the Microsoft Symbol Server.

 

So what's "Normal" for the time to open the test dmp file. I get as far as the BugCheck 24 line and then it's just been sitting there for quite a while.

Anyone want to analyze a file for me while I wait? *Smile

092616-30609-01.zip

 

You can try this from ztruker,

I haven't tried it yet, but it is doing the same thing for me sitting like that.

That dump is 1kb, its useless for anything.

 

Also change the symbol path from htto:// to https://

Made a big difference for me.

 

I tried to do this, but when I open the .dmp file I get an error that says could not open file, access denied... The file does not appear to be corrupt, is not 0 kb, and I have several .dmp files that get the same thing. I took ownership of the folder, but still access denied. Any ideas? Thanks

 

Are you trying to open them from the C:\Minidump folder? Move them to the desktop or somewhere else out of the root C: drive.

 

As @derekimo says, move the files out of the folder.

Dumps from C:\Windows and C:\Windows\Minidump cannot be opened unless you move them to another location.
Taking ownership of the folder, as you noticed, won't help.

 

That worked, thanks! Maybe there should be a note in the tutorial about this?