Computer back from repair

thescreensavers

Diamond Member
Aug 3, 2005
9,916
2
81
Got my computer back from repair for a bad Hard drive, as far as I know they replaced it with a new one. I try to run a Defrag using Perfect disk but I BSOD, using windows defrag it works fine. But it the bsod might occur with other programs and try to diagnose it.


Heres the error

Event Type: Error
Event Source: System Error
Event Category: (102)
Event ID: 1003
Date: 11/11/2008
Time: 9:43:24 PM
User: N/A
Computer: TOSHIBA-A300
Description:
Error code 1000008e, parameter1 c0000005, parameter2 8052bacc, parameter3 ab1d790c, parameter4 00000000.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 53 79 73 74 65 6d 20 45 System E
0008: 72 72 6f 72 20 20 45 72 rror Er
0010: 72 6f 72 20 63 6f 64 65 ror code
0018: 20 31 30 30 30 30 30 38 1000008
0020: 65 20 20 50 61 72 61 6d e Param
0028: 65 74 65 72 73 20 63 30 eters c0
0030: 30 30 30 30 30 35 2c 20 000005,
0038: 38 30 35 32 62 61 63 63 8052bacc
0040: 2c 20 61 62 31 64 37 39 , ab1d79
0048: 30 63 2c 20 30 30 30 30 0c, 0000
0050: 30 30 30 30 0000

I also have a minidump file.

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini111108-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

