Nicht genügend Quoten, um den angeforderten Dienst auszuführen bei Dauerbetrieb

Wenn ich das richtig verstanden habe, wird bei deaktiviertem Cache & URI der Stream offen gelassen.
Bei Aktivierten Cache wird die Datei in den Arbeitsspeicher geladen & der Stream wieder geschlossen, hierbei gibt es die Optionen 'OnDemand & OnLoad' deren namen für sich selbst sprechen.

Hm, aber was für einen Sinn ergibt das? Immerhin kann man von außen gar nicht auf den Stream zugreifen, um ihn zu schließen. Zudem scheint die Anzahl der verwaisten Objekte nicht mit der Anzahl der bisher angezeigten Bilder übereinzustimmen. Im Screenshot des Profilers mit dem Leak verwaisen innerhalb von ca. 2332 Sekunden 225 Uri-Objekte und 253 WeakReference-Objekte. Jedoch wurden in dieser Zeit auch 777 Bilder angezeigt. Im Beispielcode von MSDN wird es ja auch so gemacht, dass dem BitmapImage einfach nur eine UriSource zugeteilt wird. Ob die MSDN-Ersteller wirklich ein Leak in Kauf nehmen?

Woher hast du die Info, dass der Stream offen gelassen wird? Im Code geguckt? Das schaue ich mir auch mal an.

BitmapCacheOption Enumeration

Auf englisch versteht man es ein wenig besser.
None
Do not create a memory store. All requests for the image are filled directly by the image file.

Bereitgestellt wird die Bitmap durch die klasse 'BitmapDownload'

Hier wird der Stream geöffnet doch nie geschlossen. Ob von anderer stelle irgendwann der Stream geschlossen wird konnte ich nicht erkennen.

Der tiefere Sinn ist der, das das Laden von Bitmaps zeitintensiv sein kann, vor allem, wenn die Bilder aus dem Internet geladen werden. Über die Cache-Optionen kann man einstellen, wie man es denn gerne hätte.

Wenn der Cache aktiv ist dann werden die im Cache über die Uri als Schlüssel gehalten und eventuell irgendwann mal da auch wieder herausgeräumt (wann auch immer). Ein Cache ist ja deswegen ein Cache weil er dort etwas so lange wie möglich vorhält und nicht weil er das so schnell wie möglich wieder vergisst.

Handelt es sich auch um 777 unterschiedliche Bilder? Dann weisen die 225 Uri-Instanzen doch eindeutig darauf hin, dass der Cache auch aufgeräumt wird.

Gut, das wiederum macht Sinn. Es ist ja auch nicht zwangsläufig immer vorgesehen, dass ein Programm unendlich lange geöffnet bleibt und immer neue Bilder läd.

Es waren übrigens nur 44 unterschiedliche Bilddateien, da passen die 255 Objekte nicht dazu.

Dir ist schon klar, dass im Hintergrund immer mehr Objekte erzeugt werden, als Du es als Entwickler siehst?
Nen Profiler bekommt auch mit, wenn das .NET Framework Objekte erzeugt...