views:

202

answers:

3

I have this strange issue with some third party DLL's. The third party provider references some open source DLL's that have a memory exception whenever I try to use a certain method. This issue does not appear when the app is run on a single core machine, but obviously we cannot assume a user will have that.

Is there a way to force an app, or even better yet a referenced DLL to run on a single core? Any other way to possibly fix this? Getting the third party to rebuild the OS dll's is apparently out of the question (its a bit of a sore spot with me currently :) ) so I have to handle it myself or just forget about providing this functionality.

By the way, the error message being thrown from the OS DLL's is "Attempting to access corrupt or protected memory".

+3  A: 

What you want to do is achieved by using Process.ProcessorAffinity. Note that this will make your entire application run single-core.

Edit: your problem may be a result of the DLL expecting to have single-processor affinity, but it can also be a threading issue (e.g. race condition) that is very unlikely to happen when you only have a single core. If the last one is true, you can't really do anything except cross your fingers and pray (and maybe consider dropping the functionality to keep your application stable).

Jon
To set this for a single thread you'll need to P/Invoke SetThreadAffinityMask http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx . But this relies on assumption that a .NET thread is strictly tied to a Win32 thread, which is currently true but is not defined to always be true.
Richard
It's also important to note that there's a security issue with processor affinity. There are very few things I ever needed to do in code that caused me to go chasing down permissions issues, but this is one of them.
Toby
I honestly can't believe it, but this apparently has fixed the issue. Where I could get a crash 100% of the time I can now get a crash 0% of the time. This obviously is far from being "Stable" but it is a start. And this particular bit of functionality is requested by only a couple customers who are dying to have this, and are willing to beta it for me if need be. Thank you.
Kevin
+2  A: 

Personally I'd drop that functionality (you said this is an option). Multi-threading is a very touchy subject and it's obvious the 3rd party DLL isn't written very well.

You say the issue doesn't appear if you run it on a single core but not seeing a problem doesn't mean you don't HAVE a problem (and threading issues are only rarely seen anyway), so chances are your product might fail because of this every once in a while.

Blindy
A: 

I once had some strange problems when referencing DLLs that were 32-bit but the .NET application was built as 64-bit. Since you mentioned that it doesn't happen on the single core machines, I'm assuming they're 32-bit and the multi-core machines are 64-bit?

The only difference was I was getting a BadImageFormatException, which you didn't mention. Anyway, the way I solved it was to set the "Platform target" of my application to x86 and everything worked after that.

Sam