New
#20
Done, used zip compression.
WinDBG - The Basics for Debugging Crash Dumps in Windows 10
-
-
New #21
Hello,
My WinDBG module list shows some drivers with a date of January 1970,someone told that there is an issue with a configuration or something.Generally the drivers with the date of January 1970 are drivers from MS itself AFAIK.Can someone help with this issue ?
-
New #22
It is the same for me and my Windbg is certainly properly configured, IMO I wouldn't call it something to be worried about.
-
-
-
New #25
I would be careful in assuming that because a third-party driver is present in a call stack, that it may be a cause of the issue. The drivers which appear in the call stack are simply drivers which were present at the time of the crash.
The same principle applies to checking the PROCESS_NAME variable in the dump file, it simply indicates the last running process and does not mean that the process was the cause of the crash.
I would also like to mention that the line "memory_corruption" within a dump line, does not necessarily mean that there are issue with the RAM; it is more commonly a driver issue than a hardware issue. Typically, a poorly written driver has been performing operations on memory addresses which are invalid for some reason or another. For example, writing onto pool locations which have been reserved for another process.
-
New #26
I'm not sure what you reference with 'that', but Windows catches crashes at times a violation occurs. Often this is because the driver in the stack makes a violation, may it be a due to a write violation on the pool of a thread from another process like you say or because a driver reads from memory which it already deallocated.
-
New #27
I'll put the calls on the stack in consideration first, and then evaluate if the third-party driver may be a cause. I've seen call stacks which were full of third-party drivers, and none of which, were the exact cause of the crash.
-
New #28
Most I've seen are like this, not much to investigate on.
(Created this from different dumps)Code:0: kd> knL # Child-SP RetAddr Call Site 00 fffff802`fc383848 fffff802`fa7ded29 nt!KeBugCheckEx 02 fffff802`fc383990 fffff802`fa6bbb89 nt!KiPageFault+0x247 03 fffffa80`0c0891a0 fffff880`03bd2670 ZTEusbnet+0x35dd
-
-
New #29
Do you use any custom debugger extensions to do call stack unwinds? The !dpx debugger extension is quite good:
Here's the output from a NotMyFault dump:Code:0: kd> !load ProcDumpExt ========================================================================================= ProcDumpExt v6.4 - Copyright 2013 Andrew Richards =========================================================================================
Code:0: kd> !dpx Start memory scan : 0xa4847b24 ($csp) End memory scan : 0xa4848000 (Stack Base) ReadVirtual: 83168d20 not properly sign extended ReadVirtual: 83168d20 not properly sign extended ReadVirtual: 83175f84 not properly sign extended ReadVirtual: 83175f84 not properly sign extended ReadVirtual: a4847b3c not properly sign extended ReadVirtual: a4847b3c not properly sign extended ReadVirtual: 8307eb7f not properly sign extended ReadVirtual: 8307eb7f not properly sign extended ReadVirtual: a4847b24 not properly sign extended ReadVirtual: a4847b24 not properly sign extended ReadVirtual: ffff0ff0 not properly sign extended ReadVirtual: ffff0ff0 not properly sign extended ReadVirtual: 8001003b not properly sign extended ReadVirtual: 8001003b not properly sign extended ReadVirtual: c31b4008 not properly sign extended ReadVirtual: c31b4008 not properly sign extended ReadVirtual: de4e9780 not properly sign extended ReadVirtual: de4e9780 not properly sign extended ReadVirtual: 80b95000 not properly sign extended ReadVirtual: 80b95000 not properly sign extended ReadVirtual: 80b95400 not properly sign extended ReadVirtual: 80b95400 not properly sign extended *** ERROR: Module load completed but symbols could not be loaded for myfault.sys 0xa4847b34 : 0xa719a5ab : myfault+0x5ab 0xa4847b3c : 0xa4847bb8 : Trap @ a4847b3c 0xa4847b40 : 0xa719a5ab : myfault+0x5ab 0xa4847ba4 : 0xa719a5ab : myfault+0x5ab 0xa4847bbc : 0xa719a9db : myfault+0x9db 0xa4847bc8 : 0xa719ab26 : myfault+0xb26 0xa4847be4 : 0x83360018 : nt!PopSleepDeviceList+0x13b 0xa4847c00 : 0x83074c1e : nt!IofCallDriver+0x63 0xa4847c18 : 0x83268bf9 : nt!IopSynchronousServiceTail+0x1f8 0xa4847c38 : 0x8326bde2 : nt!IopXxxControlFile+0x6aa 0xa4847c54 : 0x82364eb5 : ndiswan!DeactivateRoute+0x161 0xa4847c60 : 0x832b274f : nt!NtDeviceIoControlFile 0xa4847c78 : 0x831229b7 : nt!MiCheckUserVirtualAddress+0xb3 0xa4847cb8 : 0xa4847c54 : 0x82364eb5 : ndiswan!DeactivateRoute+0x161 0xa4847cc4 : 0x830fe6f0 : nt!_except_handler4 0xa4847cd4 : 0x832b2779 : nt!NtDeviceIoControlFile+0x2a 0xa4847cec : 0x83360018 : nt!PopSleepDeviceList+0x13b 0xa4847d08 : 0x8307b8c6 : nt!KiSystemServicePostCall 0xa4847d20 : 0x83360018 : nt!PopSleepDeviceList+0x13b
QuoteTutorial Categories
Related Discussions
