glider1

I looked through the event log in detail but there is no mention of the GPU 2080 hanging or stopping responding at the time P3D reports the device_hung. Since in VR there is no driver crash and no interruption to the VR experience (it would be impossible not to see it) when P3D goes into hang, I STRONGLY suspect it has to be a memory corruption in VRAM inside P3D memory address space inside the card and it is random. Do you know of a way to do a reliability test on just the GPU's VRAM nothing else? What card do you have a brand new 1080ti?

I got the DEVICE HUNG again! This time no overclock on a brand new 2080. The plane was parked after completing the flight. I was in the cockpit in VR and had alt-tabbed out to Chrome browser on the virtual desktop to type my logbook up in Chrome sheets app. P3D went DEVICE HUNG but the video driver was unaffected (I know because I was interacting with Chrome in the virtual desktop with the headset on and the video driver functioned perfectly no interruption to my VR experience while P3D went DEVICE_HUNG). With headset still on (which is still using the GPU) I started MSI afterburner on the virtual desktop and noticed that when P3D reported hung, the core clock on the 2080 had throttled back to 1515MHz when I wanted it boosted to 1830MHz as it was during the whole two hour flight. The GPU temps, CPU i7700k temps all systems running fine when the DEVICE_HUNG was reported. GPU usage was probably 50% and CPU core 0 wasn't even pegged at 100% the other cores were basicallly idle. There could be something in the theory that we have to stop the clock throttling down into idle with P3D if we are going to interact with desktop apps while the sim is running. One thing for sure, it is possible for P3D to report DEVICE_HUNG when the device has not hung. EDIT: from reading other peoples reports, it can be related to when there is more than one monitor. VR uses three monitors. It uses flatscreen monitor and one display for each eye.

I seem to remember that when you plugged and played your sons 1080 into your system the error was completely eliminated is that true?

The phenom is great in VR isn't it. You have a 2080ti. Do you think that card would have solid performance in P3D on a Pimax 5K? A guess will do!

Try Jim and Rob's suggestion of reducing the GPU core clock speed down to get it more stable. Definitely no overclock. So far it is working for me but there is still more testing to do. EDIT: the brand new 2080 card I have passed all normal stress tests at the OC frequency of 2100MHz but it was not stable in P3D. I dropped it to 1800MHz and so far so good. Best wishes with it.

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!

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?

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.

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.

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.

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.

Ok then to summarise the theory so far (for testing tomorrow). Bad Old scenery/models/infrastructure still may run under P3D but adds to the load of the CPU<->GPU communication logic which combined with other CPU loads coming in from external apps as well as internal loads within the sim, all adds up to a critical CPU thread so overloaded that at some point it flags that the GPU has a problem when in some cases it does not. If this this theory is true, it should never happen on default installations on default scenery and planes on default settings, but apparently it does, and people also know that their GPU is not faulty. It could be that something external is putting pressure on the CPU thread pushing it over the edge which is still causing the device_hung flag to wave.

So the theory is that a rendering process external to the sim holds up corrupts the CPU thread that needs to be delivering something to the GPU in the sim, then the GPU throws up an exception of some kind that another thread inside the sim detects as a DEVICE_HUNG. EDIT: But it only happens in situations where there is a certain combination of overworked CPU and underworked GPU because of timing in the throughput. In other cases DEVICE_HUNG happens for totally valid and normal reasons like hardware problems.

