Hallo DerOppi!
Das .NET Framework und damit auch die Windows PowerShell arbeiten mit so genannten Managed Speicher.
Hier Sorgt eine Laufzeitkomponente, der "Garbage Collector", dafür das nicht mehr benötigte Objekte weggeräumt werden. Der "Garbage Collector" managed also den Speicher.
Der Garbage Collector entscheidet aber immer selbst wann er tätig werden möchte.
Es ist also nicht voraussagbar, wann ein Objekt aus dem Speicher entfernt wird.
COM Objekte werden außerhalb der Reichweite des "Garbage Collectors" in unverwalteten Speicher angelegt.
Hier muss der Scripter oder der Programmierer, wie in den Sprachen C oder C++ den Speicher selbst verwalten.
In dem Moment wo du das Objekt $Item nicht mehr benötigst, musst du die .NET Klasse System.Runtime.InteropServices.Marshal aufrufen.
Der so genannte Marshaller erledigt die Konvertierung und die Kommunikation von der maged zur unmanaged Welt.
Die Methode FinalReleaseComObject vom Marschaller Markiert ein COM so, das es nicht mehr benutzt wird (alle Referenzen auf dieses Objekt werden Entfernt).
Dann muss man dem Garbage Collector noch dazu auffordern, seine Arbeit zu machen.
Dies sollte man nur selten tun, da man dadurch wieder die Performance verliert oder andere Seiteneffekte erzeugt.
Function ReleaseFinal-ComRef {
<#
.Synopsis
Releases all references to a a Component Object Model (COM) and his Runtime Callable Wrapper (RCW) by setting its reference count to 0.
.DESCRIPTION
Releases all references to a a Component Object Model (COM) and his Runtime Callable Wrapper (RCW) by setting its reference count to 0.
This function is used to explicitly control the lifetime of a Component Object Model (COM) object used from managed code.
You should use this method to free the underlying COM object that holds references to resources in
a timely manner or when objects must be freed in a specific order.
Every time a COM interface pointer enters the common language runtime (CLR), it is wrapped in an Runtime Callable Wrapper (RCW).
The RCW has a reference count that is incremented every time a COM interface pointer is mapped to it.
The FinalReleaseComObject method decrements the reference count of an RCW to zero. When the reference count is zero,
the runtime releases all its references on the unmanaged COM object, and throws a System.NullReferenceException
if you attempt to use the object further. If the same COM interface is passed more than one time from unmanaged to managed code,
the reference count on the wrapper is incremented every time, and calling ReleaseComObject returns the number of remaining references.
This method enables you to force an RCW reference release so that it occurs precisely when you want it to.
However, improper use of FinalReleaseComObject may cause your application to fail, or may cause an access violation.
Consider a scenario in which managed code in an application domain is holding onto an RCW that represents a COM component.
If you call the FinalReleaseComObject method on the RCW, the managed code will be unable to access the RCW and will raise an InvalidComObjectException exception.
A more serious error may occur if a call to the RCW is executing when the RCW is released. In this case,
there is a good chance that the thread making the call will cause an access violation.
However, process memory may become corrupted, and the process may continue to run until it fails for reasons that are very difficult to debug.
This risk is compounded when the COM component that is being used is a singleton, for the following reason:
The CLR activates COM components by calling the COM CoCreateInstance function,
which returns the same interface pointer every time it is called for singleton COM components.
Thus, separate and independent pieces of managed code in an application domain can be using the same RCW for a singleton COM component,
and if either one calls the ReleaseComObject or FinalReleaseComObject method on the COM component, the other will be broken.
Therefore, use the ReleaseComObject and FinalReleaseComObject methods only if it is absolutely required.
If you want to call this method to ensure that a COM component is released at a determined time,
consider using the FinalReleaseComObject method instead. FinalReleaseComObject will release the underlying COM component regardless of
how many times it has re-entered the CLR. The internal reference count of the RCW is incremented by one every time the COM component re-enters the CLR.
Therefore, you could call the ReleaseComObject method in a loop until the value returned is zero.
This achieves the same result as the FinalReleaseComObject method.
.EXAMPLE
Release-Ref $objExcel
Releases the reference to an Excel Application COM object
.EXAMPLE
Release-Ref $objWorkbook
Release-Ref $objExcel
Releases the reference to an Excel Workbook and the Excel Application COM object in the correct manner
See KB317109; Office application does not quit after automation from Visual Studio .NET client
https://support.microsoft.com/kb/317109/en-us
#>
[CmdletBinding()]
param(
[Parameter(ValueFromPipeline=$True)]
[System.__ComObject]$InputObject
)
<#
The FinalReleaseComObject method releases the managed reference to a COM object.
Calling this method is equivalent to calling the ReleaseComObject method in a loop until it returns 0 (zero).
When the reference count on the COM object becomes 0, the COM object is usually freed,
although this depends on the COM object's implementation and is beyond the control of the runtime.
However, the RCW can still exist, waiting to be garbage-collected.
The COM object cannot be used after it has been separated from its underlying RCW.
If you try to call a method on the RCW after its reference count becomes 0, a InvalidComObjectException will be thrown.
#>
[System.Runtime.InteropServices.Marshal]::FinalReleaseComObject($InputObject)
<#
Because the runtime performs garbage collection on the RCW, the GC.Collect() method forces the garbage collector to run and
might release any references that the RCW still has.
The GC.Collect() method tries to reclaim the maximum memory that is available.
Note that this does not guarantee that all memory will be reclaimed.
#>
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
}
PowerShell Artikel, Buchtipps und kostenlose PowerShell Tutorials + E-Books
auf der deutschsprachigen PowerShell Community
Mein 21 Teiliger PowerShell Video Grundlehrgang
Deutsche PowerShell Videos auf Youtube
Folge mir auf:
Twitter |
Facebook |
Google+
