First time on this forum, and looking for some help with a problem that's been happening for a while...
I built a new Athlon 64 system about 10 months ago. 6 weeks into the initial build, I got my first BSOD. I would average another BSOD every 3 weeks or so, with no apparent problems in between. The basic info for the machine is as follows:
Athlon 64 3500+ (Newcastle) w/stock HSF
Asus A8V Deluxe (Rev 2)
2x512MB Corsair VS PC3200 (2.5-3-3-8), dual channel
Enermax EG475P-VE PSU
2x160GB Hitachi 27K250 SATA in RAID0 on VIA controller
80 GB Hitachi 7K250 SATA on Promise controller
Plextor PX-712A DVD+-R/RW
Radeon 9600XT 128MB
SB Audigy 2
I put up with the problem for a while, but finally decided a few months ago to get serious about trying to fix it. Problem is, I can't recreate or predict the problem. I've run a number of different diagnostics...memtest, docmem, Prime95, CPU burn-in, Super PI, drive utilities, etc., and nothing reported errors or crashed the system. Never had a crash during gaming, either. The BSODs seem more likely to happen when the system is idling or at light load, actually, although I haven't find an identifiable pattern. About 2 months ago, I decided to start fresh with new drives and Win XP SP2. Made sure to get the latest drivers, BIOS, etc. I got about 4 weeks out of it before another BSOD, and have had several since--the fresh install didn't do the trick, either.
This past week, I've spent some time trying to see if the windows dump files can yield any clues. Here's where I need some help, since I really don't know how to process the info in the files. I've managed to open the files with the Windows debugger, and performed a basic analysis, but I'm not able to interpret the info. I don't have a dump file for every crash (a few of them didn't give a BSOD, but just rebooted), but the three I do have contain very similar info. Here's one example of what Debugger is reporting:
*******************************************************************************
* Bugcheck Analysis *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 50, {be80f1d4, 8, be80f1d4, 2}
Could not read faulting driver name
Probably caused by : ntkrnlpa.exe ( nt!KiTrap0E+cc )
Followup: MachineOwner
---------
kd> !analyze -v
*******************************************************************************
* Bugcheck Analysis *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: be80f1d4, memory referenced.
Arg2: 00000008, value 0 = read operation, 1 = write operation.
Arg3: be80f1d4, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
WRITE_ADDRESS: be80f1d4
FAULTING_IP:
+ffffffffbe80f1d4
be80f1d4 ?? ???
MM_INTERNAL_CODE: 2
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x50
LAST_CONTROL_TRANSFER: from a11a4d64 to be80f1d4
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
a11a4d08 a11a4d64 010ffed4 bf80f1ad 00000000 0xbe80f1d4
a11a4d4c 8053c808 00bd6e1c 00000000 00000000 0xa11a4d64
a11a4d4c 7c90eb94 00bd6e1c 00000000 00000000 nt!KiFastCallEntry+0xf8
010ffee0 00000000 00000000 00000000 00000000 0x7c90eb94
FOLLOWUP_IP:
nt!KiTrap0E+cc
8053f6ec 85c0 test eax,eax
SYMBOL_STACK_INDEX: 2
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KiTrap0E+cc
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1d
STACK_COMMAND: .trap ffffffffa11a4c98 ; kb
FAILURE_BUCKET_ID: 0x50_W_nt!KiTrap0E+cc
BUCKET_ID: 0x50_W_nt!KiTrap0E+cc
Followup: MachineOwner
The one thing that strikes me as particularly odd is that the value in the second argument doesn't make sense. Debugger list 1 or 2 as valid results, but the returned value is 8. So far, I haven't been able to get any more info about that.
I'm hoping that someone here can help me interpret this information and try to discover the cause of the problem. I'll try to upload the actaully minidump files as well, in case someone wants to try to analyze them directly. Thanks for the help!
I built a new Athlon 64 system about 10 months ago. 6 weeks into the initial build, I got my first BSOD. I would average another BSOD every 3 weeks or so, with no apparent problems in between. The basic info for the machine is as follows:
Athlon 64 3500+ (Newcastle) w/stock HSF
Asus A8V Deluxe (Rev 2)
2x512MB Corsair VS PC3200 (2.5-3-3-8), dual channel
Enermax EG475P-VE PSU
2x160GB Hitachi 27K250 SATA in RAID0 on VIA controller
80 GB Hitachi 7K250 SATA on Promise controller
Plextor PX-712A DVD+-R/RW
Radeon 9600XT 128MB
SB Audigy 2
I put up with the problem for a while, but finally decided a few months ago to get serious about trying to fix it. Problem is, I can't recreate or predict the problem. I've run a number of different diagnostics...memtest, docmem, Prime95, CPU burn-in, Super PI, drive utilities, etc., and nothing reported errors or crashed the system. Never had a crash during gaming, either. The BSODs seem more likely to happen when the system is idling or at light load, actually, although I haven't find an identifiable pattern. About 2 months ago, I decided to start fresh with new drives and Win XP SP2. Made sure to get the latest drivers, BIOS, etc. I got about 4 weeks out of it before another BSOD, and have had several since--the fresh install didn't do the trick, either.
This past week, I've spent some time trying to see if the windows dump files can yield any clues. Here's where I need some help, since I really don't know how to process the info in the files. I've managed to open the files with the Windows debugger, and performed a basic analysis, but I'm not able to interpret the info. I don't have a dump file for every crash (a few of them didn't give a BSOD, but just rebooted), but the three I do have contain very similar info. Here's one example of what Debugger is reporting:
*******************************************************************************
* Bugcheck Analysis *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 50, {be80f1d4, 8, be80f1d4, 2}
Could not read faulting driver name
Probably caused by : ntkrnlpa.exe ( nt!KiTrap0E+cc )
Followup: MachineOwner
---------
kd> !analyze -v
*******************************************************************************
* Bugcheck Analysis *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: be80f1d4, memory referenced.
Arg2: 00000008, value 0 = read operation, 1 = write operation.
Arg3: be80f1d4, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
WRITE_ADDRESS: be80f1d4
FAULTING_IP:
+ffffffffbe80f1d4
be80f1d4 ?? ???
MM_INTERNAL_CODE: 2
CUSTOMER_CRASH_COUNT: 2
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x50
LAST_CONTROL_TRANSFER: from a11a4d64 to be80f1d4
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
a11a4d08 a11a4d64 010ffed4 bf80f1ad 00000000 0xbe80f1d4
a11a4d4c 8053c808 00bd6e1c 00000000 00000000 0xa11a4d64
a11a4d4c 7c90eb94 00bd6e1c 00000000 00000000 nt!KiFastCallEntry+0xf8
010ffee0 00000000 00000000 00000000 00000000 0x7c90eb94
FOLLOWUP_IP:
nt!KiTrap0E+cc
8053f6ec 85c0 test eax,eax
SYMBOL_STACK_INDEX: 2
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KiTrap0E+cc
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1d
STACK_COMMAND: .trap ffffffffa11a4c98 ; kb
FAILURE_BUCKET_ID: 0x50_W_nt!KiTrap0E+cc
BUCKET_ID: 0x50_W_nt!KiTrap0E+cc
Followup: MachineOwner
The one thing that strikes me as particularly odd is that the value in the second argument doesn't make sense. Debugger list 1 or 2 as valid results, but the returned value is 8. So far, I haven't been able to get any more info about that.
I'm hoping that someone here can help me interpret this information and try to discover the cause of the problem. I'll try to upload the actaully minidump files as well, in case someone wants to try to analyze them directly. Thanks for the help!