[tb582]

The computer has rebooted from a bugcheck. The bugcheck was: 0x000000f4 (0x00000003, 0x85faea20, 0x85faeb94, 0x80604498). A dump was saved in: C:\WINDOWS\Minidump\Mini020706-11.dmp.

Now this is my first time using WinDbg 6.6 - and I think I have done everything right up till now... when I open the dump file this is what WinDbg comes up with....

Maybe someone here can give me some more info? I'm not sure why it comes up Unable to verify timestamp, nor why it says "Probably caused by : csrss.exe"

The good thing is, is that I can reproduce the error that causes the system crash, it happens every time I open a .mov (quicktime) file that I have saved on my computer. So I'm thinking that if I save a more detailed dump file that will give me more info on exactly what is causing it?

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


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

Symbol search path is: C:\WINDOWS\Symbols
Executable search path is: 
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Feb  7 21:24:11.984 2006 (GMT-5)
System Uptime: 0 days 1:26:14.944
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
....................................................................................................
........................................................
Loading User Symbols
Loading unloaded module list
...................................
*******************************************************************************
*																			 *
*						Bugcheck Analysis									*
*																			 *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck F4, {3, 85faea20, 85faeb94, 80604498}

Probably caused by : csrss.exe

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

0: kd> !analyze -v
*******************************************************************************
*																			 *
*						Bugcheck Analysis									*
*																			 *
*******************************************************************************

CRITICAL_OBJECT_TERMINATION (f4)
A process or thread crucial to system operation has unexpectedly exited or been
terminated.
Several processes and threads are necessary for the operation of the
system; when they are terminated (for any reason), the system can no
longer function.
Arguments:
Arg1: 00000003, Process
Arg2: 85faea20, Terminating object
Arg3: 85faeb94, Process image file name
Arg4: 80604498, Explanatory message (ascii)

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


PROCESS_OBJECT:  85faea20

IMAGE_NAME:  csrss.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MODULE_NAME:  csrss

FAULTING_MODULE: 00000000 

CUSTOMER_CRASH_COUNT:  11

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

BUGCHECK_STR:  0xF4

PROCESS_NAME:  csrss.exe

STACK_TEXT:  
f7931520 80633f32 000000f4 00000003 85faea20 nt!MiRemoveUnusedSegments+0x637
f7931544 80604456 80604498 85faea20 85faeb94 nt!RtlDescribeChunkNS+0x3
f7931544 80604456 80604498 85faea20 85faeb94 nt!WmiTraceThread+0x70
f7931574 804dd98f 85faec68 c0000006 f79319b0 nt!WmiTraceThread+0x70
f7931584 804e4697 badb0d00 f79315fc 000c0000 nt!ZwQueryEvent+0x4
f7931584 804e4697 badb0d00 f79315fc 000c0000 nt!KiInsertQueue+0x57
f79319b0 80517e25 f79319d8 00000000 f7931d64 nt!KiInsertQueue+0x57
f7931d34 804e1298 0052fbe8 0052fc08 00000000 nt!PopPromoteFromIdle0+0x49
f7931d50 804dd98f 0052fbe8 0052fc08 00000000 nt!Dr_kitb_a+0x7f
f7931d54 0052fbe8 0052fc08 00000000 0052fff4 nt!ZwQueryEvent+0x4
WARNING: Frame IP not in any known module. Following frames may be wrong.
f7931d64 7c90eb94 badb0d00 0052fbdc ffffffff 0x52fbe8
f7931d68 badb0d00 0052fbdc ffffffff 00000001 0x7c90eb94
f7931d6c 0052fbdc ffffffff 00000001 00000000 0xbadb0d00
f7931d70 ffffffff 00000001 00000000 00000000 0x52fbdc
f7931d74 00000000 00000000 00000000 00000000 0xffffffff


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0xF4_IMAGE_csrss.exe

