Sign in to follow this  

System Access Violation

This topic is 399 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey folks!

 

I'm getting an error that I can't seem to track down and was wondering if I could get some input.

 

As the title of the post suggests, I'm getting an access violation error when running my application:

A first chance exception of type 'System.AccessViolationException' occurred in MyInterface.dll
Additional information: Attempted to read or write protected memory. This is an indication that other memory is corrupt.

The solution this is running from consists of three projects:

* A C# Application for the GUI

* A /CLR .DLL that the C# application references and sends data to... it's really an interface to the third project

* A DLL that houses a Wwise sound engine

 

When running the sound engine DLL from another C++ project (bypassing the C# application and the /CLR interface) it works without any problems, and the data it processes is identical, so this crash only happens when running via C#. I'm using C# so I can get a pretty user interface, but may have to ditch that approach if I can't get this working.

 

When running from C#, the application creates a separate thread for the sound engine, and the engine updates and then sleeps for 33 milliseconds (to simulate target frame rate for the game).

 

Any ideas what could be causing this crash? Are there any kind of parameters for the update thread I might be missing here?

 

I should probably note that the sound engine makes a large number of allocations, and it's accessing the memory from these allocations that seem to be triggering the crash.

 

Thanks for your input!

Share this post


Link to post
Share on other sites

You've got a bad pointer somewhere. Time to fire up the debugger and go hunting!

Only happens when running via the /clr interface and that's not where the crash is happening. Are there any memory restrictions that you know of when allocating from a separate thread like that? Driving me a bit crazy :)

I thought it might be something to do with the common language runtime compiler flag from the interface project, which is why I split the engine out in to a separate DLL. No joy though, obviously :D

Share this post


Link to post
Share on other sites

Do you pass any pointers back and forth between C# and C++?

Do you allocate memory in one language and use it in another? How do you handle the marshalling?

Is the C# wrapper around the DLL using the correct signatures everywhere / are the calling conventions correct?

Share this post


Link to post
Share on other sites

Do you pass any pointers back and forth between C# and C++?

Do you allocate memory in one language and use it in another? How do you handle the marshalling?

Is the C# wrapper around the DLL using the correct signatures everywhere / are the calling conventions correct?

 

* no pointers between C# and C++

* the only allocation that's made from C# is the singleton instance of the c++ interface (CLR)

* the C# wrapper is fine - everything is properly initialized and I can play sound events without any trouble (through Wwise). The crash is happening from within a custom wwise plugin that works in a pure C++ environment

Share this post


Link to post
Share on other sites
There are a tremendous amount of things that could be wrong, but I've never had a C# -> C++/CLI -> C or C++ program fail when it wasn't my fault.

The most likely problem is something within the C++/CLI code that you've written, but it's always possible wwise is making some unsafe assumptions that the C# process somehow violates. Is it small enough to post all of it here? Edited by Nypyren

Share this post


Link to post
Share on other sites

code that you've written, but it's always possible wwise is making some unsafe assumptions that the C# process somehow violates. Is it small enough to post all of it here?

Unfortunately the project is fairly large, and under NDA so I can't really post any of it. 

Share this post


Link to post
Share on other sites
OK, other things to check:

- Make sure your 32/64-bitness matches across all the EXEs/DLLs you load into the same process. I doubt this is the problem but you never know...
- If possible, try using a single thread to see if the problem disappears.
- If you're passing any non-primitive data types between C# and C++, check *every single one of them* to make sure it's marshalled correctly.
- If you're doing any kind of serialization, double check that the C# and C++ sides agree on everything.
- Check for missing initialization functions on the C++ side that you might be missing.
- Check everything for returned errors on the C++ side.
- If there are debug versions for the libraries you're using, try them if you aren't already. They might give you more info.
- Contact the wwise plugin vendor.
- You can try loading your C# app as a DLL from a C++ EXE which has successfully initialized the wwise plugin in a stable manner. (C# EXEs can technically be loaded as if they are DLLs, but the main function will not be automatically called)
- Try compiling your stable pure C++ program as pure CLR instead and see if that's enough to cause the problem.
- It'll be hard, but dive into each thread's TLS and try to find out if there's any fighting going on between C# and C++. I've seen third party libraries do the most absurd shit and TLS is one of those obscure things. Edited by Nypyren

Share this post


Link to post
Share on other sites

OK, other things to check:

- Make sure your 32/64-bitness matches across all the EXEs/DLLs you load into the same process. I doubt this is the problem but you never know...
- If possible, try using a single thread to see if the problem disappears.
- If you're passing any non-primitive data types between C# and C++, check *every single one of them* to make sure it's marshalled correctly.
- If you're doing any kind of serialization, double check that the C# and C++ sides agree on everything.
- Check for missing initialization functions on the C++ side that you might be missing.
- Check everything for returned errors on the C++ side.
- If there are debug versions for the libraries you're using, try them if you aren't already. They might give you more info.
- Contact the wwise plugin vendor.
- You can try loading your C# app as a DLL from a C++ EXE which has successfully initialized the wwise plugin in a stable manner. (C# EXEs can technically be loaded as if they are DLLs, but the main function will not be automatically called)
- Try compiling your stable pure C++ program as pure CLR instead and see if that's enough to cause the problem.
- It'll be hard, but dive into each thread's TLS and try to find out if there's any fighting going on between C# and C++. I've seen third party libraries do the most absurd shit and TLS is one of those obscure things.

 

#1 - good point, I'm pretty sure everything is x64 but definitely worth checking over

#2 - not sure how I can do that from c# to c++, I have to render the audio each frame and without a thread or a timer I'm not sure there's an update loop I can hijack 

#3 - will do. I don't think there are any complex types being passed, but definitely something to check

#4 - no serialization, on the c# side of things but I do load in data on the c++ side - I'll verify everything there is correct

#5 - good point, will do

#6 - no visible errors from the C++ side of things. audio events without effects work and no error reporting from wwise. I'll dig in to it.

#7 & #8 - I wrote the plugin and I'm linking against the debug libs, so I can step in to everything

#9 - I'll try that out, thanks

#10 - sound advice

 

Thanks for your help!

Share this post


Link to post
Share on other sites

This topic is 399 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this