Can Someone Please Help Me?

Try deleting the files, or even the whole minidump folder, and post the new ones when it crashes again.

Also make sure it is configured to create a minidump. Yours should be set just like mine.

Attachment 59619

Start typing Advanced into the start menu and select View Advanced System Settings.

It looks like you need to run a system files check. Open an elevated command prompt and enter sfc /scannow.

Code:

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Jonathan\Desktop\031310-28345-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a57000 PsLoadedModuleList = 0xfffff800`02c94e50
Debug session time: Sat Mar 13 18:30:07.856 2010 (GMT-5)
System Uptime: 1 days 6:15:04.025
Loading Kernel Symbols
...............................................................
................................................................
...........................
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffffa8053dc22b0, 2, 0, fffff80002acb585}

Probably caused by : CLASSPNP.SYS ( CLASSPNP!TransferPktComplete+1ce )

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

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        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: fffffa8053dc22b0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002acb585, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002cff0e0
 fffffa8053dc22b0 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!IopfCompleteRequest+415
fffff800`02acb585 f6067f          test    byte ptr [rsi],7Fh

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

TRAP_FRAME:  fffff88002f1b7e0 -- (.trap 0xfffff88002f1b7e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=fffffa8001e55fe0
rdx=fffffa800321d150 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002acb585 rsp=fffff88002f1b970 rbp=0000000000000002
 r8=fffffa8001f9ab00  r9=0000000000e07c01 r10=0000000000000000
r11=fffffa8002f8b870 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!IopfCompleteRequest+0x415:
fffff800`02acb585 f6067f          test    byte ptr [rsi],7Fh ds:d48b:00000000`00000000=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002ac8469 to fffff80002ac8f00

STACK_TEXT:  
fffff880`02f1b698 fffff800`02ac8469 : 00000000`0000000a fffffa80`53dc22b0 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`02f1b6a0 fffff800`02ac70e0 : fffff6fc`4002ae18 00000000`00000002 fffffa80`034f4d20 fffffa80`01833401 : nt!KiBugCheckDispatch+0x69
fffff880`02f1b7e0 fffff800`02acb585 : fffffa80`0321d48b 00000000`00000000 00000000`00000000 fffffa80`01833400 : nt!KiPageFault+0x260
fffff880`02f1b970 fffff880`018018ee : 00000000`00e07c01 fffff880`00e07c01 00000000`00000040 00000000`00000000 : nt!IopfCompleteRequest+0x415
fffff880`02f1ba50 fffff800`02acb516 : 00000000`00000000 00000000`00000001 00000000`00000299 fffff880`00e08507 : CLASSPNP!TransferPktComplete+0x1ce
fffff880`02f1bad0 fffff880`010976cb : fffffa80`0170b010 fffffa80`015f0101 fffffa80`020667d0 00000000`00000000 : nt!IopfCompleteRequest+0x3a6
fffff880`02f1bbb0 fffff880`010978d3 : fffff880`00000000 fffff880`000000f2 00000000`00000000 fffffa80`015e7060 : storport!RaidUnitCompleteRequest+0x1fb
fffff880`02f1bc90 fffff800`02ad45dc : fffff880`009ea180 0000027a`00000000 fffffa80`015e7128 00000000`00000076 : storport!RaidpAdapterDpcRoutine+0x53
fffff880`02f1bcd0 fffff800`02ad16fa : fffff880`009ea180 fffff880`009f4f40 00000000`00000000 fffff880`01097880 : nt!KiRetireDpcList+0x1bc
fffff880`02f1bd80 00000000`00000000 : fffff880`02f1c000 fffff880`02f16000 fffff880`02f1bd40 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
CLASSPNP!TransferPktComplete+1ce
fffff880`018018ee 837c243002      cmp     dword ptr [rsp+30h],2

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  CLASSPNP!TransferPktComplete+1ce

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: CLASSPNP

IMAGE_NAME:  CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc11e

FAILURE_BUCKET_ID:  X64_0xA_CLASSPNP!TransferPktComplete+1ce

BUCKET_ID:  X64_0xA_CLASSPNP!TransferPktComplete+1ce

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

Credit goes to my friend zigzag3143.

Well now we can hope the BSODs go away.