Studio 1558, BSODs, lockups

[woofer00]

Got a refurb Studio 1558 that was having lockups that didn't generate any dumps or error reports, just power faults and unclean shutdown on reboot. Wiped it and did a clean install of Win7, installed all the drivers, but problems persisted. Flashed to most recent BIOS, started getting bluescreen errors and minidumps in addition to the lockups (may I was actually able to get them now?). Those are attached.

Drivers are the most recent available up on Dell's Site, most recent graphics on ATI discrete card. Windows Update is current, also running MSE as AV. At one point I thought Creative X-FI MB Software was causing problems, but uninstalling had no effect. Memtest did 10 passes, no errors. Primed and used other burn ins for over 12 hours each, all calculations came back clean. Lockups tend to happen while playing flash videos, although it's happened twice while gaming, three times during browsing.

Going to get in touch with Dell in a bit and see what they say about possible hardware problems. As far as I can tell only ntoskrnl and ntkrnlmp are throwing errors, not any drivers, so I might have some kind of odd hardware errors somewhere.

 

[Capt.Jack Sparrow]

Hello Welcome to SF !!

The Dump wasn't that helpful because seems like it didn't record the rouge driver.

I would recommend to Run Hard Drive Diagnostic and Memory Diagnostic

If this turns out clean then i would recommend to Run the Driver Verifier here is the link to enable it.

http://www.sevenforums.com/crash-lo...-driver-verifier-identify-issues-drivers.html

Bugcheck:

[/COLOR]
Product: WinNt, suite: TerminalServer SingleUserTS Personal
[COLOR=black]Built by: 7600.16539.amd64fre.win7_gdr.100226-1909[/COLOR]
[COLOR=black]Machine Name:[/COLOR]
[COLOR=black]Kernel base = 0xfffff800`02c4f000 PsLoadedModuleList = 0xfffff800`02e8ce50[/COLOR]
[COLOR=black]Debug session time: Sat May 22 10:04:30.948 2010 (GMT+6)[/COLOR]
[COLOR=black]System Uptime: 0 days 4:53:33.134[/COLOR]
[COLOR=black]BUGCHECK_STR:  0x1E[/COLOR]
[COLOR=black]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[/COLOR]
[COLOR=black]Product: WinNt, suite: TerminalServer SingleUserTS Personal[/COLOR]
[COLOR=black]Built by: 7600.16539.amd64fre.win7_gdr.100226-1909[/COLOR]
[COLOR=black]Machine Name:[/COLOR]
[COLOR=black]Kernel base = 0xfffff800`02c65000 PsLoadedModuleList = 0xfffff800`02ea2e50[/COLOR]
[COLOR=black]Debug session time: Thu May 20 19:05:47.595 2010 (GMT+6)[/COLOR]
[COLOR=black]System Uptime: 0 days 7:36:46.781[/COLOR]
[COLOR=black]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[/COLOR]
[COLOR=black]Product: WinNt, suite: TerminalServer SingleUserTS Personal[/COLOR]
[COLOR=black]Built by: 7600.16539.amd64fre.win7_gdr.100226-1909[/COLOR]
[COLOR=black]Machine Name:[/COLOR]
[COLOR=black]Kernel base = 0xfffff800`02c1b000 PsLoadedModuleList = 0xfffff800`02e58e50[/COLOR]
[COLOR=black]Debug session time: Mon May 24 13:29:23.706 2010 (GMT+6)[/COLOR]
[COLOR=black]System Uptime: 0 days 2:00:11.892[/COLOR]
[COLOR=black]BUGCHECK_STR:  0x1E[/COLOR]
[COLOR=black]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[/COLOR]
[COLOR=black]Product: WinNt, suite: TerminalServer SingleUserTS Personal[/COLOR]
[COLOR=black]Built by: 7600.16539.amd64fre.win7_gdr.100226-1909[/COLOR]
[COLOR=black]Machine Name:[/COLOR]
[COLOR=black]Kernel base = 0xfffff800`02c0b000 PsLoadedModuleList = 0xfffff800`02e48e50[/COLOR]
[COLOR=black]Debug session time: Mon May 24 21:19:04.202 2010 (GMT+6)[/COLOR]
[COLOR=black]System Uptime: 0 days 0:48:01.278[/COLOR]
[COLOR=black]BUGCHECK_STR:  0x1E[/COLOR]
[COLOR=black]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[/COLOR]
[COLOR=black]Product: WinNt, suite: TerminalServer SingleUserTS Personal[/COLOR]
[COLOR=black]Built by: 7600.16539.amd64fre.win7_gdr.100226-1909[/COLOR]
[COLOR=black]Machine Name:[/COLOR]
[COLOR=black]Kernel base = 0xfffff800`02c4d000 PsLoadedModuleList = 0xfffff800`02e8ae50[/COLOR]
[COLOR=black]Debug session time: Sat May 22 12:09:13.950 2010 (GMT+6)[/COLOR]
[COLOR=black]System Uptime: 0 days 2:04:09.137[/COLOR]
[COLOR=black]BUGCHECK_STR:  0x1E[/COLOR]
[COLOR=black]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[/COLOR]

