DXGI_ERROR_DEVICE_HUNG error: Is there a solution?

[Jim Young 2,356]

As I stated at the beginning of this thread, I believe this problem is associated with the clock speeds.  Perhaps the reason why some of us are not getting this error is because of the manufacturer who made the card.  Maybe some manufacturers did not set the clock speeds properly.  I have the ASUS Strix 1080TI and it was automatically overclocked and I have not seen this error.  P3D uses a lot of resources but mostly the CPU.  Still when you are trying to render a lot of textures in nanoseconds, it puts some pressure on the GPU(s) and probably triggers the error. On the Internet, it happens in many other games too where a lot of gpu resources are required.

[Aweless 15]

The important think is here keeping the gpu clocks above p8 idle clock speeds. If you can't lock the gpu clocks for some reason try keeping the page opened: ''adjust image settings with preview'' on the nvidia control panel just keep the little nvidia 3d image run in there in background during whole flight. this will trigger the gpu not to go back to p8 idle state. this way you can have some clue at least. In my case for some reason the connection between the gpu and p3d was stopping communicate for a very short of time and the gpu clocks were going back to p8 idle then back to p0.

Edited December 13, 2018 by volantiger

[Guest]

Agree with Jim, there is also the possibility that cards that come overclocked from "the factory" may work for a XYZ period of time but then start to fail (just outside their warranty period).  And finally, people often tend to "experiment" with overclocking their GPUs which can reduce a GPU's life span and or damage the GPU/memory ... that's why you have big warning messages whenever OC is attempted (same for CPUs also) ... it may only take one experimental OC attempt to trigger a failure point in the one of many components that make up a GPU (billions of transistors)

Obviously one can never rule out "software" ... but as Jim and I have suggested, the software may just be the trigger in finding the weak spot in a GPU and/or it's memory subsystem.  I recall someone trying to tell me that P3D was the source of making their PSU fail ... and that person probably still believes that to this day ... but the real issue is that PSU wasn't sufficient to support the loads that were being placed on it ... P3D just exposed a hardware problem.  

I've searched the internet and 97% of the problem resolution to this error is to replace faulty hardware ... given the complexity of hardware, that fault can reside in many places from RAM modules to GPU, to MB to PSU or even power coming from one's wall outlet.  It's obviously cheaper to try and find a software solution first and no harm in trying that (from OS wipes/re-installs and driver wipes/re-installs) to other settings/adjustments.

Cheers, Rob.

[SKIPS2 3]

18 hours ago, glider1 said:

Hi Bruce - Recently most people will say it happened less often on 4.3 than 4.4. That is my case. 

My suggestion is do the simplest things first. Don't start debugging hardware yet. Don't start reinstalling software yet. A lot of people report doing this but it might be a waste of time and effort. They might get an improvement but the bug is random and unless the cause is found you can never know when it will hit again even with brand new GPU like I have.

The lowest hanging fruit for me in testing is to close of all the addons run the sim without addons and see how you go adding them back one by one. For me the bug happens when the simulator looses window focus mostly when I am doing something on the desktop while the sim is running and heavily loaded - similar to your observation when you switched to EZDOCK external view.

Cheers

I'd like to add my two cents. Being plagued by this error since 4.2/4.3 anything i try was deemed futile, either in cockpit prep or CRZ like yesterday.

Since l'm only restricted to only 1 PC (since my cat knocked over my secondary pc which I used for FLT planning) i have to run everything in the background such as PFPX, TOPCAT, vPILOT etc. Once I go to either one of  these programs...boom pop goes DXGI ERROR.

Yesterday's scenario was an awkward one - Was inflight for about 8hrs heading Jo'burg on Vatsim when Vastim SUP was checking in on my FLT status...as soon as I responded by text...DXGI HUNG.

Bottom line is, at least in my case, moving between Fullscreen to Window to do something on desktop creates the error while sim is running.

In my years of simming I've never remotely came across a troublesome error like this, ever!

[glider1 90]

3 hours ago, Rob Ainscough said:

Agree with Jim, there is also the possibility that cards that come overclocked from "the factory" may work for a XYZ period of time but then start to fail (just outside their warranty period).  And finally, people often tend to "experiment" with overclocking their GPUs which can reduce a GPU's life span and or damage the GPU/memory ... that's why you have big warning messages whenever OC is attempted (same for CPUs also) ... it may only take one experimental OC attempt to trigger a failure point in the one of many components that make up a GPU (billions of transistors)

