🚀The world's best VBA AI has evolved. ExcelMaster is now an autonomous Agent.Read more →
Back to Blog

VBA CreateObject in Excel — Late Binding, GetObject und warum Outlook offen bleibt

|

VBA CreateObject in Excel — Late Binding, GetObject und warum Outlook offen bleibt

TL;DR — CreateObject("ProgID") startet jede COM-Anwendung über ihren Namen — Scripting.FileSystemObject, Outlook.Application, WScript.Shell. Weil das Objekt über eine Zeichenkette benannt ist, kann der Compiler es nicht prüfen: Eine falsche ProgID scheitert zur Laufzeit mit error 429. CreateObject startet immer eine neue Instanz (nehmen Sie GetObject, um sich an eine laufende zu hängen), und alles, was Sie starten, müssen Sie freigeben — die Anwendung mit .Quit beenden und Set obj = Nothing —, sonst lassen Sie einen kopflosen Prozess laufen.

Sub CreateObjectDemo()
    Dim fso As Object
    Set fso = CreateObject("Scripting.FileSystemObject")   ' Late Binding: per Zeichenkette benannt
    Debug.Print fso.FileExists("C:\data.txt")

    Set fso = Nothing                                      ' freigeben, was Sie erzeugt haben
End Sub

CreateObject ist das Verb, das VBA von einer Excel-Sprache in eine Windows-Automatisierungssprache verwandelt. Geben Sie ihm eine ProgID — den registrierten Namen einer COM-Komponente —, und es startet diese Komponente und reicht Ihnen ein Objekt, das Sie steuern können: Dateien lesen mit Scripting.FileSystemObject, Mail versenden mit Outlook.Application, Befehle ausführen mit WScript.Shell. Es ist das mächtigste Werkzeug der Sprache, um über Excel hinauszugreifen, und verlangt im Gegenzug die größte Sorgfalt, denn der Compiler ist für alles, was es Ihnen gibt, abgeschaltet.

Was Sie lernen

  • Das mentale Modell — CreateObject ist eine Tür, die per Zeichenkette verschlüsselt ist (eine ProgID), zur Laufzeit aufgelöst
  • Die eigentliche Entscheidung: Late Binding (CreateObject) gegen Early Binding (ein Verweis + New)
  • Warum CreateObject immer eine neue Instanz erzeugt, und wann Sie stattdessen GetObject nehmen
  • Warum ein kopfloser Outlook-/Excel-Prozess laufen bleibt, und wie Sie ihn richtig freigeben
  • Was error 429 bedeutet und die Handvoll Dinge, die ihn auslösen
  • Wann Sie welchen Stil bevorzugen — früh entwickeln, spät ausliefern

Das mentale Modell: eine Tür mit einem String als Schlüssel

Jede automatisierbare Windows-Komponente registriert eine ProgID — einen Textnamen wie Scripting.Dictionary oder Word.Application. CreateObject nimmt diese Zeichenkette, schlägt sie zur Laufzeit in der Windows-Registry nach, startet die Komponente und liefert einen Verweis darauf zurück:

Dim dict As Object
Set dict = CreateObject("Scripting.Dictionary")   ' Registry-Nachschlagen per Name -> ein lebendes Objekt

Das wichtige Wort ist Laufzeit. Das Objekt ist über eine Zeichenkette benannt, also ist nichts über es bekannt, während Sie tippen oder wenn das Projekt kompiliert — VBA findet erst dann heraus, was dict ist, wenn diese Zeile tatsächlich läuft. Genau diese eine Tatsache — ein Objekt, das über eine Zeichenkette statt über einen deklarierten Typ identifiziert wird — ist es, was „Late Binding" bedeutet, und sie treibt jeden Kompromiss und jede Falle weiter unten an.

Late Binding gegen Early Binding — die eigentliche Entscheidung

Es gibt zwei Wege, ein COM-Objekt zu erreichen, und die Wahl zwischen ihnen ist das Herz dieses Themas.

Late Binding ist CreateObject mit einer Object-Variablen. Kein Verweis, kein deklarierter Typ:

Dim ol As Object
Set ol = CreateObject("Outlook.Application")   ' late: eine Zeichenkette, ein Object
Dim mail As Object
Set mail = ol.CreateItem(0)                    ' 0 = olMailItem - der Konstantenname ist nicht verfuegbar

Early Binding ist ein gesetzter Verweis (Extras → Verweise → Microsoft Outlook Library) plus ein deklarierter Typ und New:

