Windows 8 Crashes whenever I close the lid

HP Dv7 (XG300AV)

To have my laptop sleep successfully, I have to tell it to sleep, then once it's asleep close the lid. Sometimes that doesn't work however. Just closing the lid makes the computer attempt to sleep, but it just crashes. I assume there's some drivers I need to update, but I don't know which ones. I've got the latest ATI drivers for my gpu.

Here's the latest dump file. I've also attached a link to my dropbox to download a text file with about 3 weeks worth (~25 dumps).

https://dl.dropbox.com/u/12025874/multiple%20dumps.txt

Most of the errors seem to be caused by monitor.sys, although portcls.sys makes an appearance along with a few others. Thanks!

Dump File         : 122712-14484-01.dmp
Crash Time        : 12/27/2012 11:07:25 PM
Bug Check String  : SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
Bug Check Code    : 0x1000007e
Parameter 1       : ffffffff`c0000005
Parameter 2       : fffff800`4868b1d3
Parameter 3       : fffff880`0b3fdf88
Parameter 4       : fffff880`0b3fd7c0
Caused By Driver  : monitor.sys
Caused By Address : monitor.sys+89b8
File Description  : 
Product Name      : 
Company           : 
File Version      : 
Processor         : x64
Crash Address     : ntoskrnl.exe+711d3
Stack Address 1   : 
Stack Address 2   : 
Stack Address 3   : 
Computer Name     : 
Full Path         : C:\WINDOWS\Minidump\122712-14484-01.dmp
Processors Count  : 8
Major Version     : 15
Minor Version     : 9200
Dump File Size    : 281,976

monitor.sys is the Microsoft-supplied kernel mode filter driver for monitor support (as in, your display; LCD/CRT/etc.)

However, it is unlikely that the heavily-tested, widely-deployed Microsoft driver has a problem. More likely is that one of the other trusted components that this Microsoft driver interacts with is malfunctioning, and thus causing the Microsoft driver to run afoul. This is because the Microsoft driver sometimes has no choice but to execute privileged hardware operations that are ultimately driven by other user-mode or kernel-mode components, which have more hardware-specific information than the generic Microsoft kernel driver. Related drivers include:

• ACPI driver for your motherboard, CPU, and graphics card
• The EDID information provided by your monitor
• The I2C bus driver
• The graphics driver (AMD in your case)
• The PCI Express bridge driver, since anything that is passed through the graphics card to the host CPU has to come over PCI Express

I think this boils down to Windows trying to shut off your monitor, and not being able to, because something in the long "chain" of dependencies to do display power management is malfunctioning. This can be for a lot of different reasons. It may be a race condition between shutting off the display on lid close, and standby, since you said it only crashes when you shut the display without first suspending the system.

Most laptops have a lid switch driver, which notifies the operating system when the lid is closed (the closing of the lid pushes a button), and tries to turn off the monitor when that happens to save energy. So that could be getting caught in the middle, since the system is trying to suspend to RAM as this lid driver is doing its ACPI thing to turn off the monitor. Again, a race condition seems very likely -- a system service might be requested (e.g. the PCI Express bus, or the VESA BIOS) after it has already been suspended as part of the standby process.

Since Windows is closed-source, as are the drivers, nobody but AMD and Microsoft could properly debug this. Probably even HP doesn't have all the needed source code to get to the bottom of it; the most they can do is show AMD/Microsoft what info they have and pray.

Make triple sure that you have the very latest drivers for your motherboard chipset, monitor, any BIOS or firmware updates, latest graphics drivers, and so on. If you're 100% positive that everything is the latest, you are pretty much out of luck. Post-production patch and bugfix updates from vendors such as AMD and HP have been decreasing in quantity and quality in recent years, presumably to cut costs, but at the expense of making consumers suffer through broken drivers and bugs exactly like this one for the lifetime of their product. This is certainly not a unique problem.

If you are not deploying this machine as part of a large enterprise installed base, I doubt you will be able to get AMD/Microsoft/HP to actually take action and produce a functioning patch that addresses the exact issue you are experiencing. You may contact them through their consumer support channels, but in my experience, most of these channels point the finger back at the consumer, telling you to do things like reboot, reinstall your operating system, or RMA the unit. If this is a software defect, which seems incredibly likely from your problem report, then no amount of RMAing is going to fix the problem. The vendor will typically refuse to acknowledge that there is a defect designed right into their product, instead preferring to send the consumer on an endless RMA loop.

You might have a bit more success with open source software, such as GNU/Linux, where anyone with sufficient skill and interest can resolve problems, without depending on the hardware vendor to provide a fix that, in many cases, will never arrive.