/Symbol search path is: *** Invalid ***
/****************************************************************************
/* Symbol loading may be unreliable without a symbol search path. *
/* Use .symfix to have the debugger choose a symbol path. *
/* After setting your symbol path, use .reload to refresh symbol locations. *
/*/***************************************************************************
/Executable search path is:
/*********************************************************************
/* Symbols can not be loaded because symbol path is not initialized. *
/* *
/* The Symbol Path can be set by: *
/* using the _NT_SYMBOL_PATH environment variable. *
/* using the -y <symbol_path> argument when starting the debugger. *
/* using .sympath and .sympath+ *
/*********************************************************************
/Unable to load image ntoskrnl.exe, Win32 error 0n2
/*** WARNING: Unable to verify timestamp for ntoskrnl.exe
/*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
/Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
/Product: WinNt, suite: TerminalServer SingleUserTS
/Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
/Debug session time: Tue Nov 11 21:10:40.234 2008 (GMT-5)
/System Uptime: 0 days 2:00:40.951
/*********************************************************************
/* Symbols can not be loaded because symbol path is not initialized. *
/* *
/* The Symbol Path can be set by: *
/* using the _NT_SYMBOL_PATH environment variable. *
/* using the -y <symbol_path> argument when starting the debugger. *
/* using .sympath and .sympath+ *
/*********************************************************************
Unable to load image ntoskrnl.exe, Win32 error 0n2
/*** WARNING: Unable to verify timestamp for ntoskrnl.exe
/*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe/
/Loading Kernel Symbols
/...........................................................................................................................................
/Loading User Symbols
/Loading unloaded module list
/...................
/Unable to load image windrvNT.sys, Win32 error 0n2
/*** WARNING: Unable to verify timestamp for windrvNT.sys
/*** ERROR: Module load completed but symbols could not be loaded for windrvNT.sys
/*******************************************************************************
/* *
/* Bugcheck Analysis *
/* *
/*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 8052bacc, ab855944, 0}

/***** Kernel symbols are WRONG. Please fix symbols to do analysis.
/
/*** WARNING: Unable to verify timestamp for DefragFS.SYS
/*** ERROR: Module load completed but symbols could not be loaded for DefragFS.SYS
/*************************************************************************
/*** **/*
/*** ***
/*** Your debugger is not using the correct symbols ***
/*** ***
/*** In order for this command to work properly, your symbol path ***
/*** must point to .pdb files that have full type information. ***
/*** ***
/*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
/*** Type referenced: nt!_KPRCB ***
/*** ***
/*************************************************************************
/*************************************************************************
/*** ***
/*** ***
/*** Your debugger is not using the correct symbols ***
/*** ***
/*** In order for this command to work properly, your symbol path ***
/*** must point to .pdb files that have full type information. ***
/*** ***
/*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
/*** Type referenced: nt!KPRCB ***
/*** ***
/*************************************************************************
/*************************************************************************
/*** ***
/*** ***
/*** Your debugger is not using the correct symbols ***
/*** ***
/*** In order for this command to work properly, your symbol path ***
/*** must point to .pdb files that have full type information. ***
/*** ***
/*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
//*** Type referenced: nt!_KPRCB ***
/*** ***
/*************************************************************************
/*************************************************************************
/*** ***
/*** ***
/*** Your debugger is not using the correct symbols ***
/*** ***
/*** In order for this command to work properly, your symbol path ***
/*** must point to .pdb files that have full type information. ***
/*** ***
/*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
/*** Type referenced: nt!KPRCB ***
/*** ***
/*************************************************************************
/*************************************************************************
/*** ***
/*** ***
/*** Your debugger is not using the correct symbols ***
/*** ***
/*** In order for this command to work properly, your symbol path ***
/*** must point to .pdb files that have full type information. ***
/*** ***
/*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
/*** Type referenced: nt!_KPRCB ***
/*** ***
/*************************************************************************
/*************************************************************************
/*** ***
/*** ***
/*/** Your debugger is not using the correct symbols ***/
/*/** ***
/*** In order for this command to work properly, your symbol path ***
/*** must point to .pdb files that have full type information. ***
/*** ***
/*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
/*** Type referenced: nt!_KPRCB ***
/*** ***
/*************************************************************************
/*************************************************************************
/*** ***/
/*** ***
/*** Your debugger is not using the correct symbols ***
//*** ***
//*** In order for this command to work properly, your symbol path ***
//*** must point to .pdb files that have full type information. ***
//*** ***
//*** Certain .pdb files (such as the public OS symbols) do not ***
/*** contain the required information. Contact the group that ***
/*** provided you with these symbols if you need this command to ***
/*** work. ***
/*** ***
/*** Type referenced: nt!_KPRCB ***
/*** ***
/*************************************************************************
/*********************************************************************
/* Symbols can not be loaded because symbol path is not initialized. *
/* *
/* The Symbol Path can be set by: *
/* using the _NT_SYMBOL_PATH environment variable. *
/* using the -y <symbol_path> argument when starting the debugger. *
/* using .sympath and .sympath+ *
/*********************************************************************
/*********************************************************************
/* Symbols can not be loaded because symbol path is not initialized. *
/* *
//* The Symbol Path can be set by: *
/* using the _NT_SYMBOL_PATH environment variable. *
/* using the -y <symbol_path> argument when starting the debugger. *
/* using .sympath and .sympath+ *
/*********************************************************************
/Probably caused by : windrvNT.sys ( windrvNT+4555 )//

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

thescreensavers

Diamond Member
Aug 3, 2005
9,916
2
81
Event Type: Information
Event Source: Save Dump
Event Category: None
Event ID: 1001
Date: 11/11/2008
Time: 9:42:49 PM
User: N/A
Computer: TOSHIBA-A300
Description:
The computer has rebooted from a bugcheck. The bugcheck was: 0x1000008e (0xc0000005, 0x8052bacc, 0xab1d790c, 0x00000000). A dump was saved in: C:\WINDOWS\Minidump\Mini111108-04.dmp.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
 

mpilchfamily

Diamond Member
Jun 11, 2007
3,559
1
0
I agree. Assuming the drive was replaced then the memory is the next culprit. Possibly the original problem. If the Memeory is bad then files will be currupted there and then when they are writen back to the HDD it currupts the drive causing problems that look like the drive is at fault.
 

thescreensavers

Diamond Member
Aug 3, 2005
9,916
2
81
Originally posted by: mpilchfamily
I agree. Assuming the drive was replaced then the memory is the next culprit. Possibly the original problem. If the Memeory is bad then files will be currupted there and then when they are writen back to the HDD it currupts the drive causing problems that look like the drive is at fault.

well what led me to the HD was that I could not format it because of bad sectors errors that occurred, but memory is the next in line to check I suppose.
 

thescreensavers

Diamond Member
Aug 3, 2005
9,916
2
81
Originally posted by: RadiclDreamer
Run memtest86+ and see what comes back.


I will run a test also but I read that these test only do Read/write tests. But not Execute cycles something like that.



edit:
Memory checking programs are not adequate because they don't test the memory the way that Windows uses it. Most, if not all, memory checkers use read/write cycles when scanning memory. Since Windows is executing code from the memory, it uses execute cycles. Execute cycles are physically different from read/write cycles and are more vulnerable to parity errors. It is possible for memory checking programs to find parity errors if the memory is extremely faulty.

last post
 

ch33zw1z

Lifer
Nov 4, 2004
39,838
20,433
146
Originally posted by: thescreensavers
Originally posted by: RadiclDreamer
Run memtest86+ and see what comes back.


I will run a test also but I read that these test only do Read/write tests. But not Execute cycles something like that.



edit:
Memory checking programs are not adequate because they don't test the memory the way that Windows uses it. Most, if not all, memory checkers use read/write cycles when scanning memory. Since Windows is executing code from the memory, it uses execute cycles. Execute cycles are physically different from read/write cycles and are more vulnerable to parity errors. It is possible for memory checking programs to find parity errors if the memory is extremely faulty.

last post

If is still fails those "read/write" cycles then it's bad either way. I've had memtest86 show me issues more often than not. Do NOT just let it run 1 pass and call it good, let it go for at least 3 passes, the more the merrier.