views:

234

answers:

2

We are using the ASP.NET 1.1 version of dtSearch and are having an issue that is affecting our users authenticating with Active Directory (AD). This issue also is affecting another custom, in-house .NET 1.1 DLL in the same websites.

When a standard user hits the search after a period of inactivity the site will give the error below. After a server administrator hits the search page it works - and here's the strange part - the end user can then hit the search page and run a query fine. Do you know what could be causing this error?

We are using dtSearch 7.61 (Build 7769) and the .NET 1.1 dll. The index and web site are on the same server.

As for the custom DLL, the same thing happens. An admin must hit the web page before an end user.

The DLLs are local to the site - they are not in the GAC. We are on Windows Server 2003. Users authenticate with AD.

Thanks for your help,

Dirk

-----Original Message----- Sent: Wednesday, July 22, 2009 8:13 AM Subject: Extranet Unexpect Error

An error has occured while user is accessing the extranet. Details follow:

*App Name: xxxxappnamexxxx

*Error Time: 7/22/2009 8:12:54 AM

*Error Type: System.IO.FileLoadException

*Error Message: Access is denied: 'dtSearchNetApi'.

*Stack Trace: at SearchControls.SearchDAL.GetIndexId(String indexedDocumentPath) at SearchControls.SearchDAL.GetAvailableDocuments(String areaName, Int32 crossArea, Int32 active, String categoryID) at SearchControls.SearchDAL.Search(String areaName, Int32 crossArea, Int32 active, String categoryID, String strCriteria, Int32& TotalRowCount) at SearchControls.SearchResults.SearchResult() at SearchControls.SearchResults.Render(HtmlTextWriter output) at System.Web.UI.Control.RenderControl(HtmlTextWriter writer) at System.Web.UI.Control.RenderChildren(HtmlTextWriter writer) at System.Web.UI.HtmlControls.HtmlForm.RenderChildren(HtmlTextWriter writer) at System.Web.UI.HtmlControls.HtmlForm.Render(HtmlTextWriter output) at System.Web.UI.Control.RenderControl(HtmlTextWriter writer) at System.Web.UI.Control.RenderChildren(HtmlTextWriter writer) at System.Web.UI.Control.Render(HtmlTextWriter writer) at System.Web.UI.Control.RenderControl(HtmlTextWriter writer) at System.Web.UI.Page.ProcessRequestMain()

*URL Variables: http://xxxxxsitenamexxxxxx/Search.aspx?areaName=matter&crossArea=0&active=0&categoryid=b9de78ae-3085-4ee2-9372-9150b7289455&sCriteria=first amendment

*Form Variables:

*Error Source: SearchControls

*Error TargetSite: Int32 GetIndexId(System.String)

*Login User: xxxdomainxxx\xxxxxusernamexxxxxx

*User IP: xxxxxxxxxxxxx

*Template Path: /Search.aspx

+1  A: 

Are you running anti-virus or any sort of search indexer? Some such applications have been known to hold on to a DLL.

John Saunders
Indexing service is not on. The anti-virus is set to not run full-scans - just to do activity monitoring. In any case the asp.net temp file directory is excluded from the anti-virus watch. We are taking steps to exclude the actual website files - this includes the DLLs in question.
dirq
Good. Also, are you up to date with your .NET 1.1 patches? It's so old that you'd at least do better having the latest old stuff.
John Saunders
I can't really upgrade the .NET 1.1 stuff. It's production.Anyway, I also found that the .NET temp directory was OK'd for indexing. Even though indexing service is turned off for this server, I still removed that ability. Maybe this will help.
dirq
+1  A: 

Have you tried running Process Monitor to see the thread identity of the assembly being accessed? When using Windows Authentication if you have impersonation on it will try to access resources as the actual user. If your file system does not have the appropriate permissions setup it could cause an access denied.

Just a though.... While I can't say for sure I suspect there may be a process calling Assembly.Load and it is unable to hit the assembly as the user. When the admin accesses it the asembly is loaded into the AppDomain and cached for other users.

Colin Bowern
I found, using Process Monitor, that the impersonated user did not have access to the asp.net temp folder - C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\ - we gave the user groups read and write access and it's working now.
dirq