New
#1
BSOD's
Hey,
I've recently been getting alot of BSOD on my 3 year old hp computer and I need some help.
Im running Windows 7 Professional 64x.
Ive also attached my dump files.
Thanks in advance.
Windows_NT6_BSOD_jcgriff2 (2).zip
Hey,
I've recently been getting alot of BSOD on my 3 year old hp computer and I need some help.
Im running Windows 7 Professional 64x.
Ive also attached my dump files.
Thanks in advance.
Windows_NT6_BSOD_jcgriff2 (2).zip
Hello,
BSODs are definitely occurring, but no minidumps are being saved:Besides your Blackberry software crashing a lot, I see nothing in Windows Error Reporting that points to the solution to this BSOD.Code:Event[1286]: Log Name: System Source: Microsoft-Windows-WER-SystemErrorReporting Date: 2011-01-31T21:40:36.000 Event ID: 1001 Task: N/A Level: Error Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: CLTOLENTINO Description: The computer has rebooted from a bugcheck. The bugcheck was: 0x0000003b (0x00000000c0000005, 0xfffff80002c95c94, 0xfffff8800a5050b0, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: . Event[427]: Log Name: System Source: Microsoft-Windows-WER-SystemErrorReporting Date: 2011-02-01T10:56:25.000 Event ID: 1005 Task: N/A Level: Error Opcode: N/A Keyword: Classic User: N/A User Name: N/A Computer: CLTOLENTINO Description: Unable to produce a minidump file from the full dump file.
My only suggestion is more of a "shot in the dark" than anything else. I see you have Daemon Tools installed, which uses a driver (sptd.sys) that is known to cause BSODs. I suggest that you remove Daemon Tools, and then uninstall SPTD itself with this tool: http://www.duplexsecure.com/download...t-v174-x64.exe
I would love to get know what is preventing the minidump files from being created; I regret to say I cannot answer that at this time. I hope that maybe some other members may have a better idea.
If the SPTD removal does not help, run driver verifier: Driver Verifier - Enable and Disable
If you get any more BSODs, upload a new jcgriff2 report as soon as you can.
Zip up the full memory dump (it's in C:\Windows and is named MEMORY.dmp) and upload it to a free file hosting service. Then share it out and place the link here.
The last error indicates that a memory dump is being generated, but it can't be parsed into a minidump. That, to me, indicates a corruption of the memory dump, the OS, or other underlying structures (such as a hard drive failing).
Checking the full memory dump for usability is the first step here. If we can read that, then the problem is either with the OS or it's underlying structures.
STOP 0xA is generally caused by drivers - so start by removing these drivers and then installing new ones:Event[426]:
Log Name: System
Source: Microsoft-Windows-WER-SystemErrorReporting
Date: 2011-02-01T10:56:25.000
Event ID: 1001
Task: N/A
Level: Error
Opcode: N/A
Keyword: Classic
User: N/A
User Name: N/A
Computer: CLTOLENTINO
Description:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000000a (0x0000000000000043, 0x0000000000000002, 0x0000000000000001, 0xfffff80002cc6cd8). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: .
- chipset
- storage
- video
Last edited by usasma; 02 Feb 2011 at 13:20.
Full Kernel dump is present -
Please zip it up and follow instructions given by usasma.Code:Volume in drive C is HP Volume Serial Number is 26C9-CED8 Directory of C:\Windows 02/01/2011 10:59 AM 359,588,941 MEMORY.DMP
here is the dump file you asked for..
MEMORY.zip
I won't have access to download this file for some time, but there are "the usual suspects" for a 3B crash - specifically (according to Microsoft themselves) that this particular bugcheck code is "linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code".
Something to think about while we wait for someone, or myself, to analyze this one. If someone who does have access to download the file at the moment wants to run the !vm command and post back the output, that'd be pretty useful to start.
Here you go cluberti:Code:Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\Jonathan\AppData\Local\Temp\Temp1_MEMORY.zip\MEMORY.DMP] Kernel Summary Dump File: Only kernel address space is available Symbol search path is: SRV*c:\symbols*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.16617.amd64fre.win7_gdr.100618-1621 Machine Name: Kernel base = 0xfffff800`02c14000 PsLoadedModuleList = 0xfffff800`02e51e50 Debug session time: Fri Feb 4 11:43:15.524 2011 (UTC - 5:00) System Uptime: 1 days 14:12:51.538 Loading Kernel Symbols .............................................Missing image name, possible paged-out or corrupt data. .*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000 Unable to add module at 00000000`00000000 Unable to read KLDR_DATA_TABLE_ENTRY at 00000000`00000000 - NTSTATUS 0xC0000147 Image path too long, possible corrupt data. Loading unloaded module list ..Image path too long, possible corrupt data. . WARNING: .reload failed, module list may be incomplete ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {20, 2, 1, fffff80002cc50a2} Probably caused by : ntkrnlmp.exe ( nt!KxWaitForLockOwnerShip+12 ) Followup: MachineOwner --------- 0: kd> !vm *** Virtual Memory Usage *** Physical Memory: 786250 ( 3145000 Kb) Paging File Name paged out Current: 5229546031718746888 Kb Free Space: 4895032615123672228 Kb Minimum: -6540240032604370092 Kb Maximum: -144913121844878044 Kb Unimplemented error for MiSystemVaTypeCount Available Pages: 463809 ( 1855236 Kb) ResAvail Pages: 699615 ( 2798460 Kb) Locked IO Pages: 0 ( 0 Kb) Free System PTEs: 33557845 ( 134231380 Kb) Modified Pages: 14921 ( 59684 Kb) Modified PF Pages: 14885 ( 59540 Kb) NonPagedPool Usage: 82060249 ( 328240996 Kb) NonPagedPoolNx Usage: 19053 ( 76212 Kb) NonPagedPool Max: 577535 ( 2310140 Kb) ********** Excessive NonPaged Pool Usage ***** PagedPool 0 Usage: 49082 ( 196328 Kb) PagedPool 1 Usage: 5917 ( 23668 Kb) PagedPool 2 Usage: 2595 ( 10380 Kb) PagedPool 3 Usage: 2592 ( 10368 Kb) PagedPool 4 Usage: 2681 ( 10724 Kb) PagedPool Usage: 62867 ( 251468 Kb) PagedPool Maximum: 33554432 ( 134217728 Kb) Unable to read _MM_SESSION_SPACE at fffff880032a4000 Session Commit: 0 ( 0 Kb) Shared Commit: 78525 ( 314100 Kb) Special Pool: 0 ( 0 Kb) Shared Process: 8957 ( 35828 Kb) PagedPool Commit: 62905 ( 251620 Kb) Driver Commit: 9223 ( 36892 Kb) Committed pages: 583643 ( 2334572 Kb) Commit limit: 1572025 ( 6288100 Kb) Unable to read _EPROCESS at fffffffffffffe78 ProcessCommitUsage could not be calculated
So the data's not very useful, and the dump mentions that a lot of it's memory was probably paged out - that usually indicates either the system was sleeping at the time of the crash, or there was probably some memory pressure on the box at the time. There might still be useful data in here, but I think we need to get a feel from the OP what was being done on this machine at the time of the crash that generated this .dmp to get a better idea of where to poke and prod the dump file. It's not absolutely necessary, but it would help quite a bit.
Also, what does .bugcheck and !thread output?
Code:0: kd> .bugcheck; !thread Bugcheck code 0000000A Arguments 00000000`00000020 00000000`00000002 00000000`00000001 fffff800`02cc50a2 THREAD fffff80002e0cc40 Cid 0000.0000 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0 Not impersonating DeviceMap fffff8a000008d80 Owning Process fffff80002e0d140 Image: Idle Attached Process fffffa80024b8040 Image: System Wait Start TickCount 8818630 Ticks: 1 (0:00:00:00.015) Context Switch Count 84258139 UserTime 00:00:00.000 KernelTime 17:56:39.343 Win32 Start Address nt!KiIdleLoop (0xfffff80002c8ce90) Stack Init fffff80004335db0 Current fffff80004335d40 Base fffff80004336000 Limit fffff80004330000 Call 0 Priority 16 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 0 Child-SP RetAddr : Args to Child : Call Site fffff800`04335c98 fffff800`02c9224a : 00000000`0023c332 fffffa80`04b622f8 fffffa80`053d6010 fffffa80`04bdb000 : 0xfffff880`0493d9c2 fffff800`04335ca0 fffff800`02c8cebc : fffff800`02dfee80 fffff800`00000000 00000000`00000000 fffff880`01ad3c50 : nt!PoIdle+0x53a fffff800`04335d80 00000000`00000000 : fffff800`04336000 fffff800`04330000 fffff800`04335d40 00000000`00000000 : nt!KiIdleLoop+0x2c
So this one's a memory management bugcheck, not a 3B. It looks like it was a write operation at IRQL 2 (DPC Dispatch_Level), and an invalid memory address (either completely invalid, or an address unable to be paged in) was requested by another address that doesn't appear to be valid in the dump. If you run u 0xfffff880`0493d9c2, do we get any useful output?