Windows Search will not start

[Guest]

Help! I killed Windows Search.

I had a folder of ripped music CDs on a hard drive, not my system/boot
drive, on my PC. I created this folder manually a couple months ago. Today,
I tried to delete the folder but got an error that the folder "Windows" could
not be removed because it was in use by another program.

Odd, I thought. I browsed through the music folder and found a folder named
"Search" which, a couple levels deeper, held the "Windows" folder. No matter
what, I couldn't delete the Search folder or the music folder that I had
created. Well, no problem. I stopped the Windows Search service and then
was able to delete the folder.

Now, some may say, "Why are you going around on your PC deleting folders
willy-nilly?" But keep in mind that the music folder is one I created. Even
if some Windows process created this search folder underneath my folder,
which is obviously what happened - because I sure didn't do anything
specifically to cause it to be there, then it should create it again or
ignore its absense.

Well, no such luck. I went back to Services to start the Windows Search
service and now it complains with "Error 3. The system cannot find the path
specified."

Ok, next step then is to find where the path is "specified" and change the
location. I found the Windows Search\Preferences\DataDictionary value in the
registry and changed the value to F:\Search\Data instead of
F:\Music\Search\Data. Then I created the F:\Search\Data folder.

Try again to start the Windows Search service and I get the same problem.

So I start the Indexing Options control panel to set the location of the
search. But the Modify and Advanced buttons are disabled and the caption
says that the Search Service is not running.

So, I can't fix the search service because it is not running and I can't run
it because it is not fixed. Sounds like a very poorly designed service to
me. Not self healing at all and not repairable at all.

Any help or suggestions would be greatly appreciated.

Thanks,

Dale

 

[DP]

A repair installation of Windows, maybe?

System Restore doesn't help?

 

[Guest]

Both good suggestions and I appreciate them. At your suggestion, I tried a
restore point. It did not help.

While Vista doesn't support repair installations, one option is to do an
upgrade installation but I am hoping to avoid that - too much risk.

Certainly there is a way to configure or start the Windows Search service
when the search database is unreadable for any reason; whether by user error
or any other reason. What if I simply removed the drive since it is the 3rd
hard drive on my system? What if the drive failed? For whatever reason,
data files become unavailable. Could you imagine if Word would not run
simply because the last opened document was no longer availalbe? That's
basically what is happening here.

Any more suggestions?

Thanks,

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

A repair installation of Windows, maybe?

System Restore doesn't help?

 

[Guest]

Oh, one more piece that may trigger an idea. The error changed after the
system restore. Now I get an error that says to check the System Event Log.
The check of the event log shows the following:

"The Windows Search service terminated with service-specific error
2147749155 (0x80040D23)."

The help link refers me to a whole list of service errors with that error
code for a whole bunch of other Windows components, both new and old, but
nothing about the Search Service.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

A repair installation of Windows, maybe?

System Restore doesn't help?

 

[Guest]

Ok, with DP's suggestion of a system restore, I was led to the solution.
Searching on the new error, I found this thread:

http://forums.microsoft.com/msdn/sh...03&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=0

Buried in that are the instructions for how to recover two text files that
were missing after I recreated the folder structure.

Whew! I am very glad to have it fixed - not that losing it was that
terrible - but I have to say, it still seems like a very poor design that
losing two text files would cause the search service to become completely
unusable. In fact, in the referenced thread, one Microsoft employee actually
had to email the two missing files to the OP. Later, it turns out that the
two files exist elsewhere on your PC. If the search service was able to copy
those two text files in the initial configuration from their source to the
configured search data folder, why then, when they're later found to be
missing, can't the search service get them from the source again?

Bad Job, Microsoft Search team.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

A repair installation of Windows, maybe?

System Restore doesn't help?

 

[Lang Murphy]

Ok, with DP's suggestion of a system restore, I was led to the solution.
Searching on the new error, I found this thread:

http://forums.microsoft.com/msdn/sh...03&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=0

