Skip to content

What to Check if Something Stops Working

Work through these checks in order before escalating.

Step 1 — Establish Scope

  • Which subdomain instance is affected? (bmh, ced, cedproperties, scstransact, or futreconstruction)
  • Is the problem isolated to one instance or present across multiple instances? A shared codebase defect or failed deployment would affect all instances; a database or configuration fault is instance-specific.
  • Is the problem affecting all users or just a specific user?
  • Is the problem affecting all screens or a specific module/page?
  • Is the login page accessible? Navigate to ~/login.
  • Are there any HTTP error codes visible (500, 503, 404)?

Step 2 — Check for Recent Changes

  • Has there been a recent deployment (application files updated)?
  • Has there been any database maintenance, migration, or schema change?
  • Have any configuration files (web.config, touch-settings.json) been modified?
  • Has the SQL Server or IIS server been restarted or patched?
  • Note: a code deployment updates all subdomain instances simultaneously. If the issue appeared shortly after a deployment, verify whether other instances are also affected before treating the problem as instance-specific.

Step 3 — Check the Application Error Log

Query the Errors table in the database:

SELECT TOP 20 ErrorID, UserName,
       JSON_VALUE(Details, '$.exception.message') AS Message,
       JSON_VALUE(Details, '$.exception.type') AS ExType,
       JSON_VALUE(Details, '$.exception.source') AS Source
FROM Errors
ORDER BY ErrorID DESC

If a user reported a [Ref: <guid>], query by ErrorID directly:

SELECT * FROM Errors WHERE ErrorID = '<paste-guid-here>'

Step 4 — Check Windows Event Log and IIS Logs (if hosted on a VM / dedicated server)

Shared hosting note: Direct server access is not available in a shared hosting environment. If server-level log access is required, raise a support ticket with the hosting provider, supplying the approximate date/time and a description of the issue.

  • On the web server, open Event Viewer → Windows Logs → Application.
  • Look for ASP.NET or IIS errors around the time of the issue.
  • Check IIS logs under C:\inetpub\logs\LogFiles\ for HTTP status codes.

Step 5 — Check IIS Application Pool

Shared hosting note: In a shared hosting environment, IIS Manager is managed by the hosting provider. If the Application Pool appears to be stopped or misconfigured, raise a support ticket with the hosting provider rather than attempting direct IIS access.

  1. Open IIS Manager on the web server.
  2. Navigate to Application Pools.
  3. Confirm the CONPROSOFT Application Pool is in the Started state.
  4. If stopped, start it and monitor for recurring stops.
  5. Check Advanced Settings — confirm .NET CLR Version = v4.0 and Managed Pipeline Mode = Integrated.

Step 6 — Check Database Connectivity

  • Each subdomain instance uses its own isolated database. Confirm the MyCompany connection string in the affected instance's web.config references the correct database before testing connectivity.
  • Confirm SQL Server is running and reachable from the web server.
  • Test the connection string from the web server using SSMS or sqlcmd:
sqlcmd -S mart.zadns.co.za -d conprosoft_bmhcrp -U conprosoft_dbadmin -P [password] -Q "SELECT 1"
  • If the connection fails, check firewall rules between the web and database servers.

Step 7 — Check Per-Instance Configuration

Each subdomain instance shares the same deployed codebase but has its own web.config. If the issue is confined to one instance, inspect that instance's configuration for the following:

  • Connection string (MyCompany key) — confirm it points to the correct instance database.
  • SMTP credentials (<system.net><mailSettings>) — each instance uses the email provider for its own subdomain (e.g., bmh.conprosoft.co.za). If email is failing for one instance only, verify the SMTP host, username, and password in that instance's web.config.
  • BLOB storage paths — attachment adapter paths differ per instance; a stale or incorrect path causes upload and download failures.
  • touch-settings.json — verify appName and any branding values are correct for the affected instance.

Step 8 — Check Web Server Resources

  • CPU, memory, and disk utilisation on the web server.
  • If disk is full, IIS and ASP.NET may fail silently.
  • Temporary ASP.NET compilation files under %windir%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ may occasionally need clearing after a bad deployment.

Step 9 — Escalate if Unresolved

  • Collect: error messages, [Ref: guid] values, Event Log entries, HTTP status codes, and a description of what changed before the issue started.
  • Contact the Developer with this information for application-level diagnosis.

Temporary Workarounds

If possible, apply a safe, reversible workaround while investigation continues. Examples:

  • Restart only the affected IIS Application Pool (avoid full server restart unless required).
  • Temporarily route users to an unaffected workflow or module.
  • Re-run a failed non-destructive operation after confirming connectivity and permissions.
  • Disable a newly introduced optional feature/configuration change until root cause is confirmed.

Incident Record

After stabilisation, record the outcome and remediation details. Minimum fields:

  • Incident date/time.
  • Affected subdomain instance(s).
  • Affected users/modules.
  • Error details ([Ref: guid], HTTP status, Event Log entries).
  • Expected behaviour.
  • Observed behaviour.
  • Immediate workaround applied.
  • Root cause (confirmed or suspected).
  • Permanent fix implemented.
  • Verification performed and by whom.