Troubleshooting 1C-Bitrix website errors

Error Elimination on 1C-Bitrix Site

Message "An error occurred on the site" — this is not a diagnosis, but a symptom. Behind identical external manifestation hide dozens of reasons: from overflowed b_event table to module update conflict. Error elimination on Bitrix — first and foremost methodical diagnostics, and only then fixing. Let's explore systematic approach that allows finding cause, not guessing.

Error Classification

Before digging into code, determine error type:

First Step: Enable Detailed Logging

By default Bitrix suppresses error output on production. For diagnostics need to temporarily enable extended mode.

In /bitrix/.settings.php file find exception_handling section and set:

• debug → true
• handled_errors_types → E_ALL
• log → configure file write, for example /var/log/bitrix/error.log

Alternative way — via dbconn.php (for old versions): $DBDebug = true; and error_reporting(E_ALL);. On production don't forget to revert settings after diagnostics — error output reveals paths and DB structure.

Systematic Diagnostics Approach

There's established algorithm covering 90% of cases:

1. Reproduce the error. If error is intermittent — collect data: URL, time, browser, is user logged in. Often error appears only for specific user group or with specific component settings.

2. Check event log. Administrative panel → Settings → Tools → Event Log. Table b_event_log stores errors with timestamps, source module and stack trace. Filter by severity ERROR and WARNING.

3. Exclude cache problem. Clear all cache: managed cache (/bitrix/managed_cache/), auto cache (/bitrix/cache/), static cache (/bitrix/html_pages/). Via admin: Settings → Product Settings → Auto-caching → Clear all cache files. If error disappeared after flush — problem is in cached data, not code.

4. Disable third-party modules. Via bitrix/modules/ rename suspicious module (e.g., partner.module → partner.module_disabled). If error gone — culprit found. For components similarly: replace component call with stub.

5. Check core integrity. Tool "System Check" in admin (/bitrix/admin/site_checker.php) compares file checksums with reference. Modified core files — frequent cause of problems after updates.

Common Error Causes and Solutions

Service table overflow. Tables b_event, b_event_log, b_search_content_stem, b_stat_* grow without limits. On loaded sites b_event can contain millions of rows. Solution: configure cleanup agent or write cron script for rotation. For b_event — set limit in Settings → Mail Events.

Module update conflict. Updating core to version incompatible with third-party module causes Fatal Error. Pattern: updated Bitrix, everything broke. Solution: rollback update via /bitrix/updates/ or disable conflicting module. Always backup before updates and check compatibility on test copy.

Errors in result_modifier.php and component_epilog.php. Component customizations via these files in templates — main source of errors on updates. Component changed $arResult format, but result_modifier.php accesses non-existent key. Solution: add isset() checks and log mismatches.

Session issues. Bitrix by default stores sessions in files (/tmp/ or /bitrix/tmp/). On insufficient permissions or space, sessions not created, user gets endless redirect to login page. Check session.save_path in phpinfo() and directory permissions.

DB-level Errors

Most insidious — errors related to data integrity. Typical:

• "Duplicate entry" when adding iblock elements — violated auto-increment or index. Solution: ALTER TABLE ... AUTO_INCREMENT = <max_id + 1>.
• "Table is marked as crashed" (MyISAM) — table corruption. Solution: REPAIR TABLE b_iblock_element.
• Deadlocks on mass operations — two transactions block each other. Manifests as "Lock wait timeout exceeded". Solution: optimize order of table access, use SHOW ENGINE INNODB STATUS for analysis.

Resolution Time by Complexity

For each found error record: cause, detection method, solution, and prevention measures. Without this, same error will return after each update.