BUCKET_ID:  0xF4_IMAGE_csrss.exe

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

Title Edited - Please follow new forum rules from now on
-- Martin L

[cluberti]

The error you're getting is:

0x000000F4: CRITICAL_OBJECT_TERMINATION

If any system object (file, process, thread, etc.) critical to system operation terminates with any unexpected error code (and csrss.exe is a very critical system object), Windows bugchecks with this (and possibly a few other) bugcheck messages.

Is there any way you can post the dump file here, or at least the minidump file from the %windir%\minidump\ folder? I'd like to track the callstack back and see what kind of locks or traps I can find...

Csrss.exe is likely the victim here, not the culprit, and so I need to see more than just an analyze -v statement to determine what's going on. Let me know if posting that dump from your XP box is a problem, and perhaps you can email or PM me.

[tb582]

cluberti, on Feb 8 2006, 06:27 PM, said:

Is there any way you can post the dump file here, or at least the minidump file from the %windir%\minidump\ folder? I'd like to track the callstack back and see what kind of locks or traps I can find...

Csrss.exe is likely the victim here, not the culprit, and so I need to see more than just an analyze -v statement to determine what's going on. Let me know if posting that dump from your XP box is a problem, and perhaps you can email or PM me.

Here is the dump file...

Attached File(s)

•  Mini020706_11.rar (19.02K)
  Number of downloads: 31

This post has been edited by tb582: 08 February 2006 - 05:32 PM

[tb582]

Here are all the miniDump's there are 11 total including the one posted above, It only happens when I open a quicktime file...

www.silverscreencreations.com/images/Minidump.rar

[WolfX2]

forum rules said:

12. Very often we see meaningless subjects in topic title. They give no clue of what the posts are all about. For example:

- Oh no!
- Help
- I'm mad
- Please help
- Question
- I need your help
- Hmmmm ....

This should be avoided. Users should enter something more specific in topic title so that it is easier for others to help.

A few good examples:

- Strange problem with DirectX9b redist
- RunOnceEx install problem (double installation)
- Change Internet Explorer's Icon back to default

Be sure to read the forum rules

This post has been edited by wolf74481: 08 February 2006 - 07:35 PM

[cluberti]

I PM'ed, but I thought it'd be wise to post here as well. I was able to trace csrss.exe to what appears to be a driver, but the minidump doesn't contain any information about said driver. Do you perchance have a memory.dmp file in your \Windows directory that I can look at? That, assuming it's a kernel memory dump, should have at least the kernel information about the driver that belongs to the thread that dumped csrss.exe.

[tb582]

Thanks, I also sent you a PM back but I'm not sure that it went through so I will just post here also...

I don't think there is a kernel or full dump, but like I said before I can recreate the crash so if you could tell me how to setup windows to create a full dump upon crashing then I can recreate the crash and upload the file.

[cluberti]

Well, this is why I never make assumptions from minidumps - they can be wrong .

I didn't have to go any further than analyze -v to see what's wrong on your box. You've got a hard disk issue:

1: kd> !analyze -v
*******************************************************************************
*																			 *
*						Bugcheck Analysis									*
*																			 *
*******************************************************************************

KERNEL_STACK_INPAGE_ERROR (77)
The requested page of kernel data could not be read in.  Caused by
bad block in paging file or disk controller error.
In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found.  Again, bad hardware.
An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED)  normally indicates
the data could not be read from the disk due to a bad
block.  Upon reboot autocheck will run and attempt to map out the bad
sector.  If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked.  See the knowledge base article on SCSI termination.
Arguments:
Arg1: c000009d, status code
Arg2: c000009d, i/o status code
Arg3: 00000000, page file number
Arg4: 049a8000, offset into page file

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


ERROR_CODE: (NTSTATUS) 0xc000009d - STATUS_DEVICE_NOT_CONNECTED

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR:  0x77_c000009d

DEFAULT_BUCKET_ID:  DRIVER_FAULT