Dim ol As New Outlook.Application              ' early: ein echter Typ
Dim mail As Outlook.MailItem
Set mail = ol.CreateItem(olMailItem)           ' benannte Konstanten wie olMailItem existieren jetzt

Sie kompilieren zu fast demselben; der Unterschied liegt darin, wann das Objekt verstanden wird und was Sie dafür bekommen:

  • Late (CreateObject) — portabel: kein Verweis zu setzen, übersteht Versionsunterschiede, läuft auf jeder Maschine, die die Anwendung hat. Aber kein IntelliSense, benannte Konstanten (olMailItem) existieren nicht, also codieren Sie deren Zahlen hart oder deklarieren Ihr eigenes Const, und jeder Tippfehler zeigt sich erst, wenn die Zeile läuft.
  • Early (New + Verweis) — IntelliSense beim Tippen, der Compiler fängt falsch geschriebene Member ab, und benannte Konstanten funktionieren. Aber der Verweis ist an eine bestimmte Bibliotheksversion gebunden und kann auf einer anderen Maschine oder einem anderen Office-Build brechen.

Die praktische Regel, der die meisten Profis folgen: Entwickeln Sie mit Early Binding für IntelliSense und Kompilierprüfungen, wechseln Sie dann zum Ausliefern auf Late Binding — ändern Sie die Dim-Typen auf Object, ersetzen Sie New durch CreateObject, definieren Sie alle verwendeten Konstanten und entfernen Sie den Verweis. Sie bekommen den bequemen Schreibkomfort und das portable Endprodukt.

CreateObject erzeugt eine neue Instanz; GetObject hängt sich an

CreateObject startet immer eine frische Instanz der Komponente. Für einen zustandslosen Helfer wie das FileSystemObject ist das genau richtig. Für eine Anwendung, die der Nutzer vielleicht schon geöffnet hat, ist es eine Falle:

Set xl = CreateObject("Excel.Application")   ' startet ein ZWEITES, unsichtbares Excel - auch wenn eines offen ist

Nun gibt es zwei Excels, und das unsichtbare hält Ressourcen, die der Nutzer nicht sehen kann. Wenn Sie das bereits laufende meinen, nehmen Sie GetObject ohne Pfad und mit der ProgID:

Dim ol As Object
On Error Resume Next
Set ol = GetObject(, "Outlook.Application")      ' an ein laufendes Outlook haengen, falls vorhanden
If ol Is Nothing Then Set ol = CreateObject("Outlook.Application")   ' sonst eines starten
On Error GoTo 0

Dieses Muster „anhängen, falls es läuft, sonst starten" ist der korrekte Weg, eine nutzerseitige Anwendung wie Outlook oder Excel zu automatisieren, ohne Duplikate zu erzeugen. GetObject hat auch eine zweite Form — GetObject(path) —, die das Objekt einer Datei direkt öffnet (zum Beispiel eine Arbeitsmappe), ohne über die Open-Methode der Anwendung zu gehen. Der Unterschied zum Merken: CreateObject = neu, GetObject(, progID) = bestehend, GetObject(path) = eine Datei als Objekt.

Warum Outlook offen bleibt: geben Sie frei, was Sie starten

Hier der Fehlschlag, den jeder einmal trifft. Sie automatisieren Outlook oder ein zweites Excel, das Makro endet, und ein OUTLOOK.EXE- oder EXCEL.EXE-Prozess läuft im Task-Manager ohne Fenster weiter — unsichtbar, hält Speicher und manchmal eine Dateisperre. Die Ursache: Sie haben ein Anwendungsobjekt gestartet und ihm nie gesagt, dass es sich schließen soll.

Ein Objekt, das Sie mit CreateObject erzeugen, verschwindet nicht, wenn Ihre Variable den Gültigkeitsbereich verlässt, solange die Anwendung sich selbst am Leben hält. Sie müssen die Anwendung beenden und den Verweis freigeben, idealerweise in einem Aufräumteil, der selbst im Fehlerfall läuft:

Dim ol As Object
On Error GoTo Cleanup
Set ol = CreateObject("Outlook.Application")
' ... ol verwenden ...

Cleanup:
    If Not ol Is Nothing Then
        ol.Quit               ' der Anwendung sagen, dass sie schliessen soll
        Set ol = Nothing      ' den Verweis freigeben
    End If

