Re: A Very Troubled Application...

When windows terminates a process, all system-resources are cleaned up.
Dll's too. They are loaded in the virtual address space, and the address 
space is removed at termination.
Reference counting on dll's is only within a process. AFAIK there is no 
system-wide refcnt.

Dll's are loaded by creating a named filemapping to this dll. This mapping 
is a normal system resource and will be freed at termination time.

Out of process COM objects are a different story. The process where this 
COM-object lives has nothing to do with the hosting process (as far as the 
system knowns). And it is refcnted.

So if the host process is getting terminated, the only way for the COM 
process to get auto terminated is to do a watchdog check on its host if its 
still alive. There are some watchdog checks in the standard marshalling code 
(hartbeats), but I'm not sure if they are used for terminating the process 
with the COM object. Another question is how big the timeout for this 
watchdog is. So may be you want to restart the COM object before the 
watchdog timed out.

I used my proposed solution (restarting the process after failure) a few 
times in case of untrusted applications, and it worked fine. I can remember 
problems with MSWord (out of process COM) years ago. After failure (the 
process using MSWord died) I killed the MSWord instance too and than 
restarted my application. Ugly, but it worked.
I had more problems there, because word was not designed as a service. Its a 
UI, so it will popup a dialog every now and than. I had to 'answer' those 
dialogs too :-)

/Peter
----- Original Message ----- 
From: "Adam Tuliper" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 09, 2009 10:30 PM
Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application...


>I seem to recall the opposite was true.. Windows isn't very good about
> cleaning up resources (at least in the past) because of the way libraries
> dont get freed because the reference count handling is never executed..
> something along those lines. Although if someone can provide some more
> technical reference on if this is true or not.. Id love to read it.
>
>
>
> On Tue, Jun 9, 2009 at 1: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