FOLLOWUP_NAME:  ntmsd

MODULE_NAME:  hardware_disk

IMAGE_NAME:  hardware_disk

DEBUG_FLR_IMAGE_TIMESTAMP:  0

STACK_COMMAND:  kb

FAILURE_BUCKET_ID:  0x77_c000009d

BUCKET_ID:  0x77_c000009d

INTERNAL_BUCKET_URL:  http://deviceweb/Bucket/Bucket.aspx?BucketID=1543

OCA_CRASHES:  3077 (in last 90 days)

Followup: ntmsd
---------

[tb582]

What kind of hard disk issue? Why does this problem only happen with quicktime movies?

[cluberti]

I can't tell you exactly what, short of what the dump says - the status code c000009d translates to "STATUS_DEVICE_NOT_CONNECTED". That's all I can tell you - perhaps it's a chipset or disk controller driver issue, but when your machine is crashing, the OS is stating that the device being written to or read from has become disconnected, which almost always signifies a hardware error.

Sorry I can't give you more, but the dump is pretty specific that I PM'ed you.

[cluberti]

OK, looked at your second dump uploaded - similar dump, same error, reported differently:

Quote

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_OBJECT_TERMINATION (f4)
A process or thread crucial to system operation has unexpectedly exited or been
terminated.
Several processes and threads are necessary for the operation of the
system; when they are terminated (for any reason), the system can no
longer function.
Arguments:
Arg1: 00000003, Process
Arg2: 8646e020, Terminating object
Arg3: 8646e194, Process image file name
Arg4: 80604498, Explanatory message (ascii)

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


PROCESS_OBJECT: 8646e020

IMAGE_NAME: csrss.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 41107c1f

MODULE_NAME: csrss

FAULTING_MODULE: 4a680000 csrss

EXCEPTION_RECORD: f63c89d8 -- (.exr fffffffff63c89d8)
ExceptionAddress: 75b7b1c1 (winsrv!UserHardError)
ExceptionCode: c0000006 (In-page I/O error)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 75b7b1c1
Parameter[2]: c000009d
Inpage operation failed at 75b7b1c1, due to I/O error c000009d

EXCEPTION_CODE: (NTSTATUS) 0xc000009d - STATUS_DEVICE_NOT_CONNECTED

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: csrss.exe

ERROR_CODE: (NTSTATUS) 0xc0000006 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The required data was not placed into memory because of an I/O error status of "0x%08lx".

IO_ERROR: (NTSTATUS) 0xc000009d - STATUS_DEVICE_NOT_CONNECTED

EXCEPTION_STR: 0xc0000006_c000009d

FAULTING_IP:
winsrv!UserHardError+0
75b7b1c1 ?? ???

BUGCHECK_STR: 0xF4_IOERR_C000009D

STACK_TEXT:
f63c8520 80633f32 000000f4 00000003 8646e020 nt!KeBugCheckEx+0x1b
f63c8544 80604456 80604498 8646e020 8646e194 nt!PspCatchCriticalBreak+0x75
f63c8574 804dd98f 8646e268 c0000006 f63c89b0 nt!NtTerminateProcess+0x7d
f63c8574 804e4697 8646e268 c0000006 f63c89b0 nt!KiFastCallEntry+0xfc
f63c85f4 80522106 ffffffff c0000006 f63c89f8 nt!ZwTerminateProcess+0x11
f63c89b0 80517e25 f63c89d8 00000000 f63c8d64 nt!KiDispatchException+0x3a0
f63c8d34 804e1298 0069fbe8 0069fc08 00000000 nt!KiRaiseException+0x175
f63c8d50 804dd98f 0069fbe8 0069fc08 00000000 nt!NtRaiseException+0x33
f63c8d50 75b7b1c1 0069fbe8 0069fc08 00000000 nt!KiFastCallEntry+0xfc
0069fed0 75b447a0 00000000 0069feec 00000005 winsrv!UserHardError
0069fff4 00000000 00000000 00000000 00000000 CSRSRV!CsrApiRequestThread+0x18a


