Debug.Assert lets you check various things during the debugging process or when you are a debug build.

One of the problems with Debug.Assert is that it pops up a MessageBox dialog. UI dialogs are a big no-no in server applications since there are scenarios in which this UI dialog will never be show and your server application will simply get stuck waiting for someone to push the buttons of the dialog.

One of the most common cases in which you will not see the dialog is when your server application runs under different credentials than your currently logged on user. In that case the UI dialog will hide somewhere in a different sessions without any chance of being seen by any other user.

.NET employs various huristics to figure out when to display the assert dialog. In most cases, in a server application it will not show the assert dialog at all (even in debug builds). As far as I could tell (and its currently just an calculated guess), if you have a debugger installed and registered as a debugger, .NET WILL display the dialog and that may pose a problem if your server application runs under different credentials than the currently logged on user.

It seems there is a way to overcome this by using a configuration flag.

Add the following section to your web.config (or app.config for applications other than ASP.NET) and it will disable poping up a UI window in your application which make cause it to deadlock:

<system.diagnostics>
<assert assertuienabled=”false” />
</system.diagnostics>

If you have any trace listeners that might popup a UI window you can also add the following configuration in your web.config that will clear all trace listeners:

<system.diagnostics>
<trace>
<listeners>
<clear/>
</listeners>
</trace>
</system.diagnostics>

If you are not sure this is really your problem, its very easy figuring it out using WinDbg, by attaching to the process, loading the SOS.dll and running the command:

~*e!clrstack

This command will show the managed call stack of each thread in the application (some of these threads are not managed so they might return an error and you can safely disregard them).

If you’ll see in the call stack a call to “Debug.Assert” followed by “MessageBox.Show” you can be certain that this is the problem you are facing.

  • Uwe

    Great tip, this configuration setting. Thanks!

  • Eugene

    Nice article. Thanks. 🙂 Eugene

  • Thank you. The suggested entries in the web.config solved my problem. However, I have two questions:

    1) Using this method, are the assert statements still being evaluated, just no output to the UI? If so, is there a performance cost to leaving the asserts in place?

    2) I am using the VS 2005 ‘Publish’ method to compile my web project for deployment to the server. I thought that the Publish method automatically produced a release version and that a release version, combined with in the web.config, would disable debugging altogether. Why is the server deployment still evaluating asserts?

  • Hello Pamela,

    Regarding your first question, in the Debug configuration as far as I know the asserts keeps on running but the UI will not be visible.

    2) As far as I know, the ‘Public’ feature publishes whatever configuration you are currently at, be it debug or release. Make sure you are publishing when you are on the Release configuration to publish a Release build.

    Oh, and another thing, make sure that the “<compilation>” element in your web.config is set to <compilation debug=”false”. This will make sure everything is not running in debug mode.