Obviously one can never rule out "software" ... but as Jim and I have suggested, the software may just be the trigger in finding the weak spot in a GPU and/or it's memory subsystem.  I recall someone trying to tell me that P3D was the source of making their PSU fail ... and that person probably still believes that to this day ... but the real issue is that PSU wasn't sufficient to support the loads that were being placed on it ... P3D just exposed a hardware problem.  

I've searched the internet and 97% of the problem resolution to this error is to replace faulty hardware ... given the complexity of hardware, that fault can reside in many places from RAM modules to GPU, to MB to PSU or even power coming from one's wall outlet.  It's obviously cheaper to try and find a software solution first and no harm in trying that (from OS wipes/re-installs and driver wipes/re-installs) to other settings/adjustments.

Cheers, Rob.

It might not be best to just say the same things about broken clocks and reinstalling etc. I and others are seeing the error come from the multitasking environment that the simulator is working triggering it in on brand new GPU's with modest clocks even underclocks as well as new PSU's fresh installations.

[glider1 90]

3 hours ago, volantiger said:

The important think is here keeping the gpu clocks above p8 idle clock speeds. If you can't lock the gpu clocks for some reason try keeping the page opened: ''adjust image settings with preview'' on the nvidia control panel just keep the little nvidia 3d image run in there in background during whole flight. this will trigger the gpu not to go back to p8 idle state. this way you can have some clue at least. In my case for some reason the connection between the gpu and p3d was stopping communicate for a very short of time and the gpu clocks were going back to p8 idle then back to p0.

Is there some way to log the idle state that you know of? It would be interesting to see what the clock does when you switch out of the sim onto other desktop apps.

[Cruachan 705]

27 minutes ago, glider1 said:

Is there some way to log the idle state that you know of? It would be interesting to see what the clock does when you switch out of the sim onto other desktop apps.

NVIDIA Inspector:

https://www.techpowerup.com/download/nvidia-inspector/

You can monitor the P-State, Clocks, Temps, GPU Usage, etc.

Click the little icon top left-hand corner of the main window and you will be presented with a series of useful graphs that display in real time and will display on top of the Prepar3D active full screen window.

Mike

[glider1 90]

2 hours ago, SKIPS2 said:

I'd like to add my two cents. Being plagued by this error since 4.2/4.3 anything i try was deemed futile, either in cockpit prep or CRZ like yesterday.

Since l'm only restricted to only 1 PC (since my cat knocked over my secondary pc which I used for FLT planning) i have to run everything in the background such as PFPX, TOPCAT, vPILOT etc. Once I go to either one of  these programs...boom pop goes DXGI ERROR.

Yesterday's scenario was an awkward one - Was inflight for about 8hrs heading Jo'burg on Vatsim when Vastim SUP was checking in on my FLT status...as soon as I responded by text...DXGI HUNG.

Bottom line is, at least in my case, moving between Fullscreen to Window to do something on desktop creates the error while sim is running.

In my years of simming I've never remotely came across a troublesome error like this, ever!

That would have been really frustrating after such an epic flight. I too need the sim to work flawlessly for at least 4 hours a session.

Could you check your situation and run the simulator with just the bare minimum of addons necessary to do a single player flight and don't interact with the desktop unless absolutely necessary especially with apps that access the web. Just a theory. You would have to check for simulator reliability many times before concluding anything though.

Edited December 13, 2018 by glider1

[Guest]

6 minutes ago, glider1 said:

seeing the error come from the multitasking environment

You lost me, your OS regardless of application running will always (no exception) be multitasking ... it's never really "idle".  Bring up task manager and you'll see more than one core is always doing "something" (a task) even when you sit idle at the desktop.

Are you talking about running P3D and then context switching to another application like Google or a Media player or chat program or something else ... then you get the DEVICE HUNG error?  If this is your point of reference, then switching context to an application that might be attempting exclusive access to the same device (i.e. your GPU) could very well trigger errors ... depends on how those apps are trying to access the GPU.  But if this is the case, that's a clue.  Under Windows 10 GPU virtual memory is handle via WDDM V2.0 ... this gets technical as there are memory models (GpuMmu and loMmu) along with other features like context monitoring of fence objects, etc. etc. 