STACK_COMMAND: kb

FOLLOWUP_IP:
csrss!_imp__CsrServerInitialization <PERF> (csrss+0x0)+0
4a680000 4d dec ebp

FOLLOWUP_NAME: NtCon

FAILURE_BUCKET_ID: 0xF4_IOERR_C000009D_IMAGE_csrss.exe_DATE_8_4_2004

BUCKET_ID: 0xF4_IOERR_C000009D_IMAGE_csrss.exe_DATE_8_4_2004

Followup: NtCon
---------

Unless I'm in the twilight zone, this is a hardware error.

[cluberti]

Well, thought I'd do some further digging for no apparent reason, and I came up with this - this may be why quicktime is causing your box to crash with a hardware error:

Quote

3: kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
<snipt>
PROCESS 85732020 SessionId: 0 Cid: 09dc Peb: 7ffde000 ParentCid: 02dc
DirBase: 17a65000 ObjectTable: e1931f10 HandleCount: 629.
Image: QuickTimePlayer.exe

3: kd> .process 85732020
Implicit process is now 85732020
3: kd> .reload
Loading Kernel Symbols
....................................................................................................
.......................................................
Loading User Symbols
................................................................
Loading unloaded module list
..........................................
3: kd> kp
ChildEBP RetAddr
f63c8520 80633f32 nt!KeBugCheckEx(unsigned long BugCheckCode = 0xf4, unsigned long P1 = 3, unsigned long P2 = 0x8646e020, unsigned long P3 = 0x8646e194, unsigned long P4 = 0x80604498)+0x1b
f63c8544 80604456 nt!PspCatchCriticalBreak(char * Msg = 0x80604498 "Terminating critical process 0x%p (%s).", void * Object = 0x8646e020, unsigned char * ImageFileName = 0x8646e194 "csrss.exe")+0x75
f63c8574 804dd98f nt!NtTerminateProcess(void * ProcessHandle = 0x8646e268, long ExitStatus = -1073741818)+0x7d
f63c8574 804e4697 nt!KiFastCallEntry(<HRESULT 0x80004005>)+0xfc
f63c85f4 80522106 nt!ZwTerminateProcess(void)+0x11
f63c89b0 80517e25 nt!KiDispatchException(struct _EXCEPTION_RECORD * ExceptionRecord = 0xf63c89d8, struct _KTRAP_FRAME * ExceptionFrame = 0x00000000, struct _KTRAP_FRAME * TrapFrame = 0xf63c8d64, char PreviousMode = 1 '', unsigned char FirstChance = 0x00 '')+0x3a0
f63c8d34 804e1298 nt!KiRaiseException(struct _EXCEPTION_RECORD * ExceptionRecord = 0x0069fbe8, struct _CONTEXT * ContextRecord = 0x0069fc08, struct _KTRAP_FRAME * ExceptionFrame = 0x00000000, struct _KTRAP_FRAME * TrapFrame = 0xf63c8d64, unsigned char FirstChance = 0x00 '')+0x175
f63c8d50 804dd98f nt!NtRaiseException(void)+0x33
f63c8d50 75b7b1c1 nt!KiFastCallEntry(<HRESULT 0x80004005>)+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0069fff4 00000000 0x75b7b1c1
3: kd> !thread
THREAD 85fddab0 Cid 0324.0350 Teb: 7ffdd000 Win32Thread: e12cf340 RUNNING on processor 3
Not impersonating
DeviceMap e1000148
Owning Process 8646e020 Image: csrss.exe
Wait Start TickCount 2249603 Ticks: 0
Context Switch Count 2914 LargeStack
UserTime 00:00:00.0578
KernelTime 00:00:00.0265
Start Address 0x75b44616
LPC Server thread working on message Id 218e4
Stack Init f63c9000 Current f63c8c34 Base f63c9000 Limit f63c6000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 16
ChildEBP RetAddr Args to Child
f63c8520 80633f32 000000f4 00000003 8646e020 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo]) (CONV: stdcall)
f63c8544 80604456 80604498 8646e020 8646e194 nt!PspCatchCriticalBreak+0x75 (FPO: [Non-Fpo]) (CONV: stdcall)
f63c8574 804dd98f 8646e268 c0000006 f63c89b0 nt!NtTerminateProcess+0x7d (FPO: [Non-Fpo]) (CONV: stdcall)
f63c8574 804e4697 8646e268 c0000006 f63c89b0 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ f63c8584)
f63c85f4 80522106 ffffffff c0000006 f63c89f8 nt!ZwTerminateProcess+0x11 (FPO: [2,0,0])
f63c89b0 80517e25 f63c89d8 00000000 f63c8d64 nt!KiDispatchException+0x3a0 (FPO: [Non-Fpo]) (CONV: stdcall)
f63c8d34 804e1298 0069fbe8 0069fc08 00000000 nt!KiRaiseException+0x175 (FPO: [Non-Fpo]) (CONV: stdcall)
f63c8d50 804dd98f 0069fbe8 0069fc08 00000000 nt!NtRaiseException+0x33
f63c8d50 75b7b1c1 0069fbe8 0069fc08 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ f63c8d64)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0069fff4 00000000 00000000 00000000 00000000 0x75b7b1c1