Zwei Gewohnheiten verhindern das Leck: Rufen Sie .Quit der Anwendung (oder .Close für eine Arbeitsmappe bzw. ein Dokument), bevor Sie fertig sind, und Set obj = Nothing für jedes Objekt, das Sie erzeugt haben. Setzen Sie beides in einen Fehlerbehandler — siehe VBA-Fehlerbehandlung —, damit ein Absturz mitten im Makro trotzdem aufräumt. Leichtgewichtige Objekte wie Scripting.Dictionary oder das FileSystemObject erzeugen keinen Prozess und brauchen kein .Quit, aber sie auf Nothing zu setzen ist trotzdem sauber.

Der Fehler, auf den Sie treffen: error 429, zur Laufzeit

Weil die ProgID eine Zeichenkette ist, die der Compiler nie prüft, erscheint der klassische CreateObject-Fehlschlag erst, wenn die Zeile läuft: error 429, „ActiveX component can't create object". Er hat eine kurze Liste von Ursachen:

  • Eine falsch geschriebene ProgID — CreateObject("Scripting.FileSystemObjectt"). Für eine Zeichenkette gibt es keine Rechtschreibprüfung zur Kompilierzeit.
  • Die Anwendung ist nicht installiert — CreateObject("Outlook.Application") auf einer Maschine ohne Outlook. Late Binding läuft überall, aber die Zielanwendung muss tatsächlich vorhanden sein.
  • Ein Bitness- oder Registrierungsproblem — eine 32-Bit-Komponente unter 64-Bit-Office oder eine Komponente, die sich nie korrekt registriert hat.

