Last week, one of my DNN installations all of a sudden started giving me the following error:
Typically, if you log in as an administrator, then you can view the error information. But in my case, I was unable to see any information. In fact, I was unable to log in to the DNN portal. Upon further investigation what I realized was that even the content was not being rendered.
The only information that I was able to find out was from the event log tables in the database, which had the following information:
So it looked like the error was being thrown in the “DotNetNuke.UI.Skins.Skin.InjectModule” method and it looked like a property or a method was being invoked on an object that was null. But the above information is not very helpful.
Without any other information, I decided to modify the DNN code so that I could add additional logging information to the InjectModule code to see what was going on. To do this, I decided to use a simple text file to log the information. VB.Net is not my primary development language so I had to look up the syntax to create a file in append mode:
Using writer As StreamWriter = New StreamWriter(Server.MapPath(".\log\") & "attempts.txt", True) 'call code in here InjectModule(......) writer.WriteLine("log info using writeline") End Using
Once I had the code modified to perform in-depth logging, I found out that the InjectModule method would use the LoadControl method to load a user-control into a page. But before that, it would need to create the container into which it needed to load the user control. In version 4.6.2 of the DNN code, the code never expects the container to be null (ctlContainer.FindControl(glbDefaultPane)) and in our case the ctlContainer object was turning up null and was causing the “Object reference not set to an instance of an object” error.
But why was ctlContainer turning up Null. Turns out some files in the “Portals\_default\Containers” folder and in the “admin\Containers” folder had gone missing. Unfortunately for us, even the default containers had gone missing and hence ctlContainer was turning up null.
I am not sure why the files in those folders got deleted (module mis-behaving, user error, etc), but it sure was hard to track down this bug and fix it. Luckily DNN is an open-source project and we were able to track down the issue by modifying the core code for this purpose.