Ok, so revise my theory to say that if the CPU is too busy it cannot correctly form the data that the GPU needs in the time that the GPU needs it. Maybe it needs to join together a whole heap of thread outputs but can't because some of the threads aren't ready. So it is not a GPU hung problem as is reported by the sim. It is a CPU too busy problem. I like your theory that browser technology is deeply meshed into the environment the sim has to live in. I tell you what, for now chrome or any app that accesses the web not specifically designed for the simulator, won't be running in my tests in the future to track down this problem. LittleNavMap has been correlated with the DEVICE_HUNG for me when it was in the foreground more than once and accesses the web a lot. Others have reported PDF viewers in the foreground which incidentally access the web too. It is a complicated problem. If my theory is right, the outcome of the theory is that people who throw the latest GPU's (1080 series and up) into older generation CPU hardware and motherboards, are more likely to see this problem (people like myself). If the theory is wrong, it would make no difference. If the theory is correct, then people who leave their old computers as is where CPU/GPU are a good match will probably not see this problem unless they have a genuine hardware issue. EDIT: the theory could also explain why people like Rob hardly if ever see this problem because Rob always buys the best CPU available when he buys the best GPU available. It could also explain why I hardly ever saw this problem when I had my 1080 in the system, but when I put the 2080 in, the problem became far more evident because my CPU was already on the limit before the upgrade. If the theory is correct, if 4.4 tweaks the threading system in P3D in some way, it might show up problems in people's systems with mismatched CPU/GPU combinations more than 4.3 did. But there are always legitimate reasons as well when there is actually a DEVICE_HUNG when the device has actually hung.

Here is the theory I have as to what causes this error. Please comment on the theory. There are CPU threads in the simulator that hook onto the GPU and communicate with it. If the CPU is sufficiently interrupted from attending to all the threads it must attend to in the sim, to a point where it cannot handle the GPU threads quick enough, the threads to the GPU timeout, and the sim reports it as a DEVICE_HUNG but it is not the GPU that is the problem. But it is only in some cases where a device has really hung. Perhaps some people get genuine hardware problems. But for many, the CPU becomes unable to handle the threads to the GPU in sufficient time - that is the cause. So if this theory is true, then, IF your hardware has checked out for all cross checks, stress tests and it is not running too hot or otherwise stressed, try and see if you can reduce as many external apps and programs and addons that would take time away from the CPU. I wouldn't be surprised if the reason why a lot of people with 1080 series GPUs and even 2080 series GPUs are seeing this problem, because the GPU is expecting their weaker CPU's to attend to it, but the CPU is too busy to handle the big performance gap between it and the GPU. The CPU thread to the GPU that times out may not produce any visible effects on frames if it is a background data processing thread. It just simply times out and gets reported as a GPU hang. I wouldn't be surprised if things like affinity is involved in this. I wouldn't be surprised if the bug doesn't happens on a 9900K running a 1080, 2080 series GPU. I wouldn't be surprised if it doesn't happen on appropriately balanced CPU/GPU combinations. JUST A THEORY with the evidence that so far minimising the external workload on the CPU has worked for me today in testing I have not seen the hang for the first time in days. A particularly suspicious load on the CPU would be chrome browser. If you look at the number of processes that app throws up on the operating system that the CPU has to handle randomly as well as handle the simulator, I'm amazed you can run Chrome at all with it. ONLY A THEORY, and my own tests could easily prove me wrong next time I investigate this. Random problems are the worst.

I think the Discus X cockpit glass is less clear in VR in 4.4 because of PBR. I think it is the artificial reflections they textured into the glass stand out more now and are more annoying. Would like to get your opinion on that. The ASK21 from Aerosoft is beautiful in VR in 4.4 have flown it many times (but it is not officially 4.4 ready). Yes water reflections are broken, I turn them off. They were broken for a long time already. Shadows are all good and VR performance is also good. Yes most if not all the Wolfgang gliders are not VR compatible unfortunately. Yeah I will definitely get Condor2 when it is VR ready. But P3D is king with gliding for me because I am learning so much about gliding since I am flying in VR with IGC recordings of real world gliding pilots from https://www.onlinecontest.org in the same scenery and weather using ORBX and AS2016 historical weather using CumulusX and simlogger. Let me know if you ever want to know how to do that.

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

The mapping of recalibrate origin does work for me in 4.4. Strange. EnableGazeSelection off also works for me kinda. I can move the cursor around independent of my head but it still wants to follow my head movements to some degree even with it off. In Rift, you can access the virtual desktop with one click of the remote no need to take the headset off. SteamVR should have an equivalent. So you can interact with the simulator the same way you used to do it on flatscreen but with the headset on. I have to agree though that P3D VR is pretty primitive, I do find it hard to understand how P3D customers in the military find VR acceptably good for their needs. It is still very primitive but performance now is on par or better than Flyinside for me and definitely good enough for what I need it for (virtual gliding).