Note that csrss.exe owns the quicktime.exe process. This could be an issue with quicktime making a call to an invalid hardware address, an invalid pagedpool or nonpaged pool memory address, or a request to a portion of the disk that is corrupt - since csrss.exe owns the process, it's likely that quicktime is bringing down csrss.exe when it crashes, causing the bugcheck.

A reinstall of quicktime.exe to see if it still happens, perhaps?



You can see that csrss.exe owns the quicktime process in the line

"Owning Process 8646e020 Image: csrss.exe"

in the dump information pasted in above.

[tb582]

cluberti, on Feb 9 2006, 02:04 PM, said:

A reinstall of quicktime.exe to see if it still happens, perhaps?

You can see that csrss.exe owns the quicktime process in the line

"Owning Process 8646e020 Image: csrss.exe"

in the dump information pasted in above.

Reinstalling Quicktime does not solve the problem... any other ideas?

[LLXX]

Have you Scandisk'd the drive? The analyses posted so far indicate a problem with the disk subsystem hardware.

[cluberti]

TB has an external disk - is it possible the video or your pagefile is on the external hard disk? That's the only logical conclusion I can come to for the "device" in question being listed as disconnected...

[LLXX]

If the external drive is working properly, no errors should occur...

Especially with external devices I recommend checking the cabling. They are more prone to interference than internal ones as the cables are longer and exposed.

[cluberti]

