Last updated 22 August 2016. Created on 5 June 2009.
Edited by rhuffstedtler, sillygwailo, NonProfit, kenorb. Log in to edit this page.

A page being completely blank is commonly referred to as a White Screen of Death (WSOD). Because there is nothing on the page, it is not trivial resolving such a situation and you will have to go under the hood in order to restore your site.

1a. Ensure you have proper PHP Configuration, no PHP syntax errors or memory limit

The best approach to solving a WSOD problem is to identify the error– looking behind the blank screen or making it not blank. If you can access server / code at all, enable error reporting or find the system error logs first.

The White Screen of Death (Completely Blank Page) handbook page covers seeing error messages and fixing common WSOD causes.

1b. Check your recent Drupal logs

Try to go to: admin/reports/dblog (Administer -> Recent log entries)
and check for recent errors.

If you can't, you can also check for recent errors manually in your watchdog table by executing following query directly in your SQL client:


On Windows you can download: MySQL Workbench (easy to use)
Server Hostname: localhost
Username: root
Default Schema: (your database name)

If using the Syslog module, these errors will likely be in your servers syslog.

If you have some errors, please search for it in Google or raise a new support ticket:

2a. Use DTools module to diagnose common problems (Drupal 6 only)

Download Link:
and follow the README.txt instructions how to execute it in case of a WSOD.

It will help you to fix common WSOD problems like:

  • menu_execute_active_handler() in index.php returns NULL
  • Content of theme('page') rendering is empty
  • Duplicated module paths
  • metimes copy the same module to make backup, but if the second copy is inside Drupal, it causing module duplicates
  • Fix the wrong theme and module paths in the database

2b. Easy manual quick-fixing

Rename a module

Renaming directory name of bad module can temporary ignore that module without database changing and find that one which cause the problem

  1. Go to the contributed module directory (sites\all\modules\ or modules\) and before each refreshment rename a couple of modules.
  2. For example:
    • Rename module dir: sites\all\modules\Views to sites\all\modules\Views_
    • Refresh the page if this helped
    • Rename next module dir: sites\all\modules\Panels to sites\all\modules\Panels_
    • Refresh the page if this helped

Note: please ignore core modules like Filter, System, User, etc. to prevent internal error dependencies: those modules don't have any critical issues.

3. CSS & JS Compression Issues

If you upload your project to a shared host and do not have sites/default/files/css and /js folders with permissions set to 777, you could possibly experience a WSOD when you go to enable CSS and JS aggregation (admin/settings/performance). It's better to create these folders on your dev machine, give them the 777 permissions, and then upload your project to the live site.

However, if you find that you are live and you cannot change the permissions, disable the aggregation and try renaming the css & js folders. Then create new folders with permission 777.

When you re-enable compression, the WSOD should not re-occur.

Debugging tricks

Get backtrace

If some module passes unexpected data types the issues will be hard to track as the error is happening in a completely different place than the place that is causing it.

Some panels ajax only threw a 500 and apache errorlog only told us:
PHP Fatal error: Unsupported operand types in .../includes/ on line 4461
No backtrace.

That source told us some module did not pass an array but php expected it:

  // Add defaults to the special attached structures that should be processed differently.
  $elements['#attached'] += array(
    'library' => array(),
    'js' => array(),
    'css' => array(),

But with Devel and Commerce Devel module enabled hunting that down was as easy as inserting this code before said line:

      // Don't continue processing bad data.

...and collecting a backtrace in the database log.

Links to common Drupal WSOD issues

#495194: Fatal error: Unsupported operand types in on line 511 cause WSOD
#352344: Fatal error: Unsupported operand types in on line 1369
#496198: module_list() called with wrong arguments causing WSOD and breaking theme_registry

Above solutions wasn't helpful enough?

Search or Ask at Drupal Answers Stack Exchange site.

Looking for support? Visit the forums, or join #drupal-support in IRC.


Stomper’s picture

Try a permissions rebuild. It fixed my WSOD after I transferred by site from localhost to live site. See

jcarlson34’s picture

Just ran into a particularly nasty silent white screen.

Sometimes a mysql query can be too big for mysql defaults (max_allowed_packet=1M)

Check your my.cnf file in /etc/ and add or modify the following line to something higher like 16M:


A more indepth write-up is found here. This post saved me:

Gogowitsch’s picture

I spent days looking for the source of BSODs on Drupal 6.22 that would only appear when submitting forms (Login, saving/deleting blocks or nodes, etc.).

I solved it by emptying the {search_dataset} table within phpMyAdmin (in SQL terms: TRUNCATE). Then, instead of the BSOD, one single last Internal Server Error appeared directly after posting a form, then the problem was gone until after re-indexing (cron runs). My actual problem source was a node with the PHP input format that contained a die() call, and I assume a PHP syntax error would cause the same problem.

To find problem candidate nodes I queried the DB as follows:
SELECT * FROM node_revisions WHERE format=3

What didn't help: transferring files and database contents onto other computers: the problem appeared on Linux (Apache) and Windows (IIS, Apache). Also, neither emptying the cache nor looking for files with a BOM would help. Also, commanding Drupal to re-index the search didn't solve the problem.

unkn0wn’s picture

Today i wasted about 2 hours for war with WSOD. WSOD was after modules installation, database migration, image resizing, etc - every second action in admin panel was WSOD'ed. Apache, PHP and Drupal logs were clear - no errors, no warnings.

Problem was very simple: PHP version was 5.3.9, PHP modules version also was 5.3.9, but mysqli and pdo_mysqli had version 5.3.10, pgsql and pdo_pgsql had version 5.3.11. After upgrading php and php modules to one version WSOD's are gone.

pjohn’s picture

Don't forget to check your rewrite rules in .htaccess. In my case, the home page was loading just fine, but no other pages would show up... no /user, /node, etc. This happened after I moved my Drupal installation to a staging server that was on a subdomain — the site was fine on localhost. Nothing in the error logs; nothing when I turned on error reporting, etc.

I realized that I had to go into .htaccess in the site's root directory and uncomment (remove the # from the beginning of) this line:

RewriteBase /

Voilà! It must have something to do with the site's running in a VirtualDocumentRoot.

PapaGrande’s picture

I spent a half day trying to figure out why a single path was showing a WSOD on a production server and not development servers. It turns out the page callback for the menu item relied on a value that could be changed by site administrators and output nothing if that value didn't match. Needless to say, I changed the callback function to be more fail-safe.

sannminwin’s picture

I had same problem but finally It was solved. First I added the code
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

// $Id: index.php,v 1.94 2007/12/26...

in index.php file to see error.

My error was T_FUNCTION in module.webform.

So I checked version of webform module by going to public_html/ I scrolled down at the end of file and I found that It was version "7.x-4.9".

Then I created info.php see how to create it
I found that my php version was 5.2.29. As minimum requirement of php for webform module is 5.3 I upgraded PHP version of server by changing one number from "2" to "3" in file public_html/.htaccess.

if you don't have one, at the beginning of .htaccess add a line "AddHandler application/x-httpd-php53 .php .php5 .php4 .php3"

In my case I changed "application/x-httpd-php52" to "application/x-httpd-php53" by changing only "2" to "3".
Now my site running normal.

Thanks for very useful note.

DropInTheOcean’s picture

Another strategy that helped me was to visit the Drupal Database Update page (e.g. and just click continue - there was no apparent update, but the site came back up.

Background - Drupal 7: WSOD after installing combination of Devel + Theme developer + simplehtmldom API modules. Disabled them in the database following this guide : You may also need to temporarily set $update_free_access = TRUE; if not logged-in as admin.