Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

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 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
share|improve this question
upload the dmp files instead so that we can look at them with WinDbg. – magicandre1981 Dec 28 '12 at 19:03
I'd like to also see a clear answer for this. By the way, it's an issue only apparent on the latest versions of the AMD driver. Also, it manifests itself if one tries to disable/uninstall the Monitor driver (it doesn't have adverse effect on an old driver) and it also crashes if one tries to uninstall or disable the GPU driver. The old driver normally returns to a basic driver. – j riv Mar 9 '13 at 8:23
Problem remains on 13.3 beta 3. – j riv Mar 25 '13 at 20:07

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.

share|improve this answer
I'd like to also see a clear answer to his question. By the way, it's an issue only apparent on the latest versions of the AMD driver. Also, it manifests itself if one tries to disable/uninstall the Monitor driver (it doesn't have adverse effect on an old driver) and it also crashes if one tries to uninstall or disable the GPU driver. The old driver normally returns to a basic driver. – j riv Mar 9 '13 at 8:24
This is a clear answer. We don't have the source code to the relevant components, so all we can do is guess. Unless you work for Microsoft or AMD, your guess is as good as mine! – allquixotic Mar 10 '13 at 3:17
Wow that's quite a conclusion. "Source code or we can do nothing." Of course you can in several cases there is proper documentation or even a fix. – j riv Mar 10 '13 at 16:15
Well if you have a KB article or a fix available, then by all means, please share it with us. Otherwise, an answer that attempts to lay out some of the possible causes for this is as best as we can get. It would be extremely time-prohibitive for someone to get to the bottom of this without source code, and besides, I don't have his exact laptop model number just laying around. This is a very hardware-specific thing and is thus unlikely to have a widely-known cause, since most computers running Win8 can suspend and resume just fine. – allquixotic Mar 11 '13 at 13:13
Nah, it's just that the overwhelming majority of Windows users either don't reach that deep in asking help for their problem or they never update the generic Windows Update drivers at all (the problem does not appear on ancient or Windows Update drivers). – j riv Mar 11 '13 at 17:58

This has been fixed in the latest (mobility 13.4) stable driver. It appears that they have actively tried to tackle this problem (after reading specific reports about it probably) since the issue appeared to manifest itself in the slightest event of trying to manipulate the related lid mechanism or monitor/display drivers, even when trying to normally upgrade or downgrade the driver. Now, it can even upgrade the driver without a crash leading me to believe they probably actively tackled it with the installation process before and after installation of the new version.

PS. There is a small probability that it coincided with a related Windows update but I doubt it.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .