Das ist relativ einfach erklärt:
Verwaltete Ressourcen sind einfach alles, was da im Framework an Typen vorkommt.
Integer, Byte, DateTime, StringBuilder, Byte-Arrays, DataGridViewRowHeightInfoPushedEventArgs, und so weiter. Auch jede Structure und jede Class, die Du deklarierst sind im Endeffekt verwaltete Ressourcen.

Aber: Man kann auch unverwaltete Ressourcen verwenden. Ein Beispiel ist die Bitmap-Klasse. Da wird intern ein unverwaltetes Byte-Array verwendet, um die Daten zu speichern. Das kann man sogar herauslesen:

Beachte Zeile 6. Bits.Scan0 ist ein IntPtr, der auf die Position der unverwalteten Bytes im Arbeitsspeicher zeigt. Mit Marshal.Copy kann man aus unverwaltetem Speicher in verwalteten und umgekehrt kopieren.

Man braucht relativ oft unverwaltete Ressourcen. Ein Beispiel, auf das man selten achtet, sind Forms.
Wenn man einen OpenFileDialog öffnet, macht man das üblicherweise so:

Forms (generell Controls) sind stark an Windows gebunden, denn Windows (welches "unverwaltet" ist, wenn man das so sagen will) muss die Controls zeichnen. Da gibt's so einige Verbindungen, die nicht verwalted sind.


Und das Problem mit den unverwalteten Ressourcen ist, dass sie nicht verwaltet sind. Das heißt, nur Du weißt, wo sie ist (oder halt eben die Klasse, die sie wrappt). Und der GarbageCollector muss wissen, wo sich eine Ressource im Speicher befindet, damit er sie verwerfen kann. Es gibt auch keine richtige Referenzen auf die Ressourcen (im Sinne von: Es gibt keinen Datentyp für unverwaltete Ressourcen).
Unverwaltete Ressourcen funktionieren also gänzlich anders als verwaltete. Und man muss diese unverwalteten Ressourcen manuell entfernen. Die Bitmap-Klasse macht das, sobald man die Dispose-Methode aufruft. Wenn man das nicht macht und alle Referenzen auf die Bitmap-Instanz entfernt (z.B. die methode, in der die Bitmap lokal deklariert ist, verlässt), dann kann die unverwaltete Ressource nicht mehr gelöscht werden und dann bleibt die im Arbeitsspeicher, bis der Prozess beendet wird.
Die Ausnahme davon ist, dass der Garbage Collector das Objekt finalisiert, sobald alle Referenzen drauf verschwunden sind. Dabei wird die Finalize-Methode des Objekts aufgerufen und wenn alles richtig implementiert ist (schwierig hinzubekommen, aber bei Bitmaps scheint es zu passen) wird dann die unverwaltete Ressource freigegeben und man hat den Arbeitsspeicher wieder verfügbar.
Das Problem ist aber: Der Garbage Collector muss das Objekt nicht finalisieren. (Details siehe ericlippert.com/2015/05/18/whe…u-know-is-wrong-part-one/ und ericlippert.com/2015/05/21/whe…u-know-is-wrong-part-two/ )
Für ihn ist jedes Bitmap-Objekt gleich groß. Einige Bytes dürften das sein: Der Overhead jedes Objekts in .NET (VTable und so Zeugs), ein IntPtr, der auf die unverwalteten Daten zeigt und drei Referenztyp-Felder, die alle Nothing sind. Das sind wenige Bytes. Wahrscheinlich weniger als 60 (die genaue Anzahl hängt von der CLR ab). Der Garbage Collector sieht also nicht, dass da eigentlich noch ein 200MB großes Byte-Array im Arbeitsspeicher liegt, also wird er, wenn der Arbeitsspeicher knapp wird, wahrscheinlich zuerst andere, größere Objekte finalisieren.
Man darf sich also an der Stelle nicht auf den Garbage Collector verlassen.

Storch schrieb:

Gibt es andererseits Wege, die ich als Anfänger auch begreife, im Zweifelsfall fest zustellen, ob eine Ressource ggf. unverwaltet ist?

Nicht wirklich, aber du hast es ja selbst programmiert.

Also unverwaltete Resourcen sind immer iwie was krankhaftes.
ZB arbeiten viele Apis mit richtigen Pointern, wasses in .net eiglich nicht gibt. Wenn du also eine Klasse hast, die intern mit solch Apis rumfuhrwerkt, etwa Speicher alloziiert, und dabei einen IntPtr erhält, der auf den Speicher zeigt - sowas wäre eine unverwaltete Resource, weil der GC hat keine Ahnung, wasser aufrufen muß, um das, worauf der IntPtr zeigt, freizugeben.

Aber üblicherweise hast du ühaupt nix damit zu tun.

Storch schrieb:

Vermuten würde ich, das diese, zumindest aus der Sicht von VB.Net als nicht verwaltet gelten?

jou - gutes Beispiel

Edith: Etwas OffTopic aber:
Wie sollte man es mit dem Schlüsselwort Me handhaben??? Man kann ja alle möglichen Objekte ohne Me ansprechen aber ist es nicht generell besser, immer Me davor zu setzen?

ich mags nicht, weil ich Code immer kurz haben will.
Meine nonpublic KlassenVariablen einen Unterstrich als Präfix, und daran erkenne ich eh, dasses Me. ist.
Annererseits manche Public Member können auch zu Verwechslungen führen, also zb Control-Propertis wie Text, Height, Width - da setze ich schon meist ein Me. davor.