Buried in that are the instructions for how to recover two text files that
were missing after I recreated the folder structure.

Whew! I am very glad to have it fixed - not that losing it was that
terrible - but I have to say, it still seems like a very poor design that
losing two text files would cause the search service to become completely
unusable. In fact, in the referenced thread, one Microsoft employee
actually
had to email the two missing files to the OP. Later, it turns out that
the
two files exist elsewhere on your PC. If the search service was able to
copy
those two text files in the initial configuration from their source to the
configured search data folder, why then, when they're later found to be
missing, can't the search service get them from the source again?

Bad Job, Microsoft Search team.

Dale

<snip>


That's good info.

That said, I'd still be interesting in knowing the root cause for -that- dir
and -those- files going missing. (Linux and Unix seats use nothing -but-
text files for configuration; no registry whatsoever. Whack the wrong
file and kiss your system goodbye.) I can almost guarantee they didn't go
missing on their own...

Lang

 

[Guest]

That's good info.

That said, I'd still be interesting in knowing the root cause for -that- dir
and -those- files going missing. (Linux and Unix seats use nothing -but-
text files for configuration; no registry whatsoever. Whack the wrong
file and kiss your system goodbye.) I can almost guarantee they didn't go
missing on their own...

Lang

As I said earlier, the root cause of them going missing was me deleting
them. I felt it was safe to delete them because they were in a data folder I
had created myself and not in a system-created folder. Had the search files
been in a system folder or probably in any folder, such as all users
application data, that I did not specifically create myself, I would not have
touched them unless it was specifically my intention to break the search
service.

If the system added the files to my folder once, it should have been able to
recreate them where needed. When the system creates files inside of a folder
I created myself, then I expect those files to be folder specific - sort of
like folder.ini or thumbs.db - and would not expect them to be system
critical files that break services on the entire PC for me and all users.

In the case of configuration files in a Unix/Linux system, those files are
created in the installation. These Windows Search Service files were not put
in my F:\Music\ folder during installation because neither F:\ nor F:\Music\
existed when Vista was installed. The F drive was created well after
installation and so the Windows Search data files were created well after
installation and, therefore, should have been able to be recreated again. I
can only guess that the data files ended up in F:\Music\ because I probably
enabled search from the Explorer Information Bar while doing a search of
F:\Music\ without having previously enabled the Windows Search service. I am
certain that I never specifically chose that location for the data files by
using the Indexing Options control panel applet.

So, the Search Service, for whatever reason, decided to make F:\Music\ the
data folder for Windows Search globally on my PC. It was able to create
those files or copy them from the same source identified in the link in my
previous post. If it could do so once, it should have been able to do so
again.

If it couldn't do it again automatically, the search service should have had
an option to reset/rebuild the Windows Search database and functionality from
within the Indexing Options control panel.

And had I written the Windows Search service, it would have that ability. I
can say that with confidence since just last month I wrote a Windows Service
application that calls a console application. The console application uses
an XML configuration file. This application is deployed on Merchant Marine
vessels. IT support is difficult to obtain and is expensive in the middle of
the ocean. The application, therefore, has the ability to create a
configuration file with a basic working set of options in case the original
configuration file becomes unusable for any reason.


Dale

 

[Lang Murphy]

That's good info.

That said, I'd still be interesting in knowing the root cause for -that-
dir
and -those- files going missing. (Linux and Unix seats use nothing -but-
text files for configuration; no registry whatsoever. Whack the wrong
file and kiss your system goodbye.) I can almost guarantee they didn't
go
missing on their own...

Lang

As I said earlier, the root cause of them going missing was me deleting
them. I felt it was safe to delete them because they were in a data
folder I
had created myself and not in a system-created folder. Had the search
files
been in a system folder or probably in any folder, such as all users
application data, that I did not specifically create myself, I would not
have
touched them unless it was specifically my intention to break the search
service.