I hate to say this, but this dump still shows a hardware error with a different stop code from before (it's now a stop 77, 0x77_c000009d:

Quote

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_STACK_INPAGE_ERROR (77)
The requested page of kernel data could not be read in. Caused by
bad block in paging file or disk controller error.
In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found. Again, bad hardware.
An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates
the data could not be read from the disk due to a bad
block. Upon reboot autocheck will run and attempt to map out the bad
sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked. See the knowledge base article on SCSI termination.
Arguments:
Arg1: c000009d, status code
Arg2: c000009d, i/o status code
Arg3: 00000000, page file number
Arg4: 01529000, offset into page file

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


ERROR_CODE: (NTSTATUS) 0xc000009d - STATUS_DEVICE_NOT_CONNECTED

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR: 0x77_c000009d

DEFAULT_BUCKET_ID: DRIVER_FAULT

FOLLOWUP_NAME: ntmsd

MODULE_NAME: hardware_disk

IMAGE_NAME: hardware_disk

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0x77_c000009d

BUCKET_ID: 0x77_c000009d

INTERNAL_BUCKET_URL: http://deviceweb/Buc...x?BucketID=1543

OCA_CRASHES: 3096 (in last 90 days)

Followup: ntmsd

I'm sorry, and I can't tell you why quicktime is doing it (other than it's owned by csrss.exe, and appears to be bringing csrss.exe down when it crashes, which is also VERY odd), but the system says there's a hardware error here, and I'm inclined to agree. It may be as simple as running chkdsk /f against all drives on the box, or it could be a bad cable connected to a CD or hard disk - but it's just not something I see going on in any stack in the entire dump. The only stacks I can see with issues are ones with a kernel trap or kernel lock, and these are all csrss.exe processes, which would make sense because if csrss.exe crashes, the whole box will come down.

This error can only be caused by a bad block in the page file, or it is indeed a disk controller/subsystem error. My guess is that it's a bad block in your paging file (perhaps move it to a different drive and reboot?), but it could still be the actual controller on your motherboard (or PCI IDE controller) has a problem (drivers or bad hardware). If it's a bad block in the paging file, you should consider your filesystem suspect and should chkdsk /f the drive right away. If it's a controller error, you should consider replacing the drive, the controller, or both.

Wish I had a better explanation, but I don't - the issue is the filesystem (specifically in the page file location) or the actual controller/cables/hard disk subsystem. Sorry to be the bearer of bad news, but dumps don't lie .

This post has been edited by cluberti: 10 February 2006 - 05:57 PM

[tb582]

cluberti, on Feb 10 2006, 07:55 PM, said:

I hate to say this, but this dump still shows a hardware error with a different stop code from before (it's now a stop 77, 0x77_c000009d:

I'm sorry, and I can't tell you why quicktime is doing it (other than it's owned by csrss.exe, and appears to be bringing csrss.exe down when it crashes, which is also VERY odd), but the system says there's a hardware error here, and I'm inclined to agree. It may be as simple as running chkdsk /f against all drives on the box, or it could be a bad cable connected to a CD or hard disk - but it's just not something I see going on in any stack in the entire dump. The only stacks I can see with issues are ones with a kernel trap or kernel lock, and these are all csrss.exe processes, which would make sense because if csrss.exe crashes, the whole box will come down.

This error can only be caused by a bad block in the page file, or it is indeed a disk controller/subsystem error. My guess is that it's a bad block in your paging file (perhaps move it to a different drive and reboot?), but it could still be the actual controller on your motherboard (or PCI IDE controller) has a problem (drivers or bad hardware). If it's a bad block in the paging file, you should consider your filesystem suspect and should chkdsk /f the drive right away. If it's a controller error, you should consider replacing the drive, the controller, or both.

Wish I had a better explanation, but I don't - the issue is the filesystem (specifically in the page file location) or the actual controller/cables/hard disk subsystem. Sorry to be the bearer of bad news, but dumps don't lie .

Hmm ok thanks.

I usually try to run chkdsk on all my hdd's about once every 2 weeks... I normally right click the hdd - properties- scan disk, but I'm assuming that if I restart my computer using a 98boot disk I can also run it that way on all drives? What is the proper syntax? to run chkdsk/f on all drives?

[cluberti]

Quote

but I'm assuming that if I restart my computer using a 98boot disk I can also run it that way on all drives? What is the proper syntax? to run chkdsk/f on all drives?

If the drives are NTFS, a 98boot disk will do you no good (it can't read NTFS without 3rd party software). You would run the following command to run chkdsk in "fix" mode (the /f):

chkdsk C: /F /R

You should only do one drive at a time (and you should do it after a reboot, do not forcibly dismount any drives if prompted to do so!), and you should run this command for each hard disk volume on your system (obviously substituting the proper drive letter for C:, when appropriate).

[tb582]

Where is the log created of each drive scanned?