A null pointer is only a memory adress that is set it to 0 so it would do no harm.
Dangling pointers are bugs. i.e. pointers to objects memory that have been deleted amd no longer exist at the adress. If you use them you overwrite other objects than the one you intended to and create a potential disaster.
A problem are also programs that dont check null pointers and actually rely on doing something with objects that aren’t there yet. But this is simple to check. A null pointer in itself is only a memory adress that hasnt been initialized yet. Totally normal and happens millions of times in every program. You just need to handled by a simple check if xy!= nullptr (pseudocode).
If they dont catch it it is problably only because the code isnt final yet or because it happens in closed binaries. I think those will disappear with time.
Normally if I omit such checks it is for performance reasons. It is obviously not good practice to check for something that never happens.
Let’s say you have a variable set it to 0 and you only increase it. Then a check if(i<0) would be redundant. Likewise, a pointer becoming -1 means that the datatype is signed, which is odd.
Well, in this case, it’s obviously happening for some reason, and without the ADDITIONAL error trapping, causing the CTD.
Then the question becomes, if WE can see this (with a crude CrashDump) and get the CTDs, why does Asobo not appear to be seeing the same thing, and stopping it ?
Well, the title is quite broad, and it opened with file access and with an uefi/bios question and now we are talking about joysticks and VFS’s.
Well, the USB descriptor says:
bmAttributes: 0xC0 (Bus Powered Self Powered )
So, that should be ok. keep in mind, that there is always 5V coming from an usb port. And in this case seems to be isolated, otherwise it could probably not have been recognized anyway (without jumping to details). So I would not initially expect a hard hardware issue.
I do not know, but, does mfs try to read any values while creating profiles, does anyone know?
Who knows? There is probably a reason for it, such things can be complicated.
My first thought was that it happens at a completely different level of abstraction, like in legacy dll’s that they have to rely on.
I also have only a CTD maybe once a month or so, I think the problem is more about congestion of the community folder with mods that have d.i.y. coding than something being wrong with the sim. It just needs to get more robust.
MSFS actually gives detailed crash dumps (found in C:\Users\USERNAME\AppData\Local\CrashDumps) that contain more specific info. I sent a couple of those to dga over at Working Title and they informed me that, despite my exclusions, my antivirus was “hooking” (interacting) with the sim. I checked and my AV was out of date by a month. I updated and still have to test if random CTDs still occur but I suppose this was partially if not fully causing it.
The Joystick is recognised by W10, and all USB & Joystick test programs, work fine… W10 can read the post a7 Buttons fine.
But in the case of the Thrustmaster, it is only detected if there is the external Power connected, which would tend to indicate that most of its electronics , Processor, USB, are powered via the external power supply, and NOT over the USB cable.
The only thing this means here is that the whole 64 bits are set to 1.
The idea it is signed or not, a pointer or not, is semantic only, not intrinsic to the value itself. It is only what you do with it which governs its type. A very simple example of this is the difference between ASR and SHR (in x86 parlance)
Cheers, fully understood (odd design though). Ground would be connected anyway.
But, the thrustmaster, What do you see in windows itself, is accepting input? Have you noticed anything in the event viewer (like warnings etc)? I could read usb descriptors, showing it’s an hotas (because of the name included as shown in your post up there ), but the device manager still displays it as a (generic) HID. Could you check?
Before doing anything drastic (like system repair etc..), are you 100% sure, i don’t know if there is a detailed report written. You see this error when plugging in/out or it’s at the moment mfs wants to write a profile?
Edit: @CptLucky8 Thanks for hooking in. You’re quicker then i am.
Why are you assuming that CTDs were caused by the graphics driver in the first place?
MSFS doesn’t communicate directly to the driver, all windowed or borderless windowed games are handled by DWM (Desktop Window Manager), graphics drivers are not connected to MSFS in any way.
), but the device manager still displays it as a (generic) HID. Could you check?