If you're really really really motivated to try and gather more information about what is happening, you can install Visual Studio (Express is free) 2017 and attached to Prepar3D.exe and in VS check ALL c++ exception processing so as to stop on exception and then do a system dump.  If another application is the trigger then you may need to run two instances of VS 2017 and attach to the other application exe and set the same exception stops ... at that point you can pass the dump file onto LM and hope they will take a look (warning dump files can be huge 10GB+).  Apparently the DEVICE HUNG message is being trapped by P3D (taking this from the picture provided in this thread, that's why you see the P3D style error message box/window) ... so the odds are good a dump file might help ... however going thru a dump file is extremely time consuming so don't raise expectations.

From what I can gather in this thread is that others have replaced hardware and solved the problem, some re-installed drivers and that solved the problem, some forced a constant clock speed to solve the problem ... solutions seem to be there that don't involve P3D.

Cheers, Rob.

[glider1 90]

1 minute ago, Rob Ainscough said:

Are you talking about running P3D and then context switching to another application like Google or a Media player or chat program or something else ... then you get the DEVICE HUNG error?  If this is your point of reference, then switching context to an application that might be attempting exclusive access to the same device (i.e. your GPU) could very well trigger errors ... depends on how those apps are trying to access the GPU.  But if this is the case, that's a clue.  Under Windows 10 GPU virtual memory is handle via WDDM V2.0 ... this gets technical as there are memory models (GpuMmu and loMmu) along with other features like context monitoring of fence objects, etc. etc. 

Cheers, Rob.

That is definitely a factor in not just my case but others. There are legit hardware problems in the GPU that can also cause it. Some peoples reports about how they fix it can't be relied on because the problem is random. Lately though, it is more often associated with switching out of the sim to other apps that triggers it maybe not instantly but within a random amount of time while the sim has lost focus. Also the amount of external processes running alongside the sim is a factor. The theory is that DEVICE_HUNG is not actually a GPU fault in some cases but rather a corruption of data to the GPU by the CPU caused by a threading issue with the whole system.

[SKIPS2 3]

3 hours ago, glider1 said:

That would have been really frustrating after such an epic flight. I too need the sim to work flawlessly for at least 4 hours a session.

Could you check your situation and run the simulator with just the bare minimum of addons necessary to do a single player flight and don't interact with the desktop unless absolutely necessary especially with apps that access the web. Just a theory. You would have to check for simulator reliability many times before concluding anything though.

Well, I can't do it right now as I'm currently in flight to Jo'burg again (2.5hrs in as of now so fingers crossed). Funny thing is, this crash is so random it's scary man. Trying to calculate perf speed speeds, running pfpx in background gets me agitated as I fear it will just crash. However, no crash as of now. Some days you experience it..some times it never happens. 

Here are specs

i7 4820k 3.7ghz oc to 4.6ghz

Evga 970 SC (2gb) - yes i know 2gb is not enough but...i wonder if this is related too

Monitor - Asus PB287Q 4k 144hz

Edited December 14, 2018 by SKIPS2

[glider1 90]

3 hours ago, SKIPS2 said:

Well, I can't do it right now as I'm currently in flight to Jo'burg again (2.5hrs in as of now so fingers crossed). Funny thing is, this crash is so random it's scary man. Trying to calculate perf speed speeds, running pfpx in background gets me agitated as I fear it will just crash. However, no crash as of now. Some days you experience it..some times it never happens. 

Here are specs

i7 4820k 3.7ghz oc to 4.6ghz

Evga 970 SC (2gb) - yes i know 2gb is not enough but...i wonder if this is related too

Monitor - Asus PB287Q 4k 144hz

Thanks for providing the specs. You do have a big overclock and 2GB vram is marginal so your system could potentially get device hung for normal hardware reasons but I wouldn't be surprised if you are actually seeing the lost focus device hung problem as well. Yes VRAM shortages are implicated. I have 8GB but will experiment with turning off high res textures.

EDIT: if your settings are appropriate it should be ok. What is the minimum spec for VRAM in 4.4? What actually is P3D designed to do if it runs out of VRAM?

Edited December 14, 2018 by glider1

[glider1 90]

15 hours ago, Jim Young said:

As I stated at the beginning of this thread, I believe this problem is associated with the clock speeds.  Perhaps the reason why some of us are not getting this error is because of the manufacturer who made the card.  Maybe some manufacturers did not set the clock speeds properly.  I have the ASUS Strix 1080TI and it was automatically overclocked and I have not seen this error.  P3D uses a lot of resources but mostly the CPU.  Still when you are trying to render a lot of textures in nanoseconds, it puts some pressure on the GPU(s) and probably triggers the error. On the Internet, it happens in many other games too where a lot of gpu resources are required.

