>>I vaguely recall discussing this a long time ago. Try giving the application a unique GUID property on startup for logging purposes. That way, if the error is related to a recycle in progress, you can at least identify whether the exception occurred in the old or the new instance.
>
>Ok, I got the situation again. With the new log, I was able to confirm that this is happening at the same time a new version was in effect. So, basically, I had an error telling me that an object was not found. This is in regards to an object tied to App.oApp which is the shared object. But, at the same second, a new version was just uploaded and was initiated. So, it seems a shared object will be affected during that transition. So, I have to say, based on this scenario, I have some doubts that a shared object wouldn't be affected when a new instance is being created.

I'm almost 100% sure that the scope of a static (VB Shared) class is confined to the application domain. I can't find anything that suggests otherwise and, logically, if that were not the case then programming with it would be a nightmare. C# documentation actually says that, under the hood, a static class is just a regular class with only static methods and a private constructor - i.e. all the compiler is really doing when you declare a class as static is preventing instantiation.

From the above, it appears that the exception you are getting is thrown by the existing application whilst the new instance is being constructed rather than the other way around. Don't know whether it is relevant but what, exactly, is (or should be) the object that is not found and where and when would it normally be instantiated ?