Hope this helps,
Captain

 

[woofer00]

Expected as much. WinDBG didn't reveal anything on the crashes when I ran through the large dumps. Been running the verifier, but oddly enough it hasnt crashed since then. I may contact Dell and see if they can do anything. May just wipe and reinstall to see if it goes any better. Memtest and HD tests have all come back clean, through multiple passes. This is frustrating. I've seen complaints about the i7 on Dell's Community forums, so it may be a BIOS/chipset driver issue, or possibly poorly matched hardware to the processor.

 

[woofer00]

Noticed that I somehow managed to miss a cluster of drivers the first time I ran verifier, so I checked em all off. Seemed to be okay until I ejected an eSATA drive, then hit a bluescreen that pointed to stdflt.sys, which is an STMicroelectronics driver for an accelerometer (this is a laptop). Very repeatable error. Uninstalled the driver, and reinstalled the most recent version available from Dell, 1.08.1.0. Rinse, repeat, same error pops up under Driver Verifier.

In the changelog for the driver, the release notes seem to suggest that maybe it's just a problem with the verifier, but I can't really be sure. Release notes attached as well. The series of driver_verifier_iomanager_violations is mostly due to me verifying that it's related to stdflt.sys, but I figured I would attach them anyway.

The most recent crash, ironically enough, occurred in the middle of a Dell Online Chat to see if they could provide any insight on my problem. It has also locked up so that I had to hold down the power button to reboot as well. Going to run without the accelerometer drivers for a day to see what happens (although I hate having ? in my device manager)


footnote:
Presently on the phone with Dell Tech Support. The rep unfortunately has little to no knowledge of what a stop error code is, and is just reading diagnostics off the screen I've already run a million times. Their solution is to send me a replacement hard drive and memory even though I've repeatedly told them the diagnostics all passed with flying colors. Go figure.

 

[Capt.Jack Sparrow]

Yes, most of your Dump is pointing to that Driver according to the Log we have to turn off Driver Verifier then once it's rebooted once it says it would be WHQLed (WHQL stands for, "Windows High Quality Labs". Basically it means that the drivers have met some sort of standards for Microsoft and it allows the vendor to say their product is "Designed For Windows"). But in your case i wonder why it's not getting verified.

Lets keep this Driver issue aside what protect are you using ??

Then other thing we could try would be to just uninstall that Driver and make sure you delete it from C:\Windows\system32\DRIVERS then try reboot the System and turn on the Driver Verifier and see if that makes any difference.

Bugcheck:

Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 10:27:17.436 2010 (GMT+6)
System Uptime: 0 days 0:06:58.623
BUGCHECK_STR:  0xA
IRQL_NOT_LESS_OR_EQUAL (a)
IMAGE_NAME:  ntkrnlmp.exe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 05:49:40.778 2010 (GMT+5)
System Uptime: 0 days 1:15:24.980
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
BUGCHECK_STR:  0xc9_2
IMAGE_NAME:  stdflt.sys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 06:10:59.181 2010 (GMT+6)
System Uptime: 0 days 0:20:23.383
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
BUGCHECK_STR:  0xc9_2
IMAGE_NAME:  stdflt.sys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 06:40:19.859 2010 (GMT+5)
System Uptime: 0 days 0:28:12.061
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
BUGCHECK_STR:  0xc9_2
IMAGE_NAME:  stdflt.sys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 07:12:44.446 2010 (GMT+6)
System Uptime: 0 days 0:01:55.663
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
BUGCHECK_STR:  0xc9_2
IMAGE_NAME:  stdflt.sys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 07:23:35.099 2010 (GMT+6)
System Uptime: 0 days 0:02:23.317
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
BUGCHECK_STR:  0xc9_2
IMAGE_NAME:  stdflt.sys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed May 26 07:59:59.403 2010 (GMT+5)
System Uptime: 0 days 0:03:06.620
DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)
BUGCHECK_STR:  0xc9_2
IMAGE_NAME:  stdflt.sys
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hope this helps,
Captain

 

[woofer00]

