nVidia 471.96 and DXGI_DEVICE_HUNG resolved

[Whenmaker 23]

Changing QWORD to DWORD did the trick for me, 2 hour flight and everything fine.

Thanks

[Ray Proudfoot 8,954]

My second test flight was 95% successful. KSFO-CYVR was flown at x2 for 50% of the route and during this time a freeze occured SW of Portland with a buzzing sound. It lasted around 3-4 seconds.

Then it resumed and was fine all the way in and to the gate. I'll avoid acceleration on future flights.

[RXP 2,338]

@Ray Proudfoot

The topic I've referenced is one I've created, and it is not about DX11 or VR, it is about system lockup when HDD is waking up from sleep, and how changing TDR delay registry value has cured this on my test system. It just happened it is posted in this other forum in this other topic, but it is unrelated entirely!

Now like @psolk is saying, these registry values are meant for debugging supposedly, and this is basically what we're doing in this Avsim topic :-) 

Nevertheless, I was just answering you wondering whether these were even documented, and I just pointed to the online official documentation, for what it's worth.

[Afterburner 374]

Ray, I admire your patience and perserverance. I hope that you are getting some enjoyment out of your flights and do not limit them to bare test rides. When you complete a successful flight after changing a parameter, it doesn't tell you immediately whether the change will eliminate the DXGI errors in future flights or not, since you already had flights in the past after which you thought that you had found the culprit, only to be annoyed by the opposite. It's rather that the probability of getting this error is X%, and you need to have a large enough sample size to have some chance of getting that error. After Y flights, you may think that this problem is solved, but on the Y+1th flight you may get the dreaded error only to realize that the sample size wasn't large enough at all. To ensure that you have completely eliminated this error, you would need to do lots of flights to ensure a large enough sample size. (And since it NEVER happened with P3Dv3 and v4 on your system, it is safe to say that the error didn't appear with these sims).

Seeing you tinkering inside some registry entries that are not part of standard procedure and trying so hard to find and eliminate the error while LM sits idle silently and doesn't bother to comment in the respective thread on their forum, is not fair. LM does not deserve this kind of dedication from a user, for they won't comment even if you find the holy grail. Maybe it's a good idea to stop testing too much and simply accept the fact that there is a small percentage that this error will occur (which may be acceptable to you).

[fluffyflops 1,858]

3 hours ago, Afterburner said:

 

Seeing you tinkering inside some registry entries that are not part of standard procedure and trying so hard to find and eliminate the error while LM sits idle silently and doesn't bother to comment in the respective thread on their forum, is not fair. LM does not deserve this kind of dedication from a user, for they won't comment even if you find the holy grail. Maybe it's a good idea to stop testing too much and simply accept the fact that there is a small percentage that this error will occur (which may be acceptable to you).

 

Lets say for example it comes out that the coding in XYZ on line 25752 is to blame, and its 100% a LM issue. 

This means they have to acknowledge the issue, pull staff off other projects to fix it and then  start emailing clients and basically look incompetent. 

Then their existing clients start doing lawsuits due to being sold a product with bugs and new clients then start saying they won't  buy until the issue is fixed. 

This is about money, the loss of it,and in the USA where lawsuits are commonplace for anything and everything. 

They will never ever ever ever ever ever ever ever admit it.  

This is a military contracter we are talking about here, not unicef 

 

Edited October 8, 2021 by fluffyflops

[Ray Proudfoot 8,954]

@RXP, I accept your scenario is completely different to mine. It seems TdiDelay is a “catch-all” for these problems which is partially successful. It makes you wonder if these problems will ever be solved.

@Afterburner, how well you summarised the situation I find myself in. 👍👏

I do enjoy my flights because only a small number encounter the DXGI problem and a reload of the autosaved flight means I can complete them.  Worst time it can happen is taxiing out for takeoff as Autosave only starts when airborne. That’s only happened once at a very quiet UK2000 EGNT.

