Reputation: 6503

When release dlls don't work but debug dlls do

After deploying our huge distributed system to one of our clients we experience an unexpected error. During the investigation we replace the assembly causing the error with one where we have added some diagnostic code. The dll we use is built in debug mode. And suddenly it all works!

Replacing the debug dll with the release version (with the diagnostic code) makes it crash again.

There are no precompiler directives, conditional debug attributes etc. in our code. The problem has been found in two different installation sites, while it works fine in several more.

(The project has a mix of C# and VB.NET, the troublesom assembly is VB.NET.., if that makes any difference)

So the question is: What do you do in situations like this? And what can be the cause - in general? Any advice on debugging this issue is welcome.

Upvotes: 17

Answers (16)

susil95

Reputation: 300

It might be any reason, but what comes in mind is either

You might have written an logic which is under debug_enabled flag, which is accessed when debug_enabled flag is not enabled(i.e release mode). For example a pointer created under debug_enabled flagged if condition but accessed out of the area in release mode.
When I faced the same issue, what resolved is I was not returning anything while a function expected a return value, while I was returning only during negative scenarios in that function. I got to know that by adding loggers and when i fixed that, it automatically started to run fine.

Only doubt is why this issue didn't happen in debug dll whereas in release it gave an error.

Anyways hope it helps!

Upvotes: 0

Leandro

Reputation: 950

First of all sorry about my English. I know this post is old but I have just the same problem, and I realize that in debug mode the build is made for 32 bit OS, and the release mode is for 64 bit by default. This make the DLL's made for 32 bit doesn't work in release. If you go to Project properties -> build you can choose the architecture you want. This works for me.

Upvotes: 1

Ant

Reputation: 5225

This probably isn't relevant for the original question, but for anyone running an application which uses

var isThisMyAssembly = System.Reflection.Assembly.GetCallingAssembly();

it's possible for that call to get inlined into a method in another assembly at runtime, and therefore to get unexpected output (as mentioned in the MSDN documentation).

To avoid this, you can either apply a MethodImplAttribute to your method:

[MethodImpl(MethodImplOptions.NoInlining)]
void DoSomeThings()
{
    var isThisMyAssembly = System.Reflection.Assembly.GetCallingAssembly();
    //do stuff
}

or you can switch to using Assembly.GetExecutingAssembly() instead.

Upvotes: 0

Thiago Carvalho

Reputation: 31

Had the same issue with a C# DLL containing a WCF client provided for multiple client applications.

Found out there was a method in the C# client library accessing the StackTrace for logging purposes, which happens to be different when compiled in debug.

StackTrace stackTrace = new StackTrace();
MethodBase methodBase = stackTrace.GetFrame(2).GetMethod();

GetFrame(2) didn't existed in release. More info about that can be found here: StackTrace class methods not working in release mode

Funny thing is a VB.NET client was affected while in another C#.NET client it worked properly.

Hope it helps.

Upvotes: 3

Víctor Carreño

Reputation: 1

In my case it was that my DLL consumer project (in VS) had x64 configuration, but the solution was in any CPU. For some reason when running the application this did not hook with my x64 DLL. I configured the application to a x64 explicitly platform and everything worked correctly.

Upvotes: 0

Israel Rivera

Reputation: 11

Make sure that the Application is building under the correct Platform Target. This can be an issue especially when it comes to providing or consuming DLLs. Look under "Project->Properties" and select the "Build" tab. The Platform target option will allow you to select between Any CPU (default), x86 or x64.

Upvotes: 1

Ed Guiness

Reputation: 35267

Debug.Assert(ImportantMethod());

Upvotes: 3

Henry

Reputation:

I had a similar problem. My situation like this: I defined some reflection functions in a class library A. Then I defined a WPF user control library B, which uses the functions from library A. Then I coded an application which uses the user control from library B and functions in library A. When I used the debug version of library B, it works fine. But when I used the release version of library B, the reflection functions did not work. I also defined other functions in library A. It seems that only reflection functions are causing trouble. I can not figure out the reason. Finally, I gave up and moved the reflection functions from library A to library B. And it worked.

Upvotes: 0

Carlos Bomtempo

Reputation: 138

Did you solved your problem?
I'm having the same issue as you.
If I compile the dll in debug, all works fine.
If I compille in release I get a null reference exception.
But if I include some lines like the above one in some methods call, the exception is gone even in release mode:
System.Diagnostics.EventLog.WriteEntry("blablabla", "blablabla")

Hope that helps you.

Upvotes: 0

twon33

Reputation: 533

I had a problem at one point with finalizers going off sooner than expected, because I didn't fully understand the interplay between finalizers, the garbage collector, and when a local object is considered collectible (hint: it's not at the closing curly brace of the block). If your code uses finalizers, you may wish to look into GC.KeepAlive(). In the following block:

