This archived support thread addresses How do I troubleshoot a software error and file bug reports?. The discussion below documents the reported issue and the steps taken to resolve it.
Troubleshooting Steps
When encountering errors in APG vNext, the following steps help diagnose the problem quickly:
- Enable detailed errors: Set
customErrors mode="Off"inweb.configto see the full error message and stack trace. - Check the Windows Event Log: Application-level ASP.NET errors are logged in the Windows Event Log under Application.
- Review the APG error log: Admin Panel → Logs → Error Log shows application-level errors with timestamps.
- Verify recent changes: If the error appeared after an upgrade or configuration change, roll back or review what changed.
Common Fixes
- Restart the IIS Application Pool to clear stale state
- Verify database connectivity and run any pending SQL upgrade scripts
- Check that all required .NET assemblies are present in the
binfolder - Clear the ASP.NET temporary files folder (
%windir%\Microsoft.NET\Framework\...\Temporary ASP.NET Files)
For further assistance, visit the support forum or review the Knowledge Base.
Systematic Approach to APG vNext Error Diagnosis
Troubleshooting forum software errors effectively requires a systematic approach that gathers evidence before attempting fixes. Jumping to solutions without understanding the root cause often results in wasted effort applying irrelevant fixes or, worse, masking the underlying problem. The correct sequence is: reproduce the error reliably, gather the full error details from the APG error log, identify the error type and source, form a hypothesis about the root cause, test the hypothesis with a targeted fix, and verify the fix resolved the error without introducing new issues.
Reading the APG vNext Error Log
APG vNext writes all unhandled exceptions to the error log table in the database, accessible via Admin Panel → System → Error Log. Each error log entry includes the timestamp, the request URL that triggered the error, the exception type and message, the full stack trace, the SQL query (if the error occurred during a database operation), the member ID and username of the member who experienced the error (if authenticated), and the HTTP headers of the request. This information is sufficient to pinpoint most errors without needing to enable server-level diagnostics. When filing a bug report with APG support, always include the full stack trace from the error log entry — the exception type and message alone are rarely enough for the support team to identify the root cause without the stack trace context.
Enabling Detailed Error Pages During Diagnosis
When the APG error log does not capture an error (for example, when the error occurs before the APG error handling middleware initializes), enable detailed error pages in IIS and web.config to expose the full ASP.NET error details. Set customErrors mode="Off" in the system.web section of web.config, and set errorMode="Detailed" in the system.webServer/httpErrors section. After the error is reproduced and diagnosed, restore customErrors mode="On" immediately to prevent detailed error information from being exposed to end users in production. Never leave detailed errors enabled in production for more than the minimum time needed for diagnosis.
Common APG vNext Error Categories
Database Connection Errors
Database connection errors manifest as SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. These errors are caused by: incorrect connection string credentials, the SQL Server service being stopped, network connectivity issues between the web server and SQL Server, firewall rules blocking the SQL Server port (default 1433), or SQL Server running out of available connections due to a connection pool leak. Diagnose by testing the connection string credentials manually with SQL Server Management Studio from the web server. For connection pool leaks, check the active connection count in SQL Server's sys.dm_exec_connections DMV — an abnormally high count for a small forum indicates a code-level leak that requires APG support investigation.
Permission and Trust Level Errors
APG vNext requires Full Trust on IIS to access the file system, send emails via SMTP, and use certain advanced .NET APIs. If the application pool is configured with a lower trust level, permission errors manifest as SecurityException: Request for the permission of type System.Security.Permissions.FileIOPermission or similar. Verify the application pool trust level in IIS Manager → Application Pools → your pool → Advanced Settings → CLR Trust Level is set to Full. On shared hosting where Full Trust cannot be granted, contact APG support for the restricted-trust configuration guide, which documents the specific permissions required and how to request them from the hosting provider.
Filing an Effective Bug Report
When a troubleshooting session fails to identify a fix and the issue appears to be a software bug rather than a configuration problem, filing a complete bug report with APG support is the next step. An effective bug report includes: the APG vNext version and build number (Admin Panel → System → About), the exact steps to reproduce the issue from scratch, the expected behaviour versus the actual behaviour observed, the full error log entry including stack trace (if applicable), a sanitised copy of the relevant web.config sections (with passwords replaced by placeholders), and the Windows Server, IIS, and SQL Server versions. Bug reports with complete reproduction steps are typically resolved within 1-2 business days, while incomplete reports often require several back-and-forth clarifications before the issue can be diagnosed.
Related Resources
Looking for more help? Browse the support forum or check the Knowledge Base.