Greenshot: Export nach Outlook zeigt nur wieder das Menü (TYPE_E_CANTLOADLIBRARY)

Marc Oltersdorf Donnerstag, 15. Oktober 2026 5 Min. Lesezeit

Greenshot bietet Outlook als Ziel an, beim Auswählen erscheint aber nur wieder das Menü. Im Log steht TYPE_E_CANTLOADLIBRARY: Die COM-Registrierung von Outlook ist defekt. Handarbeit in der Registry half nicht, die Onlinereparatur entfernte Office sogar – erst eine Neuinstallation per Office Deployment Tool mit dem richtigen Update-Kanal löste das Problem.

$ git log --graph Der Weg zur Lösung

Problem Ziel Outlook zeigt nur wieder das Menü
Greenshot reagiert auf die Auswahl von Outlook nicht. Das Log meldet TYPE_E_CANTLOADLIBRARY beim Zugriff auf die Outlook-Schnittstelle _Application.
Erkenntnis Typbibliothek ok, Schnittstelle nur in 32-Bit-Ansicht
Die Typbibliothek 9.6 zeigte auf eine vorhandene MSOUTL.OLB, die Schnittstelle war aber nur unter WOW6432Node registriert.
Irrweg Registry-Einträge von Hand ergänzt
214 Schnittstellen in die 64-Bit-Ansicht kopiert und einen win64-Eintrag für die Typbibliothek angelegt – der Fehler blieb unverändert.
Irrweg Onlinereparatur entfernt Office
Die Reparatur deinstallierte Office und scheiterte dann an einer Richtlinie mit dem Update-Kanal MonthlyEnterprise, der nicht zu Office LTSC 2024 passt.
Lösung Neuinstallation per Office Deployment Tool
Mit entschärfter Kanal-Richtlinie und Channel PerpetualVL2024 neu installiert, Outlook-Profil eingerichtet – der Export funktioniert.

Nach einem Screenshot bietet Greenshot im Auswahlmenü das Ziel „Outlook“ an. Wählt man es aus, passiert nichts – das Menü erscheint einfach erneut, ohne Fehlermeldung. Bei mir trat das mit Office LTSC 2024 (32 Bit, Klick-und-Los) auf einem 64-Bit-Windows auf. Was wirklich schiefgeht, steht nur im Greenshot-Log:

ERROR - [Greenshot.Plugin.Office.OfficeExport.OutlookEmailExporter] Error while creating an outlook mail item:
System.InvalidCastException: Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass' to interface type 'Microsoft.Office.Interop.Outlook._Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00063001-0000-0000-C000-000000000046}' failed due to the following error: Fehler beim Laden der Typbibliothek/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
   at Microsoft.Office.Interop.Outlook.ApplicationClass.get_Version()
INFO  - [Greenshot.Base.Core.AbstractDestination] Export cancelled or failed, showing menu again

Das Problem

Greenshot steuert Outlook über COM. Das Starten bzw. Finden von Outlook funktioniert, scheitert aber im nächsten Schritt: Beim Abfragen der Schnittstelle _Application kann Windows die Typbibliothek von Outlook (MSOUTL.OLB) nicht laden. Die liefert die Beschreibung der Schnittstellen, die für die Kommunikation zwischen Greenshot und dem laufenden Outlook-Prozess gebraucht wird.

Ausschließen lassen sich damit das „neue Outlook“ (das hätte gar keine COM-Schnittstelle) und Rechteprobleme – Outlook antwortet ja, nur die Typbibliothek fehlt.

Diagnose in der Registry

Die Typbibliothek von Outlook ist unter der ID {00062FFF-0000-0000-C000-000000000046} registriert, mit einem Unterschlüssel je Version (9.6 = Office 2016 bis 2024 und Microsoft 365). Diese Abfrage zeigt alle Einträge und ob die Datei existiert:

$tl = 'Registry::HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}'
Get-ChildItem $tl | ForEach-Object { $ver = $_.PSChildName; Get-ChildItem "$($_.PSPath)\0" -ErrorAction SilentlyContinue | ForEach-Object { $pfad = (Get-Item $_.PSPath).GetValue(''); [pscustomobject]@{ Version = $ver; Plattform = $_.PSChildName; Pfad = $pfad; Existiert = Test-Path $pfad } } }

Stehen dort alte Versionen (9.5, 9.4) neben 9.6, sind das typische Reste früherer Office-Installationen und die erste Spur. Bei mir war die Typbibliothek sauber: nur 9.6, nur win32, Datei vorhanden. Die zweite Prüfung zeigt, wo die Schnittstelle selbst registriert ist – in beiden Registry-Ansichten und im Benutzerzweig:

$basen = 'HKLM:\SOFTWARE\Classes','HKLM:\SOFTWARE\WOW6432Node\Classes','HKCU:\Software\Classes','HKCU:\Software\Classes\WOW6432Node'
foreach ($b in $basen) { $if = "$b\Interface\{00063001-0000-0000-C000-000000000046}\TypeLib"; if (Test-Path $if) { $i = Get-Item $if; "{0}`n  Interface -> TypeLib {1}, Version {2}" -f $b, $i.GetValue(''), $i.GetValue('Version') }; $tl = "$b\TypeLib\{00062FFF-0000-0000-C000-000000000046}"; if (Test-Path $tl) { "{0}`n  TypeLib-Versionen: {1}" -f $b, ((Get-ChildItem $tl).PSChildName -join ', ') } }

HKLM:\SOFTWARE\Classes
  TypeLib-Versionen: 9.6
HKLM:\SOFTWARE\WOW6432Node\Classes
  Interface -> TypeLib {00062FFF-0000-0000-C000-000000000046}, Version 9.6
