New
#11
Mem dump app
Gary
Me to, I have been seeing double from looking at un-readible mem dumps. There has to be a better way.
Let me know if you find one
Ken
Gary
Me to, I have been seeing double from looking at un-readible mem dumps. There has to be a better way.
Let me know if you find one
Ken
Let me know if this works.
From time to time, we're faced with the dreaded BSOD, or bugcheck, on a Windows machine. The procedures below guide you through the steps necessary to analyze and debug dump files.
For a downloadable copy of these procedures, click here: How%20To%20Debug%20Memory%20Dumps.doc
- Download and install the Microsoft Debugging Tools from http://www.microsoft.com/whdc/devtoo...nstallx86.mspx
- Go to Start All Programs Debugging Tools For Windows WinDbg
- Click on File Symbol File Path, enter:
SRV*c:\symbols*Symbol information and click OK.- Click File Save Workspace so that your symbols path is saved for future use.
- Now locate your memory dumps. Small memory dumps are usually located in %systemroot%\minidump and Kernel memory dumps are located in %systemroot%\MEMORY.DMP.
- Go to File Open Crash Dump and load the file. You may get a message to save base workspace information. If so, choose No. Now you will get a debugging screen. It may take a little bit to run, since the symbols are downloaded as they are needed. Then you will see information such as:
Microsoft (R) Windows Debugger Version 6.7.0005.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [\\hoem02\c$\windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: SRV*c:\symbols*Symbol information
Executable search path is:
Windows Server 2003 Kernel Version 3790 MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_gdr.050225-1827
Kernel base = 0xe0b49000 PsLoadedModuleList = 0xe0be66a8
Debug session time: Wed May 9 02:01:49.965 2007 (GMT-7)
System Uptime: 6 days 22:51:23.840
Loading Kernel Symbols
.................................................................................................... ..
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffff00c). Type ".hh dbgerr001" for details
Loading unloaded module list
..
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck A, {4, 2, 0, e0b6136d}
Probably caused by : volsnap.sys ( volsnap!VspWriteVolumePhase35+3a )
Followup: MachineOwner
---------
- So far, we can tell that the bugcheck was caused by volsnap.sys, which is the Microsoft volume shadow copy driver. Use !analyze -v to get detailed debugging information. The most useful information is at the top of the analysis:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: e0b6136d, address which referenced memory
- From here, we can tell that volsnap.sys tried to read memory from an IRQL that was too high. This is usually caused by a bad driver, in this case, volsnap.sys.
- Next, let's find out what process was calling volsnap.sys. Enter !thread in the kd> command line input box and look for the line that begins with Owning Process:
2: kd> !thread
THREAD faa03658 Cid 0568.1954 Teb: 7ffac000 Win32Thread: 00000000 RUNNING on processor 2
Not impersonating
DeviceMap e1003978
Owning Process fc1913b0 Image: cvd.exe
Wait Start TickCount 38443765 Ticks: 0
- Now enter !process fc1913b0 0 (the hex number of the Owning Process), a space and the number 0.
2: d> !process fc1913b0 0
PROCESS fc1913b0 SessionId: 0 Cid: 0568 Peb: 7ffff000 ParentCid: 0218
DirBase: dd4a3000 ObjectTable: e141a910 HandleCount: 475.
Image: cvd.exe
- We can now tell that the cvd.exe process (used by Commvault) called the volsnap.sys driver. Since volsnap.sys is a Microsoft driver, a quick check on TechNet reveals that there is an updated VSS package available for our server (http://support.microsoft.com/kb/887827) which addresses the problem.
Note: Writing debugging information must be configured on the machine prior to the BSOD in order to get a memory dump. This is done in the Advanced tab of system properties. Set it to "Kernel memory dump" in order to get the process information.
Thanks Avien,
Forgot I had already installed that. Just not thinking to clear as I just found out my sister is very ill. Not been a good day.
This is what I get.
Doubt if it has anything to do with the registry as I have shutdown and rebooted several times since I last played in there. If you see anything obvious, let me know, otherwise it will have to wait.Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 74, {2, fffff88003d3fb20, 2, ffffffffc000009a} Probably caused by : ntkrnlmp.exe ( nt!CmpLoadHiveThread+23a ) Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* BAD_SYSTEM_CONFIG_INFO (74) Can indicate that the SYSTEM hive loaded by the osloader/NTLDR was corrupt. This is unlikely, since the osloader will check a hive to make sure it isn't corrupt after loading it. It can also indicate that some critical registry keys and values are not present. (i.e. somebody used regedt32 to delete something that they shouldn't have) Booting from LastKnownGood may fix the problem, but if someone is persistent enough in mucking with the registry they will need to reinstall or use the Emergency Repair Disk. Arguments: Arg1: 0000000000000002, (reserved) Arg2: fffff88003d3fb20, (reserved) Arg3: 0000000000000002, (reserved) Arg4: ffffffffc000009a, usually the NT status code. Debugging Details: ------------------ DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x74 PROCESS_NAME: System CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from fffff80003149e3a to fffff80002cdcf80 STACK_TEXT: fffff880`03d3fa68 fffff800`03149e3a : 00000000`00000074 00000000`00000002 fffff880`03d3fb20 00000000`00000002 : nt!KeBugCheckEx fffff880`03d3fa70 fffff800`02f62e66 : 00000000`0234ebb5 fffffa80`01dff060 00000000`00000080 fffffa80`003dc890 : nt!CmpLoadHiveThread+0x23a fffff880`03d3fd40 fffff800`02c8fa86 : fffff880`02f63180 fffffa80`01dff060 fffff880`02f6dfc0 fffff880`01266a30 : nt!PspSystemThreadStartup+0x5a fffff880`03d3fd80 00000000`00000000 : fffff880`03d40000 fffff880`03d3a000 fffff880`03d3efc0 00000000`00000000 : nt!KxStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_IP: nt!CmpLoadHiveThread+23a fffff800`03149e3a cc int 3 SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!CmpLoadHiveThread+23a FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 49ee9439 FAILURE_BUCKET_ID: X64_0x74_nt!CmpLoadHiveThread+23a BUCKET_ID: X64_0x74_nt!CmpLoadHiveThread+23a Followup: MachineOwner ---------
Thanks again.
Gary
All i see is a lot of information about Vista. Did you install any Vista drivers lately?
I may have replaced the Windows nVidia driver to the latest Vista one, but I don't think so. I did install the nVidia control panel. I device manager the nVidia driver is 8.15.11.8585. I think that is the Windows driver. Also an XP driver for my printer. Also my MX revolution mouse driver is Vista.
What did you edit in your registry?
BAD_SYSTEM_CONFIG_INFO (74)
Can indicate that the SYSTEM hive loaded by the osloader/NTLDR
was corrupt. This is unlikely, since the osloader will check
a hive to make sure it isn't corrupt after loading it.
It can also indicate that some critical registry keys and values
are not present. (i.e. somebody used regedt32 to delete something
that they shouldn't have) Booting from LastKnownGood may fix
the problem, but if someone is persistent enough in mucking with
the registry they will need to reinstall or use the Emergency
Repair Disk.
Yeah, saw that, but as I said, I haven't played with the registry for a bit and have shutdown/rebooted several times since. I'm sure that unchecking the cpu box in msconfig wouldn't have fixed a corrupt hive. Checking that box may just have made it inaccessible for some reason. As it says, it would have checked the hive once loaded. I did get a couple BSOD's, but it rebooted before I could read anything.
Have you gotten any BSOD lately? If so turn off automatic restart on error so you can get a good look at the screen.
Nope. Everything seems to be fine. Been running fine all day. Several reboots with no issues. That checkbox is the only change. The reg changes I've made are tweaks that I've seen here, but I'm sure it's not them. Things like removing entries from the 'new' context menu and such. Nothing scary or that I haven't done a half dozen times before. I had forgotten to turn off auto restart as I usually do that right off also, but will take care of that when I reboot into 7100. Thanks for the input.
Gary
Here is where I read that article, if you are interested about ticking the box to use all your cores in the CPU.
http://lifehacker.com/5033518/debunk...tweaking-myths