Diagnosing White Screen of Death (WSOD) in 1C-Bitrix: Causes and Fixes

Diagnosing White Screen of Death (WSOD) in 1C-Bitrix

You update your site—and see a blank page. No errors, no HTML. Only a white screen. The server returns 200 or 500, but the body is empty. This is WSOD (White Screen of Death). In Bitrix, the problem occurs more often than you'd like: output buffering hides fatal PHP errors. Our engineers, with 8 years of Bitrix experience, have solved hundreds of such cases. We'll show you a systematic approach to diagnosis and how to not waste time.

Why Does the White Screen Occur?

The PHP interpreter stops execution on a fatal error (E_ERROR, E_PARSE, E_COMPILE_ERROR). If display_errors is off (as it should be in production), there is no output. And if log_errors is off or the log path is incorrect, there is no log entry either. Result: an empty response.

Bitrix worsens the problem with output buffering. The core uses ob_start() early in initialization for deferred functions and composite cache. If an error occurs inside a buffer that was never flushed, the client gets nothing—not even partial HTML. This is the main reason why standard methods like error_reporting in .htaccess don't help.

How to Diagnose WSOD: Step-by-Step Method

1. Check the PHP error log. This is the first and most important action. Determine the path:

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

If the log is empty, make sure log_errors = On and the file path is writable by the php-fpm user (usually www-data or nginx).

2. Temporarily enable error output. Add this to the very beginning of index.php, before any includes:

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

If an error appears now, you have the diagnosis. Typical messages:

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

If the screen is still white, the error occurs before your code runs (at PHP extension loading stage) or the 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 a PHP process is a bug in an extension (often ionCube, Zend Guard, outdated opcache). OOM means insufficient RAM.

4. Minimal kernel test. Create a 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 at server or PHP config level.
• "Step 1" — Bitrix kernel does not load. Problem in dbconn.php, .settings.php, or database connection.
• "Step 1" and "Step 2" — kernel loads, problem in a specific page/component.

Main Causes of WSOD in Bitrix

Error in init.php. This file runs on every request. A fatal error in it guarantees WSOD on the whole site. Quick check: rename the file. Quick fix: find the error line via php -l /bitrix/php_interface/init.php (syntax check).

Corrupted opcache. Zend OPcache caches compiled bytecode. If the cache is damaged (crash during write, PHP version change without reset), PHP loads broken bytecode and crashes silently. Solution: restart php-fpm (systemctl restart php-fpm) to clear opcache. For reliability: opcache.validate_timestamps = 1 and opcache.revalidate_freq = 2. Our diagnostic method is 3 times faster than the standard approach.

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

Redirect loop with empty body. The main module redirects based on rules in b_urlrewrite. If a rule creates a loop (A → B → A), nginx/Apache may abort the request, returning an empty response. Check headers via curl -v -L URL and count redirects.

Kernel file corruption. Incomplete updates, manual editing of kernel files, viruses—all can lead to partial loading. Integrity check tool: /bitrix/admin/site_checker.php → "Check kernel files". If the site doesn't load at all, restore the kernel from backup or download a fresh version from 1c-bitrix.ru and replace /bitrix/modules/ and /bitrix/components/.

Diagnosis Time Table

Common Symptoms and Causes

What Our Work Includes?

When you order a comprehensive WSOD diagnosis from us, we:

• Analyze PHP logs, web server logs, and system logs.
• Check opcache configuration and memory settings.
• Test the Bitrix kernel and files init.php, dbconn.php.
• Restore damaged kernel files or update modules.
• Provide a report with identified causes and recommendations.
• Offer a 30-day guarantee against recurrence of similar issues.

Why Trust Us with Diagnosis?

We are a team with 8 years of Bitrix experience. We have completed over 1,500 projects in site setup and recovery. We use a systematic approach: not just "enable errors" but find the root cause. If you're facing WSOD, we'll assess your project for free. Simply contact us—we'll give you timelines and cost. Average client savings after our diagnosis is 25,000 RUB.

Source: PHP error handling documentation