Originally posted by: Woofmeister
Geez, you're surprisingly untroubled by having to downclock a factory overclocked card. I'd be fuming! Even if its a difference of 10mhz, you should at least be able to run your card at the speed promised. Anyway, running my cards at stock speeds makes no difference, I still get the NSR message in certain games.Originally posted by: Mem
Originally posted by: n7
Originally posted by: Woofmeister
I noticed that Mem who has never experienced the problem (OK, Mem, we get it, you have no problems with Vista evah ) is running a 7800GT while everyone else complaining about the problem on this thread is running 8 series cards. Anybody see a pattern?
Good observation, but the pattern i see is that the AT rigs feature has been broken for years, so the only way to update your rigs is delete the old ones & add new ones...which only works sometimes (i managed to get it to work after trying about 10 times :frown: )
IOW, Mem might be running an 8800...but maybe he's not gaming enough...you don't notice the problems w/o a lot of gaming i've found.
I have changed my ISP and PSU from my main rig (as you know can't edit at moment),but still running 7800GT card.
I'm holding off until next gen of cards,why change now when its all running sweet (at least for me) oh and I don't overclock at all, so don't know if that comes into the equation too.
Btw my factory shipped OC 7800GT card will give me that error message(nvlddmkm stopped responding( at factory default OC speed,I had reduce OC a little,however I had to do same thing in XP with this card even before I installed Vista,thats why I said try reducing OC on your video card even factory shipped ones,works for me FYI only 10mhz underclock so technically still overclocked 7800GT card.
NVIDIA statement on TDR Error Messages
Some Windows Vista users have reported that their systems are displaying an error message that says: "Display driver stopped responding, but has successfully recovered." This is called a Timeout Detection and Recovery error message.
Timeout Detection and Recovery (TDR) is a new feature of Windows Vista that attempts to detect problematic situations and recover to a functional desktop without forcing a reboot. Hangs can occur when the GPU is processing intensive graphics operations, typically during gameplay, and nothing is being updated on the monitor. To the user it appears that the system is frozen with no resolution to the problem; in previous operating systems users generally had to wait a few seconds and then reboot.
The TDR error message "Display driver stopped responding and has recovered" lets the user know that the NVIDIA display driver (specifically the "nvlddmkm.sys" file) has been re-initialized and the GPU is reset without requiring a reboot. The only visible artifact from the recovery is a screen flicker, the result of a screen redraw. Note that some older Microsoft DirectX applications may render to a black screen at the end of the TDR, requiring the user to restart these applications.
TDRs are not specific to a single driver problem, and can occur for a variety of reasons. When they occur, diagnostic information is collected in the form of a debug report that is sent to Microsoft through the Online Crash Analysis (OCA) mechanism if the user opts to provide feedback.
NVIDIA encourages users to submit their own bug reports via the NVIDIA Vista Quality Assurance Program, using the keyword "TDR" in the description of the problem. The NVIDIA bug report link is here:
https://surveys.nvidia.com/ind...=749...8f09e040b4a437a
We understand that many users have expressed frustration with this issue, and we apologize for the inconvenience. Since the NVIDIA v101.41 beta driver release, NVIDIA has been fixing many TDR issues reported by users. Our software team is currently preparing a new driver which will dramatically reduce the number of TDR errors that users have reported on the forums. Thank you for your patience.
More information on TDRs can be found here:
http://www.microsoft.com/whdc/...ispl...dm_timeout.mspx.
Timeout Detection and Recovery of GPUs through WDDM
Updated: November 13, 2006
Introduction
One of the most common stability problems in graphics is when the system appears completely "frozen" or "hung" while processing an end-user command or operation. Users generally wait a few seconds and then reboot the system by pressing the Power button. Usually the graphics processing unit (GPU) is "busy" processing intensive graphical operations, typically during gameplay. This results in nothing being updated on the screen, thus appearing to the user that the system is frozen.
This paper briefly describes the timeout detection and recovery (TDR) process in Windows Vista. It also documents the registry controls so developers can easily debug problems.
Timeout Detection and Recovery
Windows Vista attempts to detect these problematic hang situations and recover a responsive desktop dynamically. In this process, the Microsoft Windows Display Driver Model (WDDM) driver is reinitialized and the GPU is reset. No reboot is necessary, which greatly enhances the user experience. The only visible artifact from the hang detection to the recovery is a screen flicker, which results from resetting some portions of the graphics stack, causing a screen redraw. Some older Microsoft DirectX applications may render to a black screen at the end of this recovery. The end user would have to restart these applications.
The following is a brief overview of the TDR process:
1. Timeout detection: The Video Scheduler component of the Windows Vista graphics stack detects that the GPU is taking more than the permitted quantum time to execute the particular task and tries to preempt this particular task. The preempt operation has a "wait" timeout?the actual "TDR timeout." This step is thus the "timeout detection" phase of the process. The default timeout period in Windows Vista is 2 seconds. If the GPU cannot complete or preempt the current task within the TDR timeout, then the GPU is diagnosed as hung.
2. Preparation for recovery: The operating system informs the WDDM driver that a timeout has been detected and it must reset the GPU. The driver is told to stop accessing memory and should not access hardware after this time. The operating system and the WDDM driver collect hardware and other state information that could be useful for post-mortem diagnosis.
3. Desktop recovery: The operating system resets the appropriate state of the graphics stack. The Video Memory Manager component of the graphics stack purges all allocations from video memory. The WDDM driver resets the GPU hardware state. The graphics stack takes the final actions and restores the desktop to the responsive state. As mentioned earlier, some older DirectX applications may now render just black, and the user may be required to restart these applications. Well-written DirectX 9Ex and DirectX 10 applications that handle "Device Remove" continue to work correctly. The application must release and then recreate its Microsoft Direct3D device and all of its objects. DirectX application programmers can find more information in the Windows SDK.
Error Messaging
Throughout the process of GPU hang detection and recovery, the desktop is unresponsive and thus unavailable to the user. In the final stages of recovery, a brief screen flash occurs that is similar to the one when the screen resolution is changed. After the desktop has been successfully recovered, the following informational message appears to the user.
Error Messaging
The message is also logged in the Windows Vista Event Viewer. Diagnosis information is collected in the form of a debug report that is returned to Microsoft through the Online Crash Analysis (OCA) mechanism if the user opts in to provide feedback.
Registry Keys
The following registry keys are documented for testing purposes only. These registry keys should not be manipulated by any applications outside targeted testing or debugging.
The TDR-related registry keys are located under HKLM\System\CurrentControlSet\Control\GraphicsDrivers.
?
TdrLevel: REG_DWORD. The initial level of recovery. The possible values are:
?
TdrLevelOff (0). ? Detection disabled.
?
TdrLevelBugcheck (1) ? Bug check on detected timeout, for example, no recovery.
?
TdrLevelRecoverVGA (2) ? Recover to VGA (not implemented).
?
TdrLevelRecover(3) ? Recover on timeout. This is the default value.
?
TdrDelay: REG_DWORD. The number of seconds that the GPU is allowed to delay the preempt request from the scheduler. This is effectively the timeout threshold. The default value is 2.
?
TdrDdiDelay: REG_DWORD. The number of seconds that the operating system allows threads to leave the driver. After a specified time, the operating system bug checks the system with the code VIDEO_TDR_FAILURE (0x116). The default value is 5.
?
TdrTestMode: REG_DWORD: Internal test usage.
?
TdrDebugMode: REG_DWORD: The debugging-related behavior of the TDR process.
?
TDR_DEBUG_MODE_OFF (0) breaks to kernel debugger before the recovery to allow investigation of the timeout.
?
TDR_DEBUG_MODE_IGNORE_TIMEOUT (1) ignores any timeout.
?
TDR_DEBUG_MODE_RECOVER_NO_PROMPT (2) recovers without break into the debugger. This is the default value.
?
TDR_DEBUG_MODE_RECOVER_UNCONDITIONAL (3) recovers even if some recovery conditions are not met (for example, recovers on consecutive timeouts).
Next Steps
Graphics hardware vendors:
? Ensure that graphics operations (that is, DMA buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and gameplay.
Graphics software vendors:
? Ensure that the DirectX graphics application does not run at a low frames per second (FPS) rate. As the FPS decreases, the likelihood of the GPU getting reset increases. If the application is running at 10 FPS or lower and a complex graphics operation is about to start, then a flush can be inserted.
? For running benchmark tests on low-end GPUs, use the aforementioned registry keys that control the TDR timeout. Remember that they should not be used in production systems because it would affect overall system stability and robustness. Use these keys only as a final solution.
System manufacturers:
? Work with the graphics hardware vendor to diagnose the TDR debug reports.
? Remember that any system that uses the aforementioned TDR registry keys to change the default values is a Windows Logo Program violation.
Originally posted by: Woofmeister
Seek and ye shall find. From the NVIDIA Forums:
NVIDIA statement on TDR Error Messages
Some Windows Vista users have reported that their systems are displaying an error message that says: "Display driver stopped responding, but has successfully recovered." This is called a Timeout Detection and Recovery error message.
Timeout Detection and Recovery (TDR) is a new feature of Windows Vista that attempts to detect problematic situations and recover to a functional desktop without forcing a reboot. Hangs can occur when the GPU is processing intensive graphics operations, typically during gameplay, and nothing is being updated on the monitor. To the user it appears that the system is frozen with no resolution to the problem; in previous operating systems users generally had to wait a few seconds and then reboot.
The TDR error message "Display driver stopped responding and has recovered" lets the user know that the NVIDIA display driver (specifically the "nvlddmkm.sys" file) has been re-initialized and the GPU is reset without requiring a reboot. The only visible artifact from the recovery is a screen flicker, the result of a screen redraw. Note that some older Microsoft DirectX applications may render to a black screen at the end of the TDR, requiring the user to restart these applications.
TDRs are not specific to a single driver problem, and can occur for a variety of reasons. When they occur, diagnostic information is collected in the form of a debug report that is sent to Microsoft through the Online Crash Analysis (OCA) mechanism if the user opts to provide feedback.
NVIDIA encourages users to submit their own bug reports via the NVIDIA Vista Quality Assurance Program, using the keyword "TDR" in the description of the problem. The NVIDIA bug report link is here:
<a target=_blank class=ftalternatingbarlinklarge href="https://surveys.nvidia.com/index.jsp?pi=749...8f09e040b4a437a">https://surveys.nvidia.com/.........8f09e040b4a437a</a>
We understand that many users have expressed frustration with this issue, and we apologize for the inconvenience. Since the NVIDIA v101.41 beta driver release, NVIDIA has been fixing many TDR issues reported by users. Our software team is currently preparing a new driver which will dramatically reduce the number of TDR errors that users have reported on the forums. Thank you for your patience.
More information on TDRs can be found here:
http://www.microsoft.com/whdc/...ispl...dm_timeout.mspx.
Then following the link we get to the WHDC Page
Timeout Detection and Recovery of GPUs through WDDM
Updated: November 13, 2006
Introduction
One of the most common stability problems in graphics is when the system appears completely "frozen" or "hung" while processing an end-user command or operation. Users generally wait a few seconds and then reboot the system by pressing the Power button. Usually the graphics processing unit (GPU) is "busy" processing intensive graphical operations, typically during gameplay. This results in nothing being updated on the screen, thus appearing to the user that the system is frozen.
This paper briefly describes the timeout detection and recovery (TDR) process in Windows Vista. It also documents the registry controls so developers can easily debug problems.
Timeout Detection and Recovery
Windows Vista attempts to detect these problematic hang situations and recover a responsive desktop dynamically. In this process, the Microsoft Windows Display Driver Model (WDDM) driver is reinitialized and the GPU is reset. No reboot is necessary, which greatly enhances the user experience. The only visible artifact from the hang detection to the recovery is a screen flicker, which results from resetting some portions of the graphics stack, causing a screen redraw. Some older Microsoft DirectX applications may render to a black screen at the end of this recovery. The end user would have to restart these applications.
The following is a brief overview of the TDR process:
1. Timeout detection: The Video Scheduler component of the Windows Vista graphics stack detects that the GPU is taking more than the permitted quantum time to execute the particular task and tries to preempt this particular task. The preempt operation has a "wait" timeout?the actual "TDR timeout." This step is thus the "timeout detection" phase of the process. The default timeout period in Windows Vista is 2 seconds. If the GPU cannot complete or preempt the current task within the TDR timeout, then the GPU is diagnosed as hung.
2. Preparation for recovery: The operating system informs the WDDM driver that a timeout has been detected and it must reset the GPU. The driver is told to stop accessing memory and should not access hardware after this time. The operating system and the WDDM driver collect hardware and other state information that could be useful for post-mortem diagnosis.
3. Desktop recovery: The operating system resets the appropriate state of the graphics stack. The Video Memory Manager component of the graphics stack purges all allocations from video memory. The WDDM driver resets the GPU hardware state. The graphics stack takes the final actions and restores the desktop to the responsive state. As mentioned earlier, some older DirectX applications may now render just black, and the user may be required to restart these applications. Well-written DirectX 9Ex and DirectX 10 applications that handle "Device Remove" continue to work correctly. The application must release and then recreate its Microsoft Direct3D device and all of its objects. DirectX application programmers can find more information in the Windows SDK.
Error Messaging
Throughout the process of GPU hang detection and recovery, the desktop is unresponsive and thus unavailable to the user. In the final stages of recovery, a brief screen flash occurs that is similar to the one when the screen resolution is changed. After the desktop has been successfully recovered, the following informational message appears to the user.
Error Messaging
The message is also logged in the Windows Vista Event Viewer. Diagnosis information is collected in the form of a debug report that is returned to Microsoft through the Online Crash Analysis (OCA) mechanism if the user opts in to provide feedback.
Registry Keys
The following registry keys are documented for testing purposes only. These registry keys should not be manipulated by any applications outside targeted testing or debugging.
The TDR-related registry keys are located under HKLM\System\CurrentControlSet\Control\GraphicsDrivers.
?
TdrLevel: REG_DWORD. The initial level of recovery. The possible values are:
?
TdrLevelOff (0). ? Detection disabled.
?
TdrLevelBugcheck (1) ? Bug check on detected timeout, for example, no recovery.
?
TdrLevelRecoverVGA (2) ? Recover to VGA (not implemented).
?
TdrLevelRecover(3) ? Recover on timeout. This is the default value.
?
TdrDelay: REG_DWORD. The number of seconds that the GPU is allowed to delay the preempt request from the scheduler. This is effectively the timeout threshold. The default value is 2.
?
TdrDdiDelay: REG_DWORD. The number of seconds that the operating system allows threads to leave the driver. After a specified time, the operating system bug checks the system with the code VIDEO_TDR_FAILURE (0x116). The default value is 5.
?
TdrTestMode: REG_DWORD: Internal test usage.
?
TdrDebugMode: REG_DWORD: The debugging-related behavior of the TDR process.
?
TDR_DEBUG_MODE_OFF (0) breaks to kernel debugger before the recovery to allow investigation of the timeout.
?
TDR_DEBUG_MODE_IGNORE_TIMEOUT (1) ignores any timeout.
?
TDR_DEBUG_MODE_RECOVER_NO_PROMPT (2) recovers without break into the debugger. This is the default value.
?
TDR_DEBUG_MODE_RECOVER_UNCONDITIONAL (3) recovers even if some recovery conditions are not met (for example, recovers on consecutive timeouts).
Next Steps
Graphics hardware vendors:
? Ensure that graphics operations (that is, DMA buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and gameplay.
Graphics software vendors:
? Ensure that the DirectX graphics application does not run at a low frames per second (FPS) rate. As the FPS decreases, the likelihood of the GPU getting reset increases. If the application is running at 10 FPS or lower and a complex graphics operation is about to start, then a flush can be inserted.
? For running benchmark tests on low-end GPUs, use the aforementioned registry keys that control the TDR timeout. Remember that they should not be used in production systems because it would affect overall system stability and robustness. Use these keys only as a final solution.
System manufacturers:
? Work with the graphics hardware vendor to diagnose the TDR debug reports.
? Remember that any system that uses the aforementioned TDR registry keys to change the default values is a Windows Logo Program violation.
So, bottom line, no solution as yet, but at least we know what to call the problem--"Timeout Detection and Recovery Errors." Yay us!
This part intrigues me :
Ensure that graphics operations (that is, DMA buffer completion) take no more than 2 seconds in end-user scenarios such as productivity and gameplay.
Anybody want to bet the the problem is with the DMA (direct memory access) buffers on NVIDIA G80s?
Originally posted by: BS
Just like I was saying looks like a Vista issue to me. Since it doesn't just happen with Nvidia video cards.
Originally posted by: lopri
It was extremely annoying, but in my case relieving the NB of some stress by loosening memory configuration helped a lot. Haven't experienced this issue on DFI NF4 SLI-D with GTS 320, tough.
Originally posted by: Mem
Originally posted by: BS
Just like I was saying looks like a Vista issue to me. Since it doesn't just happen with Nvidia video cards.
I would say more of a driver/hardware issue ,you can't blame Vista for everything,its an OS not a fix it all for everything.
Remember most people don't have problems so this points it towards driver/hardware combo rather then OS,not much you can do if its the case,apart from try my suggestions in my previous post to rule out other possible causes.
Originally posted by: Narse
snip
Sorry you're biting a wrong person. I do not know 1) whether there is any co-relation between DMA buffer and memory timings, and 2) if so how. (although I have my own suspicion, I intentionally omitted that part because again, I don't have enough knowledge to back my hypothesis)Originally posted by: Woofmeister
Originally posted by: lopri
It was extremely annoying, but in my case relieving the NB of some stress by loosening memory configuration helped a lot.
OK Lopri, I'll bite. How would loosening memory timings on the MOBO affect DMA buffer on the graphics card? Not saying you're wrong, just trying to understand your thinking.
Originally posted by: Mem
Also overclocked video cards can cause this problem too,underclocking fixes it.
Originally posted by: n7
<blockquote>quote:
Originally posted by: BS
Dont be so quick on the gun I have an HD2900XT and to have got the driver not responding problem a few times. This could be a Vista problem.</blockquote>
Good god i hope not.
I highly doubt it though, since my X1900 XT ran more than fine in Vista 32 & then 64 for the last half a year.
All my problems have started after getting this 8800 GTX...
Originally posted by: Woofmeister
<blockquote>quote:
Originally posted by: lopri
It was extremely annoying, but in my case relieving the NB of some stress by loosening memory configuration helped a lot. Haven't experienced this issue on DFI NF4 SLI-D with GTS 320, tough.</blockquote>
OK Lopri, I'll bite. How would loosening memory timings on the MOBO affect DMA buffer on the graphics card? Not saying you're wrong, just trying to understand your thinking. Since I'm using NVIDIA EPP "set and forget" memory timings (Max OC) I'm open to suggestion.
A computer that has NVIDIA G80 series graphic drivers installed stops responding
Originally posted by: Woofmeister
Update and Bump There's a Vista update from Microsoft that supposedly resolves some Vista compatibility issues including:
A computer that has NVIDIA G80 series graphic drivers installed stops responding
Get it here.
I hope to God this works.
Originally posted by: Stangs55
Originally posted by: Woofmeister
Update and Bump There's a Vista update from Microsoft that supposedly resolves some Vista compatibility issues including:
A computer that has NVIDIA G80 series graphic drivers installed stops responding
Get it here.
I hope to God this works.
It doesn't
Originally posted by: Stangs55
Originally posted by: Woofmeister
Update and Bump There's a Vista update from Microsoft that supposedly resolves some Vista compatibility issues including:
A computer that has NVIDIA G80 series graphic drivers installed stops responding
Get it here.
I hope to God this works.
It doesn't
Originally posted by: WT
I've had this issue crop up since 10/11, with over 20 instances a day of this error. Its gotten so bad that it even happens in 2D, not just in games. I posted in the eVGA forums in a 2+ page thread that only started on 10/3, so it seems this nvlddmkm error is a fairly common error. Using the 163.69 drivers on an MSI P6N (i650) with an e6600 that I had clocked to 3.2 but backed down to 3.0 just in case. Buffalo Firestix as well, but I do have Super Talent DDR2-800 sticks to swap out in case this is a RAM issue.
This needs fixed, as I am watching all these new games pass me by, and I sit here with a $1,400 internet appliance unable to play ANY games.