I've developed a test setup for this bug thanks to one of the guys on this forum. Slew any plane at dusk at 160kts 5000ft over populated areas and let the sim run on its own. Wait for the DEVICE HUNG to happen. Make sure that multi-monitor or VR headset software is running and note the load on the GPU and CPU making sure they are roughly 50%. Let the setup run until the error happens. Compare things that were changed for each test. Not having to actually fly the plane is a huge step forward for finding this error.

These things did not work for me on a stock 2080 latest build of W10. reducing GPU power limit to 75% in Gigabyte aorus (DID NOT WORK) reducing GPU overclock to default in aorus (DID NOT WORK) Cleaning out the driver in DDU in safe mode and reinstalling (DID NOT WORK) The only lead so far is that the DEVICE HUNG happened when I had LITTLENAVMAP in the foreground maximised with P3D window maximised in the background. I don' think it matters what monitor the other app is on, it is just whether it has the focus or not. I think it might trigger a DEVICE HUNG at a random time interval while the other app has the foreground it could be milliseconds to minutes before it happens. The only lead for me so far. Unlikely to be hardware since I replaced the PSU with a new more powerful one and the GPU was stock clocked and throttled back for the test today.

I replaced the PSU for nothing! New PSU, new GPU (2080). Passes all the stress tests. Still a random DEVICE HUNG! Sh#$%*$% I think I might have got it once on 4.3 a few months ago, But on 4.4 it is every second flying session what gives?

I'm going down the route of thinking it is a power supply problem for myself and possibly you. Your 1000W is getting old at 2011 vintage. The rails might not be as solid as they used to be with caps aging so I'm thinking it is not a bad idea to get a new one. I swapped out my PSU for a beefier one today and will look forward to testing it over coming days. The clue for me is that I started getting device hung a lot more frequently a few days ago and I only now realise that at the same time I had added periripherals to the PC to the extent where every single USB port was being used. My VR headset needs USB and when I saw in the event log that the VR driver was doing a user power mode reset only shortly before the device hung came up on P3D, it made me strongly suspect that my PSU rails were dropping off under max load which drops the VR headset, which drops the GPU which P3D reports as a device hung. Yeah it is an intermittent problem, they are the most difficult to track down.

Ok more testing. When P3D reports device hung in the system event viewer there are some event 12, UserModePowerService faults which may or may not cause the VR driver to reset. The weird part is that the display is never lost even with the faults it is just that P3D reports a device hung which is probably exactly what it is supposed to do. So P3D is in the clear it has got to be something else.

Protip for anyone who is testing this device hung error. Don't change any video settings in P3D unless you restart P3D first. In the debug phase the only clue so far is if I change vsync or fps limit settings inside P3D and then return, I am more likely to get the device hung problem. It is probably not the cause but a good step in testing. It also makes sense not to change settings since it is a test of the GPU under absolutely consistent conditions in order to try and reproduce what I think is memory corruption problem.

I think I can prove that the problem is P3D. I run P3D in VR. If I switch to virtual desktop after a while P3D will report device hung and I can close it. But there is no interruption to the virtual desktop. There is no log entry for any reset of the video driver or oculus VR drivers. Matter of fact, I can still have the headset on, see that P3D has device hung and continue on the full VR experience on the virtual desktop without any interruption or loss of performance. It is a clean P3D problem in my case. I can hear you say: "But if the VRAM space is corrupted only in the P3D area of the space, that wouldn't cause the driver to stop or reset. It doesn't prove that it is not a hardware problem". But surely if the memory is corrupted in P3D space, the driver should pick this up and there should be some kind of notification of it at the driver level. The driver thinks there is not a problem in the world which is matched by my own experience after the crash. The GPU carries on perfectly where it left off except that P3D reports that the device is hung but it clearly has not. EDIT: More testing. I actually now think that when P3D reports that the device has hung it is merely saying that the VRAM memory has corrupted nothing more nothing less.