Sounds quite workable and we do similar things here too. The problem in this case is that the issue is some sort of file encoding issue so that AFAIK the error is occurring at the OS/ASP.NET level, not the application level. I don't think this sort of thing will be trapable.

Bill

>I have written a piece of code that sets error object to a session variable when something happens. CustomError is set to "On" with defaultRedirect set to a none-existing file captured by a httpHandler in web.config, pointing it to a custom class. This class grabs the error object from session and can then perform a desired operation, like send you an email, or as in my case generate an xml file with all error, client and browser info for me to review. Finally, it redirects to a custom, friendly error page.
>
>For me, this works quite nicely and it only took a few hours to write.
>
>>This was to be a consideration at some point but we believed it had to do with file encoding/corruption issues so we tried some different things.
>>
>>Except for some curious anomalies all is working at this point.
>>
>>Bill
>>
>>>I suppose it would be an idea to set customErrors=Off in web.config on production to get a better idea of the error occuring.
>>>
>>>
>>>>Anonymous access, no impersonation. We have only seen the generic ASP.NET "friendly" message at this point.
>>>>
>>>>Looks like it has to do with file corruption of some sort, possibly due to VSS. Unless a "fix" can be found, the HTML portion of the file will probably havce to be recreated.
>>>>
>>>>>Are you doing any impersonation or hardwired username passwords? What is the error message? Is it a generic error message? Do you allow detailed errors to the client?
>>>>>
>>>>>-R!