Simmconnect I/O Error

Good day all, When I use the SetDataOnSimObject function from the SDK at a
high frequency, for example at every frame (through a
SIMMCONNECT_RECV_ID_FRAME event for instance) , after a few minutes,
SimConnect crashes with the following message: I/O Error! (2, 80004004). This
does not happen though on lower frequencies (like 6Hz or every second). Is
this something known ? And if yes, is there a workaround ?

Can confirm this issue on our C# Application running not on 6Hz but every 1-4
seconds. It is not reproducable at which point this triggers and seems random
for now.

Hi, There is no such limitation. Even if you use SetDataOnSimObject at “high
frequency”, the sim (and the client) should be able to handle that. Note that
you external app has (in general) a higher frame rate than the sim. I’m afraid
that there is no workaround for now but I would be interested by your project
and a good way to repro, so I can investigate. Best Regards Maxime / Asobo

Hey Maxime, what can such “I/O error” trigger? the Log is not very helpfull at
this point to track it down.

Bonjour Maxime, Happy to provide some info about that. Roughly: I am
interfacing a non visual simulator ( PSX 744 ) to
MSFS to have a scenery generator. I want to control the plane through external
variables (lat, long, pitch, bank angle) provided by PSX. In order to do so:
fetch the external variables from PSX in a struct. 2/ I Subscribe to the
system event EVENT_FRAME 3/ In my callback function, if the EVENT_FRAME is
triggered, I update MSFS via a call to SetDataOnSimObject. But as I
mentionned, if I run the update for example in the 6Hz system event, there is
no such error.

Hi, Can you provide me with your source code (or a sample which reproduces the
problem)? As you said and as Kaiii3 said, this issue happens randomly/after a
few time… so this is not something linked to the function itself but this is
a side effect of something else. Basically, without a sample, the only thing I
can try is the calls mentioned in your point 0, 2 and 3. The PSX part is
missing and every thing else is missing too. So there is no way i can track a
side effect with that. You can send it in private by following the third
section of this link: [
crash/77) Best Regards Maxime / Asobo

Bonjour Maxime, Sure thing, I will send you something that does not need the
PSX part

And just wondering… does the struct packing have a potential effect here ?
My struct size was 224 bytes, and that caused the problem. Reducing the size
to an aligned struct seems to solve it (but I am still testing)

Hi Yes, it might be the problem or a part of the problem. Most of the struct
returned by SimConnect don’t have padding. So if on your side, your struct has
padding, you will try to read more memory that you should which leads “in the
best case” to random and false data in your sruct, and to a crash in the worst
case. So for those struct you should use:

// C++
#pragma pack(push, 1)

struct MyStruct
    // ...

#pragma pack(pop)

// C#
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 1)]
struct MyStruct
    // ...

Does it solve the crash even in “high frequency”? Best Regards Maxime / Asobo

Hi As documentation says: IOException is the base class for exceptions thrown
while accessing information using streams, files and directories. In our case,
the problem comes from the reading of messages sent by server in the client
part. As depayns said, it might be linked to “reading to much data” because of
padding issues. Best Regards Maxime / Asobo

Merci Maxime ! That indeed seems to have solved the issue. Now back to some
intensive stress testing. Cheers, -Stephan

Hi guys, Sorry to get back on this topic, but actually now I found the real
cause of those crashes. Padding the structures improved a lot, but after some
heavy testing it still occasionally crashed. It turns out actually that
SetDataOnSimObject is not thread safe. And in some occasions this might
cause a crash of SimConnect with the above mentioned error. The solution was
to MUTEX the access to SetDataOnSimObject and this indeed solved totally
the issue. Hope this might help other people having a similar problem. This
leads to the following question: are all functions in the SDK thread unsafe ?

This was already answered [in another
thread-safety.html): NO, SimConnect is not thread-safe.