Hi Guys, Ive got a less than month old Toshiba Equium U300 laptop which i had being using at home for the last 3 weeks previous to this at home with no issues what so ever until tuesday when now back at uni i experienced 12 blue screens of death! So i did all the usual stuff, racked my brains for anything i had recently installed (nothing) any new hardware plugged in (in this case a monitor and tv card so i removed them both) and then also did a system restore to about 4/5 days before hand. The problem is still occuring though, i had about 5 blue screens yesterday and a couple today. I have looked at the crash dumps and there are a couple of drivers that seem to be causing the problems such as dxgkrnl.sys which i believe is to do with directx and there was also a driver by realtek for my audio i think but i can't remember the exact name. Ive got all the usual things like anti virus installed, auto updates turned on so ive now also got service pack 2 etc. As im still experiencing the problem after doing a system restore to a period in which i know there where no problems, im thinking hardware..... What do you guys reckon?? I can post up the crash logs and stuff as well if thats any use.
It's just crashed again! I wasn't doing anything out of the ordinary, i had outlook open, a couple of firefox windows, playing some music using media player and then i started scanning for windows updates and it fell over. Also i checked the log for windows updates and the only ones mentioned are two windows defender updates in the last few days. The posted output log below is pretty typical of the errors i have being getting as it keeps mentioning dxgkrnl.sys and ntkrnlmp.exe. Microsoft (R) Windows Debugger Version 6.8.0004.0 X86 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\Minidump\Mini041708-03.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: Windows Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 6001.18000.x86fre.longhorn_rtm.080118-1840 Kernel base = 0x81c16000 PsLoadedModuleList = 0x81d23930 Debug session time: Thu Apr 17 17:57:20.504 2008 (GMT+1) System Uptime: 0 days 5:39:29.832 Loading Kernel Symbols ............................................................................................................................................................................ Loading User Symbols Loading unloaded module list ...... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 18, {a3f08778, 863fd258, 2, a747d7d3} Map \SystemRoot\System32\drivers\dxgkrnl.sys: Image region 1c800:73e00 does not fit in mapping Probably caused by : ntkrnlmp.exe ( nt!ObpWaitForMultipleObjects+2b4 ) Followup: MachineOwner --------- 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* REFERENCE_BY_POINTER (18) Arguments: Arg1: a3f08778, Object type of the object whose reference count is being lowered Arg2: 863fd258, Object whose reference count is being lowered Arg3: 00000002, Reserved Arg4: a747d7d3, Reserved The reference count of an object is illegal for the current state of the object. Each time a driver uses a pointer to an object the driver calls a kernel routine to increment the reference count of the object. When the driver is done with the pointer the driver calls another kernel routine to decrement the reference count. Drivers must match calls to the increment and decrement routines. This bugcheck can occur because an object's reference count goes to zero while there are still open handles to the object, in which case the fourth parameter indicates the number of opened handles. It may also occur when the objects reference count drops below zero whether or not there are open handles to the object, and in that case the fourth parameter contains the actual value of the pointer references count. Debugging Details: ------------------ CUSTOMER_CRASH_COUNT: 3 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x18 PROCESS_NAME: svchost.exe CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from 81e00899 to 81c82d63 STACK_TEXT: aa6c8990 81e00899 bfd1a9d0 0000001b 0000001b nt!ObfDereferenceObject+0x66 aa6c8bfc 81e005a0 0000001b 00000001 00000001 nt!ObpWaitForMultipleObjects+0x2b4 aa6c8d48 81c6d9aa 0000001b 001c1000 00000001 nt!NtWaitForMultipleObjects+0xcc aa6c8d48 77599a94 0000001b 001c1000 00000001 nt!KiFastCallEntry+0x12a WARNING: Frame IP not in any known module. Following frames may be wrong. 00fafea8 00000000 00000000 00000000 00000000 0x77599a94 STACK_COMMAND: kb FOLLOWUP_IP: nt!ObpWaitForMultipleObjects+2b4 81e00899 85f6 test esi,esi SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!ObpWaitForMultipleObjects+2b4 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 47918b0a FAILURE_BUCKET_ID: 0x18_nt!ObpWaitForMultipleObjects+2b4 BUCKET_ID: 0x18_nt!ObpWaitForMultipleObjects+2b4 Followup: MachineOwner ---------
I have no ideaa what all those numbers mean. But: The ram are usually easily accessible on laptops. Have a look at them and see if they are properly seated.
