34 minutes ago, brucewtb said:

Is this bug a 4.4 thing? Because with 4.3 and and earlier I never had a Device Hung error but having just installed 4.4 (client only because I have a system rebuild planned) I have had my first - at KSEA at the gate about to push back seemed to be precipitated by changing to an external view (EZDOCK).  Reset the scenario with the same settings and addons P3D4.4, LittleNav, AS, GSX2, EZDOK and the usual hi end Pacific NW scenery/airports but couldn't reproduce the error and my flight to KSFO proceeded without incident.  However if this keeps happening it is back to 4.3.  My current system is 4770 @ 4.4/980ti based.

Bruceb

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

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.

Edited December 13, 20187 yr by glider1

9 hours ago, Cruachan said:

Yes, I did, and it reminded me of an annoying period last year when I was having trouble accessing the NVidia Control Panel - kept crashing as it loaded. I noted I could get it to work if I ran it during a brief window after the desktop appeared and this success persisted throughout a session. I suspected the ASUS AISuite 3 and, indeed, delaying the loading of a couple of elements of the Suite via the Scheduler provided a workaround. In the end, the problem somehow resolved itself (? via an update) with no acceptance of responsibility from ASUS. Should I be surprised or was it a system-specific issue since I found no similar reports on the Net?

Regards,

Mike

Basic normality on these complicated systems. Any update or new driver install can disrupt the system with some little bug, that mysteriously disappears with the next update.

17 minutes ago, glider1 said:

ONLY A THEORY, and my own tests could easily prove me wrong next time I investigate this. Random problems are the worst.

That's pretty good for me to see that and several others posts, suggesting a host of things that lead to what I mentioned earlier, the confluence of situations within the system can present badly formed data at the card. That is the basic DXGI error condition since it is related to what is expected of the card to do with that malformed data. Could be a problem in scenery no longer handled by future versions of the simulator. Could be another situation within the system bottlenecking the card and maybe some part of the data making up a sized structure is lost. That's what the error suggests - an error in the data not the hardware - even so that can contribute to cause a similar issue but hardware and PSU errors make more of a fuss, normally you will know if it is hardware because the effects are usually more severe.

6 hours ago, Tino said:

I have yet to see any DXGI error since my re-install of windows and P3D. I used to get them constantly..

One thing I did do differently was,  to only install P3Dv4 compatible scenery. I left other FSX only scenery in my storage drive. Another thing I've noticed was WIn 10 1809 included newer drivers in the release package. It didn't take as long to update my default drivers to the latest releases. I'm wondering if the previous Windows update didn't overwrite the video drivers properly? A proper re-install may have corrected that.

I'm saying this was the solution but, I haven't seen any errors since doing a full re-install. 

Anyway, thought I'd contribute to the conversation, since it's such a difficult error to pinpoint.

Cheers.

Getting a new system? Please make precautions as Tino says.

Step carefully, check it through at each stage. Don't be too eager to get your fave airport or scenery on there or plane installed right away. Wait for those until it is certain the simulator performs properly.

Set up the system to support the sim properly - it's not FSX and we don't simply slam 100% CPU at it. P3D requires overhead in the system so that the host of sub-processes can also continue in a timely manner to support the sim. If not then any kind of thing can happen that does not comply with the expected pattern of service. Doesn't work as LM state? Look to your system - do not suspect the experts are wrong.

Any addon, simconnect, dll, scenery static aircraft can balk the simulator enough under the hood to cause this kind of random problem.

Edited December 13, 20187 yr by SteveW

.Just a warning, maybe do a virus/malware scan if you see any errors.

Could also be malware related since malware will attempt to breach some process related to browser technology. So when I mention that - I don't mean you probably ran Chrome or Firefox, and systems that avoid browsing are the same - the entire system is basically the same software running. The desktop is in fact just a fancy explorer window. Lots of windows may be utilising the browser rendering code specifically through COM for example, so cannot be ruled out. I noticed some report behavioural differences depending on browsing or not.

Be careful with your simulator PC - the number of systems running any kind of software with admin privilege, addons setting up to run as and - did you know the UAC slider is basically unneeded, did you mess with it? This kind of thing attracts the attention of the nefarious. Only reason to run as admin is to change system settings, make folders, update protected files, we see apps cut corners with the install or running behaviour and so then forcing admin on us for things to work - could let something in. Even then forcing Admin to avoid lower user privilege is not a cure as even admins don't automatically have access to anything, especially personal files and folders.

1 hour ago, SteveW said:

That's pretty good for me to see that and several others posts, suggesting a host of things that lead to what I mentioned earlier, the confluence of situations within the system can present badly formed data at the card. That is the basic DXGI error condition since it is related to what is expected of the card to do with that malformed data. Could be a problem in scenery no longer handled by future versions of the simulator. Could be another situation within the system bottlenecking the card and maybe some part of the data making up a sized structure is lost. That's what the error suggests - an error in the data not the hardware - even so that can contribute to cause a similar issue but hardware and PSU errors make more of a fuss, normally you will know if it is hardware because the effects are usually more severe.

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.

