none
Crawl Error - Error in the Site Data Web Service. (Exception of type 'System.OutOfMemoryException' was thrown.)

    Question

  • I have a Sharepoint site that includes a WIki library.  Recently searches have stopped returning any hits from the Wiki pages.  (Search hits from documents and discussions are correctly returned.)  When I check the crawl log from Shared Services Admin site, I see the following error every time a crawl is performed:

     

    http://cao.tfn.com/caopedia/wiki%20pages/forms/allpages.aspx

    Error in the Site Data Web Service. (Exception of type 'System.OutOfMemoryException' was thrown.)

     

    The URL above is part of the Wiki library.  When I look at the raw Sharepoint logs, I see the following entries every time a crawl is performed:

     

    11/26/2007 05:01:50.93  mssdmn.exe (0x1F98)                      0x1368 Search Server Common           MS Search Indexing             7hp2 Monitorable EnumerateListFolder fail. error 2147755542, strWebUrl http://cao.tfn.com/Caopedia, strListName {e9acf8e9-f23f-4afd-b8e9-6eaf6b0101db}, strFolder  
    11/26/2007 05:01:50.93  mssdmn.exe (0x1F98)                      0x1368 Search Server Common           PHSts                          0 Monitorable CSTS3RowFilter::EnumLinks: Return error to caller, hr=80042616 - FileBig Smile:\office\source\search\search\gather\protocols\sts3\sts3filt.cxx Line:1431 
    11/26/2007 05:01:50.93  mssdmn.exe (0x1F98)                      0x1368 Search Server Common           PHSts                          0 Monitorable CSTS3RowFilter::HrOnFilterGetChunk: Return error to caller, hr=80042616 - FileBig Smile:\office\source\search\search\gather\protocols\sts3\sts3filt.cxx Line:1609 

     

    I have manually initiated a full crawl, rebooted the machine, the error still occurs and I still cannot search WIki pages.  Does anyone have any suggestions regarding how to debug this further?


    Thanks,

    Gene Osgood

    Tuesday, November 27, 2007 4:15 AM