As for LM and their silence it’s depressing. You would think that just basic courtesy would kick in and they would make a comment. I can only assume they cannot replicate it or don’t have a clue how to fix it. If the latter it doesn’t bode well for the future of P3D. Having said that it will be interesting to see what the impact is if or when DX12 is applied to MSFS.

Whilst the problem occurs at random it invariably occurs at altitude well away from complex airports. The route from KSFO / KLAX up to the Seattle / Vancouver area seems particularly problematical with the AA livery of the PMDG737-800. Failure rate is 50% or greater. It used to crash with the DXGI message but yesterday I just had the freeze and buzzing noise for a few seconds but it didn’t crash.

I have FTX Global and Ultimate Terrain v2 USA and FS Global. Nothing fancy. Perhaps that’s one route and aircraft others could try.

I’m going to check my sound drivers later as I uninstalled the Realtek drivers some time ago because of sound level problems with P3D and GSX.

[Whenmaker 23]

13 minutes ago, Ray Proudfoot said:

I’m going to check my sound drivers later as I uninstalled the Realtek drivers some time ago because of sound level problems with P3D and GSX.

Good morning Ray,

this and an update of my Mobo-BIOS solved the "buzzing freezers" on my end a while ago.

Edited October 8, 2021 by Whenmaker
Typo...

[psolk 3,040]

2 hours ago, fluffyflops said:

 

Lets say for example it comes out that the coding in XYZ on line 25752 is to blame, and its 100% a LM issue. 

This means they have to acknowledge the issue, pull staff off other projects to fix it and then  start emailing clients and basically look incompetent. 

Then their existing clients start doing lawsuits due to being sold a product with bugs and new clients then start saying they won't  buy until the issue is fixed. 

This is about money, the loss of it,and in the USA where lawsuits are commonplace for anything and everything. 

They will never ever ever ever ever ever ever ever admit it.  

This is a military contracter we are talking about here, not unicef 

 

What a load of garbage.  If they find an issue they fix it and send out a fix.  

This isn't about lawsuits in the USA and them being a military contractor has nothing to do with it.  

Plenty of companies have contracts with the military, find bugs and even security vulnerabilities, fix them, issue patches and we all move on. 

I don't even know where your assumption that this is about money and lawsuits came from.  Talk about going right to tin foil hat speculation... 

[psolk 3,040]

1 hour ago, Ray Proudfoot said:

@RXP, I accept your scenario is completely different to mine. It seems TdiDelay is a “catch-all” for these problems which is partially successful. It makes you wonder if these problems will ever be solved.

@Afterburner, how well you summarised the situation I find myself in. 👍👏

I do enjoy my flights because only a small number encounter the DXGI problem and a reload of the autosaved flight means I can complete them.  Worst time it can happen is taxiing out for takeoff as Autosave only starts when airborne. That’s only happened once at a very quiet UK2000 EGNT.

As for LM and their silence it’s depressing. You would think that just basic courtesy would kick in and they would make a comment. I can only assume they cannot replicate it or don’t have a clue how to fix it. If the latter it doesn’t bode well for the future of P3D. Having said that it will be interesting to see what the impact is if or when DX12 is applied to MSFS.

Whilst the problem occurs at random it invariably occurs at altitude well away from complex airports. The route from KSFO / KLAX up to the Seattle / Vancouver area seems particularly problematical with the AA livery of the PMDG737-800. Failure rate is 50% or greater. It used to crash with the DXGI message but yesterday I just had the freeze and buzzing noise for a few seconds but it didn’t crash.

I have FTX Global and Ultimate Terrain v2 USA and FS Global. Nothing fancy. Perhaps that’s one route and aircraft others could try.

I’m going to check my sound drivers later as I uninstalled the Realtek drivers some time ago because of sound level problems with P3D and GSX.

Ray, sorry if I missed it but what Nvidia driver version are you on?  Any chance of reverting to an older driver?  I am on 456.71 and never seen a device_hung error in all my simming.  Perhaps it's at the driver level?  Have you tried a driver rollback?  

[Ray Proudfoot 8,954]

