Unity Editor crashes with Native Plugin on Stop

I've got a very strange situation with a Native plugin I'm working on. I've seen similar (but not exact) posts, and am hoping someone might have some info on this.

I'm writing a native plugin that talks to the Logitech Gaming SDK so that I can bind to a specific input device without worrying about windows' internal ID's. I've got the functionality working, and in a dedicated WPF test application, everything works flawlessly.

When I go to Unity, things start to get weird. First off, in a build, everything works perfectly. In the editor is where things get tricky.

First, the Logitech SDK uses DirectInput, so I get an uncatchable unhandled exception if my current window is not the calling window for the controller bind. I've worked around this by making a button in the game window to initialize and destroy my plugin functionality (basically, allocating my controller information and releasing the controller). The challenge is that we can't use this in our final product. We can work around it by initializing the plugin on demand, and make sure the user has clicked something in the game window before trying to use it. It's not ideal (we'd like the controller to bind on load and unbind on shutdown), but it works.

It seems the editor doesn't put the focus on the game window anymore when you click the play button. That's the cause of that issue--as I said, it's minor.

What's not minor is that the editor crashes when I click the stop button. I suspect that even though I've shutdown all of the resources within my native dll, the editor is holding onto something.

Interestingly enough, this is the exact reason I started building my own native DLL in the first place. The Logitech Gaming SDK that's on the asset store does the exact same thing when you set properties on the device. So, it's not just me. And this all seems new to Unity 5 (it was working flawlessly in Unity 4).

If you want to see this behavior, you can load the default Logitech Gaming Software asset in a blank project, attach the sample steering wheel code to a blank gameobject, and run the scene. If you hit PgUp while running the scene, everything will work, until you hit stop--at which point Unity will crash.

I suspect that some process is binding to DirectInput and holding onto some memory in the scene somewhere, but there's no crash logs or anything along those lines to find out. Moreover, if I try to debug the process, it tells me that there's an Access Violation (0xC00000005) in mono.dll, but I can't get any further, because obviously I don't have the source files with the mono exceptions to connect to. This *could* be related to the core functionality of the Logitech SDK, but as I mentioned earlier, it works flawlessly in a WPF project using C#, so I suspect the issue is somewhere in Mono's handling of the DllImport.

What I'm hoping to find is if I'm doing something wrong in my Native DLL, or better yet if there's unsupported functionality of P/Invoke that I need to be aware of and work around, as the documentation's a little bit lacking.

What I've found so far:
In my WPF test app, I call:

Code (CSharp):

1.  
2. [DllImport( "G27Plugin.dll", CallingConvention = CallingConvention.Cdecl )]
3. private static extern bool UpdateG27 ();
4.  

In my Unity code, I call:

Code (CSharp):

1.  
2. [DllImport( "G27Plugin" )]
3. private static extern bool UpdateG27 ();
4.  

