2

I'm using the Windows Search API from C# (OleDB access) to retrieve all the index entries on a local machine (Windows 8.1) search index using the following C# code:

string query = @"SELECT System.ItemNameDisplay,SYSTEM.ITEMURL,System.DateModified, System.ItemName, System.Search.AutoSummary,System.Search.GatherTime FROM SystemIndex";

query = query + "WHERE System.Search.GatherTime > '" + LastRunTime.ToString("yyyy-MM-dd h:mm:ss") + "' Order by System.Search.GatherTime Desc";

string connectionString = "Provider=Search.CollatorDSO;ExtendedProperties=\"Application=Windows\"";

OleDbConnection connection = new OleDbConnection(connectionString);
connection.Open();
OleDbCommand command;          
command = new OleDbCommand(query, connection);
Cursor.Current = Cursors.WaitCursor;         
reader = command.ExecuteReader();
int iResults = 0;
int iSummaries = 0;
string sDate = "";
string sText = "";
string sFile = "";

while (reader.Read())
{
    try
    {
        sText = reader.GetValue(4).ToString();
        sFile = reader.GetString(1);
        sDate = reader.GetDateTime(5).ToString();
        Debug.Print(iResults + " " + sFile + " " + sDate);
        //if (sText != "")  { Debug.Print(sText); iSummaries++; }
    }
    catch (Exception Ex)
    {
        MessageBox.Show(Ex.Message);
    }
    iResults++;
}

I find that that the code crashes non-reproducibly on the While(Reader.Read()) line with the error IErrorInfo.GetDescription failed with E_FAIL(0x80004005). The loop processes about 55,000 of the 76,080 entries. If I comment out sText = reader.GetValue(4).ToString(); then the loop runs much faster, as the Autosummary field is about 1000 characters and is present for most of the entries. No crash occurs in this case . If I set a breakpoint in the loop and step through one entry at a time, the crash occurs much sooner, making me think that it is a timing problem. Has anyone had similar problems with programmatic access to search indexes and found a workaround?

Community
  • 1
  • 1
SimonKravis
  • 553
  • 1
  • 3
  • 24
  • The underlying issue is that the component that is supposed to tell you what went wrong, IErrorInfo, failed itself when the CLR tried to obtain the reason for the failure. So you have no idea what went wrong. Nor do we. Try another machine. – Hans Passant Sep 10 '14 at 11:12
  • The error always occurs 30 secs after creating the connection - this is why the failure occurs after a smaller number of loops if I step through and why the crash point is variable. Any clues from this? – SimonKravis Sep 10 '14 at 13:15
  • No, a dbase operation failing is of course entirely normal. Including and not limited to a connection timeout. It is the next thing that goes wrong, finding out what went wrong and generating a proper exception for it. You will have to get your machine stable again. – Hans Passant Sep 10 '14 at 13:19
  • Same error appears on a different machine (Windows 7). I think the lack of proper error reporting is specific to the MS Search API – SimonKravis Sep 15 '14 at 00:27
  • In my case the error occurred because the "Window Search" service was disabled. I enabled it to "Automatic (Delayed Start)", then started it and after that, the error was gone. – Uwe Keim Jun 07 '20 at 11:02

1 Answers1

0

Set CommandTimeout to 0 after defining the OLEdb command with the query and this seems to have fixed the problem.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
SimonKravis
  • 553
  • 1
  • 3
  • 24