Die Verwendung des Stop-Buttons der IDE, hat die gleiche Wirkung, wie die End-Anweisung im Programmcode und beendet sofort jede Code-Ausführung ohne Möglichkeit Aufräumarbeiten zu erledigen. Es werden keine der üblichen Ereignisse, wie Unload oder Terminate ausgeführt.

Solange man sich in den Grenzen der VB Runtime bewegt ist das dennoch ein recht kontrollierter Vorgang. Verlässt man diese Grenzen jedoch, durch den Einsatz des Windows API oder von Third-Party Controls, gerät schnell einiges außer Kontrolle und Standard-Routinen, die Aufräumarbeiten erledigen sollten, kommen nicht mehr zu Zuge. Es bleiben Handle-Leichen zurück und Zeiger, die auf nicht mehr existente Speicherbereiche verweisen. Gerade beim Einsatz von Subclassing. Dies führt unweigerlich zum Crash der VB-IDE.

Daher ist der Stop-Button der IDE auf jeden Fall tabu, sobald man die Grenzen von VB hinter sich lässt, insbesondere wenn man mit Subclassing experimentiert.

Zudem müssen Sie dafür sorgen, dass alle Subclassing Routinen vor Programm-Ende wieder auf die original WndProc-Adressen verweisen und nicht auf die umgeleiteten in Ihrer Anwendung. Einmal vergessen und der Absturz ist vorprogrammiert. Auch Subclassing von UserControls ist in der IDE nicht ganz ohne und kann unerwünschte Abstürze zur Folge haben. Am besten arbeitet man hier mit bedingter Kompilierung und testet die Anwendung erst vor Fertigstellung mit den Subclassing Routinen, während der allgemeinen Entwicklung aber, lässt man Subclassing aus dem Spiel. Denn hier können während der Debug-Sitzung immer unerwartete Fehler auftreten, die in Verbindung mit dem aktiven Subclassing Routinen, die IDE abstürzen lassen.