As I said, I've got everything working, and in a build, it's just fine. This is only an in-editor problem. But, it's kind of a showstopper if we're guaranteed to crash the editor every time we try to test something (and input is such a core functionality we can't just test it from time to time).

 

OK, I think I found the issue.

The Logitech SDK internally interacts with DirectInput and does some mangling to add hot-swappability of Controllers.

What this means in practice is that the SDK is going to the Unity Window being used and wrapping it's primary responses with an internal version that calls the Unity Callback. So, it's the Logitech SDK that's the problem. I've actually adjusted some of the code in the SDK so it works now--primarily allowing Background access to the DirectInput device, and ensuring that the WndProc gets reset to its original state when the interface is destroyed. So, this would be a problem if I was using multiple devices, but with the setup I'm developing for it works.

 

I'm putting together a Bug Report for this now, I've had time to work out most of the kinks, and I've narrowed things down pretty significantly. It seems that the editor will crash on stop if any Win32 commands have been called in a native plugin. Everything works fine in a build. And, this seems to apply to Unity 4 as well as 5. I've traced the problem with the Logitech SDK to setting the properties on the wheel (wheel range, force amount, etc), which reading through the SDK triggers a Win32 SendMessage call to the Logitech Device Driver. I rewrote my plugin to open a separate window (which never gets shown) which can process the rest of the data and all of the Various Logitech Messages. That part works fine, the crash happens when I hit stop in the editor, and if I debug or read the logs I get "Access Violation (0xC00000005) in mono.dll", and can debug no further.

I've made a simple test where I just create a window which maintains an internal count, so when I update the count increments (no new window, just a number gets updated). The window is closed OnDestroy(). Again, works perfectly in a build, crashes on Stop in the Editor.

In order to work around this issue, I created a windows service which will handle all of this for me through Remoting--again, which works perfectly for a .Net application. I don't like the idea of latency, but ok. This works in unity as well. However, with Remoting, when I release the object, Unity seems to hold onto the remote connection. My guess there is that this is more related to Mono's implementation of remoting rather than anything else though. I've made a desktop shortcut that restarts the service and makes it work, but having that is not an option for a shipping product, and from what I've seen we can't get the permissions to start and stop a service from within code.

My current solution is using Conditional Compilation to use the native plugin in a build, and Remoting for the editor so that our team can just restart the service rather than restarting unity.

When the editor hangs from the remoting, it throws a Remote Connection Forcibly closed error when I restart the service, which confirms that the editor's hanging onto the connection--however, the way to close a connection with remoting is to set your remote proxy to null. With a TCP connection and a remote object created by Activator.GetObject(), there's no real way to close it from the client end other than that.

I'll update once the bug's posted.

 

Bug and Sample Projects submitted! http://fogbugz.unity3d.com/default.asp?698602_da3afu536f0edjef

 

Also experiencing the exact same thing with LogitechGSDK.

Unhandled exception at 0x00007FFAA76533F2 (mono.dll) in crash.dmp: 0xC0000005: Access violation reading location 0x0000000100000031.​

I stopped at the disassembled lib's hex representation.

Thanks for this insight!!! Helped me narrowing down the s**** vastly.

I'm with you that it seems to be an Unity issue, escpecially as long as it is an Editor issue and thus should be fixed by Unity.

 

For searchers out there who are also experiencing this issue. I just want to be fair to Logitech that this issue is specifically related to Unity 5 up to 5.1.1 (as of this post) The SDK worked excellent in U4. The OP who I work with worked on this for weeks and was able to sort of get it working by hacking their code. But it is still crashing. I wish Logitech would update their SDK for U5. We can't roll back to U4 due to memory limits in the 32-bit editor.

[UPDATE] We were able to get our native dll to work (Unity 5.0 and up). Unity has been notified and was able to reproduce the error with the example we sent in. They asked us for our re-written code to see what we've done - so it seems they're looking into it...see fogbugz link.

http://fogbugz.unity3d.com/default.asp?698602_da3afu536f0edjef

 

I too had issues with this sdk, getting the same access violation both in editor play mode and in builds. I tracked it down to incompatibility with other joysticks. The joy.cpl list must be empty except for the G27. Depending on which other joystick might be connected, best case is simply that the sdk will not affect the G27, worst case is the above crashes. Otherwise it is working fine both in U4.6 and U5.1.2.

 

Any more information on this!? Is it finally working?

 

WM_QUIT lol Will check out.

 

Same problem here. Working with Unity 5.2.2f1, and logitech sdk 1.6. Cant read any value in my G27, the function LogiSteeringInitialize returns always false. The wheel is visible and working from windows device panel, also working in old impl in unity 4. I've tried to put architecture DLLs in build folder & editor folder, no success

 

I'm working with Unity 5.3.0 Pro and I'm getting false every time, too. I've tried both 32 and 64 bit plugins, moved them around into Plugins folders and such.. but nope, can't get any sort of result. The sample code from the Logitech plugin just says to plug in a device.. it never detects the wheel, but if I go into C:\Program Files\Logitech\Gaming Software and unzip the regular SDK Logitech_SDK_For_PC_1.00.002.zip, the test exe it contains works fine.. so I know the wheel works, it's got the right version of DirectX and the regular SDK will run with it .. but the Unity plugin never detects anything.

Anybody got any fix / workaround for this?

Thanks!

 

My fix was use the old logitech sdk which i used in unity 4, but now in unity 5. Can't make 1.6 work in unity...

 

What version are you using of the Logitech SDK for Unity 5?
I just imported the new one from the asset store into 5.1.2 and it was hollering about compiling it in 64bit.

Im just trying to update a working 3.5.7 project with Force Feedback to 5.1.2

Thanks.

 

Don't know exactly. It's an old one which i used in a unity 4 project. Downloaded time ago, but fortunately it has 64bits dll's also.

 

Okay, thought I'd update everyone looking into using the original Logitech SDK 1.6 in Unity 5. As you know the SDK worked fine in U3 & U4, but when we upgraded to U5 we had crash issues in the editor. Well, as stated above we went to extreme measures to fix the problem. My coworker, the OP above (who oddly enough used to work for Logitech years ago as a customer service tech), rewrote some of the Logitech SDK Lib and created a Win service to communicate with the G27 in U5. This worked great until recently.

So...as you may already know Logitech discontinued their G27 Wheel - Aarrgg!!!. Since we make driving sims we had to use something so we opted for the G920. However, the G920 would not work with our custom code. And the original programmer has since left for other opportunities. I am not adept at C++ but I tried to fiddle with his code to no avail. Then out of desperation I decided to go back to the original 1.6 Logitech SDK from the asset store. Here's what I found...

I loaded Logitech's example scene and code and it worked great in the U5 editor and in build - with both the G27 and G920 (go figure). So I basically rewrote our input by stitching in their exact code example then slowly modifying it to our needs. The SDK does work in Unity 5 (we're currently on 5.1.2 f1), but there's a catch. The offending code that causes the editor to crash is associated with the set wheel properties function: LogitechGSDK.LogiSetPreferredControllerProperties();

