mchelper crashing in XP

I had some problems with an installation in the field (client said inputs became unresponsive and it was necessary to restart the computer - which restarts an application and mchelper - to make it work again). So I left mchelper.exe running with a controller kit attached via USB here in my lab. When I checked up on it a few hours later, mchelper.exe had stopped with an Application error: mchelper Preferences: mchelper.exe - Application Error "The instruction at 0x004ea955 referenced memory at 0x008000a. the memory could not be read." has anyone else been seeing errors if the controllers are left attached and running for extended periods of time? I am repeating the experiment - now with the Firmware 1.2.0 loaded (rather than whatever it shipped with) and am curious if this firmware update should be part of the process after a microcontroller is received? This was running on XP sp2. controller was right out of the box. running mcHelper 2.0.0 thanks!

As we continue to release firmware updates, it's always best to apply them to new boards. We do our best to get the latest version to the boards when they're manufactured but sometimes the updates come after a board has been manufactured and before it gets shipped. mchelper 2.0 definitely works best with boards on at least Heavy 1.2. As for the crash, that doesn't provide too much info about what might have caused it - can you provide any other details about what it was doing? I suppose if you just left it running you probably didn't see if the crash happened in response to something in particular? In any event, please let me know if you still see this problem once the firmware is upgraded. Thanks.

I have seen a different type of crash using mchelper 2.2.0 running on XP. This sometimes occurs after I send a "/system/task-report" OSC command to the controller (running Heavy 1.5.1 firmware). Immediately before mchelper crashes, it displays an error message in the dialog window: COM4 Error - Osc packets must start with either a '/' (message) or '[' (bundle). I also noticed that the "/system/task-report" command does not always result in a complete list of running tasks being displayed, in the times when mchelper 2.2.0 does not crash. Does anyone have any idea why this might be happening?

Huh. As for the crash, have you noticed it only in response to the /system/task-report message? Any other circumstances? And how have you determined that all the tasks are not being listed?

I found the same issue.  mchelper crashes when you send it a /system/task-report.

 The other issue/feature I found is when you send a unmatched subsystem entry via usb, mchelper looses connection with your controller for a few seconds.  The controller is fine, and shows back up, but this feature doesn't give the user the best warm and fuzzy feeling.

I am using a custom C# interface to talk to my hardware and have had no problems