^i was thinking of that could be the prob too. actually this has happened quite a few times ard. usually i left my pc on overnite. then the next morning, my whole monitor screen became blank. i have to restart my pc then came up this error. i was having prob with ICS coz previously i didn't have this kind of prob. could it be the NIC driver prob?

try to find more info from event viewer.
event viewer will show you basic info.

Microsoft ® Windows Debugger Version 6.4.0004.4
Copyright © Microsoft Corporation. All rights reserved.


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

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 2
*** 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 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055ab20
Debug session time: Fri Aug 27 00:49:10.406 2004 (GMT+8)
System Uptime: 0 days 0:09:43.010
Unable to load image ntoskrnl.exe, Win32 error 2
*** 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 unloaded module list
.........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 1, ed21c86c, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Probably caused by : ks.sys ( ks!ntoskrnl_NULL_THUNK_DATA+14c )

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

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

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 1, ed21c86c, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

Probably caused by : ks.sys ( ks!ntoskrnl_NULL_THUNK_DATA+14c )

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

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 00000001, The address that the exception occurred at
Arg3: ed21c86c, Trap Frame
Arg4: 00000000

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

FAULTING_IP:
+1
00000001 ?? ???

TRAP_FRAME: ed21c86c -- (.trap ffffffffed21c86c)
ErrCode = 00000000
eax=00000000 ebx=ff811a68 ecx=00000000 edx=00000000 esi=ff811aa8 edi=00000018
eip=00000001 esp=ed21c8e0 ebp=ff6b9f48 iopl=0 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=ed21c364
00000001 ?? ???
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from ed21cb00 to 00000001

SYMBOL_ON_RAW_STACK: 1

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
ed21c8dc ed21cb00 f13eef4d f13ef398 ffffffff 0x1
ff6b9f48 00000000 001a59ec 00000000 45ffaaa0 0xed21cb00


STACK_COMMAND: dds @$csp ; kb

FOLLOWUP_IP:
ks!ntoskrnl_NULL_THUNK_DATA+14c
f13ef398 ffff ???

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: ks!ntoskrnl_NULL_THUNK_DATA+14c

MODULE_NAME: ks

IMAGE_NAME: ks.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107ef8

BUCKET_ID: WRONG_SYMBOLS

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


I got this message...but do not know how to solve it...anyone can help?
and i have the message as philipcs(1st page)..and i downloaded memtest,but i do not know how to make a boot up disk..in the manual,it says the installation is for linux...?

Btw, your symbol fileset (either local or remote) must actually match your OS version. Symbols for XP retail are not the same as XP SP1 and XP SP2 due to file versions difference. The same applies for Win2K. Nowadays I think you need not worry about this as the symbol server will take care of this.

Symbols (.pdb files) for third party drivers are virtually non-existant on the net and are only used internally by hardware/software vendors. So let's say your PC crashes due to a abc123.sys driver fault. You will notice that particular driver caused a break on your debugger but you will not be able to examine in depth the stack information.

Also, you can debug a machine on the remote machine instead of using dump files but you'll need another PC/notebook. This is useful when your PC crashes on bootup.

1. Create an alternate boot option in your debugee's (the machine that's being debugged) boot.ini file. E.g.,

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Debug" /fastdetect /debug /debugport=COM1 /baudrate=115200

2. Connect a null serial cable from your debugger to your debuggee (usually both at COM1).

3. Start windbg from your debugger with the correct com port number and baudrate.

4. When your debuggee boots up, you should be able to see your debugger windbg session spewing text, meaning you're connected

KS.sys is related to Intel Hyper-Threading CPU
Please see the solution from Microsoft below:
http://support.microsoft.com/?kbid=812035

event viwer is the built function in windows.

start --> run --> type: eventvwr

in system log, you can see those error due to system related issue such as driver, hardware error, OS error.

i just wanted to say that "Klpf.sys" is related to Kasperky Anti-Hacker.
an update might fix the problem.
or windows just doesn't like the prog

This post has been edited by bombspec: Apr 22 2005, 10:46 PM