Debugging Difficult Exceptions in DotNetNuke

During my time working with DotNetNuke, I have encountered innumerable forum posts in the following general form:

I’m getting a very vague general exception error, and I’m not sure what is causing it.  There doesn’t seem to be anything visible in the application . . . [and] no errors as I’m navigating the site. Any and all help is greatly appreciated!

StackTrace: [NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.UI.Skins.SkinDefaults..ctor(SkinDefaultType DefaultType) +189
   DotNetNuke .Common.Globals.get_DefaultSkin() +31
   DotNetNuke.Entities.Portals.PortalSettings.GetPortalSettings(Int32 TabId, PortalAliasInfo objPortalAliasInfo) +2797
   DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabId, PortalAliasInfo objPortalAliasInfo) +82
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +3303
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Experienced DNN developers will recognize the general area in which the error is occurring (missing skinningDefaults in DotNetNuke.config) and probably some general guidance to rectify the error (check that DotNetNuke.config exists, and correctly contains the proper skinningDefaults element).

This is fine for exceptions that occur frequently, but how does an experienced developer guide a novice in finding a solution to this issue?

[NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.HttpModules.UrlRewriteModule.RewriteUrl(HttpApplication app) +378
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +1180
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Even a sophisticated developer would need to explore several avenues in finding a solution.  Assisting a relatively novice forum user in performing these tasks is problematic — such assistance would require a number of back-and-forth exchanges.  With regret, I unfortunately observe many problems go unremedied for this reason (as, to date, is the exception posted immediately above).

A Better Way to Debug

Clearly, for difficult-to-diagnose problems, a call stack is not sufficient to identify a solution.  Fortunately, there is a relatively easy way to augment this stack with information that greatly aids in diagnosis — assemblies with debugging symbols.  A debug build provides line numbers that may be used to target with much greater accuracy the particular problem that a user is experiencing. 

For a non-developer experiencing a difficult problem, he or she could replace existing production-build assemblies with their debug-symbol counterparts, reproduce the error, and post the augmented call stack for analysis.  I argue that this would (a) significantly increase error resolution, and (b) decrease debug time per issue for both assistor and assistee.

Unfortunately, at this time the DNN team seems to have little interest in providing such assemblies to the public at large (arguing that users can build these themselves).  I respectfully disagree, and would suggest that most capable of producing such assemblies would not need the additional forum assistance that such the debug builds would allow.

Fortunately, the DotNetNuke license allows me to both recompile core assemblies with debug symbols, and to publish these builds to the general public.  I intend to do so, and thereby (hopefully) aid others in solving some of the more difficult problems encountered in the wild.

To this end, my next entry will contain major DotNetNuke assemblies with debugging symbols.  I decided to split off the deployment instructions and downloads into a separate post so that downloading users can skip the preamble and get straight to the instructions and downloads.

For those who have feedback regarding the philosophy and feasibility of this approach, I’d appreciate both.

B

Be Sociable, Share!

3 Comments

  1. From the Desk of Brandon Haynes » DotNetNuke Debugging with Debug-Build Assemblies (4.9 Update)

    September 18, 2008 @ 2:42 pm

    1

    […] to identify and correct difficult–to-diagnose problems with a DotNetNuke installation (see this for a detailed […]

  2. From the Desk of Brandon Haynes » Enhanced DotNetNuke Debugging with Debug-Build Assemblies (Updated for 4.9)

    September 18, 2008 @ 3:52 pm

    2

    […] my previous post, I discussed my reasons and motivations behind providing DotNetNuke assemblies with debug symbols […]

  3. From the Desk of Brandon Haynes » DotNetNuke Debugging with Debug-Build Assemblies (4.9.2 and 5.0.1 Update)

    March 11, 2009 @ 11:57 am

    3

    […] symbols contained in these assemblies make some types of problems easier to diagnose (see this for a detailed […]

Log in