Satellite crashes running under Windows 11

[phillipivan]

We have encountered a crash when running Satellite Version 1.8.1 under Windows 11, with a Stream deck XL connected. See attached error message.

Please let me know what other information I can provide to assist. We will check the event log for further clues tomorrow.

[Julusian]

Does this happen when connecting or disconnecting the streamdeck, or randomly?
How consistently/often is this happening?

[phillipivan]

We have only seen it occur once to date, without obvious cause, so for the time being 'randomly'. Happy to do some investigative work if you can point in a worthwhile direction.

Edit to add: This was not during a stream deck connect / disconnect.

[phillipivan]

We have had this occur again overnight, here is the message from the event log, this time on a machine running satellite 1.7.5:

Application popup: Companion Satellite.exe - Application Error : The instruction at 0x00007FFFA8C1B48A referenced memory at 0x0000000000000048. The memory could not be read.

[Julusian]

Does windows event view say anything more on this issue? perhaps giving an indicate of a dll or executable filename that triggered it?

[phillipivan]

My previous comment had the only relevant entry we could find in windows event viewer last time it occurred, which doesn't really add anything beyond the error message dialog box.

[JuddiP]

Hi @Julusian,

Copying in further application event details from Windows Event Viewer (from 04-09-2024) -

4/09/2024 9:40:29 AM

• Faulting application name: Companion Satellite.exe, version: 1.7.5.0, time stamp: 0x656fb32b
• Faulting module name: 550c65d3-0e4e-4a70-9e1f-00129bcc3de2.tmp.node, version: 0.0.0.0, time stamp: 0x651b0c23
• Exception code: 0xc0000005
• Fault offset: 0x000000000004b48a
• Faulting process id: 0x0x2C64
• Faulting application start time: 0x0x1DAF5263C924422
• Faulting application path: C:\Program Files\Companion Satellite\Companion Satellite.exe
• Faulting module path: \?\C:\Users\hanlocal\AppData\Local\Temp\550c65d3-0e4e-4a70-9e1f-00129bcc3de2.tmp.node
• Report Id: 67f480f6-601c-42f1-9929-f2559f9051ca
• Faulting package full name:
• Faulting package-relative application ID:

It is interesting to note that we currently have another application that runs on these PCs that allows us to control and preview our ingest servers that is experiencing a memory leak. Do you think that could possibly be related? These events are typically occurring a little while after reported resource exhaustion events -

The above was reported last night, and subsequently Satellite was closed out (with no application error event, oddly enough).

[Julusian]

Thanks, that additional details gives me a bit more direction.
Could you check if the file C:\Users\hanlocal\AppData\Local\Temp\550c65d3-0e4e-4a70-9e1f-00129bcc3de2.tmp.node still exists? It would be really good to know which native module that is.

Mostly from the fault offset, which sounds like it is address of what was currently being executed, I think this is either from @julusian/image-rs or usb. Both of those have instructions which align with that offset, the other libraries do not.

I am trying to figure out where the problem could be by looking at the decompiled code at that offset, but this is hard and is a lot of guesswork..

I'm hitting a dead end in this. In both cases it really looks like the address from that report is deep inside system library code, both times it looks like it could be in areas handling utf8.

[JuddiP]

Hey mate,

Unfortunately it looks like that temp file no longer exists on the machine.

Is there anything else I can do to assist?

Check the faulting module path file again as soon as it occurs?

[Julusian]

Yeah when it next happens, the same information as provided above and a copy of that .tmp.node file would be good.

I'm not sure what else to do. Maybe I could make a build of satellite which does more logging to try and narrow down where it is happening? Ill have a think about that

[Julusian]

I've added a new library which should produce better logs/errors when encountering a segfault. This is in 1.9.3.

[Julusian]

Is anyone still experiencing this?
Maybe the library I added back in october produces some further logging that could be helpful in figuring this out?

[phillipivan]

I don't think we have seen another crash in some time. Probably since we last reported one here.

We have stopped running the software @JuddiP referred to as having a memory leak. So perhaps this is a contributibg factor.