If the system added the files to my folder once, it should have been able
to
recreate them where needed. When the system creates files inside of a
folder
I created myself, then I expect those files to be folder specific - sort
of
like folder.ini or thumbs.db - and would not expect them to be system
critical files that break services on the entire PC for me and all users.

In the case of configuration files in a Unix/Linux system, those files are
created in the installation. These Windows Search Service files were not
put
in my F:\Music\ folder during installation because neither F:\ nor
F:\Music\
existed when Vista was installed. The F drive was created well after
installation and so the Windows Search data files were created well after
installation and, therefore, should have been able to be recreated again.
I
can only guess that the data files ended up in F:\Music\ because I
probably
enabled search from the Explorer Information Bar while doing a search of
F:\Music\ without having previously enabled the Windows Search service. I
am
certain that I never specifically chose that location for the data files
by
using the Indexing Options control panel applet.

So, the Search Service, for whatever reason, decided to make F:\Music\ the
data folder for Windows Search globally on my PC. It was able to create
those files or copy them from the same source identified in the link in my
previous post. If it could do so once, it should have been able to do so
again.

If it couldn't do it again automatically, the search service should have
had
an option to reset/rebuild the Windows Search database and functionality
from
within the Indexing Options control panel.

And had I written the Windows Search service, it would have that ability.
I
can say that with confidence since just last month I wrote a Windows
Service
application that calls a console application. The console application
uses
an XML configuration file. This application is deployed on Merchant
Marine
vessels. IT support is difficult to obtain and is expensive in the middle
of
the ocean. The application, therefore, has the ability to create a
configuration file with a basic working set of options in case the
original
configuration file becomes unusable for any reason.


Dale

Dale,

OK... missed that original point, my bad.

Out of curiosity, what language did you write your app in? I work on a
project for the Navy and am involved with supporting deployed units so I do
very much the same kind of thing you do, apparently.

Lang

 

[Guest]

I spent 10 years in the Navy and then many more years contracting to the
Navy. One thing you learn about in dealing with anything shipboard is the
importance of reliability and maintainability. Self-healing apps are
critical.

I remember one time even opening the can on a TO-5 transister package and
resoldering hair-like leads back from the silicone substrate to the package
when the nearest replacement for a critical system was thousands of miles and
many days away.

Most of the work I do is in C# these days but an occaisional C++ still.


Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

That's good info.

That said, I'd still be interesting in knowing the root cause for -that-
dir
and -those- files going missing. (Linux and Unix seats use nothing -but-
text files for configuration; no registry whatsoever. Whack the wrong
file and kiss your system goodbye.) I can almost guarantee they didn't
go
missing on their own...

Lang

As I said earlier, the root cause of them going missing was me deleting
them. I felt it was safe to delete them because they were in a data
folder I
had created myself and not in a system-created folder. Had the search
files
been in a system folder or probably in any folder, such as all users
application data, that I did not specifically create myself, I would not
have
touched them unless it was specifically my intention to break the search
service.

If the system added the files to my folder once, it should have been able
to
recreate them where needed. When the system creates files inside of a
folder
I created myself, then I expect those files to be folder specific - sort
of
like folder.ini or thumbs.db - and would not expect them to be system
critical files that break services on the entire PC for me and all users.

In the case of configuration files in a Unix/Linux system, those files are
created in the installation. These Windows Search Service files were not
put
in my F:\Music\ folder during installation because neither F:\ nor
F:\Music\
existed when Vista was installed. The F drive was created well after
installation and so the Windows Search data files were created well after
installation and, therefore, should have been able to be recreated again.
I
can only guess that the data files ended up in F:\Music\ because I
probably
enabled search from the Explorer Information Bar while doing a search of
F:\Music\ without having previously enabled the Windows Search service. I
am
certain that I never specifically chose that location for the data files
by
using the Indexing Options control panel applet.

So, the Search Service, for whatever reason, decided to make F:\Music\ the
data folder for Windows Search globally on my PC. It was able to create
those files or copy them from the same source identified in the link in my
previous post. If it could do so once, it should have been able to do so
again.

