Share via

COM- og .NET-feil etter office-arkitekturoverføring

  • Artikkel
  • Gjelder for:
    Microsoft 365

Symptomer

Når du overfører Microsoft Office-arkitektur fra 32-biters til 64-biters, opplever du feil hvis et COM-program eller en .NET Framework-klient brukes. Disse mulige feilene omfatter, men er ikke begrenset til, følgende:

  • TYPE_E_CANTLOADLIBRARY

  • TYPE_E_LIBNOTREGISTERED

  • TYPE_E_ELEMENTNOTFOUND

Feilene oppstår vanligvis hvis COM-programmet eller .NET-klienten kjører som en 32-biters prosess.

Eksempel

Disse feilene kan oppstå når følgende kode kjøres i 86-biters PowerShell:

$xl = New-Object -ComObject Excel.Application

$xl.Visible = $True

Årsak

Feilene skyldes frittstående registerundernøkler som er opprettet av overføringen.

Løsning

Du kan løse dette problemet ved å bruke én av følgende metoder.

Metode 1: Slett frittstående undernøkler automatisk

Kjør dette skriptet fra følgende GitHub-plassering for å finne og fjerne de foreldreløse undernøklene:

Utbedring av Office TypeLib

Metode 2: Slette frittstående undernøkler manuelt

Hvis PowerShell-skriptet fra trinn 1 ikke sletter de frittstående undernøklene, kan du også se etter frittstående oppføringer manuelt. Den berørte enheten kan ha frittstående undernøkler som ligner på følgende eksempel:

HKEY_CLASSES_ROOT\WOW6432Node\TypeLib\GUID\1.9\0\Win32

Obs! I dette eksemplet GUID er en streng som er spesifikk for undernøkkelen.

Undernøkkelen vil ha en verdi som peker til en manglende kjørbar Fil-fil i Office i programfiler (x86)-filbanen. Eksempel:

C:\Programfiler (x86)\Microsoft Office\Root\Office16\EXCEL.EXE

Det bør også være en tilstøtende undernøkkel som peker til riktig 64-biters programfilplassering.