Support Thread

Error Being Generated

Error Being Generated — APG vNext Guide

Error Being Generated — this archived support thread from the APG vNext community covers a reported issue and its resolution.

Troubleshooting This Issue

  1. Set customErrors mode="Off" in web.config to expose the full error and stack trace.
  2. Check Windows Event Viewer → Application log for ASP.NET exceptions.
  3. Review Admin Panel → Logs → Error Log for timestamped application errors.
  4. Restart the IIS Application Pool to clear stale state.
  5. Verify the database connection string and run any pending upgrade SQL scripts.

Related Resources

Diagnosing APG vNext Errors - Using the Error Log

When APG vNext encounters an unhandled exception, it logs the error to the database error log and optionally sends a notification email to administrators. This guide covers how to access, interpret, and act on errors logged in the APG vNext error system.

Accessing the Error Log

Admin Panel -> System -> Error Log. The log shows:

  • Timestamp of the error
  • Error type and message
  • Stack trace
  • Request URL that triggered the error
  • User ID (if logged in) and IP address

Querying the Error Log Directly

SELECT TOP 50
       ErrorID, ErrorType, ErrorMessage,
       RequestUrl, MemberID, ClientIP, OccurredAt
FROM   apg_ErrorLog
WHERE  OccurredAt > DATEADD(DAY, -1, GETDATE())
ORDER  BY OccurredAt DESC;

Common Error Types and Fixes

  • SqlException: Connection timeout - connection pool exhausted or SQL Server overloaded; check SQL Server performance counters
  • HttpException: A potentially dangerous Request.Form value - XSS filter blocking legitimate HTML in posts; review APG.Editor.AllowedTags setting
  • UnauthorizedAccessException: upfiles/ - IIS app pool identity lacks write permission on upload folder
  • FileNotFoundException: skin file - skin template file missing or path misconfigured

Configuring Error Notification Emails

<add key="APG.Error.NotifyEmail"     value="[email protected]" />
<add key="APG.Error.NotifyOnCritical" value="true" />
<add key="APG.Error.NotifyThrottle"  value="5" />
<!-- Send at most 5 error emails per hour to prevent inbox flooding -->

Proactive Error Monitoring with APG vNext Health Checks

Rather than reacting to errors after they occur, configure APG vNext's built-in health check endpoint to allow uptime monitoring services to proactively detect problems. The health check endpoint at /healthz returns HTTP 200 with a JSON payload when the application and database are healthy, and HTTP 503 when a problem is detected. Register this endpoint with your monitoring service (UptimeRobot, Pingdom, AWS CloudWatch, or similar) to receive alerts within seconds of a problem rather than discovering it from user complaints:

GET https://yourforum.com/healthz
Content-Type: application/json

{
  "status": "healthy",
  "database": "connected",
  "cache": "operational",
  "version": "5.5.2",
  "uptime_seconds": 86400
}

Alerting on Error Rate Spikes

In addition to health checks, configure error rate alerting in APG vNext to notify administrators when the volume of errors exceeds a threshold within a rolling time window. An error rate spike often precedes a complete outage — catching it early allows intervention before members are impacted:

<add key="APG.Error.AlertThreshold"    value="10" />
<!-- Alert when more than 10 errors occur within the window below -->
<add key="APG.Error.AlertWindowMinutes" value="5" />
<add key="APG.Error.AlertEmail"         value="[email protected]" />

Error Recovery Runbook

Document a recovery runbook for the most common APG vNext error scenarios so that any team member can respond to an alert without deep application knowledge. The runbook should cover: database connectivity failures (check SQL Server status, connection pool, and firewall), IIS application pool crashes (check Windows Event Viewer, restart pool, check .NET CLR version), disk space exhaustion (check upfiles and logs directories), and authentication failures (check Forms Authentication ticket encryption keys in web.config machineKey settings).

Structured Incident Response for APG vNext Errors

When an error occurs in a production APG vNext forum, a structured incident response process minimises downtime and member impact. The process has four phases: detection (when an alert fires or a member reports an issue), diagnosis (using the error log, IIS logs, and Event Viewer to identify the root cause), remediation (applying the fix, which might be an IIS pool restart, web.config change, or database script), and post-incident review (documenting what happened, why it wasn't caught earlier, and how to prevent recurrence). Maintaining an incident log even for minor issues builds a historical record that helps identify recurring problems that deserve a permanent fix rather than a repeated workaround.

Common Error Patterns and Their Root Causes

  • 500 errors concentrated on a specific page — usually a template rendering bug or a missing database column from an incomplete upgrade
  • Intermittent 500 errors across all pages — usually a connection pool exhaustion issue caused by connection leaks or SQL Server overload under high traffic
  • 500 errors starting at a specific time — usually correlated with a deployment, configuration change, or scheduled task that ran at that time
  • 403 errors for authenticated pages — usually caused by an expired Forms Authentication machine key change that invalidates all existing session cookies
  • 404 errors for all URLs — usually a URL rewrite rule misconfiguration in web.config after an IIS reconfiguration or server migration

Related Resources

Looking for more help? Browse the support forum or check the Knowledge Base.