DNN Troubleshooting: “Module is currently unavailable” (ModuleLoadException/NullReferenceException) and IIS Application Pool Stopping

Symptoms / How to Recognize the Issue

A) Module fails to render

You may see a module placeholder message like:

• “WRT_Parking_Tickets is currently unavailable.”

DNN error details/logs commonly include a stack trace similar to:

DotNetNuke.Services.Exceptions.ModuleLoadException: Object reference not set to an instance of an object.
 ---> System.NullReferenceException: Object reference not set to an instance of an object.
 at <custom_namespace>.<custom_module_namespace>.Settings.LoadSettings()

B) Site outage due to IIS Application Pool stopping

The DNN site may not load because the IIS Application Pool won’t stay started (starts and then stops, or gets disabled due to rapid-fail protection).

Investigation Workflow (Separate the Two Problems)

Even if a module is failing, an Application Pool that stops is higher priority and is usually driven by server/runtime configuration. Treat these as two parallel tracks:

• Track 1: Why the IIS worker process is terminating (Windows/IIS/.NET)
• Track 2: Why the custom module’s LoadSettings() is encountering a null dependency

Track 1: Troubleshoot IIS Application Pool Auto-Stopping (Site Down)

Step 1 — Collect decisive evidence from Windows Event Viewer

On the web server, open Windows Event Viewer and check at the exact time the app pool stops:

• Windows Logs → Application
• Windows Logs → System

Look for related sources such as WAS, W3SVC, and .NET Runtime.

Capture and review the full event details, specifically:

• Faulting application / process
• Faulting module
• Exception code and exception message
• Any referenced config file or assembly

These fields typically determine whether the failure is caused by:

• a configuration parsing problem (often web.config related),
• a dependency/assembly load failure,
• a permission/identity problem,
• or a runtime crash.

Step 2 — Validate IIS Application Pool configuration

In IIS Manager:

1. Confirm the Application Pool Identity is correct.
   • If using a custom service account, verify credentials are valid (not expired/rotated).
2. Verify NTFS permissions for the app pool identity on:
   • the DNN site root
   • and required writable locations (commonly under folders such as Portals, App_Data, and other deployment-specific writable directories)
3. Check whether Rapid-Fail Protection is disabling the pool.
   • If it is, the underlying crash reason should still appear in Event Viewer and must be addressed first.

Step 3 — Correlate with recent changes

If the problem started after any of the following, prioritize reviewing/reverting them:

• Windows updates / .NET updates
• web.config edits
• DLL deployments/overwrites
• Permission changes
• Password rotations for service accounts

Step 4 — Common resolution pattern: a web.config line causes startup failure

If Event Viewer points to configuration parsing or startup errors, validate web.config changes by:

1. Reverting the most recent web.config edits (or restoring from a known-good backup).
2. Restarting the Application Pool.
3. Reloading the site and monitoring for subsequent crashes.

Track 2: Troubleshoot Custom Module “ModuleLoadException / NullReferenceException in LoadSettings()”

What the stack trace implies

A NullReferenceException inside:

<custom_module_namespace>.Settings.LoadSettings()

typically means the module code is trying to read something it assumes exists, such as:

• a required module setting value,
• a portal/module record,
• or a backing database row in a custom table,

but that item is null/missing.

Step 1 — Confirm whether it is a custom/third-party module

In DNN:

• Go to Settings → Extensions
• Locate the module package entry for the failing module (by friendly name)

If it is not a DNN core package, remediation usually requires the module owner/developer (source code access) to handle compatibility or add null-checking where required. This is not typically a core DNN defect when the exception originates inside the module’s own namespace/methods.

Step 2 — Validate module settings for the failing instance

For the specific module instance (identify by module ID in logs, e.g., <module_id>):

1. Navigate to the page containing that module.
2. Enter edit mode.
3. Open the module’s Settings.
4. Check for required fields that are blank, invalid, or referencing removed entities.

Step 3 — Validate backing data existence

If the module stores configuration in custom database tables:

• Confirm expected records exist for the relevant scope (module instance and/or portal).
• Missing rows commonly trigger LoadSettings() failures when code does not handle absent data.

Step 4 — Check module compatibility after a DNN upgrade

Even if the module DLL hasn’t changed recently, a DNN upgrade or platform dependency change can expose an unhandled null path or compatibility issue.

If the module is custom:

• Rebuild/update the module against the currently deployed DNN version as needed.
• Retest module load after deployment.

Validation Signals

• App pool issue resolved: The Application Pool remains started and the site loads consistently.
• Module issue resolved: The module renders without the “currently unavailable” message and ModuleLoadException entries stop appearing in DNN logs.

Example Outcome from a Real-World Case

• The site outage (Application Pool stopping) was resolved by correcting/removing a problematic web.config line. After that change, the app pool started and the site loaded.
• The failing module was confirmed to be custom/third-party, and the next step was to rebuild/update the module package for the upgraded DNN environment.
• No DNN platform hotfix or version-specific defect was confirmed for the module exception in this case.