Uninstalling the drivers and sweeping them off stopped the bluescreens, but the computer still locked up on occasion. In any case, Dell sent a replacement hard drive and memory, along with a standard image that seems pretty stable thus far (48 hours or so. May just need to chalk this up as a hardware malfunction. Oh, well.

 

[woofer00]

Hmph. Dell came in, replaced motherboard, expresscard board, hard drive, and ram under warranty. I opted to just go with the default factory image rather than a clean install to let their "stable" drivers settle in. Updated the firmware, mouse, and video drivers to the most recent releases. Lo and behold, more lockups and BSODs today. Minidump attached, contents as follows:

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


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\SymCache*[url=http://msdl.microsoft.com/download/symbols]Symbol information[/url]
Executable search path is: 
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Machine Name:
Kernel base = 0xfffff800`02a19000 PsLoadedModuleList = 0xfffff800`02c56e50
Debug session time: Wed Jun  9 17:18:20.649 2010 (UTC - 4:00)
System Uptime: 0 days 0:19:51.925
Loading Kernel Symbols
...............................................................
................................................................
...................................
Loading User Symbols

Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff880400bfff4, 2, 1, fffff80002a952b0}

Probably caused by : ntkrnlmp.exe ( nt!KiPageFault+260 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff880400bfff4, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002a952b0, address which referenced memory

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


WRITE_ADDRESS:  fffff880400bfff4 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!ObfReferenceObject+20
fffff800`02a952b0 f0480fc11f      lock xadd qword ptr [rdi],rbx

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

TRAP_FRAME:  fffff88008796a50 -- (.trap 0xfffff88008796a50)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=fffff880400c0024
rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002a952b0 rsp=fffff88008796be0 rbp=0000000000000001
 r8=0000000000000023  r9=0000000000000000 r10=fffff80002a19000
r11=0000000000007532 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!ObfReferenceObject+0x20:
fffff800`02a952b0 f0480fc11f      lock xadd qword ptr [rdi],rbx ds:9b98:0000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002a88b69 to fffff80002a89600

STACK_TEXT:  
fffff880`08796908 fffff800`02a88b69 : 00000000`0000000a fffff880`400bfff4 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`08796910 fffff800`02a877e0 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`08796a50 fffff800`02a952b0 : fffffa80`00000075 00000000`00000030 00000000`00000030 00000000`0000000b : nt!KiPageFault+0x260
fffff880`08796be0 fffff800`02b73a4c : fffffa80`04ab9b98 fffffa80`04ab9b98 00000000`00000001 00000000`00000000 : nt!ObfReferenceObject+0x20
fffff880`08796c10 fffff800`02cf3c1f : fffffa80`04ab9b98 00000000`00000001 00000000`00000000 00000000`00007533 : nt!IopDisassociateThreadIrp+0x9c
fffff880`08796c40 fffff800`02d6f8ab : 00000000`00000000 ffffffff`fffe7960 00000000`00000000 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x1e79a
fffff880`08796c70 fffff800`02d735c1 : 00000000`00000000 fffff800`02d2ea00 fffffa80`04ab9700 00000000`00000000 : nt!PspExitThread+0x58b
fffff880`08796d30 fffff800`02a67b06 : fffff880`009b1180 00000000`00000080 fffffa80`04ab97b0 fffff880`01228534 : nt!PspTerminateThreadByPointer+0x4d
fffff880`08796d80 00000000`00000000 : fffff880`08797000 fffff880`08791000 fffff880`087969c0 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiPageFault+260
fffff800`02a877e0 440f20c0        mov     rax,cr8

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  nt!KiPageFault+260

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4b88cfeb

FAILURE_BUCKET_ID:  X64_0xA_nt!KiPageFault+260

BUCKET_ID:  X64_0xA_nt!KiPageFault+260

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

 

[Jonathan_King]

Please enable driver verifier: http://www.sevenforums.com/crash-lo...-driver-verifier-identify-issues-drivers.html

 

[woofer00]

Presently running it, seems mostly stable thus far. I wasn't having issues until I started using the eSata drive again. I suspect there's something wrong with either the eSata driver that's being installed by default or the drive itself. I've mostly ruled out overheating, video drivers, running dual display, bad OS install, and pretty much every piece of hardware in the laptop itself out as a cause of error. O well. We'll see how this goes this time around.

 

[tonyvr4]

I was wondering if there was any resolution to this issue as I am having a similar issue with my new Studio 15 1558

 

[ttran]

You can start your new thread and attach the minidump to us:
If you wish to have others assist you with your computer's BSOD symptoms, upload the contents of your "\Windows\Minidump" folder. The procedure:

* Copy the contents of \Windows\Minidump to another (temporary) location somewhere on your machine.
* Zip up the copy.
* Start your own thread in the "Crashes and Debugging" section of the forum and attach the ZIP archive to your post using the "paperclip" (file attachments) button.
* Briefly describe the problem history and circumstances in the same post. Somebody will attend to your query as soon as possible.