BSOD's

Hello,

BSODs are definitely occurring, but no minidumps are being saved:

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.

Besides your Blackberry software crashing a lot, I see nothing in Windows Error Reporting that points to the solution to this BSOD.

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.

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: .

STOP 0xA is generally caused by drivers - so start by removing these drivers and then installing new ones:
- chipset
- storage
- video

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?