Random BSOD / After waking from Sleep! PLZ HELP!

Okay, I took your advice and done that so that driver verification is ON. This made me lol: As soon as it finished saying "Welcome" BOOM: BSOD, I debugged and it was the synTP.sys file. From past experience, that is my touch pad driver. I uninstalled, rebooted, and again after the "Welcome" BOOM: This BSOD Occured, and this one is the

atikmdag.sys

file. Since I can only boot into safe mode (or in Safe Mode w/ networking like I am in now) I cannot uninstall the ATI Catalyst Suite due to the "Windows Installer Service" Cannot be loaded in Safe Mode. Here is the BSOD I got:

Code:

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


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

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82a17000 PsLoadedModuleList = 0x82b5f810
Debug session time: Mon Oct  5 17:41:58.528 2009 (GMT-4)
System Uptime: 0 days 0:01:05.666
Loading Kernel Symbols
...............................................................
................................................................
..........................
Loading User Symbols
Loading unloaded module list
.....
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.  This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 000000f6, Referencing user handle as KernelMode.
Arg2: 0000048c, Handle value being referenced.
Arg3: ab2a2700, Address of the current process.
Arg4: 8f634c7a, Address inside the driver that is performing the incorrect reference.

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

*** WARNING: Unable to verify timestamp for atikmdag.sys
*** ERROR: Module load completed but symbols could not be loaded for atikmdag.sys

BUGCHECK_STR:  0xc4_f6

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME:  CCC.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 82d4bf03 to 82af3d10

STACK_TEXT:  
ae7497d4 82d4bf03 000000c4 000000f6 0000048c nt!KeBugCheckEx+0x1e
ae7497f4 82d50766 0000048c ab2a2700 a04f1cc8 nt!VerifierBugCheckIfAppropriate+0x30
ae749888 82c3b26c 0000048c ae749ba0 00000000 nt!VfCheckUserHandle+0x14f
ae7498bc 82c3b126 0000048c 000f001f 00000000 nt!ObReferenceObjectByHandleWithTag+0x13b
ae7498e0 82d59736 0000048c 000f001f 00000000 nt!ObReferenceObjectByHandle+0x21
ae749908 8f634c7a 0000048c 000f001f 00000000 nt!VerifierObReferenceObjectByHandle+0x21
WARNING: Stack unwind information not available. Following frames may be wrong.
ae749938 8f61e961 00000000 ae749ba0 8e49efc0 atikmdag+0x29c7a
ae749958 8f621b87 ae749ba0 8e49efc0 ae749ba0 atikmdag+0x13961
ae749974 8f61b381 ae749b90 00000020 ae749ba0 atikmdag+0x16b87
ae7499d8 8f61b8ac 00000000 ae749b0c 00000038 atikmdag+0x10381
ae749a04 8fac8435 8e49efc0 ae749a60 87035000 atikmdag+0x108ac
ae749a2c 8fac7e4a ae749a60 21dfffdb 03dedf50 dxgkrnl!DXGADAPTER::DdiEscape+0x46
ae749d28 82a5a42a 03dedf50 03dedf8c 77cd64f4 dxgkrnl!DxgkEscape+0x4c8
ae749d28 77cd64f4 03dedf50 03dedf8c 77cd64f4 nt!KiFastCallEntry+0x12a
03dedf8c 00000000 00000000 00000000 00000000 0x77cd64f4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
atikmdag+29c7a
8f634c7a 3bc7            cmp     eax,edi

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  atikmdag+29c7a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: atikmdag

IMAGE_NAME:  atikmdag.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a162550

FAILURE_BUCKET_ID:  0xc4_f6_VRF_atikmdag+29c7a

BUCKET_ID:  0xc4_f6_VRF_atikmdag+29c7a

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

I turned Verifier Off and am now going to uninstall the catalyst suite and just leave the ATI Drivers. I will post all of my notes and progress here. Again everyone, I want to extend a huge thanks for everyone helping me!

iMarcintosh said:

I turned Verifier Off and am now going to uninstall the catalyst suite and just leave the ATI Drivers. I will post all of my notes and progress here. Again everyone, I want to extend a huge thanks for everyone helping me!

Great job with the troubleshooting. I hope it leads to a problem resolution for you :)

Driver verifier (DV) is not one but around a dozen different mechanisms for trying to spot flaws in drivers and even trigger them on purpose. A potential result of running DV with all of its options enabled is to expose driver flaws that have nothing to do with the original BSOD problem that drove you to DV in the first place. In other words, if it wasn't for DV, that flaw in driverX.sys would stay quietly dormant on the vast majority of systems.

In your specific case, the original issue from the first page of your thread is a problem called "pool corruption". One or more drivers are overwriting "pool" memory regions which do not belong to them. Since you have the luxury of knowing the precise nature of the driver flaw you're seeking to isolate, you may want to deactivate all the other DV extras and use only the mechanism which looks for pool corruption.

"Special Pool" is a subcomponent of DV which focuses solely on pool corruption. This is how you'd activate only special pool, without the other DV bits:

VERIFIER /FLAGS 1 /ALL

Optionally, you can add a "/volatile" switch which will make the settings bite immediately, even without rebooting, but with /volatile the act of rebooting then reverts back to the previous state (deactivates volatile DV settings).

You might want to try testing that for a bit. The aim is to get a BSOD where DV "special pool" catches the original pool corruptor driver.

Okay, so my BAD_POOL_HEADER BSOD is because one of my Drivers (Suspect of mine is the ATI Drivers) is "flooding or overwriting" other regions of the memory pool. Now this is just a bit of my own figuring, but could this be caused by the BIOS or Memory in my computer? Because on the Model Content Page I posted in my last post, there were several Updates for my BIOS. I currently have the latest version (Insyde 1.9). My brother has the Exact same computer as mine, and when he is running Windows 7 he gets the same BSOD exactly with the same effect like that in my video. I will do the DV you suggested with those flags and let you know for sure what driver it is doing it, and what you all suggest I try or do. Again, Thanks so much for the help on this!

iMarcintosh said:

Now this is just a bit of my own figuring, but could this be caused by the BIOS or Memory in my computer?

Yes, unreliable hardware - and that includes the BIOS - can manifest itself as almost any type of crash imaginable, including pool corruption. However, there is nothing yet in these data to suggest that your hardware is definitely responsible. The flickering image corruption in your youtube video can also be caused by a bad driver interfering with the video buffer.

iMarcintosh said:

Because on the Model Content Page I posted in my last post, there were several Updates for my BIOS. I currently have the latest version (Insyde 1.9). My brother has the Exact same computer as mine, and when he is running Windows 7 he gets the same BSOD exactly with the same effect like that in my video.

Your brother's machine will probably share other attributes with yours, including your favourite anti-malware utilities, similar NICs you both purchased at the same time, preferred audio cards... that sort of thing. If the pool corruption on your machine(s) turns out to have software causes, it'll be a driver along those lines, irrespective of the fact that they're currently all up-to-date.

iMarcintosh said:

I will do the DV you suggested with those flags and let you know for sure what driver it is doing it, and what you all suggest I try or do. Again, Thanks so much for the help on this!

No probs :)

If special pool ends up fingering one of the OS drivers as supposedly responsible, you can be 99.9% sure that it's a hardware defect. Has the manufacturer certified the laptop for use with WIn7 at this point?