So far you are correct Jim (and Rob) on my experience today so thank you. It is the last time I ever use Gigabyte software I have had trouble with it for years. This time AORUS Gigabyte GPU utility did not update my clock speed properly on it's own brand hardware! The card is brand new.

I did my testing based on a 1800MHz reference boost clock for a 2080 and its own graphs where showing it but when I checked it with GPU-Z it was showing 2100MHz! I also saw heaven bench showing 2100 but didn't believe it because I thought Gigabyte software should be considered as the authority on their own card. The card was passing the standard stress tests.

But I triple checked when I downloaded MSI afterburner which was also reporting 2100MHz! No wonder it was falling apart in P3D. It is branded as an OC card but It was obviously on the ragged edge this entire time while I have been testing the DEVICE_HUNG problem.

It is not conclusive yet though but I have a feeling it is going to be the cause. Another 5-10 flights should be good confidence. I feel completely stupid about this. There is no benefit at all in the extra 300MHz!

Cheers

EDIT: the card has a three year warranty so I guess 2100MHz must put time to fail at 3 years and one day!

Edited December 14, 2018 by glider1

[Aweless 15]

13 hours ago, glider1 said:

Is there some way to log the idle state that you know of? It would be interesting to see what the clock does when you switch out of the sim onto other desktop apps.

You can check it via nvidia inspector or msi AB if you expolre any value below 400 Mhz with msi AB that means your gpu works at idle speeds. Also make sure that nothing is working on the background after you switch out of the sim for example a steam app or gfe or any web browser may trigger the gpu to work at higher clock speeds. Values may vary depending on your gpu.

[Cruachan 705]

Hi,

Our chickens are coming home to roost as we reap the seeds we sow, springs to mind!

Overclocking our CPUs has become entrenched in our psyche courtesy of the likes of FSX and Prepar3D. To extract maximum performance from our sims we require that main thread to be running as fast as possible.. and so we overclock. However, overclocking can, and often does, have consequences and these must be mitigated to avoid curtailing the life of the CPU needlessly. Those are excessive heat and overvoltage. Nowadays we have quite efficient cooling solutions which can take care of the former but, unless we exercise caution, pushing that vCore to unsafe levels in order to achieve that boast worthy clock speed is fraught with potential danger. There is, of course, a mind set shared by those who perceive these risks as being inversely proportional to the depth of their pockets since, in the event it fails, the replacement of a CPU would not be a big deal...and that’s fine.

The rest of us are also driven along by a passion for the hobby. A side effect is that shared, and occasionally, impulsive desire to extract what we can from the hardware. After all, it’s only reasonable to expect the best from our investment. Then, issues like the DXGI_ERROR_DEVICE_HUNG error come along and we wonder why? After all, most are riding this overclocking bandwagon and the majority, myself included, don’t appear to be having such problems, so why are our experiences different? I don’t know, but I can hazard a guess or two.

We have done our research and only purchased/installed components from respected manufacturers that continue to insist on high standards of quality control.

We have accepted that the silicon lottery can dictate how effectively a chip can be overclocked. Rather than pushing the CPU to the absolute limit we aim for a safe overclock rather than hiking the vCore to a level that, while permitting a short term high clock rate, is likely, in the end, to cause inevitable premature degradation of the chip circuitry along with consequent instabilities and eventual failure.

We have opted to implement a Dynamic overclock that is triggered both immediately and only when required by the running simulator or game and this targetted clock speed is maintained with stability throughout a session.

With the appearance of CPUs with ever increasing core counts, we have optimised the number of cores used by the simulator. My investigations and testings, documented elsewhere on this forum, have determined that the optimum core count dedicated to Prepar3D is 6 and no useful additional performance of the sim can be achieved by using more. The remaining free Cores can be allocated, by the use of Affinity Masks, to 3rd Party Apps running alongside the sim and, by so doing, avoid contention with threads running on cores reserved for the sim itself.

We have decided to purchase our GPU/s from trusted manufacturers without any intention of overclocking. Alternatively, we have opted for a GPU that has had a modest overclock pre-applied by the manufacturer with an implied guarantee of stability throughout the life of the product.

Assuming that the error encountered, and the subject of this thread, is hardware (CPU/GPU) related and this is occurring on systems that have been overclocked by whatever method, then I am speculating that by the time of its appearance the ‘damage’ has in fact occurred. This might explain why, on some systems, it keeps recurring even when the clocks have been reduced. In such cases one would expect hardware replacement should provide a solution.

Mike

Edited December 14, 2018 by Cruachan