Logging Site Exceptions to the NT Event Log

Commerce Server 2002

The global.asax file in a Commerce Server ASP.NET site contains the Application_Error event that handles exceptions not handled by individual pages. This event should handle logging, notifications, and any other processing needed before you return a user-friendly error to the site user.

In the Application_Error event, the Server.GetLastError method is used to obtain a reference to the unhandled exception object. The following code is from the global.asax file and shows the Application_Error event.

// In global.asax file
protected void Application_Error(Object sender, EventArgs e)
Exception exc = Server.GetLastError();
// Perform logging, send any notifications, and so on.

The Server.ClearError method can be used to clear the exception and stop any further propagation. For example, the page might have a Page_Error event that uses to Server.GetLastError method to access the unhandled exception object. If you do not clear the exception by using the Server.ClearError method, the unhandled exception will continue to propagate up to the Application_Error event. If you use Server.ClearError method to clear the exception in the Application_Error event, the defaultRedirect setting in the web.config file will not redirect the user because the unhandled exception no longer exists. If you want the defaultRedirect setting to properly redirect users, do not clear the exception in the Application_Error event.

The following is a sample implementation of the Application_Error event that will log the exception to the event log file using the Commerce Server Commerce.AdminEventLog object.

Ee784611.note(en-US,CS.20).gif Note

  • You will need to add a reference to MSCSAdmin.dll to use this object from your ASP.NET pages.
        using AdminLib;        // For the Commerce.AdminEventLog object.

        protected void Application_Error(Object sender, EventArgs e)
            Exception ex = Server.GetLastError();
            string sLogMsg = null;

                // You do not need to log the HttpUnhandledException that 
                // ASP.NET wrapped the exception in.
                if ((ex as System.Web.HttpUnhandledException) != null)
                    ex = ex.InnerException;

                // Format message for the main exception.
                sLogMsg = string.Format("Unhandled exception.  Type={0} Msg={1}\nStackTrace=\n{2}",
                    ex.GetType().FullName, ex.Message, ex.StackTrace);

                // Format the message for any inner exceptions.
                while ((ex = ex.InnerException)!= null)
                    sLogMsg += string.Format("\n\nInner exception.  Type={0} Msg={1}",
                        ex.GetType().FullName, ex.Message);
                    COMException ce = ex as COMException;
                    if (ce != null)
                        sLogMsg += "\nCOM Exception errcode = " + ce.ErrorCode.ToString();
                // Log the event to the event log.
                AdminEventLog logger = new AdminEventLogClass();
                logger.WriteErrorEvent(CommerceApplicationModule.SiteName, sLogMsg);

The EventLog type in the System.Diagnostics namespace could also be used to log the exceptions. Applications that need to write to the Application event log can do so while running as the ASPNET account. If an application needs to create a new event log category, it must create a registry key under the HKLM hive, which the ASPNET account cannot do. If impersonation is enabled and a privileged account is impersonated, the category can be created at run time. Otherwise, an administrator can create the category and the application can write to it at run time.

Applications that need to create new event log categories should create the categories at installation. Once the category is created, the ASPNET account can write to the log file.

See Also

Extending Commerce Events

Copyright © 2005 Microsoft Corporation.
All rights reserved.