New
#11
I have never been able to open a .dmp out of a zip archive - nor have I spent any significant time trying to figure this out..
Nor have I ever setup my system to open .dmp files with WinDbg or kd.exe Inor have I setup the file association for .dmp).
I am unable to drag/drop a .dmp from a zip archive into WinDbg - and never have been able to do so as long as explorer.exe has supported opening zip archives
My workaround is to drag the .dmp files out of the zip archive and into my BSOD analysis directory - and then run kd.exe/WinDbg from there..
This behavior didn't change when I upgraded to the new Win10 tools. But, I have to wonder if the tight integration of WinDbg with Visual Studio may have affected the way that the debugger is setup on your system.
FYI - I am not a WinDbg expert. I use a relatively few commands to extract info from the dump files. Those that are more familiar with the debugger will generally request full/kernel dumps. I don't do that because the amount of work/time spent on coaxing info out of full/kernel dumps isn't very productive and (IME) rarely results in helping users. The extra commands/functions are very useful for driver developers - but users generally can't fix the things that driver developers are looking for.
Strange.....all I do is double-click the .dmp in the zip file and it opens in WinDBG. No buggering about required.
Attachment 16848
I'll have to give these different methods a shot.
There's a couple of issues present here:
- the ability to run a memory dump out of an archive (which may have changed since I last tried it - or I may have goofed in my assessment of the problem).
- the ability to open a .dmp file in a particular program.
My primary debugger is kd.exe, which I use in the scripts that run multiple memory dumps on my system.
As such my system will be configured a bit differently than those who use WinDbg primarily.
Also, I look at the reports in the archive while my system is running the memory dumps.
As I open most reports in File Explorer, it's easy for me to drag and drop the dump files into the directory that I run dumps from (using kd.exe)
And, for those that are uploaded in other archive formats, I use Universal Extractor and then proceed with the results in File Explorer as I described in the previous sentence.
In short, "Nothing succeeds like success." If it works for you, that's all that counts.
Usasma also thinks it? ? ? Thank god!!!
Who cares the rest of the world then!!!
If you would know what I want to say and if I could explain it to you what I want to mean, but what I can say in a single word that it is extremely relieving to me, much more relieving than anything else.
Two of my BSOD troubleshooting philosophies put me in my worst. I lost friends, I got attacked, but I never left them. Now one of them got supported by my hero.
I thank God that you posted this post.
If you are not an expert, the word "expert" does not exist, at least to me.
The second philosophy is, a stop 0x124 does not necessarily mean a processor failure. I am not ready to believe that all those machine check exceptions are caused only by processor failure, at any cost; whatever windbg output you may show me.
What is your thinking about it, John? Please let me know?
If anyone is interested, I've found a subtle difference between Windbg 6.12 and 10.0
!analyze -v seems to give much more detailed information
6.12
10.0Code:2: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffffb000c4780000, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff8006ccf0825, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000000, (reserved) Debugging Details: ------------------ Could not read faulting driver name READ_ADDRESS: ffffb000c4780000 FAULTING_IP: Ntfs!memmove+a5 fffff800`6ccf0825 f30f6f4c0a10 movdqu xmm1,xmmword ptr [rdx+rcx+10h] MM_INTERNAL_CODE: 0 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x50 PROCESS_NAME: System CURRENT_IRQL: 0 TRAP_FRAME: ffffd000274d7f40 -- (.trap 0xffffd000274d7f40) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=000000000000ffff rbx=0000000000000000 rcx=ffffb000c477ff00 rdx=00000000000000f0 rsi=0000000000000000 rdi=0000000000000000 rip=fffff8006ccf0825 rsp=ffffd000274d80d8 rbp=ffffb000c4747000 r8=0000000000000008 r9=0000000007ffe38b r10=ffffe001e697ba28 r11=ffffb000c4747098 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc Ntfs!memmove+0xa5: fffff800`6ccf0825 f30f6f4c0a10 movdqu xmm1,xmmword ptr [rdx+rcx+10h] ds:0180:ffffb000`c4780000=???????????????????????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80378e0105e to fffff80378dd1ca0 STACK_TEXT: ffffd000`274d7cd8 fffff803`78e0105e : 00000000`00000050 ffffb000`c4780000 00000000`00000000 ffffd000`274d7f40 : nt!KeBugCheckEx ffffd000`274d7ce0 fffff803`78cd4839 : 00000000`00000000 ffffe001`e4f06040 ffffd000`274d7f40 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x1ee9e ffffd000`274d7d80 fffff803`78ddbf2f : 00000000`00000000 00000000`00000098 00000000`00000000 00000000`00000000 : nt!MmAccessFault+0x769 ffffd000`274d7f40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x12f STACK_COMMAND: .bugcheck ; kb FOLLOWUP_IP: Ntfs!memmove+a5 fffff800`6ccf0825 f30f6f4c0a10 movdqu xmm1,xmmword ptr [rdx+rcx+10h] SYMBOL_NAME: Ntfs!memmove+a5 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Ntfs IMAGE_NAME: Ntfs.sys DEBUG_FLR_IMAGE_TIMESTAMP: 54387b6b FAILURE_BUCKET_ID: X64_0x50_Ntfs!memmove+a5 BUCKET_ID: X64_0x50_Ntfs!memmove+a5 Followup: MachineOwner ---------
Much more information and a larger Stack...Code:2: 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: ffffb000c4780000, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff8006ccf0825, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000000, (reserved) Debugging Details: ------------------ Could not read faulting driver name SYSTEM_SKU: LENOVO_MT_20354_BU_idea_FM_Lenovo Z50-70 SYSTEM_VERSION: Lenovo Z50-70 BIOS_DATE: 10/20/2014 BASEBOARD_PRODUCT: Lancer 5A5 BASEBOARD_VERSION: 31900058WIN BUGCHECK_P1: ffffb000c4780000 BUGCHECK_P2: 0 BUGCHECK_P3: fffff8006ccf0825 BUGCHECK_P4: 0 READ_ADDRESS: ffffb000c4780000 FAULTING_IP: Ntfs!memcpy+a5 fffff800`6ccf0825 f30f6f4c0a10 movdqu xmm1,xmmword ptr [rdx+rcx+10h] MM_INTERNAL_CODE: 0 CPU_COUNT: 4 CPU_MHZ: a22 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 45 CPU_STEPPING: 1 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: System CURRENT_IRQL: 0 ANALYSIS_VERSION: 10.0.10041.3 amd64fre TRAP_FRAME: ffffd000274d7f40 -- (.trap 0xffffd000274d7f40) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=000000000000ffff rbx=0000000000000000 rcx=ffffb000c477ff00 rdx=00000000000000f0 rsi=0000000000000000 rdi=0000000000000000 rip=fffff8006ccf0825 rsp=ffffd000274d80d8 rbp=ffffb000c4747000 r8=0000000000000008 r9=0000000007ffe38b r10=ffffe001e697ba28 r11=ffffb000c4747098 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc Ntfs!memcpy+0xa5: fffff800`6ccf0825 f30f6f4c0a10 movdqu xmm1,xmmword ptr [rdx+rcx+10h] ds:ffffb000`c4780000=???????????????????????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80378e0105e to fffff80378dd1ca0 STACK_TEXT: ffffd000`274d7cd8 fffff803`78e0105e : 00000000`00000050 ffffb000`c4780000 00000000`00000000 ffffd000`274d7f40 : nt!KeBugCheckEx ffffd000`274d7ce0 fffff803`78cd4839 : 00000000`00000000 ffffe001`e4f06040 ffffd000`274d7f40 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x1ee9e ffffd000`274d7d80 fffff803`78ddbf2f : 00000000`00000000 00000000`00000098 00000000`00000000 00000000`00000000 : nt!MmAccessFault+0x769 ffffd000`274d7f40 fffff800`6ccf0825 : fffff800`6cd96c76 ffffb000`c4747098 ffffc001`79635010 00000000`08707000 : nt!KiPageFault+0x12f ffffd000`274d80d8 fffff800`6cd96c76 : ffffb000`c4747098 ffffc001`79635010 00000000`08707000 ffffb000`c4747098 : Ntfs!memcpy+0xa5 ffffd000`274d80e0 fffff800`6ce725e4 : ffffd000`274d86b0 fffff803`78cb85bf ffffd000`274d8880 ffffd000`274d8590 : Ntfs!NtfsDeleteAttributeRecord+0x142 ffffd000`274d8180 fffff800`6ce784c5 : ffffb000`c4747098 ffffd000`274d82d0 ffffe001`e4f30180 ffffb000`c4747400 : Ntfs!NtfsRepairDeleteAttribute+0x90 ffffd000`274d81d0 fffff800`6ce6c459 : ffffc001`79635140 00000000`00000000 ffffe001`f192a260 ffffd000`274d86b0 : Ntfs!NtfsVerifyAndFixFileRecord+0x671 ffffd000`274d8480 fffff800`6ce73b0d : ffffd000`274d8880 00000000`00000000 fffff800`6cdc36c0 00000000`000007df : Ntfs!NtfsProcessRepairVerbBadFRS+0x691 ffffd000`274d8630 fffff800`6cd0d3f5 : ffffe001`e4f31702 ffffe001`e4f30180 ffffe001`e4f30180 00000000`00000000 : Ntfs!NtfsRepairItem+0x5a7 ffffd000`274d8b70 fffff803`78d8136c : ffffe001`e4f47c40 ffffe001`ef8db080 00000000`00000080 ffffe001`e5caa8d8 : Ntfs!NtfsProcessRepairQueue+0x245 ffffd000`274d8c00 fffff803`78dd82c6 : fffff803`78f84180 ffffe001`ef8db080 ffffe001`f1ba6500 fffff803`78d421e8 : nt!PspSystemThreadStartup+0x58 ffffd000`274d8c60 00000000`00000000 : ffffd000`274d9000 ffffd000`274d3000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_IP: Ntfs!memcpy+a5 fffff800`6ccf0825 f30f6f4c0a10 movdqu xmm1,xmmword ptr [rdx+rcx+10h] SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: Ntfs!memcpy+a5 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Ntfs IMAGE_NAME: Ntfs.sys DEBUG_FLR_IMAGE_TIMESTAMP: 54387b6b IMAGE_VERSION: 6.3.9600.17399 BUCKET_ID_FUNC_OFFSET: a5 FAILURE_BUCKET_ID: AV_Ntfs!memcpy BUCKET_ID: AV_Ntfs!memcpy PRIMARY_PROBLEM_CLASS: AV_Ntfs!memcpy ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:av_ntfs!memcpy FAILURE_ID_HASH: {aa969c68-5663-a25d-b5d0-944f50187a22} Followup: MachineOwner ---------
Im sure Im not the first to discover this but I thought it was interesting.
I don't know of a way to specifically update Windbg but Im far from the person to know that, lol.
You can get 10.0 here via SDK for Win 10
Windows Driver Kit (WDK) and Debugging Tools for Windows (WinDbg) downloads