Debugging Drupal's White Screen of Death?

I have a Drupal installation that previously worked perfectly on my localhost. However, now, after a formatted my computer, it just shows a blank screen (completely white).

So my question is, how can I see where things are going wrong, if I can't even log into the sever?

The only errors I can find are (taken from the Apache Error Logs):

[Tue May 17 05:05:04 2011] [notice] Parent: child process exited with status 255 -- Restarting.
[Tue May 17 05:05:04 2011] [notice] Digest: generating secret for digest authentication ...
[Tue May 17 05:05:04 2011] [notice] Digest: done
[Tue May 17 05:05:07 2011] [notice] Apache/2.2.11 (Win32) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8i PHP/5.2.9 configured -- resuming normal operations
[Tue May 17 05:05:07 2开发者_JAVA百科011] [notice] Server built: Dec 10 2008 00:10:06
[Tue May 17 05:05:07 2011] [notice] Parent: Created child process 6992

There are no errors in Watchdog...

I am using Xamp 1.7.1 (PHP 5.2) and Drupal 6.

I just also need to mention that once I try and load the site on my local machine, apache also crashes! I added this:

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

And it still just shows the screen of death? Where can I actually see errors?

I also found this in apache access.log:

127.0.0.1 - - [17/May/2011:05:22:14 +0200] "GET /greekmerchant/src/ HTTP/1.1" 200 3
127.0.0.1 - - [17/May/2011:05:25:45 +0200] "GET /greekmerchant/src/update.php HTTP/1.1" 302 -
127.0.0.1 - - [17/May/2011:05:25:46 +0200] "GET /greekmerchant/src/update.php?op=info HTTP/1.1" 200 -

... after trying to access update.php. It also just goes to a white screen.

I have this in my sql config file:

[mysqld]
port= 3306
socket= "C:/xampp/mysql/mysql.sock"
basedir="C:/xampp/mysql" 
tmpdir="C:/xampp/tmp" 
datadir="C:/xampp/mysql/data"
skip-locking
key_buffer = 16M
max_allowed_packet = 128M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
log_error="mysql_error.log"

And...

[mysqldump]
quick
max_allowed_packet = 128M

Also, my PHP memory is set to 1024MB.

Anyone got any idea why this is just dying? Is it really a memory problem? What else can I do to get errors shown to me? I still see nothing even after enabling error logging.

Update:

The website runs on my local machine if I delete the files folder. So, for some reason, when it has to access files in the files folder, it runs out of memory. Why? Or better yet, what could be causing this excessive use of memory?

There is a whole page in the Drupal handbooks dedicated to debugging the "White Screen of Death". In a nutshell, enable error reporting by adding the following at the top of your index.php file:

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

...and check the logs, which you've already started to do. Those two steps tend to pinpoint the problem, most of the time. If that doesn't point you towards a solution, continue down the handbook page, for lots more tips.

If I had to take a wild guess, I would say your case is probably an out-of-memory error.

I know this may be late, but it helped me. Most times a module causes WSOD, I couldn't just disable modules to test which it was, since I may have lost data in the process. What I did was to edit this function in module.inc

function module_invoke_all($hook) {
  $args = func_get_args();
  // Remove $hook from the arguments.
  unset($args[0]);
  $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;
}

And I added those 2 print statements in the code above, then refresh the page, the module which didn't reach the "Finish loading $module" statement is the one with the problem... it was devel in my case.

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 run the query:

UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1

Reference: Debugging Drupal White Screen of Death (WSOD)

Check your error reporting settings for PHP. You may need to enable error reporting.

This may help: http://drupal.org/node/158043

Content of theme('page') rendering is empty, and that would sure enough give you a WOD.

Use this to help you, it finds a couple of common issues related to WOD.

Also try rebuilding permissions, best way is to use drush and type:

drush php-eval 'node_access_rebuild();'

Also use drush to view currently installed modules, with

drush sm

disable ALL custom modules, and search.

drush disable <modulename>

And while you are in drush, clear the cache:

drush cc

If you figure cron is the problem , I've had huge problems with badly written cron hooks before, just in case it is your issue, supercron will be your friend for this.

You should have enough memory unless you have some module in there behaving very badly.

* Troubleshooting update

If the problem occurs while running update.php open update.php in a text editor and uncomment the following line:

ini_set('display_errors', FALSE);

See this page for a bunch of other wsod fixes. Notably if you use path-auto, the fix mentionned on that page is worth a look into.

My advice is to take the entire contents of your module and theme folder and download them to your desktop. These themes and modules are still installed just temporarily disabled. If your site comes back then it was most likely a module or theme error. Maybe someone missed a ending bracket '}'. If you are certain that the modules or themes are not the problem then place them back in the folder with no loss what so ever. It does not hurt to try this since you won't lose anything. If you find out it is a module problem start placing them one by one back in the folder refreshing along the way. Once the site white screens you found your problem and an update to a module might help.

I always try this first since the drupal install is pretty rock solid it is the modules and themes that you have to worry about.

Unlike the other answers here this wont exactly pin point the problem but if you are lazy like me and don't want to modify config files and turn on errors then this is the way to go, or at least start here then go and modify the configs when all else fails.

Assuming it is a Linux host, it could be a permissions issue if your host is running suPHP or some other form of suexec. Make sure that the ownership of the files is correct and the access mode is correct.

You may also have an invalid .htaccess file, try to remove it just to test for this.

In my php.ini I modified these variables:

error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On 
display_startup_errors = On

Executed:

sudo apachectl restart

An get rid of these errors in all my Drupal sites.

Had a WSOD that just wouldn't tell me what was wrong. No errors showed up after enabling display_errors/display_startup_errors/error_reporting. There was nothing in the PHP error log. There was nothing in the server error log. Just a WSOD and go figure.

The way I finally managed to coax Drupal into displaying error messages was to enable $update_free_access = FALSE; and navigate to /update.php. This showed that there were no pending updates, but listed a whole bunch of errors in the database, which were the result of a messed up data import.

Check the contents of the directory of your theme (directory or file).

In the marinelli theme the absence of folder logic causes this kind of problem.