Debugging Drupal White Screen of Death (WSOD)

When using Drupal for a web application, one may experience the dreaded White Screen of Death (WSOD). The WSOD has been extensively documented by the Drupal community at Typically, everything seems fine, and then, almost out of the blue, the Drupal based web application you are working on suddenly becomes completely broken; it gives a blank page for some, if not all requests. Usually I can't even remember what inconsequential-seeming things I had recently changed. In this post I'll talk about some things that have helped me in the past to fix Drupal's WSOD. The WSOD is not usually caused by themes, and all of the theme issues I'm aware of that causes the WSOD are thoroughly documented here. In this article I will focus mainly on WSOD scenarios caused by modules.

Note: When trying to fix the WSOD issue, you should always work on a local or development copy of your website.

Skip to a fast solution that has been most successful for me. (Yes it did help me fix this site)

Narrowing down the possible problem

The first thing you want to do is to narrow down the possible problems that could've caused the WSOD. Here we look at some mechanisms to do this, then later we delve into ways to solve the WSOD problem.

Did you just do an update

One of the main scenarios in which the WSOD appear on sites is after an update. If your WSOD was caused right after an update, you can be almost sure that it's one of the updated modules that's causing the problems.

Which type(s) of users or which roles are the WSOD occurring for?

Different modules are usually available for different roles; for example: the "devel" and "admin-menu" modules are usually only available for site administrators. If the WSOD is occurring only for a specific role or set of roles, we can again narrow down the problem to the set of modules.

Methods to fix the WSOD

Now that we've managed to possibly narrow down the set of modules, we can proceed to fix our WSOD. WSOD can be caused by several problems, none of which have one simple fix. Here I discuss several methods that can be used to fix your problem, you may have to try all of them, and it may work at the last one, but keep at it, the problem CAN be fixed!

Without any Code

Here are a few solutions that can help to fix the WSOD without the need for any coding.

Clear cache tables

If you have caching turned on, then Drupal will be loading most of your content, pages, scripts, views, etc from the cache tables. Sometimes a part of the cache can get corrupted; this mostly happens when you move your site to a different server. Emptying the cache tables would not affect the functionality of your application in any way. There are several ways to clear your cache table:

Using Drush
drush cc
You can use PHPMyAdmin or any way of accessing your database, then empty all of the tables with prefix "cache_". Do not delete the tables, just empty them
You can also Flush all caches under the performance page at "admin/config/development/performance" or using the "Clear Cache" link if you're using Admin Menu.

Rebuild permissions

If you have just enabled or disabled any module that modifies your permissions table or node access, you may get a WSOD, you may need to rebuild node permissions. You can rebuild permissions using Drush like: drush php-eval 'node_access_rebuild();' You can also rebuild permissions using the Admin UI through the admin_menu or "devel" modules; that is if you have access to the Administration interface.

Enable/Disable modules one at a time

This method may not be very feasible since you may have quite a few modules enabled on your website. However, if you have narrowed down the set of possible modules that may have caused the problem, you can now try disabling each module one at a time, and checking if the WSOD problem disappears. you can disable modules: 1. Through the modules page at "admin/modules". 2. Using drush: drush disable <modulename> 3. Directly editing the database by running the SQL query: UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1

Check watchdog table

Well, this is one of the first things you should do if your website is experiencing the WSOD. Drupal's watchdog table contain logs of most, if not all errors that your website have experienced. You can view the watchdog table at /admin/reports/dblog or through PHPMyAdmin or any Database browsing tool. You can also view the watchdog table using drush: drush watchdog-show

Lets get into coding!

If the above methods don't help you to solve your WSOD problems, I'm almost sure one of these will, as they have solved all the WSOD problems I've had in the past.

Setup error reporting

Well this isn't much coding and anyone can do this. You need to add the following code to the top of your index.php file which is in the root directory of your Drupal installation.
    ini_set('display_errors', TRUE);
    ini_set('display_startup_errors', TRUE);
This will tell PHP to display any PHP errors and warnings onto the screen. After you have enabled error reporting, go ahead and refresh the page and see if any errors show up; if there are errors, then we've made some progress, now you just need to figure out how to fix these errors. Sometimes the errors may point to a specific module, you can try disabling this module and see if it fixes the WSOD problem.

Increase memory limit

Drupal is very memory intensive. If you have lots of modules installed on Drupal, then Drupal would need quite a bit of memory to load a webpage. After enabling error reporting, if your site runs out of memory while loading, then an error would show up: PHP Fatal Error: Out of memory. There are several mechanisms to fix this problem, the easiest being to increase your PHP memory limit. Increasing your memory limit is documented here Several other problems can also cause Drupal to use more memory than necessary, however this topic is out of the scope of this article.

Add some code to check it!

Now here comes my favorite solution! This has worked for me more often than any solution, and it does help you find and fix the problem very fast, especially if you have a LIVE site needing fast attention! From my experiences, most of the time, it's a module that causes the WSOD. And in most of my experiences, I couldn't just disable modules to test which it was, since I may have lost data in the process. What you need to do it to edit this function in, and add the 2 lines with the print statements as shown below:

    function module_invoke_all($hook)
        $args = func_get_args();
        // Remove $hook from the arguments.
        $return = array();
        foreach (module_implements($hook) as $module)
            print "Starting loading $module <br />";
            $function = $module . '_' . $hook;
            if (function_exists($function))
                $result = call_user_func_array($function, $args);
                if (isset($result) && is_array($result))
                    $return = array_merge_recursive($return, $result);
                elseif (isset($result))
                    $return[] = $result;
            print "Finished loading $module <br />";
        return $return;
After refreshing the page that is currently experiencing the WSOD, you'll see a listing of all modules on your site, there will be one module for which the "Finished loading $module" statement will not print, you need to disable that module. After finding the module, you can go into the system table and look for that module, set it's status = 0 and bootstrap = 0, or you can run the query shown below or use drush to disable the module, as shown above. UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1

Other possible reasons and their fixes

Invalid .htaccess file

It is possible that you have an invalid .htaccess file, this can be caused by a malformed upload, or an update to the server, or a bad edit. Try to remove your .htaccess file (keeping a backup of course) just to test for this.

Funny CSS

Believe it or not, I once set my website background to white, and text color to white, and thought I had a WSOD, so do use FireBug and check if there is any text there.