We are experiencing problems with what I believe to be a program that is part of the Rhythmyx system, cqindex.exe in the \Rhythmyx\sys_search\rware\bin folder. Until we added it to an exclusion list, it was being prevented from running by Window’s Data Execution Prevention system (DEP.)
The following is the analysis of our IT Support Manager:
The error was generated because the DEP (data execution prevention) protection mechanism in Windows detected that the cqindex program was trying to run code from its data area in memory. This can happen because of poorly written code, but is also the main trick that viruses and malware use to hack into a machine (ie. hide code in areas marked for data and then get the cpu to try and run it).
So, the real answer is to go back to the developers, report the fault to them (especially if it’s a re-occurring one) and ask them to check and rewrite the offending parts. It’s NOT good practice to disable the DEP protection features as the server would then be very vulnerable to such attacks.
You may or may not agree with that but I thought I should report it to you.
We have set up an exclusion for cqindex.exe in the DEP control panel. But now we cannot search for items by Content ID - it causes the web browser to hang. Do I need to start a full re-index or something?
I think I can answer my own question regarding whether cqindex.exe runs continuously or periodically. It seems every time you tell Rhythmyx to re-index a content type, it starts a copy of cqindex.exe. They all sit there, each taking up about 10-12 MB, only one actually doing something at any one time. And there are lots of other cq*.exe programs. I cannot find any documentation on this subject.
All of these cq*.exe’s are in the retrievalware folder, meaning they are part of the embedded Convera search. We replaced the embedded search Convera in version 6.6 with Lucene.
In the mean time, engineering is looking into what is the purpose of these cq executable and if they are required.
The program does run successfully with DEP enabled (that’s how we run it here,) so I don’t understand why it happens to be failing for you.
An instance of cqindex is started for each content type (parent and complex child) being indexed (if one is not already running for that type.) It auto exits after ~1hr of no activity on that type.
Thanks for the info. All the cqindex.exe processes do indeed seem to have disappeared overnight. And searches in the Content Editor and when filling slots do now appear to now be working again, so presumably they did their job rather than timing out.
We are still left with six cqquery.exe processes, each using just under 23,000 K of memory, six cqshed.exe processes, each using just over 4,000 K of memory, six cqserv.exe processes, each using around 16,000 K of memory, and one cqxref.exe process. Are these perhaps left over from failed attempts at searching yesterday? Should I kill them?
Regarding DEP, we run Windows Server 2003 SP2. Is it possible the DEP security is tighter on that than on what you run? Or configured differently.
There is a cqquery and cqserv for each set of 10 search libraries (there is a library for each parent content type and each complex child in a content type.) There is a cqsched for each cqquery/cqserv pair.
I am also running Server 2003 SP2. My DEP is OPTOUT w/ no exclusions. Has this behavior always been present on this system or have you updated recently? I’m wondering if the error is being caused by the data being sent to the index? Do all content types exhibit the problem?
Thanks again for the info. BTW, this sort of thing, while maybe not part of the Rhythmyx system, depending on your point of view, would be useful if included in a troubleshooting help document (if you are still working to improve 6.5.2 documentation now that 6.6 is released.)
We have had problems with search, off and on, never something we could really pin down, since we started adding real content. But the first time I saw a DEP message was this week. It could be a coincidence, but it occurred after I had to manually shutdown and restart the server, after it had failed to shutdown the night before as part of a scheduled shutdown we do twice a week in order to create copies of our systems for testing.