Finally a strange but working solution for "display driver has stoppedworking and has recovered"

[Laszlo Lebrun]

On some notebooks this error "display driver has stopped working and
has recovered" can drive users crazy.
While that error may be caused by overheating and real hardware defects,
it is frequently caused by an "overoptimization" of power management on
notebooks.

When idle, the GPU does not get enough voltage to restart correctly.
(you are in this case if you get a black screen mostly immediately after
starting doing someting after an idle time and, minutes after, the
screen returns with the message "display driver has stopped working
and has recovered", you can also experience GPU artifacts before the
crashes).

The real solution would have been to address your notebook manufacturer
and insist for a patched BIOS with correct settings in the DSDT. You
will probably not be successful, most of the manufacturers just don't care!

I found a simple, unconventional, but *really working* solution

Since you get the nasty error after beeing idle, the solution is to
avoid idle!

The university of Berkeley issues the BOINC program to donate computer
power for research purposes. You can get their small program and install
in in seconds.
Then tune it to use your GPU to 15% instead of being idle and -Bingo!-
no more crashes, no more GPU artifacts!

My computer never had been so stable.
It is not noticeably slower and runs only a few minutes shorter on
battery, not really worth to mention.
I am happy and am helping mankind for cancer research, the perfect
Win-Win...
;-)

 

[VanguardLH]

On some notebooks this error "display driver has stopped working and
has recovered" can drive users crazy.
While that error may be caused by overheating and real hardware defects,
it is frequently caused by an "overoptimization" of power management on
notebooks.

When idle, the GPU does not get enough voltage to restart correctly.
(you are in this case if you get a black screen mostly immediately after
starting doing someting after an idle time and, minutes after, the
screen returns with the message "display driver has stopped working
and has recovered", you can also experience GPU artifacts before the
crashes).

The real solution would have been to address your notebook manufacturer
and insist for a patched BIOS with correct settings in the DSDT. You
will probably not be successful, most of the manufacturers just don't care!

I found a simple, unconventional, but *really working* solution

Since you get the nasty error after beeing idle, the solution is to
avoid idle!

The university of Berkeley issues the BOINC program to donate computer
power for research purposes. You can get their small program and install
in in seconds.
Then tune it to use your GPU to 15% instead of being idle and -Bingo!-
no more crashes, no more GPU artifacts!

My computer never had been so stable.
It is not noticeably slower and runs only a few minutes shorter on
battery, not really worth to mention.
I am happy and am helping mankind for cancer research, the perfect
Win-Win...
;-)

In the Power Options applet in Control Panel, there are no settings for
monitor power and lid-close event? If so, and rather than keeping the
computer busy so it doesn't go into a low-power (idle) mode, why not
instead configure the monitor to never power down and the lid-close
event to hibernate or shutdown?

 

[charlie]

In the Power Options applet in Control Panel, there are no settings for
monitor power and lid-close event? If so, and rather than keeping the
computer busy so it doesn't go into a low-power (idle) mode, why not
instead configure the monitor to never power down and the lid-close
event to hibernate or shutdown?

I hate to say this, but that's a fairly old "solution" at heart. The
original method was to patch one of the ATI video driver related files
that controlled the low GPU speed. With "current AMD drivers, the patch
should not be necessary. It seems that if the GPU speed was slow enough,
a windows time out occurred.

 

[VanguardLH]

I hate to say this, but that's a fairly old "solution" at heart. The
original method was to patch one of the ATI video driver related files
that controlled the low GPU speed. With "current AMD drivers, the patch
should not be necessary. It seems that if the GPU speed was slow enough,
a windows time out occurred.

