C# app runs with debugging, but not without [closed]

Answer 1

Try take off optimizations from the Release build (in the project settings) and see if that helps.

Answer 2

I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.

1. Switch to release mode
2. Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
3. Run executable in debugger, ignore the warnings from VS that there's no debug info

It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong

EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)

Answer 3

we found and fixed this issue with MSFT, we faced this problem with VSTO development. Apply the following patch from MSFT.

http://support.microsoft.com/kb/975954

http://support.microsoft.com/kb/974372

Answer 4

Here is a support article with that error. Does that apply?

Perhaps the debugger is eating an excaption the VE3D API is throwing. In VS, do a ctrl+alt+e and change it to break whenever any exception is thrown. This can be tedius b/c it will break on all your try catch blocks, but it might give you some information.

Here is some info. about that PlugInLoader. It seems to imply it must be called from the FirstFrameRendered eventhandler. Perhaps one of your forms is doing that and one not?

Answer 5

I once had a similar problem with exactly the same behaviour using a plug-in-system. When loading a plug-in from a MarshalByRef-object (see example code below), it seems as if .NET creates a new AppDomain or Context for the loaded assembly. (Can anyone confirm this? I've not found any source regarding this.)

public class ProxyAssemblyLoader : MarshalByRefObject {
    public Assembly GetAssembly(string path) {
        return Assembly.LoadFrom(path);
    }
}

Furthermore in my case the plug-in loads a different version of the mscorlib. (My app is CLR2 and the loaded is CLR4) Afterwards I used the plug-in by reflection and tried to access a value of the new mscorlib, which was loaded from the other application domain. Usually both should be usable because the mscorlib is a commonly used assembly and only loaded once (see Global Assembly Cache). But it seems as if this is not the case. But in general Microsoft advises to avoid that.

I've not exactly figured out what the problem was, but I figured out the call that causes the application to crash without any hint. Why without any hint? It crashed without any hint, because the thrown exception was only available in "the other" appdomain and not available for the main/default app domain.

The taken action was just implicit copying the value of another appdomains assembly to a local untyped value (object) in the default appdomain. This was enough to get a type identity mismatch error due different versions of the assembly. It seems as if Visual Studio could handle it, but if the application runs standalone it crashes.

This may also explains why you needed to reinstall your .NET. Maybe your installed .NET-Framework was a beta or something like that, which contained a minor difference.

In conclusion some general solutions for the problem could be:

• Avoid using different versions of assemblies with different versions of the same type.
• In other cases may try to load both assemblies inside the same appdomain. (As far as possible regarding the probing context.)
• A solution for cross appdomain communication could be serialization of the values.
• (Make sure that the correct .NET-Framework Non-Beta Version is installed.)

Answer 6

One thing left I think is to use WinDbg to try and debug it. Here are some links on how to use it:

1. http://www.codeproject.com/KB/debug/windbg_part1.aspx
2. http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx
3. http://blogs.msdn.com/tess/ (good blog about debugging in general in windbg)

Thinking about it, it could also be some service or something that's clashing. Try stopping all unneeded services and closing unneeded programs (including startup ones) and see what happens then.