c#: ObjectDisposedException in SuspendLayout - wie den Übeltäter finden?

[Uhu U. (uhu)]

Ich amüsiere mich jetzt schon den zweiten Tag mit dem Problem und komme 
auf keinen grünen Zweig:

- Ich entsorge ein selbstgestricktes, kleines Control - das geht
  beliebig oft gut:

   editPanel.Controls.Remove(a.Control);
   a.Control.Dispose();
   a.Control = null;

  a.Control.Dispose setzt eine Referenz auf a im Control auf null:

    protected override void Dispose(bool disposing) {
       _aspect = null;               // Zeigt auf a
       <es folgt der übliche, generierte Dispose-Code>
    }

- Dann verlasse ich den von Form abgeleiteten Dialog und entsorge
  ihn mit Dispose aus dem Hauptdialog heraus.
- Dann erzeuge ich den Dialog neu und wiederhole die Übung
  Nach dem ersten Control-Löschen bekomme ich ein

   ObjectDisposedException in SuspendLayout

  bevor der Fensterinhalt neu angezeigt werden soll, direkt nach
  der Löschoperation.
  Wenn ich die Löschoperation(en) nicht mache, tritt der Fehler in
  der Anzeigeroutine nicht auf.

Bei beiden Dialogen, die im Programm vorkommen und in meinem Control in 
die Dispose-Routinen sind Trace-Ausgaben eingebaut. Ebenso in den 
Konstruktor des Controls - die Ausgaben zeigen keine Auffälligkeiten. 
(Der Haupdialog läuft dabei durch, der zweite wird vom ersten geöffnet.)

Wie kann man herausfinden, welches Objekt der Übeltäter ist, wenn man 
keine Quellen von dem .net-Zeugs hat?

---------

Nachtrag:
Die Komponente ObjectName im Exception-Objekt ist "".
Der Stack-Eintrag zum Absturz lautet:

System.Drawing.dll!Microsoft.AGL.Common.MISC.HandleAr(
  Microsoft.AGL.Common.PAL_ERROR ar = InvalidHandle) + 0x5c bytes

[Uhu U. (uhu)]

Des Rätsels Lösung:

Ich hatte einen static delegate in der Control-Klasse beim ersten Aufruf 
des zweiten Dialogs initialisiert und dann nicht mehr. Der Delegate 
zeigte auf eine Methode im zweiten Dialog.

Dann wurde der Dialog mit Dispose entsort, aber der Delegate blieb 
unverändert.

Das ist fatal, weil im Delegate neben der Methode auch der this-Zeiger 
auf das Objekt steckt, zu dem die Methode gehört - in dem Fall also die 
erste Instanz des zweiten Dialogs.

Mit der zweiten Instanz dieses Dialogs nahm das Verhängnis seinen Lauf: 
der Delegate-Aufruf arbeitete auf der (entsorgten) ersten Instanz des 
Dialoges...

[Arc N. (arc)]

Uhu Uhuhu schrieb:
> Wie kann man herausfinden, welches Objekt der Übeltäter ist, wenn man
> keine Quellen von dem .net-Zeugs hat?

Dem kann abgeholfen werden...
http://referencesource.microsoft.com/netframework.aspx

[Uhu U. (uhu)]

Arc Net schrieb:
> Dem kann abgeholfen werden...
> http://referencesource.microsoft.com/netframework.aspx

Interessant. Kennst du auch eine Quelle für .net 2.0 CF?

[Arc N. (arc)]

Uhu Uhuhu schrieb:
> Arc Net schrieb:
>> Dem kann abgeholfen werden...
>> http://referencesource.microsoft.com/netframework.aspx
>
> Interessant. Kennst du auch eine Quelle für .net 2.0 CF?

Das könnte mit beim Quelltext von CE dabei sein...
http://www.microsoft.com/en-us/sharedsource/windows-embedded-ce-licensing-program.aspx