BSOD while computer was unattended

I am new to this forum - thanks in advance for your help.

I left my computer running (with a few programs open: Word 2010, Excel, Opera, etc.). When I came back, a BSOD awaited me.

I've attached a photo I took of the screen and a zip file containing:

• the output directory of the jcgriff tool
• The perfmon output
  

I noted that the current MEMORY.DMP file did not seem to be copied to the jcgriff directory - should I upload that, too?

Also - FYI - I started the jcgriff tool and almost immediately canceled it because I realized I had not followed the instruction to Run As Administrator. I then re-ran it correctly.

My system specs:
Is Windows 7 . . .
- x86 (32-bit) or x64 ?
- the original installed OS on the system? YES
- an OEM or full retail version?
- OEM = came pre-installed on system
- Full Retail = you purchased it from retailer

- What is the age of system (hardware)? 1.5 years.
- What is the age of OS installation (have you re-installed the OS?) have not re-installed - it is original factory installation.

Hi HeyYou,

Thanks for the quick reply. It restarted OK, but all is not well. I have had recurring blue-screens for the last month or two (and less frequently before that). Yesterday's made me decide it wasn't going to go away by itself & I started looking for a solution - and found this forum.

This morning - after waking my computer from Sleep mode I mistyped my password & before I had a chance to try again, it blue-screened again. (Should I re-do the jcgriff & perfmon procedure?).

I have attached a photo of today's blue screen. I've also attached photos of some other blue screens in the recent past. You can see the date of each bluescreen by the filename from when I snapped the photo. They are in reverse chronological order going back to March 5.

Thanks for any guidance,
Yosh

You may have a virus that is affecting many systems lately. Run the Kaspersky TDSSKILLER program: How to remove malware belonging to the family Rootkit.Win32.TDSS (aka Tidserv, TDSServ, Alureon)?

Code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff880018533e4, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800036b3100
 0000000000000008 

CURRENT_IRQL:  2

FAULTING_IP: 
CLASSPNP!ClasspDequeueIdleRequest+44
fffff880`018533e4 48895008        mov     qword ptr [rax+8],rdx

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  System

TRAP_FRAME:  fffff80000ba2580 -- (.trap 0xfffff80000ba2580)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8004c339f8
rdx=fffffa8004c33a00 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880018533e4 rsp=fffff80000ba2710 rbp=0000000000000002
 r8=000000005aa3e5f6  r9=0000000000000000 r10=fffff800035f6e80
r11=fffffa8004c33a50 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
CLASSPNP!ClasspDequeueIdleRequest+0x44:
fffff880`018533e4 48895008        mov     qword ptr [rax+8],rdx ds:2a60:00000000`00000008=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800034801e9 to fffff80003480c40

STACK_TEXT:  
fffff800`00ba2438 fffff800`034801e9 : 00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff800`00ba2440 fffff800`0347ee60 : fffffa80`091598d0 fffffa80`07e57050 00000000`00000000 fffffa80`04c33010 : nt!KiBugCheckDispatch+0x69
fffff800`00ba2580 fffff880`018533e4 : 00000000`00000001 fffffa80`04a9ad40 fffff800`00ba2800 fffffa80`04c33010 : nt!KiPageFault+0x260
fffff800`00ba2710 fffff880`01863ef5 : fffffa80`04c311b0 00000000`0000ffff 00000000`00000001 fffff800`035f6e80 : CLASSPNP!ClasspDequeueIdleRequest+0x44
fffff800`00ba2740 fffff880`018542fd : fffffa80`04c33a10 fffffa80`04c33a50 00000000`00000001 fffff800`034895fa : CLASSPNP!ClasspServiceIdleRequest+0x15
fffff800`00ba2770 fffff800`0348c5fc : fffff800`035f6e80 00000000`00000000 00000002`408f0088 00000000`00000004 : CLASSPNP! ?? ::FNODOBFM::`string'+0x3116
fffff800`00ba27a0 fffff800`0348c496 : fffffa80`04c33a10 00000000`002c008e 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff800`00ba2810 fffff800`0348c37e : 00000068`bdfe7704 fffff800`00ba2e88 00000000`002c008e fffff800`035fa448 : nt!KiProcessExpiredTimerList+0xc6
fffff800`00ba2e60 fffff800`0348c167 : fffff800`035f6ec1 00000000`002c008e fffff880`00f40f00 00000000`0000008e : nt!KiTimerExpiration+0x1be
fffff800`00ba2f00 fffff800`03483765 : 00000000`00000000 fffffa80`0704c250 00000000`00000000 fffff880`0442b588 : nt!KiRetireDpcList+0x277
fffff800`00ba2fb0 fffff800`0348357c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KyRetireDpcList+0x5
fffff880`08db91e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchInterruptContinue


STACK_COMMAND:  kb

FOLLOWUP_IP: 
CLASSPNP!ClasspDequeueIdleRequest+44
fffff880`018533e4 48895008        mov     qword ptr [rax+8],rdx

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  CLASSPNP!ClasspDequeueIdleRequest+44

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: CLASSPNP

IMAGE_NAME:  CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce7929b

FAILURE_BUCKET_ID:  X64_0xD1_CLASSPNP!ClasspDequeueIdleRequest+44

BUCKET_ID:  X64_0xD1_CLASSPNP!ClasspDequeueIdleRequest+44

Followup: MachineOwner
---------

Thanks, Yowanvista, for the suggestion. I ran the Kapersky program and it found no threats.

Any other ideas or suggestions?

FYI, in general, my system seems to get stuck a lot - I spend inordinate amounts of time waiting for Windows explorer to respond. This made me think that it may be some driver that is bad (and may also be causing the blue screens). But how to find out which?

Thanks,
Yosh

Question: Should I re-run jcgriff tool and/or perfmon & upload results?

yoshm said:

Question: Should I re-run jcgriff tool and/or perfmon & upload results?

Re-run it, your attachment doesn't seem to contain any recent dump files.

yowanvista said:

yoshm said:

Question: Should I re-run jcgriff tool and/or perfmon & upload results?

Re-run it, your attachment doesn't seem to contain any recent dump files.

I re-ran it yesterday and it is attached.

I put the machine to "sleep" last night. When I opened it this morning - a new blue screen! (See attached photo).

I am re-re-running jcgriff and will upload when it is complete.

Note that I do not see any recent "mini-dumps" - why would I not be getting those? What about the full dump (MEMORY.DMP) - should I be uploading that somehow?

Also, I do not know if this is related, but I got a message that drivers were causing Windows to resume slowly - I've attached a screenshot. I note there a mention of a device "Blackberry SD" - not sure what that is or how to get rid of it. I've uninstalled all the Blackberry software a few weeks ago. The Intel driver I assume I need for the display.

Thanks for any help. Things are going form bad to worse so I sure hope someone can guide me to finding what's wrong...

Thanks!
Yosh

p.s. should jcgriff take so long to run? It's been going for nearly an hour - previously it also took a really long time.

Here's the next jcgriff (see my previous post).

Can anyone help?

yoshm said:

Here's the next jcgriff (see my previous post).

Can anyone help?

Your attachments contain no recent dumps, the latest ones date from last year.