All replies

  • We are also seeing the exact same problem. Were you able to fix this issue ?

    Also, it does not happen with all the pages folder's but only a few.

    Any help would be greatly appreciated.

     

    Thanks,

    Prashanth

     

    Tuesday, December 04, 2007 9:35 PM
  •  

    I have experienced this problem too.  I am in the process of testing a fix.  A question for you.  Are you on a 32 or 64 bit environment?  If 64 your problem maybe different from what I am seeing.  If 32 you might be experiencing some sort of heap fragmentation on the w3wp worker process on the machine that is being crawled.  Consider recycling the worker processes in your application pool.  I have written about my experience on this issue here:

     

    http://www.ranjanbanerji.com/techtalk/20080109.aspx

     

    Hope it helps.

    Thursday, January 10, 2008 3:33 AM
  • Wow, you've done quite a bit of research on this issue.

     

    Yes, I am in a 32 bit environment.  I have tried recycling application pools as well as rebooting the machine, and the problem still persists.  I've also tried installing a hotfix (at the suggestion of Microsoft support) but no help there.  I will keep looking.


    Thanks for the suggestion.

    Friday, January 11, 2008 10:42 PM
  •  

    Gene,

     

    The main issue behind this error based on analysis of the debug dump files of the w3wp.exe process by Microsoft was that there was heap fragmentation occurring.  If you have large amounts of data in your lists, folders etc and process recycling is not helping then 64 bit may just be your only answer. 

     

    Once we shifted to 64 bit machines the error vanished and the search crawl which used to take 20 hours is now wrapped up in 2 hours.  The 64 bit machine I am using has 8 GB of RAM and I can see the W3WP using up to 4GB on the machine being crawled.  The indexer itself barely gets any stress.  It is the machine/s that get crawled.

     

    Which raises another issue for you if you stay in the 32 bit world with SharePoint 2007.  If your indexer is crawling a machine that your users are using then your users will also experience poor performance and random OutOfMemoryException.  Adjusting the number of worker processes in IIS and their recycle policies is not a sure shot solution.

     

    Microsoft should just 'fess up and say SharePoint 2007 requires 64 bit servers.

    Sunday, January 27, 2008 3:33 AM
  •  

    Last week we ran in the a similar issue with our search engine giving the same error.  After reviewing the results, all of the errors were with lists containing 5000+ items (bad bad bad!).  However, this was a new enviornment that had only been live for approx 2 months and had cataloging the results up until a certain point. 

     

    We noticed that the timer / search services were having issues on the machines and were throwing the following error "Not enough storage is available to process this command".  On our DEV / QA machines we had resolved this by writing some batch jobs to restart some of the services + IIS each night (1-2 minute downtime).   Once we installed the same scripts in production, it resolved our search issue right away. 

     

    For your information, here is what we setup on our Application server that ran Central Admin / Serach, etc..

     

    net stop "Office SharePoint Server Search"

    net start "Office SharePoint Server Search"

    net stop "Windows SharePoint Services Search"

    net start "Windows SharePoint Services Search"

    net stop "Windows SharePoint Services Administration"

    net start "Windows SharePoint Services Administration"

    net stop "Windows SharePoint Services Timer"

    net start "Windows SharePoint Services Timer"

    iisreset /noforce

     

    Hope this helps you out as well!
    Friday, February 22, 2008 9:06 PM
  • I ran into the same problem with a wiki library. Upgrading to Windows 2003 x64 is on our to-do list, but isn't practical in the short term. Restarting services didn't do anything.

    I tried deleting the view where the index was crashing. It still crashed, and with the same view name. Maybe if you delete the view, there is still an implicit one for system use?

    I tried creating a new view called Standard View which was filtered to display nothing. The index no longer crashed, but no articles were indexed. I modified the new Standard View to display only article title and no other data. The index now works correctly. There are only about 1650 articles in the library, so it may become an issue again when that number increases.

    YMMV, but it seems to be working until MS patches it properly.

    Tuesday, January 27, 2009 7:00 PM
  • We are experiencing the same thing, but on more than just the on Library.  More like a couple hundred errors on multiple sites with very few documents.

    32-bit Windows 2003, MOSS 2007
    32-bit Windows 2003, SQL 2000 (soon to be 64-bit SQL 2005)

    Anyone else figure this out?

    Tuesday, June 16, 2009 1:44 PM
  • Hi,

    We have 64-bit machines and I am receiving teh same error:

    Error in the Site Data Web Service - there is a file listed; the strange thing is I can find teh file in the search

    The other error is: The filtering process could not be initialized. Verify that the file extension is a known type and is correct.

    Well, pdf files are in our extension list.  I checked.  I do not know what to do.  And I am unable to resume the crawl.  It is in some sort of permanent pause state.
    Saturday, June 20, 2009 8:16 AM
  • Do you have either an Adobe iFilter or a FoxIT iFilter installed on your machine?
    Wednesday, June 24, 2009 3:55 AM
  • That issue might be connected to security issues in-place.

    Check task manager and check whow many instaces are running for the Search Service.

    One thing to save up some memory is to set the IIS Worker Recycling set to sorter intervals. To recycle the Search Service use the script above, put it in a batch file and create a task to make ir run on regular basis.

    I'm having some Search Service processes stay running and using resources because the do not flush themselves after crawling. I'm regularly Recycling the service manually.
    Friday, June 26, 2009 10:11 AM
  • We were having huge problems with slow server porformance for a while and we ended up doing one thing that really helped a lot. Sometimes wiki pages would take over a minute to load.  For some reason it was wiki's that would get slow first, and most of the time they would be the only thing to get slow.

    In SQL server (we are using 2008 32bit) -> Properties -> Memory, the 'Maximum server memory (in MB)' was set to 2147483647.  I think that translates to 2 petabytes, or something crazy like that.  That is slightly more memory than what we had in our server. 

    We have 3GB right now, so we adjusted that down to 1.5GB to see what would happen.  So far we have not had any real slow downs.  Usually pages load in less than a second, maybe 3 at most.  We do have one list with 45k records in it too, and I don't notice slow downs with that site either.

    This sounds closely related.  I don't know exactly how our crawls were doing at that time though.
    Tuesday, March 02, 2010 10:01 PM
  • Hello Gene,

    We were facing a similiar kind of issue with wiki pages . We managed to solve it by clicking the box that enables the crawler to crawl aspx pages . I am also looking for other scenarios and will let you know soon

    Hope this helps you .

    Regards

    Franklin

    Tuesday, April 27, 2010 2:30 AM
  • Just to add my two cents here, I've been experiencing similar search crawl problems with large lists/document libraries.  My crawl log will show an error such as "Error in the Site Data Web Service. (*** There is an error in XML document (338364, 16).)."  The numbers tend to vary per list. 

    I've found that if I alternate IISRESET and incremental crawls I will usually get better results.  The error is removed and hits on my list or library items start coming into the crawl log.  I usually have to do this a few times before everything looks ok.  It seems that once the items are indexed, I can do additional full or incremental crawls without error.  I've only had to do these steps when I had to reset the crawl content due to some unrelated issues and had to crawl everything fresh.

    RBanerji's post above seems to spot on in this case.  I'm thinking my very large item counts are causing some sort of problem for IIS in loading everything during a crawl.  When I recycle the applications (although I did IISRESET to be thorough) it clears the problem for the time being and I can get some more search items.

    This seems to be quite the problem as I've found a lot of people struggling with it on the 'net.  This workaround has gotten me out of a couple jams, although to be sure it is only a workaround.

    Tuesday, March 29, 2011 12:28 PM