Anytime you try to set these the Editor crashes - even in their code example scene. I am trying to find other ways to work around this problem to hopefully get the wheel to feel right. But it's a big let down since I can't set the wheel range.

Also note, the G920 LGS profiler 8.79 does not have the same settings available as on their older G27 compatible LGS profiler 5.1...and it does not recognize the G27 - and of course the 5.1 profiler will not see the G920. But you can have both LGS profilers installed simultaneously. Why would they make multiple LGS profilers? Why not one LGS to rule them all? I don't get it!

 

Have you found any workaround for the editor crash problem?

LogiSetPreferredControllerProperties() doesn't work and it oddly seems to work only when regaining focus of the editor window, stopping the player will crash unity. You can't effectively work with this plugin in it's current state.

Someone do something!

 

For a work around I have been just clicking on a chrome web browser and then back to the editor and it starts working again. (Finds the FFB Controller and returns (true)). It does not crash in my standalone as the user always has a controller plugged in and does not "un focus" the game.

 

Hah, just saw the notification on an update to this and was curious...quite a bit of activity!

I believe the final workaround I used before I moved on to other pastures was to use #if EDITOR (or something similar) to avoid calling LogiSetPreferredControllerProperties in editor. I also wrote a WPF app that could be used to test and then find settings that worked well with the plugin, which just meant that to really test our code we had to make a build, but there was far less rebuilding there than there would be with no feedback in editor. Definitely not ideal, but more effective than having to restart the editor every single time I used the dang wheel.

 

This is still not working in 5.3.6p6

Well it used to kind of work before (sometimes crashing, other times you had to disconnect and connect the device multiple time before it started working properly again after setting device properties from code)

Apparently now it got finally fixed, it just doesn't work anymore.

Why am I even still trying, release date is getting closer and we had to remove the force feedback support from the game features.

Unity is a joke.

 

I found that the wheel SDK from http://gaming.logitech.com/developers works with g27 steering wheel in Unity 5 (meaning I get force feedback). The version from asset store is older and not updated.