void MyFunction() 
{ 
  Foo f = new Foo();
  SomeFunction(f.SomeProp);
}

f becomes eligible for finalization before SomeFunction() even runs! If the finalizer does something like dispose whatever SomeProp hands out, you could get into trouble. Adding a call to GC.KeepAlive(f) after the call to SomeFunction ensures that f isn't eligible for finalization until after the call to KeepAlive().

Edit: After all that, I forgot to point out that this problem was much more pronounced when running in Release mode. I don't know if the Debug build puts implicit KeepAlives for locals at the end of the function for the debugger's benefit, or if the garbage collection is simply less aggressive, or what, but Release mode exacerbated this problem greatly in my case.

Upvotes: 1

Cokes

Reputation: 51

You probably know this, but, variables are sometimes initialised differently in debug and release builds. E.g. I think variables are auto-init'd in VC6 debug builds, this can hide problems if you didn't initialise something. I also think debug arrays may use sentry bytes in an attempt to indicate overruns. This too can lead to different behaviour.

Upvotes: 0

faulty

Reputation: 8347

I've seen timing which cause issues between Debug and Release build. Generally Debug build runs slower than Release build. You might want to check time critical section of your code.

Upvotes: 4

Brian Schmitt

Reputation: 6068

Have you tried including the debug files? (the pdbs)

If you co go your project settings and then the compile 'tab' select your release build in the dropdown near the top, then choose advanced compile options near the bottom, make sure to set it to create FULL debug information, then redeploy, you should now get more detailed information about the reason for the crash.

Upvotes: 4

Morten Christiansen

Reputation: 19570

It might be some sort of race condition you have, if you're not working in single-threaded code. For example, if some part of your program needs to perform some actions before other parts can access it, it might fail in release mode simply because the code is accessed too early. We once had a similar problem with some code for mobile phones which ran fine in the emulator but on the phone which was slower, the sitution was not the same at all.

Upvotes: 3

JoshBerke

Reputation: 67068

You can try and turn off Optimize Code in the Build Settings. What is the actual error you are getting.

Another thing you can do is compile in release mode but enable the #Debug conditional. This will handle the case if your using Diagnostics.Debug and the code in there effects your application.

Upvotes: 6

Marc Gravell

Reputation: 1062770

For causes... well, some hint of the symptom would help. One possibility is that you have code to a method like Debug.WriteLine that has side effects (i.e. makes it work). Calls to methods marked with [Conditional(...)] are not compiled unless you have the right symbols defined - so anything marked [Conditional("DEBUG")] will be silently dropped.

It could also be a compiler bug, but that is a bit unlikely (but not impossible).

What is the symptom? How does it break?

As an example of the above:

    static string Bar { get; set; }
    static void Main()
    {
        Bar = "I'm broken";
        Debug.WriteLine(Foo());
        Console.WriteLine(Bar);
    }
    // note Foo only called in DEBUG builds
    static string Foo()
    {
        Bar = "I'm working";
        return "mwahahah";
    }

Compiled in DEBUG mode it prints "I'm working"; compiled in RELEASE mode it prints "I'm broken". Does this sound similar? Check you aren't calling any debug methods directly with things that have side-effects. In most cases, you can fix by indirection:

string foo = Foo();
Debug.WriteLine(foo);

Now it gets called in either mode.

Upvotes: 13

When release dlls don&#39;t work but debug dlls do

Answers (16)

Related Questions

When release dlls don't work but debug dlls do