48 minutes ago, psolk said:

Ray, sorry if I missed it but what Nvidia driver version are you on?  Any chance of reverting to an older driver?  I am on 456.71 and never seen a device_hung error in all my simming.  Perhaps it's at the driver level?  Have you tried a driver rollback?  

471.96 - the title of this topic. I wish it was as simple as reverting to an older driver. I've had this problem with several.

I'm going to check sound drivers shortly.

[psolk 3,040]

12 minutes ago, Ray Proudfoot said:

471.96 - the title of this topic. I wish it was as simple as reverting to an older driver. I've had this problem with several.

I'm going to check sound drivers shortly.

Yeah, that was a stupid question.   

How far back have you gone?  With a 1080 card there is probably very little in the later driver versions for that card.  I have a 2080ti and tried to standardize on a driver before all the 3K cards became the focus.  

Couldn't hurt to go all the way back to a year old driver which is what 456.71 is and see if the issue still exists.  Perhaps there was something introduced for the 3K cards our 1K and 2K cards don't like... 

Edited October 8, 2021 by psolk

[Ray Proudfoot 8,954]

1 minute ago, psolk said:

How far back have you gone?  With a 1080 card there is probably very little in the later driver versions for that card.  I have a 2080ti and tried to standardize on a driver before all the 3K cards became the focus.  

Couldn't hurt to go all the way back to a year old driver which is what 456.71 is and see if the issue still exists.  Perhaps there was something introduced for the 3K cards our 1K and 2K cards don't like... 

I haven't a clue. I don't keep track of what drivers were installed and when. The general advice is you should use current drivers so I'm reluctant to install older ones. Unless you used those with a 1080Ti it's not a like-for-like comparison. I very much doubt newest drivers are not backward compatible. There would be chaos if they weren't.

The problem with this topic is I'm not getting any feedback from those with 471.96 drivers who also have edited the Registry with the recommended entries. Unless others do that I'm alone. It needs more people to try these workaround and report back.

Thanks for your suggestion Paul.

[psolk 3,040]

1 minute ago, Ray Proudfoot said:

I haven't a clue. I don't keep track of what drivers were installed and when. The general advice is you should use current drivers so I'm reluctant to install older ones. Unless you used those with a 1080Ti it's not a like-for-like comparison. I very much doubt newest drivers are not backward compatible. There would be chaos if they weren't.

The problem with this topic is I'm not getting any feedback from those with 471.96 drivers who also have edited the Registry with the recommended entries. Unless others do that I'm alone. It needs more people to try these workaround and report back.

Thanks for your suggestion Paul.

Two trains of thought (as with every in Flight simmin LOL)  

1st is you should always be on the latest and greatest driver.  Second is if it isn't broken don't fix it.  Hence 456.71 for me as it resolved the security vulnerabilities but was rock stable with a 2080 card.  Yes, they are always backwards compatible to an extent but inevitably the features they drive into the latest versions are targeted and optimized for the latest cards which may not be ideal for our prior gen cards.   

If all else fails you could revert to 456.71 to see if the issue exists.  If it does you can very quickly rule out video driver as a cause.  If it doesn't fail you could start to rule out a P3D bug.  It's all about trying to eliminate potential causes to get to actual root cause.  Sadly if the issue is within the driver then all the registry changes in the world may not help you and unless you try to rule out the driver itself this could all be a fruitless effort despite everything you've put into it!  

[Ray Proudfoot 8,954]

Paul,

I only made changes to the Registry yesterday for these two entries changing them from QWORD to DWORD. That negated all previous tests. So far with 2 flights I've had one 100% successful one and another with a freeze but it did recover. Neither has shown the DXGI _HUNG message.

It may transpire this is as good as it gets for me. I'll only know after more flights. If the dreaded message reappears only then will I consider different drivers.

[Ray Proudfoot 8,954]

3rd test flight from Vancouver to Portland in the AA 737-800 NGXu. Paused it for 40 mins for lunch and when I returned it was still okay and I completed the flight without any issues.