For a few months I've got a serious problem with an error - "Display driver stopped responding and has recovered" in Esenthel. It's a bit complicated, so let me explain.

My video card: Radeon HD 3870 X2
OS: Windows 7, 64bit

   

They say it's a common problem and can be caused almost by everything, from hardware malfunction to corrupted drivers. It happened for me for the first time in September 2012, when Guild Wars 2 came out. It was the only game/application that caused it. Screen just freezes for a moment, then turns black and the info about recovery pops out. Sometimes it finishes at that, and sometimes it will repeat the same thing over and over.

After some time (don't remember exactly when, but probably around February 2013) it started to happen in the Esenthel as well. In the World Editor, to be exact. It's so random bug, that I'm unable to find the source. It just happens and drives me crazy, because there are days I'm not able to work at all.

What I tried to do to stop it - formatting the HDD, cleaning the PC inside, downgrading video card drivers (even to 2009 ones - nothing), updating every other driver in the system, working on clean Esenthel build (without our changes), even applying the Microsoft register solution from the first page in Google's search, and so on. I even went to PC service and they said computer had been working fine on newest drivers for a few days with 3DMark turned on. And after returning home and starting Esenthel again... yes, exactly.

So there are only two applications that cause this thing on my card - Guild Wars 2 and Esenthel's World Editor (first one from the beginning, Esenthel for a few months and I worked on it for more than two years now). Every other game works great, really. Guild Wars 2 Support told me that the game was never tested on such dual video cards and that they suggest to change it, just like that (after 5,5 years it still runs even newest games without bigger problems, so...). I of course thought about AMD just screwing the drivers (again...) but downgrade didn't worked as well, which is extremely strange in this case. They stopped supporting my card around September 2012, so I now have the newest version available (which is some beta 3.14 Catalyst version that, according to the site below, "Resolves a driver crash in Company of Heroes 2"...).

http://support.amd.com/us/gpudownload/wi...sta64.aspx

So, summing it up, I seriously need some advice. Everything else works flawless, so I doubt it's a hardware issue. Esenthel, do you know what can cause such problem in your editor? You are probably my best chance to find a solution right now.

First thought that comes to my mind is that Esenthel doesn't support SLI/Crossfire to my knowledge.

Thanks for quick reply. The trick is, it's not SLI or Crossfire, it's a single video card with two chips.

Edit:
Sorry, that probably is SLI, my bad. But it worked perfectly fine for two years in Esenthel 1.0 (I'm not working in 2.0, forgot to mention that).

Edit 2:
Ok, nevermind. xD I just find out it is NOT SLI after all. This card has two chips on one integrated circuit. Source (in Polish) - http://www.pcformat.pl/Karty-grafiki-pod...0,strona,2

AMD uses Crossfire, NVidia uses SLI, and yes it is crossfire, it is handled internally by the card, and whatever issues that might come from that is up to AMD drivers. Hence why I don't trust dual GPU cards, from my experience you can turn off crossfire if you meet an application which is being difficult because of it. from what I know it should be possible to disable it by turning of Catalyst AI..actually I believe AMD(Not sure if actually AMD makes it or not) made a program named RadeonPro for more extensive control on crossfire and dual-gpu cards.

Edit: Added link.
RadeonPro

I have AI turned off all the time. It often worked bad with older games. For now I found options you suggested in CCC, so will use RadeonPro when it will be really needed (I don't know what to choose there anyway ).

So... I disabled the CrossFireX for all applications and for editor specifically, the bug showed up. Then I tried to work with AI turned on (and with and without CrossFireX), but nothing as well.

As I said before - I worked with this editor for more than two years. And this computer is still the same, without any modifications. For half a year this bug is making my work almost impossible. There are days I can work all day without seeing it, and days like today, when I see it all the time. :(

mhhh read this http://answers.microsoft.com/en-us/windo...91d?page=1

but especially last page:

http://answers.microsoft.com/en-us/windo...1d?page=30

Another Solution is here:
http://www.instructables.com/id/How-to-F...mkm-Error/

Thanks for suggestions, but I tried many of those already. :( The worst thing about this is this randomness - this bug can be caused by anything. But I spent all day thinking about it and testing and must check one more thing - for now I can't replicate the bug on all maps. There is one place in particular where it happens a lot. So I will try to work on a different map (I shouldn't, but it's better than doing nothing) and will see if the bug occurs even once. To be honest I never thought about the cause being connected to a map.

if it is connected to map it is a memory error like ram, graphics ram or hdd. Random errors with different irq errors are often a ram register issue. You did a RAM-Test? http://hcidesign.com/memtest/download.html

I did a quick test (too short I think) of graphics ram some time ago. Thanks for the link - will run it during the night.

It seems I tested ram last time - I remember this program. It didn't find anything this night though.

   

How can I test my video card memory?

I also worked three hours straight without crash on another map. So maybe the map I was working on for so long really is corrupted in some way or there are effects/shaders there which sometimes cause the driver's crash. I sent the map files to Esenthel and hope he has some way to check its data consistency. Maybe one of our tools inserted some trash data in there.

Try also looking at your Windows Event Viewer > System logs. See what error codes it gives when the GPU drivers reset-is it the same error every time?
I'd also recommend trying to run it without Aero or any other programs running. There is a possibility of programs conflicting with each other(I've seen stranger things).
Did you try changing some of the graphics settings in Esenthel? It could be some technique the GPU has issues with like AA, or some lighting option, etc.
If the PC service people you took it to tested it with GW2 or Esenthel and it didn't have the issue, then it may be worth looking into a UPS/Line conditioner. People seriously underestimate what kind of strange issues sub-optimal power can cause. Program crashes, hangs, freezes, blue screens, etc.

Thanks for suggestions. I tried turning off Aero and applications the other day, experimented with Esenthel settings as well. I also thought about UPS some time ago and it turned out it is too weak for my PC (I discovered it when it started to make noise because computer was draining power quicker than it was able to recharge it... or so I guess). Now I don't use one.

So I'm investigating the corrupted map trace. First I divided it into two parts and... I'm able to work without any problems in the place bug was most common! At least for now. I tried to add one more line of area files to this part and then, after just few seconds - driver crushed. After returning to the previous state I'm still able to work without problems. Will try to work only on those "corrupted" areas and see what I can find out.

I was also working with Windows Event Viewer turned on, as you suggested. It showed, during the bug, that at the same time (16:36:23):

Quote:A request to disable the Desktop Window Manager was made by process (4)

Quote:The Desktop Window Manager was unable to start because composition was disabled by a running application

Then Firefox crushed (I'm often using it during work and listen to music through YouTube; that's probably Flash crushing, but I encountered this bug even without Firefox turned on) (16:36:35 - when the screen turned on again probably):

Quote:Faulting application name: plugin-container.exe, version: 22.0.0.4917, time stamp: 0x51c06ab5
Faulting module name: mozalloc.dll, version: 22.0.0.4917, time stamp: 0x51c05025
Exception code: 0x80000003

And also Windows Error Reporting (16:36:37):

Quote:Fault bucket , type 0
Event Name: LiveKernelEvent
Response: Not available
Cab Id: 0

I guess it's error info that showed on the screen about Firefox crushing. There's also one information at 16:37:56, probably when I hit button after making the screen of the whole mess:

   

Most of it is probably irrelevant. I think that's just Flash crushing because of the driver crash, which crashed because of... something in the map. I'm almost sure about it now. Still testing.

For now I replicated the bug (still not sure what cause it, I'm just flying around) and in Windows Event Viewer found info about Windows Error Reporting I didn't copied in full last time:

Quote:Fault bucket , type 0
Event Name: LiveKernelEvent
Response: Not available
Cab Id: 0

Problem signature:
P1:
P2:
P3:
P4:
P5:
P6:
P7:
P8:
P9:
P10:

Attached files:
C:\Windows\LiveKernelReports\WATCHDOG\WD-20130802-1808.dmp
C:\Windows\Temp\WER-23752025-0.sysdata.xml
C:\Windows\Temp\WER7037.tmp.WERInternalMetadata.xml

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_0_0_cab_12a27056

Analysis symbol:
Rechecking for solution: 0
Report Id: c7b3247b-fb8d-11e2-885b-001d7d035039
Report Status: 4

So I've found this "Kernel_0_0_cab_12a27056" folder and using the site below:
http://windows7themes.net/how-to-open-dm...ows-7.html

...opened dmp file. And here it is. Any help with deciphering it is welcome.

Quote:*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

VIDEO_TDR_TIMEOUT_DETECTED (117)
The display driver failed to respond in timely fashion.
(This code can never be used for real bugcheck).
Arguments:
Arg1: fffffa8003d78010, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: fffff88003f72eec, The pointer into responsible device driver module (e.g owner tag).
Arg3: 0000000000000000, The secondary driver specific bucketing key.
Arg4: 0000000000000000, Optional internal context dependent data.

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


FAULTING_IP:
atikmpag+8eec
fffff880`03f72eec ?? ???

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_TDR_TIMEOUT

TAG_NOT_DEFINED_202b: *** Unknown TAG in analysis list 202b


BUGCHECK_STR: 0x117

PROCESS_NAME: System

CURRENT_IRQL: 0

STACK_TEXT:
fffff880`0771d630 fffff880`040da64b : fffffa80`03d78010 fffff880`04126f57 fffffa80`03d78010 fffff880`040a8843 : watchdog!WdDbgReportRecreate+0xa3
fffff880`0771db50 fffff880`040db310 : fffff8a0`0a8c57c0 fffff8a0`0a8c57c0 00000000`00000080 fffffa80`03d78010 : dxgkrnl!TdrUpdateDbgReport+0xcb
fffff880`0771dba0 fffff880`040af6b3 : 00000000`00000001 fffffa80`05707000 00000000`00000000 fffff880`0000005d : dxgkrnl!TdrCollectDbgInfoStage2+0x220
fffff880`0771dbd0 fffff880`040dbe63 : fffffa80`05632658 ffffffff`fffe7960 fffffa80`03d78010 00000000`00000000 : dxgkrnl!DXGADAPTER::Reset+0xef
fffff880`0771dc80 fffff880`041ab03d : fffffa80`04869a40 00000000`00000080 00000000`00000000 fffffa80`05632010 : dxgkrnl!TdrResetFromTimeout+0x23
fffff880`0771dd00 fffff800`03530ede : 00000000`fffffc32 fffffa80`05beb760 fffffa80`03cd1b30 fffffa80`05beb760 : dxgmms1!VidSchiWorkerThread+0x101
fffff880`0771dd40 fffff800`03283906 : fffff800`0340de80 fffffa80`05beb760 fffff800`0341bcc0 00000000`000dabb3 : nt!PspSystemThreadStartup+0x5a
fffff880`0771dd80 00000000`00000000 : fffff880`0771e000 fffff880`07718000 fffff880`09997d70 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
atikmpag+8eec
fffff880`03f72eec ?? ???

SYMBOL_NAME: atikmpag+8eec

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: atikmpag

IMAGE_NAME: atikmpag.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5177fec0

FAILURE_BUCKET_ID: X64_0x117_IMAGE_atikmpag.sys

BUCKET_ID: X64_0x117_IMAGE_atikmpag.sys

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

Event Viewer logs events even when not running. Scroll down to the time of the last time your drivers reset, and see what the Event Viewer says. Often times, the 0x code helps pinpoint the problem. You had it in the pasting of the FireFox/flash crash.

Another thing to try is if you have a spare GPU, put it in your computer instead for a while to rule out the GPU as the culprit.

There are always three things listed there after driver crash:

1. Desktop Window Manager

Quote:A request to disable the Desktop Window Manager was made by process (4)

2. Desktop Window Manager

Quote:The Desktop Window Manager was unable to start because composition was disabled by a running application

3. Windows Error Reporting

Quote:Fault bucket , type 0
Event Name: LiveKernelEvent
Response: Not available
Cab Id: 0

Problem signature:
P1:
P2:
P3:
P4:
P5:
P6:
P7:
P8:
P9:
P10:

Attached files:
C:\Windows\LiveKernelReports\WATCHDOG\WD-20130802-1959.dmp
C:\Windows\Temp\WER-30428665-0.sysdata.xml
C:\Windows\Temp\WER4FAE.tmp.WERInternalMetadata.xml

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_0_0_cab_15144fdd

Analysis symbol:
Rechecking for solution: 0
Report Id: 5347a88c-fb9d-11e2-885b-001d7d035039
Report Status: 4

There's only one thing in the Details section written hexadecimally and it's the same for all three of these:

Quote:Keywords 0x80000000000000

On the map I think I've found the area which cause the crash (probably). Only suspicious thing there is a volumetric cone light, which original template was of another type (point light to be specific). I'll try to work without that part of the map and if there won't be any crashes any more, I'll investigate further.

PS
Funny thing is, crashes only occurs not on that part, but usually when it is on the border of visibility. When I fly with the camera around such places, it CAN happen. Usually video card is starting to work much harder and produce much more noise just before the crash.