Re: A Very Troubled Application...

Hi Mike,

Because you use COM-components, and because you don't trust them, creating a 
separate AppDomain (.NET's notion of a process) is less robust than a 
separate process. A failing COM-component is able to corrupt the memory that 
is used by the .Net VM. Even memory that is used by a different AppDomain.

Yes, I propose to create an application wrapper, that does nothing more than 
spawning your original application, and wait for it. If it ends (by a 
crash), just spawn it again.
To discriminate between a crash and a normal end, return a special non-zero 
returncode from your original application. For instance 123. Of course both 
the wrapper and the original app should agree on this value.

The fact that your primary application can be spawned only once doesn't feel 
like a problem: the application wrapper will only spawn a new one if the 
previous instance failed...

/Peter



----- Original Message ----- 
From: "Mike Andrews" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 09, 2009 7:08 PM
Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application...


> Hi Peter,
>
> Thanks for the reply.
>
> Right now I'm creating a separate AppDomain and instantiating my Wrapper
> object (which wraps all of the COM method calls because any method call 
> can
> cause a COM exception) inside that AppDomain.  Another problem with this
> process is that it only allows one instance at a time (by reading the
> process list and seeing if it's already there and if it is it throws up
> another dialog).
>
> I'm not sure what you mean by creating a worker-process.  Would I create 
> an
> application wrapper that then spawns the primary application?  If the
> primary application fails would the worker-process fail or would I just
> attempt to restart it?
>
> Thanks,
> Mike
>
> On Tue, Jun 9, 2009 at 12:00 PM, Peter vd Weerd <[email protected]> wrote:
>
>> Mike,
>>
>> In general: if you have access violations caused by COM-components, its 
>> not
>> a good idea to recover from that.
>> If you can isolate the complete application to a kind of a 
>> worker-process,
>> you write a controller-program that starts this worker-process, and if it
>> fails, just start a new one.
>>
>> Windows is very good in recovering from crashed processes: all resources
>> are freed. So, when the controller process fires up a new worker-process 
>> its
>> a brand new one with clean memory, a clean .NET virtual machine, etc.
>>
>> /Peter
>>
>>
>> ----- Original Message ----- From: "Mike Andrews" <
>> [email protected]>
>> To: <[email protected]>
>> Sent: Tuesday, June 09, 2009 6:06 PM
>> Subject: [ADVANCED-DOTNET] A Very Troubled Application...
>>
>>
>>   I have a very troubled application (not mine but a 3rd party) that 
>> likes
>>> to
>>> fail with various Unhandled exceptions (memory access and others) when
>>> certain files are loaded (I have no idea of the reason).  Sometimes
>>> loading
>>> a file causes a COM exception to occur (no one knows why and it's very
>>> unlikely that the manufacturer will ever fix it).  This causes the 
>>> entire
>>> application to crash (and/or provide some other unpredictable behavior).
>>> This does not occur most of the time but only occasionally.  However I
>>> must
>>> account for these eventualities as this process will be running on
>>> multiple
>>> servers and I need it the most stable I can get it.
>>>
>>> What I have been doing is looking for the process in the process list 
>>> and
>>> then killing it.  That works most of the time but when one of those
>>> dialogs
>>> is thrown up asking you to click OK it really messes things up.  I've
>>> started looking for the dialog, but the time when the dialog appears
>>> varies
>>> so any predictability is out.
>>>
>>> What I need to know is if it's possible to attach a hook (or some other
>>> such
>>> mechanism) to the window to intercept any unhandled win32 exceptions
>>> similar
>>> to the capability available in the .NET framework.  I'm at my wit's end
>>> here
>>> on this one.  I need to create something stable enough so I can recover 
>>> on
>>> the server and continue.
>>>
>>> Any help or information would be most appreciated.
>>>
>>> Thanks,
>>> Mike
>>>
>>> ===================================
>>> View archives and manage your subscription(s) at
>>> http://peach.ease.lsoft.com/archives
>>>
>>>
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>
> ===================================
> View archives and manage your subscription(s) at 
> http://peach.ease.lsoft.com/archives
> 

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives