Re: A Very Troubled Application...

Right, codesegments are shared between processes. But this is done using the 
memorymapped segments I wrote about earlier. These segments are use-counted, 
but on a handle basis. Since the system does a cleanup (close) on all 
handles, the memorymap will be freed (after the last using handle has been 
closed), and therefore the DLL...

I think you are referring to Win95 or so...
I cannot quickly find a reference on this part, but I encourage you to peek 
around using process explorer from sysinternals.
If you don;t trust the cleanup, write an application that loads a dll a lot 
of times, and than kill the process from process explorer. You will see that 
also the loaded DLL is gone.

/P

----- Original Message ----- 
From: "Adam Tuliper" <[email protected]>
To: <[email protected]>
Sent: Wednesday, June 10, 2009 6:22 PM
Subject: Re: [ADVANCED-DOTNET] A Very Troubled Application...


> we had to do the same hacks for word.. using it as server side doc
> generation before good pdf components were available to us and I recall 
> word
> would fail after a while. that goodness we've come a long way  : )
>
> For dlls being cleaned at termination time.. library code segments are
> shared between processes (that reference the same lib). So there is only 
> one
> code section in memory (unless specifically designated otherwise I 
> believe).
> When LoadLibrary is called, ref count is incremented. So when a process
> crashes.. how does the system know what to decrement counts for? I don't
> believe it does.. and hence a potential memory issue with crashed
> appliations leaving resources around.  If I'm not 100% correct on this.. I
> would like to know a reference to how the system cleans up.. Id be curious
> of the inner workings, this is all from rusty memory.
>
>
>
>
>
> On Wed, Jun 10, 2009 at 2:01 AM, Peter vd Weerd <[email protected]> wrote:
>
>> 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
>>
>
> ===================================
> 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