locked
Failed to initialize storage module **17243** RRS feed

  • Question

  • User-2048372337 posted

    We are suddenly getting this error message:

    PHP Fatal error: session_start(): Failed to initialize storage module: wincache (path: C:\inetpub\temp\sessions) in C:\Inetpub\wwwroot\library\common.php on line 32 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    It's not happening every time, or on every page, but only one one page and only some of the time. 

     

     

     

    Thursday, July 22, 2010 5:00 PM

All replies

  • User-1405480850 posted

    Hi,

    Can we get some kind of sample code to repro this in-house.

    Thanks,

    Don.

    Thursday, July 22, 2010 5:03 PM
  • User-2048372337 posted

    I don't know how I would do that. The application it's happening in is hugely complex.

    Thursday, July 22, 2010 5:06 PM
  • User-1405480850 posted

    Hi,

    Is your session.save_path set to C:\inetpub\tmp\sessions? Can you clean up the files there and see? Also ensure that you have enough space to write to that folder. And run the 'dir' command on the folder before deleting and let me know what the output is.

    I believe there is no code in your application which is changing the session.save_path or session handler?

    Thanks,

    Don.

    Thursday, July 22, 2010 5:20 PM
  • User-1405480850 posted

    Hi,

    In your application code are you calling session_destroy(). Apparently it seems calling session_destroy is destroying all the user set sessions too. Look for details at http://drupal.org/node/834962. See if this helps.

    Thanks,

    Don.

    Thursday, July 22, 2010 5:46 PM
  • User-2048372337 posted

    Yes, the path is C:\inetpub\temp\sessions and there's plenty of space. Clean up files? How?

     

     Volume in drive C has no label.
     Volume Serial Number is 14C7-A1B6

     Directory of C:\Inetpub\temp\sessions

    07/22/2010  02:21 PM    <DIR>          .
    07/22/2010  02:21 PM    <DIR>          ..
    07/19/2010  09:56 AM               123 sess_0m9n8loi4pcbk6o92g93bmr4o7
    07/19/2010  11:34 AM                 0 sess_0t0evc5a7t4ckgi256dddcslb6
    07/16/2010  04:44 PM               118 sess_1pe7u4ul3p0ck8dapg9r1in3f4
    07/22/2010  02:21 PM               118 sess_38p90cea34gg9cpa264lma5k12
    07/20/2010  09:14 AM                 0 sess_3ehj4pbaqo27fs54vkacd2ff03
    07/16/2010  12:59 PM               142 sess_52861j6ma2s4a7oj3v6he24487
    07/16/2010  12:55 PM                90 sess_57g2kr1g1q6tddvn8807mk0qc0
    07/20/2010  02:44 PM                 0 sess_85mmubucfcm6p4ttto6icq85m4
    07/23/2010  07:50 AM               121 sess_acltejopsc37vjimlt2kn5vug5
    07/19/2010  09:39 AM               142 sess_acrt7clo98fobrergiu4vopv22
    07/22/2010  02:34 PM               121 sess_aogd0hgl4v5asv6ue0g0lbifl2
    07/20/2010  09:22 AM               123 sess_ct79budme1doqepbf5oo92t8b0
    07/21/2010  08:53 AM                90 sess_g0frga69vdqo1eas7cilso2er5
    07/21/2010  07:26 PM               121 sess_h6tucia0li0s8imf8ugtk31vn6
    07/21/2010  11:10 AM                 0 sess_huqvcgduaps3i5t3dp4is881o7
    07/19/2010  12:08 PM               118 sess_jj3ek2ri5okn34pllf07r3vck3
    07/21/2010  08:58 AM               142 sess_jssm1lgk97crpm7egc1n9ae332
    07/19/2010  11:34 AM               123 sess_n917nnre1nfkdfggri4iv91bs1
    07/21/2010  11:10 AM               123 sess_offc07sbgvlbufg3t02ma1i1q3
    07/19/2010  08:58 AM               123 sess_ol00gd7ldfmncoj91tqhm1tim3
    07/20/2010  02:45 PM               118 sess_ps6416cl33dv30sbuoddqv0ud6
    07/19/2010  09:38 AM                90 sess_rr0s92feeuotu0ef8cm6f2bg26
    07/21/2010  11:14 AM               123 sess_so4j461edhpsckk6t1psb1k1j4
    07/16/2010  06:16 PM        67,108,864 wincache_session_1_93823.tmp
                  24 File(s)     67,111,133 bytes
                   2 Dir(s)  385,991,925,760 bytes free

    Friday, July 23, 2010 9:37 AM
  • User-2048372337 posted

    No, we are not using session_destroy or changing handlers. This worked fine for a few days, it seems (or the users weren't reporting it.) Also, it seems to not do this on my local machine (Windows 7 x64), but only on production (Server 2003 x86.)

    Friday, July 23, 2010 9:41 AM
  • User-2048372337 posted

    I know this sounds crazy, but I have been testing this problem and I cannot make it happen from my machine (as a client to the production server), but I can make it happen on the other machines. The differences in the machines:

    • Mine: Windows 7 x64, high-performance hardware
    • Other clients: Windows XP x86, moderate hardware

    The function that is causing this makes two very fast and fairly lightweight Ajax calls in succession (asynchronously.) Hmm, maybe I should make those calls (syncrhronously.) Could they be getting out of order and causing this issue? We haven't had this issue in the past with the default session handler. Just a thought.

    I still don't know why the client OS or hardware could affect this, but there is definitely different behavior.

    Friday, July 23, 2010 10:57 AM
  • User-1405480850 posted

    Yes, the path is C:\inetpub\temp\sessions and there's plenty of space. Clean up files? How?

    Can you delete all the files in this folder. I can see both wincache_ file as well as sess_ files. Are they from different applications? If you have set the handler to WINCACHE, there should be only wincahce_session_ files. Unless some other application which is using 'files' as a session handler is also writing to this folder. Please delete all the files and see. Only wincache_ files should be present here.

    Thanks,

    Don.

    Friday, July 23, 2010 11:59 AM
  • User-2048372337 posted

    Those sess_ files appeared again. I don't know how that's happening. Any ideas how to trace it?

    Monday, July 26, 2010 2:29 PM
  • User-2048372337 posted

    We're still getting the error. It appears that I am going to have to disable the Session Cache for now, until you have some ideas as to how it's happening. It's causing my users disruption.

    Monday, July 26, 2010 2:51 PM
  • User-1405480850 posted

    Hi,

    This means somewhere session.save_handler is getting reset to "files". This can be done using function ini_set. Also see if there are any occurence of session_set_save_handler in your code.

    Thanks,

    Don.

    Monday, July 26, 2010 3:44 PM
  • User-2048372337 posted

    I've already checked and there is not.

    Monday, July 26, 2010 3:48 PM
  • User-1405480850 posted

    Is there some other application writing there? Try opening the file in a text editor (sess_ files) and see if you can make out which application is creating it.

    The other way is to set session.save_path to a non-existant folder. See if the application logs something in the PHP error log.

    Thanks,

    Don.

    Monday, July 26, 2010 3:54 PM
  • User-2048372337 posted

    That file just contains some user information, the username, domain, token, etc.. We use NTLM authentication. Do you think that makes a difference?

    Monday, July 26, 2010 5:29 PM
  • User-1405480850 posted

    That should not make a difference in my opinion.

    Thanks,

    Don.

    Monday, July 26, 2010 5:34 PM
  • User-2048372337 posted

    So, it appears that the session handler is possibly not starting correct, because the only data pulled into those files is the users authentication information.

    Monday, July 26, 2010 5:39 PM
  • User-2048372337 posted

    We still are unable to use this. Any ideas?

    Wednesday, September 1, 2010 9:19 AM
  • User-1653247517 posted

    Hi,

    Which PHP application are you running? Can you send me your php.ini and describe repro steps as best you can so that I can try to repro this on a test machine? My email id is ksingla at microsoft dot com.

    Thanks,
    Kanwal

    Thursday, September 2, 2010 1:19 PM
  • User-2048372337 posted

    It's all custom code written in-house. Not sure how to do what you ask. The application works fine on my Windows 7 x64 development machine. It only has this problem on our production server (Server 2003 x86.) It's a huge application and I don't know where it's coming from.

    Tuesday, September 7, 2010 12:50 PM
  • User-2048372337 posted

    It causes too much of a problem to test. Sucks, but we are just going to have to do without it.

    Monday, September 13, 2010 8:15 AM
  • User-917625502 posted

    We have users reporting this issue too. From Wordpress to OpenCart.

    Saturday, February 5, 2011 10:50 AM
  • User-2048372337 posted

    Just tested 1.2.614-dev and appears to be the same problem we were having before. Not 100% certain, as this time, all I can get is HTTP 500. One thing to note, is it appears to only happen to non-administrators.

    Monday, June 20, 2011 1:18 PM
  • User-1672167363 posted

    So have you tried using Process Monitor from System Internals to

    verify the problem?

    Maybe you could check this http://www.iislogs.com/articles/processmonitorw3wp/ guide

    and get Process Monitor and look for the Account(s) Users having issues?

    Martin

     

    Monday, June 20, 2011 3:13 PM
  • User-2048372337 posted

    The problem is that it ONLY happens on the production site, and therefore my users are constantly disrupted. I haven't been able to duplicate this in a test or dev enviroment.

    Monday, June 20, 2011 3:26 PM
  • User-1672167363 posted

    Ok.

    Do you have logs from php_errors.log or IIS Server logs?

     Maybe you could collect the IIS Server logs or php_error.logs and using Log Parser

    filter for failures and a pattern ?

    Then using the logs and pattern simulate test on the dev or test site?

    Martin

     

     

    Monday, June 20, 2011 3:45 PM
  • User-2048372337 posted

    Ok, was able to duplicate on our failover server. The HTTP 500 errors are not generating an error in the php_error log at all. I was able to get the specific error, and yes, it is the same problem:

     

    PHP Fatal error: session_start(): Failed to initialize storage module: wincache (path: C:\inetpub\temp\sessions) in C:\inetpub\wwwroot\library\common.php on line 30

    Tuesday, June 21, 2011 10:08 AM
  • User-2048372337 posted

    The w3wp.exe process doesn't access the sessions directory, the php-cgi.exe does. No errors though:

    9:15:49.2279590 AM php-cgi.exe 5360 CreateFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, Impersonating: PRIDEDALLAS\test, OpenResult: Opened
    9:15:49.2280171 AM php-cgi.exe 5360 CreateFileMapping C:\inetpub\temp\sessions\wincache_session_1_608445.tmp FILE LOCKED WITH WRITERS SyncType: SyncTypeCreateSection, PageProtection:
    9:15:49.2280391 AM php-cgi.exe 5360 QueryStandardInformationFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS AllocationSize: 67,108,864, EndOfFile: 67,108,864, NumberOfLinks: 1, DeletePending: False, Directory: False
    9:15:49.2280809 AM php-cgi.exe 5360 CreateFileMapping C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS SyncType: SyncTypeOther
    9:15:49.2281313 AM php-cgi.exe 5360 CloseFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS 
    9:17:38.4946052 AM explorer.exe 3480 RegOpenKey HKLM\Software\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS Desired Access: Read
    9:17:38.4946368 AM explorer.exe 3480 RegQueryValue HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions\MachineThrottling NAME NOT FOUND Length: 24
    9:17:38.4946652 AM explorer.exe 3480 RegCloseKey HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS 
    9:17:38.4946940 AM explorer.exe 3480 RegOpenKey HKLM\Software\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS Desired Access: Read
    9:17:38.4947228 AM explorer.exe 3480 RegQueryValue HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions\GlobalSession NAME NOT FOUND Length: 24
    9:17:38.4947501 AM explorer.exe 3480 RegCloseKey HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS 
    9:17:46.6523514 AM explorer.exe 4860 RegOpenKey HKLM\Software\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS Desired Access: Read
    9:17:46.6523817 AM explorer.exe 4860 RegQueryValue HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions\MachineThrottling NAME NOT FOUND Length: 24
    9:17:46.6524085 AM explorer.exe 4860 RegCloseKey HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS 
    9:17:46.6524359 AM explorer.exe 4860 RegOpenKey HKLM\Software\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS Desired Access: Read
    9:17:46.6524633 AM explorer.exe 4860 RegQueryValue HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions\GlobalSession NAME NOT FOUND Length: 24
    9:17:46.6524892 AM explorer.exe 4860 RegCloseKey HKLM\SOFTWARE\Microsoft\SQMClient\Windows\DisabledSessions SUCCESS 
    9:17:51.9876717 AM explorer.exe 4860 RegQueryValue HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\SessionStartTimeDefaultDeltaSecs NAME NOT FOUND Length: 144
    9:18:14.7836718 AM php-cgi.exe 5360 CreateFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, Impersonating: PRIDEDALLAS\test, OpenResult: Opened
    9:18:14.7837275 AM php-cgi.exe 5360 CreateFileMapping C:\inetpub\temp\sessions\wincache_session_1_608445.tmp FILE LOCKED WITH WRITERS SyncType: SyncTypeCreateSection, PageProtection:
    9:18:14.7837491 AM php-cgi.exe 5360 QueryStandardInformationFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS AllocationSize: 67,108,864, EndOfFile: 67,108,864, NumberOfLinks: 1, DeletePending: False, Directory: False
    9:18:14.7837923 AM php-cgi.exe 5360 CreateFileMapping C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS SyncType: SyncTypeOther
    9:18:14.7838422 AM php-cgi.exe 5360 CloseFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS 
    9:19:56.6266268 AM php-cgi.exe 5360 CreateFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, Impersonating: PRIDEDALLAS\test, OpenResult: Opened
    9:19:56.6266834 AM php-cgi.exe 5360 CreateFileMapping C:\inetpub\temp\sessions\wincache_session_1_608445.tmp FILE LOCKED WITH WRITERS SyncType: SyncTypeCreateSection, PageProtection:
    9:19:56.6267103 AM php-cgi.exe 5360 QueryStandardInformationFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS AllocationSize: 67,108,864, EndOfFile: 67,108,864, NumberOfLinks: 1, DeletePending: False, Directory: False
    9:19:56.6267539 AM php-cgi.exe 5360 CreateFileMapping C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS SyncType: SyncTypeOther
    9:19:56.6268039 AM php-cgi.exe 5360 CloseFile C:\inetpub\temp\sessions\wincache_session_1_608445.tmp SUCCESS 

     

    Tuesday, June 21, 2011 10:15 AM
  • User-2048372337 posted

    Suddenly, I cannot get it to fail on my test server....

    Tuesday, June 21, 2011 10:36 AM
  • User-2048372337 posted

    Got it to fail again. I think I found a pattern. It appears to work like this. If and Administrator opens a session first (creates the .tmp file), then it will fail for Users. Right now, they have Modify through Write....maybe they need Full Control??? Not sure why, but I'm going to test that theory.

    Tuesday, June 21, 2011 10:39 AM
  • User-2048372337 posted

    Yes, that was the case. I tested it several times. When I had the user Test create the session file (be the first one to use it), no failures, when I had an Administrator do the same, failure for Test user only. So, I changed the permissions on the sessions folder to give Users Full Control - NO FAILURE (so far.)

    Tuesday, June 21, 2011 11:20 AM
  • User-2048372337 posted

    Strange, it worked pefect for my test usr on my test server, and then fine for my test user at first when we turned it on in production, and then failed for another user, then failed for my test user.

    Tuesday, June 21, 2011 11:59 AM
  • User-1672167363 posted

    Hi,

    Ok.

    worked pefect for my test usr on my test server,

     and then fine for my test user at first when we turned it on in production

    then failed for my test user.

     

    Martin

     

    Tuesday, June 21, 2011 1:03 PM
  • User-2048372337 posted

    They had write before and it did not work. Only after Full Control did it work at all, and again, fails after being on (not for very long either.)

     I really can't go any further. Too much interuption for my users and I can't duplicate the failure on a test site (no errors in either logs for this failure.) I guess we just can't use it. Too bad.

    Tuesday, June 21, 2011 1:07 PM
  • User791823492 posted

     Hello,

     I don't know if you ever got this resolved but I was having the exact same issue and wanted to share what worked for me.  I was pulling my hair out with this because it was hard to reproduce and nothing showed up in the logs as to the cause of the error.  I finally figured out that it was caused by McAfee AV OnAccess scanner locking up the temp file in the php sessions directory.  Once I added the php sessions directory to the exclusions list for McAfee OnAccess scanning, the problem disappeared. 

    I'm not sure if this will help you any, but I wanted to share just in case.

    Good luck.

    Sunday, January 29, 2012 3:30 PM
  • User-2048372337 posted

    Hmm, don't think I tried that. I'll give it a shot (we were on eTrust back then, but now are using AVG.)

    Sunday, January 29, 2012 3:39 PM
  • User791823492 posted

     Well...scrap that idea.  This error disappeared right after disabling McAfee scanning, but after a week of no errors it is back.  This is really quite a pain.

    Tuesday, January 31, 2012 12:30 AM
  • User-917625502 posted

     Yes this is not the issue, our server had no AV systems on it and we had this problem.

    Tuesday, January 31, 2012 12:34 AM