White Screen of Death (WSOD) Diagnostics on 1C-Bitrix

White Screen of Death (WSOD) Diagnostics on 1C-Bitrix

White screen — empty page without content, without errors, without HTML. Browser receives empty response body with HTTP-status 200 or 500. Difference from usual 500 error: server doesn't even return standard error page. For Bitrix this means PHP process died or interrupted before sending any output. Cause is hardest to find because by default nothing gets logged.

Mechanics of WSOD Appearance

PHP interpreter on fatal error (E_ERROR, E_PARSE, E_COMPILE_ERROR) stops script execution. If display_errors = Off (and on production it should), there's no output. If log_errors = Off or log path is incorrect — no entries either. Result: empty response.

Bitrix aggravates problem with output buffering. Kernel uses ob_start() on early initialization stages for delayed functions and composite cache. If error occurs inside buffer that wasn't flushed — client receives nothing, not even partial HTML.

Step-by-Step Diagnostics

1. Check PHP error log.

This is first and most important action. Determine path:

• php -i | grep error_log — for CLI
• phpinfo() — for web (create temporary file)
• php-fpm pool config: /etc/php-fpm.d/www.conf → php_admin_value[error_log]

If log is empty — make sure log_errors = On and path is writable for user running php-fpm (usually www-data or nginx).

2. Temporarily enable error output.

Add to very start of index.php, before any include:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

If error appeared after this — you got diagnosis. Typical messages:

• Parse error: syntax error — broken PHP file
• Fatal error: Class 'CBitrixComponent' not found — kernel corruption
• Fatal error: Allowed memory size exhausted — memory shortage

If screen still white — error happens before your code executes (on PHP extension load stage) or process is killed by OOM-killer.

3. Check system logs.

dmesg | grep -i "oom\|kill\|segfault"
journalctl -u php-fpm --since "1 hour ago"

Segfault in PHP process — this is bug in extension (often ionCube, Zend Guard, outdated opcache). OOM — not enough RAM.

4. Minimal kernel test.

Create file /test_kernel.php:

<?php
echo "Step 1: PHP works\n";
require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';
echo "Step 2: Kernel loaded\n";

Results:

• Empty — PHP can't even execute echo. Problem on server or PHP config level.
• "Step 1" — Bitrix kernel doesn't load. Problem in dbconn.php, .settings.php or DB connection.
• "Step 1" and "Step 2" — kernel loads, problem in specific page/component.

Main WSOD Causes in Bitrix

Error in init.php. This file executes on every request. Fatal error in it — guaranteed WSOD across entire site. Quick check: rename file. Quick fix: find error line via php -l /bitrix/php_interface/init.php (syntax check).

opcache corruption. Zend OPcache caches compiled bytecode. If cache corrupted (crash during write, PHP version change without cache reset) — PHP loads broken bytecode and crashes silently. Solution: php-fpm restart (systemctl restart php-fpm) resets opcache. For reliability: opcache.validate_timestamps = 1 and opcache.revalidate_freq = 2.

PHP version incompatibility. Upgrading PHP from 7.4 to 8.0 breaks sites using removed functions: each(), create_function(), mysql_*. Bitrix may load, but third-party module will cause Fatal Error. Check compatibility in advance via php -l for all project files.

Looped redirect with empty body. Module main redirects by rules from b_urlrewrite. If rule creates loop (A → B → A), nginx/Apache may interrupt request, returning empty response. Check headers via curl -v -L URL and count redirects.

Core file corruption. Incomplete update, manual core file editing, virus — all can lead to partial-load. Integrity check tool: /bitrix/admin/site_checker.php → "Check core file integrity". If site doesn't load at all — restore kernel from backup or download fresh version from 1c-bitrix.ru and replace /bitrix/modules/ and /bitrix/components/.

Diagnostics Time Table

Prevention

Configure exception_handling in .settings.php with mandatory file logging. Add to php-fpm config: php_admin_value[log_errors] = On, php_admin_value[error_log] = /var/log/php/bitrix-error.log. These settings can't be overridden from PHP code, guaranteeing logging even on Bitrix config errors.