Edited December 13, 20187 yr by glider1

You're definitely on the right track. Those apps don't only access the internet, they often do window content rendering themselves, which is utilising the same stuff as browsers. The device in question that is hung is not the actual card, but rather a rendering item within.

1 hour ago, SteveW said:

You're definitely on the right track. Those apps don't only access the internet, they often do window content rendering themselves, which is utilising the same stuff as browsers. The device in question that is hung is not the actual card, but rather a rendering item within.

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.

Edited December 13, 20187 yr by glider1

Yes, it is a possibility, something like that maybe, or something in the sim scenery or objects, vehicles, static planes and other things. There's night and day texture sets, different way of flying, watching different systems. Then there's invoking some kind of activity by approaching the vicinity, as the bubble encroaches a new area. Differences in the GPS route can hit or miss the area with objects coming on-line, or not.

Edited December 13, 20187 yr by SteveW

So some external or internal influence on the sim as it compiles the scene it may find a complex object just a bit too complex at that time and some timeout doesn't complete the set of data and the size is wrong it flags a DXGI error and that item hangs as it cant continue, this in turn may prevent the card continuing with the rest of the scene or part. Or it's just a confluence from within the function of the sim coming to a problem in certain circumstances, and otherwise it's OK.

You might find simply flying on the other side of the world instead 'fixes' it.

Now I think there may be a lot of stuff coming from FSX, moved over to P3D because P3D will run it all - right?

I notice when I mention the possibility of P3D no longer accepting certain things that were OK in FSX seemed odd to some. I think I noticed some eyes glossing over.

That's because the differences between D3D9 and D3D11 are not too well understood, and how these can influence compatibility might seem strange.

Until it becomes clear that D3D9 is a system that fills in for GPU cards unable to reproduce some aspect of the render. It does this by means of DevCaps. Device Capabilities are ascertained for the current hardware and data and the result are adjusted to suit whatever happens up ahead. If it's a part of a render the card doesn't do in hardware, the software equivalent is used. So things have a lot more 'looseness' in what is acceptable, or can be got away with.

Enter DX11.

Now we have a system free of DevCaps. How's that? The D3D11 card must have the complete set of functions on it or it will fail, some item will hang because it can't process it. Of course they have all the functions, but some problem can hold one up and unexpectedly it can appear as if that function is missing.

So now we have a more stringent system that can be stopped by some item within and possibly externally 'helped', made worse by the confluence of another process or processes.

 

 

Edited December 13, 20187 yr by SteveW

40 minutes ago, SteveW said:

Now I think there may be a lot of stuff coming from FSX, moved over to P3D because P3D will run it all - right?

I notice when I mention the possibility of P3D no longer accepting certain things that were OK in FSX seemed odd to some. I think I noticed some eyes glossing over.

That's because the differences between D3D9 and D3D11 are not too well understood, and how these can influence compatibility might seem strange.

Until it becomes clear that D3D9 is a system that fills in for GPU cards unable to reproduce some aspect of the render. It does this by means of DevCaps. Device Capabilities and ascertained for the current hardware and data and the result are adjusted to suit whatever happens up ahead. If it's a pat of a render the card doesn't do in hardware the software equivalent is used. SO things have a lot more 'looseness' in what is acceptable, or can be got away with.

Enter DX11.

Now we have a system free of DevCaps. How's that? The D3D11 card must have the complete set of functions on it or it will fail, some item will hang because it can't process it. Of course they have all the functions, but some problem can hold one up and unexpectedly it can appear as if that function is missing.

So now we have a more stringent system that can be stopped by some item within and possibly externally 'helped', made worse by by the confluence of another process or processes.

 

 

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.

 

Edited December 13, 20187 yr by glider1

Yes, it comes and goes on systems affected. That may be because they defeated Boss 2 and are now into new scenery. In P3D anything can happen in the scenery make up. Flying the same route to invoke the same effect exactly is also very problematic.

My explanations won't do for instructing a developer class, but they are formed so as to, hopefully, give an idea of how things go for regular computer users not having the time to get into those things fully.

 

 

I don't know if there are people who still deal with this error. I have solved this issue long time ago and i think i should state my experience here. It may or may not help in your case but worth to give a shot, in may case i have locked my gpu clock speeds at it's max (in stock speeds not OC). and i no longer got dxgi error device hung or removed error And the reason when i launch p3d at start up screen or in flight at random place or at any time gpu was pulling it self to p8 states idle speeds at 139mhz suddenly and back to p0 state to 1974mhz and in this very short period p3d was collapsing. locking the gpu clocks solved my issue for p3d. in other games at default clock speeds i don't get any error because gpu knows there is something going on that gpu have to handle but when it comes to p3d gpu doesn't know what to do.

 

 

Edited December 13, 20187 yr by volantiger