If it couldn't do it again automatically, the search service should have
had
an option to reset/rebuild the Windows Search database and functionality
from
within the Indexing Options control panel.

And had I written the Windows Search service, it would have that ability.
I
can say that with confidence since just last month I wrote a Windows
Service
application that calls a console application. The console application
uses
an XML configuration file. This application is deployed on Merchant
Marine
vessels. IT support is difficult to obtain and is expensive in the middle
of
the ocean. The application, therefore, has the ability to create a
configuration file with a basic working set of options in case the
original
configuration file becomes unusable for any reason.


Dale

Dale,

OK... missed that original point, my bad.

Out of curiosity, what language did you write your app in? I work on a
project for the Navy and am involved with supporting deployed units so I do
very much the same kind of thing you do, apparently.

Lang

 

[Lang Murphy]

I spent 10 years in the Navy and then many more years contracting to the
Navy. One thing you learn about in dealing with anything shipboard is the
importance of reliability and maintainability. Self-healing apps are
critical.

I remember one time even opening the can on a TO-5 transister package and
resoldering hair-like leads back from the silicone substrate to the
package
when the nearest replacement for a critical system was thousands of miles
and
many days away.

Most of the work I do is in C# these days but an occaisional C++ still.


Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA

:
That's good info.

That said, I'd still be interesting in knowing the root cause
for -that-
dir
and -those- files going missing. (Linux and Unix seats use
nothing -but-
text files for configuration; no registry whatsoever. Whack the wrong
file and kiss your system goodbye.) I can almost guarantee they
didn't
go
missing on their own...

Lang

As I said earlier, the root cause of them going missing was me deleting
them. I felt it was safe to delete them because they were in a data
folder I
had created myself and not in a system-created folder. Had the search
files
been in a system folder or probably in any folder, such as all users
application data, that I did not specifically create myself, I would
not
have
touched them unless it was specifically my intention to break the
search
service.

If the system added the files to my folder once, it should have been
able
to
recreate them where needed. When the system creates files inside of a
folder
I created myself, then I expect those files to be folder specific -
sort
of
like folder.ini or thumbs.db - and would not expect them to be system
critical files that break services on the entire PC for me and all
users.

In the case of configuration files in a Unix/Linux system, those files
are
created in the installation. These Windows Search Service files were
not
put
in my F:\Music\ folder during installation because neither F:\ nor
F:\Music\
existed when Vista was installed. The F drive was created well after
installation and so the Windows Search data files were created well
after
installation and, therefore, should have been able to be recreated
again.
I
can only guess that the data files ended up in F:\Music\ because I
probably
enabled search from the Explorer Information Bar while doing a search
of
F:\Music\ without having previously enabled the Windows Search service.
I
am
certain that I never specifically chose that location for the data
files
by
using the Indexing Options control panel applet.

So, the Search Service, for whatever reason, decided to make F:\Music\
the
data folder for Windows Search globally on my PC. It was able to
create
those files or copy them from the same source identified in the link in
my
previous post. If it could do so once, it should have been able to do
so
again.

If it couldn't do it again automatically, the search service should
have
had
an option to reset/rebuild the Windows Search database and
functionality
from
within the Indexing Options control panel.

And had I written the Windows Search service, it would have that
ability.
I
can say that with confidence since just last month I wrote a Windows
Service
application that calls a console application. The console application
uses
an XML configuration file. This application is deployed on Merchant
Marine
vessels. IT support is difficult to obtain and is expensive in the
middle
of
the ocean. The application, therefore, has the ability to create a
configuration file with a basic working set of options in case the
original
configuration file becomes unusable for any reason.


Dale

Dale,

OK... missed that original point, my bad.

Out of curiosity, what language did you write your app in? I work on a
project for the Navy and am involved with supporting deployed units so I
do
very much the same kind of thing you do, apparently.

Lang

Interesting... thanks for the post. From a civilian's perspective, resupply
does seem to be an issue for deployed units. I guess it's always been, and
will always be, thus.

Lang