HKLM:\SOFTWARE\WOW6432Node\Classes
  TypeLib-Versionen: 9.6

Die Schnittstelle war also nur in der 32-Bit-Ansicht registriert, nicht in der 64-Bit-Ansicht. Die Prüfung des Benutzerzweigs (in einer nicht erhöhten PowerShell unter dem betroffenen Benutzer, sonst liest man das HKCU des Admins) ergab nichts.

Was nicht geholfen hat

Registry von Hand ergänzen. Naheliegende Idee: Greenshot läuft als 64-Bit-Prozess und sucht die Registrierung in der 64-Bit-Ansicht. Ich habe deshalb alle 214 Outlook-Schnittstellen aus WOW6432Node\Classes\Interface in die 64-Bit-Ansicht kopiert und zusätzlich unter der Typbibliothek einen win64-Eintrag mit demselben Pfad angelegt. Ergebnis: exakt derselbe Fehler. Davon würde ich abraten – es verändert die Registry, ohne die eigentliche Ursache zu treffen.

Als Administrator testen. Startet man Greenshot als Admin, öffnet sich plötzlich der Einrichtungsassistent von Outlook – das sieht nach Fortschritt aus, ist es aber nicht. Das Admin-Konto hat nur kein Outlook-Profil, Greenshot kommt bis zum Start von Outlook und nie bis zum fehlerhaften Schritt. Getestet wird immer unter dem normalen Benutzer mit eingerichtetem Outlook.

Die Onlinereparatur von Office – siehe Warnung im nächsten Abschnitt.

Die Lösung: Office sauber neu installieren

1. Vorher festhalten, was installiert ist – nach einer missglückten Reparatur lässt sich das nicht mehr abfragen:

reg query "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" /v ProductReleaseIds /reg:64
cscript "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" /dstatus

ProductReleaseIds liefert die Product-ID für das Office Deployment Tool (bei mir Standard2024Volume), /dstatus zeigt, ob per KMS oder MAK aktiviert wird. Bei 64-Bit-Office liegt OSPP.VBS unter C:\Program Files\….

2. Update-Kanal-Richtlinie prüfen und gegebenenfalls für diesen Rechner entfernen bzw. per Filter ausnehmen:

reg query "HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate" /reg:64

    officemgmtcom    REG_DWORD    0x1
    enableautomaticupdates    REG_DWORD    0x0
    hideenabledisableupdates    REG_DWORD    0x1
    hideupdatenotifications    REG_DWORD    0x1
    updatebranch    REG_SZ    MonthlyEnterprise

reg delete "HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate" /v updatebranch /f
reg delete "HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate" /v officemgmtcom /f

Lokal gelöschte Werte schreibt die GPO beim nächsten Aktualisieren zurück – dauerhaft gehört die Richtlinie so gefiltert, dass sie Rechner mit Office LTSC nicht trifft.

3. Office Deployment Tool von Microsoft herunterladen und nach C:\install\odt entpacken. Zwei Konfigurationsdateien anlegen:

<Configuration>
  <Remove All="TRUE" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

<Configuration>
  <Add SourcePath="C:\install\odt\src" OfficeClientEdition="32" Channel="PerpetualVL2024">
    <Product ID="Standard2024Volume">
      <Language ID="de-de" />
    </Product>
  </Add>
  <Updates Enabled="FALSE" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

Bei KMS-Aktivierung ist kein Schlüssel nötig, das ODT setzt den KMS-Client-Schlüssel selbst. Bei MAK kommt PIDKEY="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" in das Product-Element. OfficeClientEdition und Channel an die vorhandene Installation anpassen.

4. Installieren (PowerShell als Administrator):

cd C:\install\odt
.\setup.exe /download install.xml
.\setup.exe /configure remove.xml
Restart-Computer
cd C:\install\odt
.\setup.exe /configure install.xml

Das vorherige /download legt die Installationsdateien lokal ab, damit die Installation nicht von einer zwischenzeitlich zurückgeschriebenen Kanal-Richtlinie abhängt.

5. Prüfen und testen: ProductReleaseIds muss wieder einen Wert liefern. Outlook unter dem normalen Benutzer starten und das Profil einrichten, dann Greenshot neu starten und das Ziel „Outlook“ wählen – jetzt öffnet sich eine neue Mail mit dem Screenshot als Anhang.

Warum das funktioniert

Die Neuinstallation schreibt sämtliche COM-Registrierungen von Office – Klassen, Schnittstellen und Typbibliotheken – konsistent in beide Registry-Ansichten. Welcher einzelne Eintrag ursprünglich defekt war, habe ich nicht herausgefunden; die Handarbeit an den naheliegenden Stellen hat jedenfalls nicht gereicht. Bei einer kaputten COM-Registrierung ist die saubere Neuinstallation schneller als die Suche nach der Nadel im Heuhaufen.

Stolperfallen

Kein Fehlerdialog: Greenshot zeigt bei jedem fehlgeschlagenen Export nur erneut das Menü – die Ursache steht ausschließlich im Log.
Onlinereparatur bei abweichender Kanal-Richtlinie entfernt Office, ohne es neu zu installieren. Vorher Richtlinie und Product-ID prüfen.
Snapshot oder Sicherung vor dem Eingriff anlegen, wenn es sich um eine VM oder ein Master-Image handelt.
Tests als Admin sind ohne Outlook-Profil aussagelos.
Nach der Reparatur fragte Outlook bei jedem Export, ob ein Programm auf Adressinformationen zugreifen darf. Wie man das steuert und worauf man dabei achten muss: Outlook-Zugriffswarnung abschalten.