Weil es ein Laufzeitfehler ist, sichern Sie den Aufruf mit Fehlerbehandlung ab und geben Sie dem Nutzer eine klare Meldung („Outlook ist nicht installiert") statt eines nackten 429. Dieser reine Laufzeit-Fehlschlag ist der Preis des Late Binding und der Grund, warum viele Entwickler zuerst mit Early Binding schreiben: Der Compiler hätte den Tippfehler abgefangen.

Das ehrliche Fazit: das Tor zu Windows, mit abgeschaltetem Compiler

CreateObject ist das mit Abstand fähigste Verb, um über Excel hinauszugreifen — die Tür zu Dateien, Mail, der Shell, Datenbanken und jeder anderen Office-Anwendung. Seine Macht und seine Gefahr sind dasselbe: ein Objekt, über eine Zeichenkette benannt, ungeprüft, bis es läuft. Vier Regeln halten es sicher:

  • Es ist Late Binding per Zeichenkette → eine ProgID, zur Laufzeit aufgelöst; ein Tippfehler oder eine fehlende Anwendung scheitert mit error 429, wenn die Zeile läuft, nie zur Kompilierzeit.
  • Wählen Sie Late gegen Early bewusst → Early (New + Verweis) für IntelliSense und Kompilierprüfungen beim Entwickeln; Late (CreateObject), um eine portable Datei auszuliefern.
  • CreateObject ist neu; GetObject ist bestehend → nehmen Sie für nutzerseitige Anwendungen das Muster „anhängen, falls es läuft, sonst erzeugen", damit Sie nie ein unsichtbares Duplikat erzeugen.
  • Geben Sie frei, was Sie starten → die Anwendung mit .Quit beenden und Set obj = Nothing, in einem Fehlerbehandler, sonst lassen Sie einen kopflosen Prozess zurück, der Speicher und Dateisperren hält.

Alles bis hierher lebte innerhalb von Excels eigenem Objektmodell, wo ein Aufruf vor der nächsten Zeile abschließt und ein Fehler einen lauten Fehler wirft. Shell, Environ und CreateObject treten aus dieser Sicherheit heraus — und CreateObject tritt am weitesten heraus und reicht Ihnen ein Objekt, das der Compiler nie gesehen hat. Respektieren Sie die vier Regeln, und es ist ein Tor, kein Minenfeld.

Wie ExcelMaster hilft

Die CreateObject-Bugs, die echte Zeit kosten, sind die unsichtbaren: ein zweites kopfloses Excel, das weiterläuft, ein Outlook-Prozess, der nie beendet wurde, ein Laufzeit-429 auf einer Maschine, der die Anwendung fehlt, eine Late-Binding-Konstante, hart auf die falsche Zahl codiert. Jeder davon kommt daher, dass der Compiler für Objekte, die über eine Zeichenkette benannt sind, abgeschaltet ist.

ExcelMaster schreibt den Automatisierungs-Klebstoff richtig. Beschreiben Sie die Aufgabe — „verschicke diesen Bereich als Outlook-E-Mail" oder „lies eine Textdatei mit dem FileSystemObject" — und es erzeugt die richtige Bindung (Late, damit sie überall läuft), hängt sich mit GetObject an eine laufende Anwendung, wenn Sie das meinen, definiert die Konstanten, die dem Late Binding fehlen, und räumt jedes Objekt, das es gestartet hat, in einem Fehlerbehandler auf. Sie beschreiben, welche Anwendung gesteuert werden soll; es schreibt Code, der sie steuert und nichts hängen lässt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen CreateObject und New in VBA?

New (Early Binding) braucht einen gesetzten Verweis auf die Bibliothek der Komponente und einen deklarierten Typ — Dim ol As New Outlook.Application — und gibt Ihnen IntelliSense, Prüfung zur Kompilierzeit und benannte Konstanten. CreateObject("Outlook.Application") (Late Binding) benennt die Komponente über eine ProgID-Zeichenkette, braucht keinen Verweis und funktioniert über Versionen und Maschinen hinweg, hat aber kein IntelliSense und scheitert erst zur Laufzeit, wenn der Name falsch ist. Entwickeln Sie mit New für das Werkzeug, liefern Sie mit CreateObject für die Portabilität aus.

Was ist Late Binding gegenüber Early Binding in VBA?

Early Binding deklariert ein Objekt als bestimmten Typ (As Outlook.Application), gestützt auf einen Eintrag unter Extras → Verweise, sodass der Compiler das Objekt kennt und IntelliSense und benannte Konstanten anbietet. Late Binding deklariert es als generisches Object und erzeugt es mit CreateObject("ProgID"), sodass das Objekt zur Laufzeit per Zeichenkette aufgelöst wird, ohne Wissen des Compilers. Early Binding ist besser zum Schreiben; Late Binding ist besser zum Ausliefern, weil es nicht davon abhängt, dass ein bestimmter Bibliotheksverweis vorhanden ist.

Wie behebe ich error 429 (ActiveX component can't create object)?

error 429 bedeutet, dass CreateObject die ProgID, die Sie übergeben haben, nicht starten konnte. Prüfen Sie drei Dinge: dass die ProgID korrekt geschrieben ist (Scripting.FileSystemObject, keine Variante); dass die Anwendung auf dieser Maschine tatsächlich installiert ist (Late Binding läuft überall, aber die Zielanwendung muss vorhanden sein); und dass es keine Bitness-Diskrepanz gibt (eine 32-Bit-Komponente unter 64-Bit-Office). Hüllen Sie den Aufruf in Fehlerbehandlung, damit Nutzer eine klare Meldung sehen statt des nackten 429.

Wie verwende ich CreateObject mit einer bereits geöffneten Anwendung?

CreateObject startet immer eine neue Instanz, also nehmen Sie für eine Anwendung, die der Nutzer vielleicht schon geöffnet hat, stattdessen GetObject: Set ol = GetObject(, "Outlook.Application") hängt sich an ein laufendes Outlook. Das sichere Muster ist „anhängen, falls es läuft, sonst erzeugen": Versuchen Sie GetObject unter On Error Resume Next, und wenn das Objekt Is Nothing ist, greifen Sie auf CreateObject zurück. Das vermeidet, eine zweite, unsichtbare Kopie von Excel, Outlook oder Word zu erzeugen.

Warum bleibt Excel oder Outlook offen, nachdem mein Makro fertig ist?

Weil Sie ein Anwendungsobjekt erzeugt und es nie freigegeben haben. Eine automatisierte Anwendung hält ihren Prozess am Leben, bis Sie .Quit aufrufen und den Verweis auf Nothing setzen. Wenn das Makro endet — oder abstürzt —, ohne beides zu tun, verweilt der EXCEL.EXE- oder OUTLOOK.EXE-Prozess unsichtbar im Task-Manager und hält Speicher und manchmal eine Dateisperre. Setzen Sie obj.Quit : Set obj = Nothing immer in einen Aufräumabschnitt, der über einen Fehlerbehandler erreicht wird, damit er selbst dann läuft, wenn etwas scheitert.

Getestet in

Getestet in: Excel 365 (Windows 11), VBA 7.1 — zuletzt geprüft am 30.08.2026.

Verwandte Anleitungen: VBA Shell · VBA Environ · VBA FileSystemObject · VBA Dictionary · VBA Outlook Automation