Application failure in Release mode

Question

I have a problem with my ASP.NET application. It has been developed for about a year or so without disabling Debug mode. I wanted to test if it works without debug and it isn't but, when I set debug="true", it works fine.

When I try to open application for the first time it gives me "Server not available" error. In the events log I have two errors:

1. .NET Runtime 2.0 error - Faulting application aspnet_wp.exe, version 2.0.50727.3082, stamp 492b8702, faulting module kernel32.dll, version 5.1.2600.3119, stamp 46239c44, debug? 0, fault address 0x00012a5b.
2. ASP.NET 2.0.50727.0 - Unexpected end of process aspnet_wp.exe (PID: 4932) (it may be written a little different, it's translated).

My IIS version is 5.1 running on Windows XP.

I'll be grateful for any suggestions.

UPDATE: Change of debug mode is made in the web.config

Answer 1

I propose you check your code against asserts containing nondebug code. I did several times a common mistake writing code like following:

Assert(doSomeCrucialOperation());

when compiling in release mode the whole Assert with the operation invocation is not compiled.

Answer 2

Make sure you don't have any conditional code that checks for debug environment. I once spent days trying to track down a random crash bug... and eventually came across something like this:

#ifdef DEBUG
  threadPoolCount = 1;
#else
  threadPoolCount = 16;

Guess what... it was a threading bug! In C# it will look more like this:

[Conditional("Debug")]

Answer 3

There is an older question about a similar issue:

http://stackoverflow.com/questions/186237/program-only-crashes-as-release-build-how-to-debug

This may also help:

http://blogs.msdn.com/rahulso/archive/2006/03/02/what-is-a-crash-technically-in-asp-net-and-what-to-do-if-it-happens.aspx

Have you tried to attach to the process with a (remote) debugger, even though it is not built in debug mode?

Answer 4

The crash you're describing is happening in kernel32.dll - this might indicate that this is not a crash inside your managed code, but rather in the .NET engine itself (ugh) - in which case things like verifying precompiler paths etc. would not yield any positive results (IMHO).

I would suggest you try resolving this issue via "binary search" (for the culprit) :-). As the first "iteration", I would create a trivial aspx page (/Test.aspx), keep the debug mode disabled and try to hit the page (no code-behind, just basic HTML with title and Hello, world body). This will verify ASP.NET is installed and working properly on your IIS server.

If this simplest page fails again, I suggest exactly what @JSC mentioned in comments: re-register ASP.NET on IIS:

rem (reregister ASP.NET in IIS)
rem (run as administrator!)
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

Once the simplest page is running, I would add simple code-behind, try that. Once code-behind is running, I would try updating the real starting page of your application by stripping ALL code-behind, leave only the markup and try hitting the page - yes, it will look horrible but at least it might display :-). Afterwards, I would try adding only the initialization logic, see how that goes...

Essentially, you need to find whatever "thing" in your application is causing the crash. I presume the two extremes are: markup + no code behind = works, markup + all code behind = crashes; binary search "approach" would enable half of your code, see if it still displays (we are not worrying about functionality right now - it will not behave as expected, of course). If it does not display, disable the second half of the first half (i.e. only a quarter of your code will be active), try that. Keep going until you restrict your search to the problematic area...

Another approach I would suggest is to install Server 2003 (IIS6) / Server 2008 (IIS7) on a virtual machine - VirtualPC, VMWare, VirtualBox (if you don't have access to MSDN downloads of server images, you can always download trials - Server 2008 trial is good for 60 days plus two "resets"). After installing clean OS in a virtual machine, try to deploy your application and see how it behaves in that environment.

Answer 5

Release debugging is always tricky because the one thing you rely on to debug problems is the very thing stopping it failing in the first place. So you have to improvise and go back down the list of tools at your disposal.

Reduce the problem down a bit: remove/disable chunk after chunk of code until it stops crashing, then re-enable bits to make it crash again, narrowing down the problem field. Break down the problem from "it crashes somewhere" to "it crashes somewhere round here".

Log stuff. Log more than usual. Log optimistically ("program reached this point with X={0}"). Using a good logging subsystem, you can always leave them in and disable the output. Then you can analyse the path your program took to the point of failure and identify where the problem might be.

Answer 6

Monitor you site with DebugDiag tool and catch all leaks. Remember to install PDBs.

More information read "Application debugging in a production environment"

Answer 7

Try clearing the temporary DLLs

iisreset /stop
del "%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\*.*" /s/f
iisreset /start

Make sure you are properly freeing unmanaged resources. Using USING and .Dispose.