 | |
| |
| 30 Jan 2011 | #1 |
| | Weird Dump File Result. When analyzing dump files and I get this: Code: Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\DOWNLOADS\012911-20248-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\XSymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.20738.amd64fre.win7_ldr.100618-1621
Machine Name:
Kernel base = 0xfffff800`03c65000 PsLoadedModuleList = 0xfffff800`03e99eb0
Debug session time: Sat Jan 29 15:22:02.793 2011 (UTC + 0:00)
System Uptime: 0 days 0:41:40.603
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 124, {0, fffffa80047e4028, b2000040, 800}
*** WARNING: Unable to verify timestamp for hal.dll
*** ERROR: Module load completed but symbols could not be loaded for hal.dll
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: hal!_WHEA_PROCESSOR_GENERIC_ERROR_SECTION ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: hal!_WHEA_PROCESSOR_GENERIC_ERROR_SECTION ***
*** ***
*************************************************************************
Probably caused by : hardware
Followup: MachineOwner Should my suspsions be aroused? Does it mean what I'm thinking it means? Or is it entirely innocent? First time I've seen one of these TBH. |
My System Specs | |
| 30 Jan 2011 | #2 |
| | This can arise when your Symbols are corrupt (the contents of the SymCache folder) Delete the folder and set the symbol path to SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols |
| My System Specs |
 |
Weird Dump File Result. problems?
| Thread Tools | |
| Similar help and support threads for: Weird Dump File Result. | ||||
| Thread | Forum | |||
| BSOD problem (weird memtest result) | BSOD Help and Support | |||
| Weird Result after Imaging | Backup and Restore | |||
| BSOD BBCode 116 - DMP file result | BSOD Help and Support | |||
| My dump file | BSOD Help and Support | |||
| Help with Dump File | BSOD Help and Support | |||
All times are GMT -5. The time now is 01:27 PM.
