If I had the answer to this, I would expect a FREE
Power Gaming Computer,
Free MS–STORE :For Life:
and a autographed Picture of all the Asobo & MS FS Team !!
But I don’t
But one thing that stuck me with the few CTD analyzed Crash Dumps I have had (and got from others) was that many seem to be associated with file access, not unable to access, and Null (or -1) Pointers.
Lots of check for returned Null Pointers, but not many for -1 pointers !!
Could there be a correlation between UEFI vs Legacy ?
Uefi settings make a huge difference. I turned off my game boost (6700k) and had heavy stutters, boost on everything fine. I turned on a very light OC profile that was preconfigured by the manufacturer/seller of my PC and had CTDs. Wrong drivers, not only gra-card have an impact, aggressive antivirus softwares have a huuuge impact on performance and stability.
A good friend of mine is IT expert, OC and PC configurations is his daily bread. His sour comment was simply „people read a bit in forums where people give advice who googled the answers in other forums and then they start to mess up their computers. And then they run into issues and then they complain to software developers. And it‘s even worse when resellers do that and sell expensive gaming systems that are totally messed up and overclocked with google knowledge.“
I think the most stable systems are those of a couple years of age with default setups. The urge of some people to get the last bit of FPS out of a system is not always the best idea. And when „totally vanilla“ systems make problems I‘d start where I got them. I have a quite old computer, cramped with all kind of stuff, games, utilities, 4 SSDs and one HDD. It‘s not the fastest PC but I haven‘t had a single CTD that wasn‘t caused by faulty addons. I think there‘s a connection to what I wrote above.
I didn‘t have One CTD before SU5. After SU5 I had a number of them, not a lot, but I had them. No change in configuration. Same OC on CPU/ GPU. No changes between the versions. Ar least on my end OC is not the problem. Btw: A null pointer exception is always a bug. Be in the SIM, be in the driver , be it in the OS.
Yeah SU5 wasn‘t the brightest star. It basically lead to me dismounting my yoke etc and take a break from flight sim. But the crashes have been around since the release for sone people while others had no issues.
A detected and handled null pointer exception can be caused by a bug.
I suppose a null pointer exception, detected or not, almost always represents a bug in the program.
Only case imho there is no bug in the program, is when a null reference pointer originates from external sources (drivers, libs like DX-11, DX-12, servers), that should be detected and handled properly, and should not cause an exception in the program, let alone a CTD. We agree on that one…
… but sometimes, bugs in a program get fixed by detecting the null-result and circumvent that. Your answer designates these cases as non-bugs, because they get handled properly. I think these types of handlers are repairs. The null-pointer (or bug) occurred, but the program is prevented from crashing by the handler. Symptom: a certain feature seems unavailable, or a change is done, but not visible. These are also bugs.
Ok, maybe shooting blanks here. So please correct me if i’m wrong. And this is definitely not a blame on xbox development, but from a developers perspective when creating generic api’s. I also need to say I have no experience in the technique i’m adressing here.
So, with that said.
There has been development for xbox release, running dx12, the pc is running dx11. I do not know if DirectStorage is implemented there. But, if that is the case i would expect file access layers not expecting different return handles like @N6722C is stating (have fun handle these with USB returns can be so inconsistent there).
If these generic interfaces are based on these assumptions on return handles, it could explain a lot I’m extremely simplifying here, there would be way more layers (dispatchers, handovers, abstraction layers etc…).
\ Generic Api
Couldn’t the latest update not have #$%^ this up with heavy parallelisation? I’ve seen a illegal access to a resource pointer expected by a graphics card which wasn’t present (reported by a directx api method)?
It could be the parallelisation f-ing up here because in different handle implementations where timing could be off because of these different file handle layers?
I realise now i’m saying two different causes here, but from same source.
Edit 2: It could also partly explain the exfat stories i’m reading.
When that resource pointer is passed, it must not be a null-pointer (causing illegal access), it must be filled in ! When it is a null pointer, as @N6722C refers to, the aquire went wrong: server packet issues, or something went wrong with the texture decompession, or with BGL decoding (meshes or UV coords read from addins). Null content should not reach the GPU, so the CPU throws the exception and you see that message.
Parallellisation could be an issue as well, but the most obvious cause for a null pointer found in GPU resources is a read error of some kind. Missing data in the rendering pipeline.
At the part of the above code, where the -1 Pointer was called, it is correctly testing for ZERO, but not for -1 – which in this case, was obviously an OPTION as a returned handle, for whatever was going on, and went wrong.
Its obviously not so much a problem when things go wrong, if the are handled correctly (Forgive the PUN !! )
Normally CTD are caused due PSU that can not handle the energy required and the PC decides to “turn off” what is causing that peak of energy
Heat. My 3080 easily reach 72 celcius degree in a case with a good airflow. Some PC identifies the heat and, to avoid damage, shut off the software