Also "old" is keeping the computer busy so it doesn't switch into a
low-power mode. I offered a solution (don't go into low-power mode for
video) that was no newer than the other old solution (keeping the
computer busy so it didn't go into low-power mode). Why waste CPU
cycles keeping the computer busy when you can simply configure the video
to never go into low-power mode in the first place?

Patient: Doctor, it hurts when I do this.
Doctor: Then don't do that.

If going into low-power mode causes problems for some components then
don't go into low-power mode for the affected components. You don't
need to install more software to keep the computer from going into
low-power modes.

 

[Laszlo Lebrun]

In the Power Options applet in Control Panel, there are no settings for
monitor power and lid-close event? If so, and rather than keeping the
computer busy so it doesn't go into a low-power (idle) mode, why not
instead configure the monitor to never power down and the lid-close
event to hibernate or shutdown?

This is happening during regular (but low) usage of the computer, not in
sleep mode and not in the screensaver mode.

 

[Laszlo Lebrun]

I hate to say this, but that's a fairly old "solution" at heart. The
original method was to patch one of the ATI video driver related files
that controlled the low GPU speed. With "current AMD drivers, the patch
should not be necessary. It seems that if the GPU speed was slow enough,
a windows time out occurred.

If you have a patch for a NVidia i'd love to get it.
I have spent months searching for it and installed zillions of drivers
without luck.

 

[VanguardLH]

This is happening during regular (but low) usage of the computer, not in
sleep mode and not in the screensaver mode.

You said "when idle". You're saying between keypresses that the error
happens? Waiting for keypresses is eons to a computer.

"low usage" is still usage. Why would any video card be lowering any of
its voltages if the computer is still in use (not idle)? It still
sounds like you're describing a low-power mode for the video controller
even if the idle period is short when that low-power mode activates.
I've also seen this with some wireless mice: they power down when not
moved around and that's LONG before the idle timeouts specified in the
low-power modes defined in Power Options. Some wireless mice infuriate
their users by themselves (not part of Power Options) going to sleep in
just a minute or two. It takes a bit more movement than normal to get
them to wake up. There is no way for the user to adjust the mouse's own
internal timeout for when it goes into low-power mode. If the same is
happening in the notebook for its video then nothing in the operating
system's Power Options is going to help.

I take it in the /unidentified/ notebook there are no settings in the
BIOS regarding power management that you could disable or reconfigure.
Notebook have their own internal hardware-level power monitoring. They
monitor for system activity, like keyboard, mouse, hard disk, connected
peripherals, and video memory. For your unit to be idle means none of
these hardware devices were used. You didn't type anything on the
keyboard for a long time, didn't move the mouse for a long time, there
were no disk accesses for a long time, none of the peripherals got used
for a long time, and there was no change in the display for a long time.
However, "long time" might not be that long on a notebook trying to
preserve power on an undersized battery. If no activity is detected on
these devices for some time, they get powered down or stops those
devices to conserve power.

For your unidentified notebook, I don't know what is the notebook's idle
expiration on its hardware devices. You sure using Power Options set to
an interval shorter than the notebook's own power management won't
eliminate it stopping the video?

Is there a "fast startup" option on this /unidentified/ notebook?
That's part of the Power Options in the OS. If so, have you tested
resumption of [changing] video output after disabling this feature?

How is BOINC going to work (to keep your computer busy) when you don't
happen to have a network connection? It shares some of your CPU cycles
to assist in peered projects. Without a network, you cannot peer your
host into their network for BOINC to share out your resources. Doesn't
seem like BOINC will be doing anything if it cannot participate in a
BOINC-based project over the Internet. That means BOINC would be idle,
your notebook would be idle, and you'd still run into the GPU problem.
You can't do grid computing unless you're on the grid. Even if you do
have Internet access all the time, it's not installing BOINC that will
solve the problem by keeping your computer's hardware from being idle.
It's BOINC plus subscribing to a project that would then share your
computer on their grid to perform some of the collaborative effort of
the project. So for that solution to be effective means not just BOINC
but BOINC+Internet+project.

Since you're asking about the problem on Windows 7, and since Windows 7
has its Timeout Detection & Recovery (TDR) feature, maybe you should try
disabling that feature. It waits only 2 seconds for your graphics
controller to show what it is doing and display it on the monitor. If
the update fails to appear in that short time, you get the screen flash
and the message you mentioned. It's basically a false positive caused
by an overly short timeout in the OS for too-slow hardware. You never
mentioned trying the registry hack to disable TDR.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
32-bit users:
Create a new DWORD data item under that key.
64-bit users:
Create a new QWORD data item under that key.
Name the key "TdrDelay". It's value is the number of seconds that TDR
waits before timing out.

If this setting is missing in the registry, the default is 2 seconds.
To use a different value, you have to define the key and give a value to
it. Try setting it to 8 to have Win7's TDR feature wait 8 seconds.

Timeout Detection and Recovery of GPUs
http://msdn.microsoft.com/en-us/windows/hardware/gg487368.aspx

Microsoft added this to eliminate what appeared to be frozen computers.
Users could tell they weren't frozen because music was still playing,
they could hear sound events play when they use hotkeys to load a web
browser, the hard disk would change its tune when the user blindly
entered commands, and so on. It wasn't frozen other than there was no
video output. They got a black screen, not a frozen host. TDR was to
force a reset on the controller after a timeout to correct this problem.
Apparently the default of 2 seconds is too slow for some slower or very
busy hardware.

While I got the registry tweak from Googling around to find what others
had done, the Microsoft KB article (which I found later) mentions those
registry settings. Uninstall BOINC and change this registry setting for
TdrDelay to see if that fixes your problem.

 

[Laszlo Lebrun]

You said "when idle". You're saying between keypresses that the error
happens? Yes.

"low usage" is still usage. Why would any video card be lowering any of
its voltages if the computer is still in use (not idle)?

By design. To save energy. Most current GPUs adapt their voltage to the
workload.

It still
sounds like you're describing a low-power mode for the video controller
even if the idle period is short when that low-power mode activates.

Yes. Business as usual.

I've also seen this with some wireless mice: they power down ...

Here we don't speak about power down but reduced voltage.

I take it in the /unidentified/ notebook

This happens for many notebook makes...

there are no settings in the
BIOS regarding power management that you could disable or reconfigure.

No nothin accessible to th user. The DSDT is manufacturer's black magic.

However, "long time" might not be that long on a notebook trying to
preserve power on an undersized battery.

A minute of GPU inactivity is enough...

If no activity is detected on
these devices for some time, they get powered down or stops those
devices to conserve power.

No they reduce voltage... GPUs do not power down until in stand-by or
hibernation.
Stand-by and hibernation work like a charm.

For your unidentified notebook, I don't know what is the notebook's idle
expiration on its hardware devices. You sure using Power Options set to
an interval shorter than the notebook's own power management won't
eliminate it stopping the video?

No, that's irrelevant.

Is there a "fast startup" option on this /unidentified/ notebook?
That's part of the Power Options in the OS. If so, have you tested
resumption of [changing] video output after disabling this feature?

Irrelevant, no power down occured.

How is BOINC going to work (to keep your computer busy) when you don't
happen to have a network connection?

It harvests some job requests and returns the results later when you are
online again. (usually within a week).

It shares some of your CPU cycles to assist in peered projects.

.... some GPU cycles: it uses the graphic card upon CUDA requests.

Without a network, you cannot peer your
host into their network for BOINC to share out your resources. Doesn't
seem like BOINC will be doing anything if it cannot participate in a
BOINC-based project over the Internet.

Of course it runs off-line as well...

That means BOINC would be idle,

BOINC only runs idle when the job buffer is empty (which is usually
several full days of computing when using only 15% of the GPU ressouces.)

your notebook would be idle, and you'd still run into the GPU problem.
You can't do grid computing unless you're on the grid.

You seem uninformed...
Beleive me it works.

Since you're asking about the problem on Windows 7, and since Windows 7
has its Timeout Detection & Recovery (TDR) feature, maybe you should try
disabling that feature. It waits only 2 seconds for your graphics
controller to show what it is doing and display it on the monitor. If
the update fails to appear in that short time, you get the screen flash
and the message you mentioned. It's basically a false positive caused
by an overly short timeout in the OS for too-slow hardware. You never
mentioned trying the registry hack to disable TDR.

Yes I did not mention, I tried that as well, whitout any luck...
The GPU begins to work weird (displays artifacts in menus) early before
Windows notices that something went wrong.
If it only has a very little to do (less than 10% of its power) it works
perfectly.

 

[Laszlo Lebrun]

You said "when idle". You're saying between keypresses that the error
happens? Yes.

"low usage" is still usage. Why would any video card be lowering any of
its voltages if the computer is still in use (not idle)?

By design. To save energy. Most current GPUs adapt their voltage to the
workload.

It still
sounds like you're describing a low-power mode for the video controller
even if the idle period is short when that low-power mode activates.

Yes. Business as usual.

I've also seen this with some wireless mice: they power down ...

Here we don't speak about power down but reduced voltage.

I take it in the /unidentified/ notebook

This happens for many notebook makes...

there are no settings in the
BIOS regarding power management that you could disable or reconfigure.

No nothin accessible to th user. The DSDT is manufacturer's black magic.

However, "long time" might not be that long on a notebook trying to
preserve power on an undersized battery.

A minute of GPU inactivity is enough...

If no activity is detected on
these devices for some time, they get powered down or stops those
devices to conserve power.

No they reduce voltage...

For your unidentified notebook, I don't know what is the notebook's idle
expiration on its hardware devices. You sure using Power Options set to
an interval shorter than the notebook's own power management won't
eliminate it stopping the video?

No that's irrelevant.

Is there a "fast startup" option on this /unidentified/ notebook?
That's part of the Power Options in the OS. If so, have you tested
resumption of [changing] video output after disabling this feature?

Irrelevant, no power down occured.

How is BOINC going to work (to keep your computer busy) when you don't
happen to have a network connection?

It harvests job request and returns the results online. (usually within
a week).

It shares some of your CPU cycles to assist in peered projects.

.... some GPU cycles: it uses the graphic card upon CUDA requests.

Without a network, you cannot peer your
host into their network for BOINC to share out your resources. Doesn't
seem like BOINC will be doing anything if it cannot participate in a
BOINC-based project over the Internet.

Of course it runs off-line as well...

That means BOINC would be idle,
your notebook would be idle, and you'd still run into the GPU problem.
You can't do grid computing unless you're on the grid.

You seem uninformed...

Since you're asking about the problem on Windows 7, and since Windows 7
has its Timeout Detection & Recovery (TDR) feature, maybe you should try
disabling that feature. It waits only 2 seconds for your graphics
controller to show what it is doing and display it on the monitor. If
the update fails to appear in that short time, you get the screen flash
and the message you mentioned. It's basically a false positive caused
by an overly short timeout in the OS for too-slow hardware. You never
mentioned trying the registry hack to disable TDR.

Yes I did not mention, I tried whitout any luck...
The GPU begins to work weird (displays artifacts in menus) early before
Windows notices that something went wrong.

 

[Stan Brown]

This is happening during regular (but low) usage of the computer, not in
sleep mode and not in the screensaver mode.

Not for me. I get it about 10% of the time when coming back from
hibernate or shutdown. It's annoying, but takes only a few seconds
even when it happens.

To say "well, just don't hibernate or shut down then" is ridiculous.
I'm not going o keep my laptop burning 24/7.

 

[Stan Brown]

Since you're asking about the problem on Windows 7, and since Windows 7
has its Timeout Detection & Recovery (TDR) feature, maybe you should try
disabling that feature. It waits only 2 seconds for your graphics
controller to show what it is doing and display it on the monitor. If
the update fails to appear in that short time, you get the screen flash
and the message you mentioned. It's basically a false positive caused
by an overly short timeout in the OS for too-slow hardware. You never
mentioned trying the registry hack to disable TDR.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
32-bit users:
Create a new DWORD data item under that key.
64-bit users:
Create a new QWORD data item under that key.
Name the key "TdrDelay". It's value is the number of seconds that TDR
waits before timing out.

If this setting is missing in the registry, the default is 2 seconds.
To use a different value, you have to define the key and give a value to
it. Try setting it to 8 to have Win7's TDR feature wait 8 seconds.

Timeout Detection and Recovery of GPUs
http://msdn.microsoft.com/en-us/windows/hardware/gg487368.aspx

Microsoft added this to eliminate what appeared to be frozen computers.
[snip]

While I got the registry tweak from Googling around to find what others
had done, the Microsoft KB article (which I found later) mentions those
registry settings. Uninstall BOINC and change this registry setting for
TdrDelay to see if that fixes your problem.

Cool! I had always assumed this was a borderline problem on my
laptop. A Registry fix would remove an annoyance.

But -- the MSDN article makes no mention of QWORD for 64-bit Windows,
an dthe other two values in that key (DxgKmlVersion and UseXPModel)
are both DWORDS. Are you sure a QWORD is correct?

And -- under Graphics Drivers there's a key DCI with a value Timeout
set to 7. (My laptop is 64-bits.) Any idea how this timeout relates
to TdrDelay?

 

[Laszlo Lebrun]

My problem is that it happens when I'm using the computer, not when
idle. It recovers and it may be days or weeks before it occurs again.

me too...
It never happened however when I stressed the GPU eg upon viewing videos
or even transcoding full-power with CUDA, so it is not overheating.
It happened mainly when I just BEGUN doing something e.g. re-opened
Thunderbird after a phone call, which is nasty since then you want to do
something and get a black screen for 3-5 minutes. Sometimes never in a
full week, sometimes twice a day...
Sleep and hibernating never was a problem.

Are you also using a NVidia GPU?

 

[Laszlo Lebrun]

No, I have ATI on an Acer laptop. It usually happens to me when I'm
playing Spider Solitaire but it has also happened just surfing the web
or anything else. I have a fan under my laptop so I don't think it's
heat. It's *never* happened when it wakes up from hibernation or stand
by. Is your machine an Acer?

No it's a Fujitsu E8410 pro with NVidia.
And for me it's definively undervoltage upon low load.
Since i have BOINC to keep my GPU doing a little something, it runs
smoothly.
But afaik BOINC would not use an ATI GPU and run on the CPU instead,
which is not useful for our purpose.

 

[charlie]

You said "when idle". You're saying between keypresses that the error
happens? Yes.

"low usage" is still usage. Why would any video card be lowering any of
its voltages if the computer is still in use (not idle)?

By design. To save energy. Most current GPUs adapt their voltage to the
workload.

It still
sounds like you're describing a low-power mode for the video controller
even if the idle period is short when that low-power mode activates.

Yes. Business as usual.

I've also seen this with some wireless mice: they power down ...

Here we don't speak about power down but reduced voltage.

I take it in the /unidentified/ notebook

This happens for many notebook makes...

there are no settings in the
BIOS regarding power management that you could disable or reconfigure.

No nothin accessible to th user. The DSDT is manufacturer's black magic.

However, "long time" might not be that long on a notebook trying to
preserve power on an undersized battery.

A minute of GPU inactivity is enough...

If no activity is detected on
these devices for some time, they get powered down or stops those
devices to conserve power.

No they reduce voltage...

For your unidentified notebook, I don't know what is the notebook's idle
expiration on its hardware devices. You sure using Power Options set to
an interval shorter than the notebook's own power management won't
eliminate it stopping the video?

No that's irrelevant.

Is there a "fast startup" option on this /unidentified/ notebook?
That's part of the Power Options in the OS. If so, have you tested
resumption of [changing] video output after disabling this feature?

Irrelevant, no power down occured.

How is BOINC going to work (to keep your computer busy) when you don't
happen to have a network connection?

It harvests job request and returns the results online. (usually within
a week).

It shares some of your CPU cycles to assist in peered projects.

... some GPU cycles: it uses the graphic card upon CUDA requests.

Without a network, you cannot peer your
host into their network for BOINC to share out your resources. Doesn't
seem like BOINC will be doing anything if it cannot participate in a
BOINC-based project over the Internet.

Of course it runs off-line as well...

That means BOINC would be idle,
your notebook would be idle, and you'd still run into the GPU problem.
You can't do grid computing unless you're on the grid.

You seem uninformed...

Since you're asking about the problem on Windows 7, and since Windows 7
has its Timeout Detection & Recovery (TDR) feature, maybe you should try
disabling that feature. It waits only 2 seconds for your graphics
controller to show what it is doing and display it on the monitor. If
the update fails to appear in that short time, you get the screen flash
and the message you mentioned. It's basically a false positive caused
by an overly short timeout in the OS for too-slow hardware. You never
mentioned trying the registry hack to disable TDR.

Yes I did not mention, I tried whitout any luck...
The GPU begins to work weird (displays artifacts in menus) early before
Windows notices that something went wrong.

"The GPU begins to work weird (displays artifacts in menus) early before
Windows notices that something went wrong."

This issue seems to be part of a larger one.
Originally, it started showing up on both NVidia and ATI (later AMD)
GPUs possibly in Vista.

The real question was what was/is common that might cause the problem?

Commonality
Windows various later versions, possibly from XP to current.
Likely the windows development environment in general
Since the problems occurred with different GPUs, MBDs and support chip
sets, That sort of lets them out of the potential main problem area.

Another likely prospect has to do with the variation from one GPU to
another (Same GPU that is) Production testing may not test for a
particular problem under conditions that allow it to appear.
This, along with all the other potential variables, seems to be a
probable cause.

Since the problems first showed up, AMD and NVIDIA have been able to
reduce the occurrence rates by revising video drivers. I also assume
that somewhere in the mass of windows updates, Microsoft has also
modified windows.

It sounds like the problems are still there, just partially mitigated by
software work-arounds.

With both AMD and NVIDIA GPUs, I've watched the problem mutate from the
"time out" symptom to application lockups, followed by corrupt video,
then black screen, and even the infamous blue screen. Different video
driver revisions seem to have somewhat different symptoms. Later driver
versions don't seem to "crash" as often.

Interestingly enough, both very light and heavy GPU loading seem to be
involved.

The desktop I'm currently using day to day is a somewhat older one (DDR2
memory for example). It has had various ATI/AMD GPU based video cards
over the years,from the HD 4000 series to the current HD7770 cards.
Originally, Crysis and Crysis 2 were almost unplayable due to video
crashing. Later, Far Cry 2 also had similar problems. NVIDIA cards in my
other P/Cs also had the same general problems. (Although, there were
time periods when the NVIDIA cards and driver versions had lower crash
rates than the ATI cards and drivers.
The CPUs in my P/Cs vary from AMD to INTEL, so the CPUs don't seem to be
the culprit.

On this particular desktop, Win 7 has been updated from "Gold"
to current. It started out as a "reference" system for game application
behavior and so forth. One of the really old non standard windows "mods"
was to "bare bones" the error reporting and logging. This was originally
done to see if it would help with response issues in some "first person
shooter" games.
(There was some improvement, but no real cigar!)

I really got discouraged when two of the same make and model of a video
card (sequential serial no's no less) behaved differently in relation to
the windows "time out" issues on the same system with the same exact
software. Both cards were production cards, not engineering samples.
Further, the problems started occurring after the cards had "burned in"
for a couple of months, rather than just out of the box.
An additional pair of cards from the same GPU family behaved in a
similar fashion.

So far, all I can say is that nothing is perfect!

 

[Laszlo Lebrun]

I really got discouraged when two of the same make and model of a video
card (sequential serial no's no less) behaved differently in relation to
the windows "time out" issues on the same system with the same exact
software.

I am not surprised. Since GPU manufacturers are teasing the hardware to
its limits (with respect to power consumption at the low end and
performance to the high end) it's no wonder when 2 production models
differ by half a percent tolerance and behave differently at these limits.
I don't mind if my notebook (that I use docked to 95%) lasts 3 hours and
45 min instead of 3 hours an 55 min when unplugged. I want stability.
So I just have chosen to avoid these limits.

BTW I can confirm, being running MAC OSX and Linux on the same installed
base that these OS don't make any trouble.
They probably don't tease the GPU as strong to the limits as the Windows
drivers do.

 

[charlie]

I am not surprised. Since GPU manufacturers are teasing the hardware to
its limits (with respect to power consumption at the low end and
performance to the high end) it's no wonder when 2 production models
differ by half a percent tolerance and behave differently at these limits.
I don't mind if my notebook (that I use docked to 95%) lasts 3 hours and
45 min instead of 3 hours an 55 min when unplugged. I want stability.
So I just have chosen to avoid these limits.

BTW I can confirm, being running MAC OSX and Linux on the same installed
base that these OS don't make any trouble.
They probably don't tease the GPU as strong to the limits as the Windows
drivers do.

I wish that the difference was as small as your example.
It was more like a 50% difference in the "time out" occurrence.
Eventually, various video driver revs made the results more consistent.
This system will not experience the "time out" symptom, although it
(instead) may crash in an interesting way.
The last AMD driver rev also changed some of the failure symptoms.

The previous common failure sequence with the "time out" virtually
disabled by extending the timeout to a longer period.
Possible minor to major visible video corruption, with an alternate of
the app screen display/video locking up. Sound (on video card sound
system) may loop. Only the app and associated software is really fully
locked. Other apps and system functions more or less work ok.
"offing" the offending app and tree often restores the P/C to more or
less normal operation, with occasional icon corruption, which refresh
may or may not cure.

Current symptoms with AMD 12.10 drivers and two HD7770 video cards in
"crossfire"
Occasional flicker, and a small vertical display video "jump"
So far none of the hard app crashing has occurred.

 

[VanguardLH]

Cool! I had always assumed this was a borderline problem on my
laptop. A Registry fix would remove an annoyance.

But -- the MSDN article makes no mention of QWORD for 64-bit Windows,
an dthe other two values in that key (DxgKmlVersion and UseXPModel)
are both DWORDS. Are you sure a QWORD is correct?

I don't have a 64-bit version of Windows on my hosts. For me, it
doesn't give me much of real value but incurs lots of headaches. As I
mentioned, I first found most the stuff about TDR from a Google search
showing what others have done. For example:

http://answers.microsoft.com/en-us/...-and-has/6343475b-2262-e011-8dfc-68b599b31bf5

http://support.microsoft.com/kb/256986
"introduced in Windows 2000"

 

[charlie]

Not for me. I get it about 10% of the time when coming back from
hibernate or shutdown. It's annoying, but takes only a few seconds
even when it happens.

To say "well, just don't hibernate or shut down then" is ridiculous.
I'm not going o keep my laptop burning 24/7.

As a continuation of previous comments.

It looks like the problem is caused by several things in combination,
and Microsoft points to the video GPU/Driver. On the other hand,
the real issue seems to be related to how the error that causes the time
out to occur is handled. Documents indicate that this process involves
windows system drivers and functions, quite probably Microsoft's
development documentation, and the revision/version levels
of the development software. At the same time, it looks like Microsoft
is saying that the application itself need to be involved with
recovering from the error.

In not a few cases, the apps were written using much earlier development
packages, and those packages likely did not deal with the
time out problem, or perhaps even document the related functions/calls.

To me and others, most of the onus is shared by Microsoft and the video
driver developers, in that Microsoft sells the development software and
so forth. The drivers really need to have a better error
handling/recovery scheme for apps that cannot/do not handle the error.
Flagging the app as earlier windows version compatible isn't getting the
job done.

 

[charlie]

As a continuation of previous comments.

It looks like the problem is caused by several things in combination,
and Microsoft points to the video GPU/Driver. On the other hand,
the real issue seems to be related to how the error that causes the time
out to occur is handled. Documents indicate that this process involves
windows system drivers and functions, quite probably Microsoft's
development documentation, and the revision/version levels
of the development software. At the same time, it looks like Microsoft
is saying that the application itself need to be involved with
recovering from the error.

In not a few cases, the apps were written using much earlier development
packages, and those packages likely did not deal with the
time out problem, or perhaps even document the related functions/calls.

To me and others, most of the onus is shared by Microsoft and the video
driver developers, in that Microsoft sells the development software and
so forth. The drivers really need to have a better error
handling/recovery scheme for apps that cannot/do not handle the error.
Flagging the app as earlier windows version compatible isn't getting the
job done.

Even worse, the problem can occur with the latest AMD drivers and very
expensive video cards! (I don't know about the latest NVIDIA cards &
drivers!)

 

[Laszlo Lebrun]

Am 16.01.2013 17:54, schrieb Laszlo Lebrun:

No it's a Fujitsu E8410 pro with NVidia.
And for me it's definively undervoltage upon low load.
Since i have BOINC to keep my GPU doing a little something, it runs
smoothly.
But afaik BOINC would not use an ATI GPU and run on the CPU instead,
which is not useful for our purpose.

I must correct myself BOINC runs on some ATI hardware as well.