Fix 'Automation error: The object invoked has disconnected from its clients' in VBA Excel

TL;DR — Quick Fix

Short answer: your code is holding a reference to an Excel object — Workbook, Worksheet, Range — that no longer exists. The workbook closed, the COM server crashed, or Excel was killed while your macro was still running. Re-acquire the reference fresh before each use and add a guard to confirm it's still alive.

Quick pattern that solves most cases:

Dim ws As Worksheet
Set ws = ThisWorkbook.Worksheets("Sheet1")  ' Re-acquire every time

' Guard before use
If Not ws Is Nothing Then
    ws.Range("A1").Value = "Hello"
End If

What Causes This Error

Under the hood, 0x80010108 is a COM/DCOM error — specifically RPC_E_DISCONNECTED. Windows throws it the moment VBA tries to call a method or read a property on an object whose COM server has already shut down.

Nine times out of ten, one of these scenarios triggered it:

• A workbook was closed while your code still held a Workbook or Worksheet variable pointing to it.
• You opened Excel via CreateObject("Excel.Application") or GetObject() from another Office app (Access, Word, Outlook), and that Excel instance shut down mid-run.
• A long-running loop left a stale object reference after the user manually closed a workbook.
• A module-level or global variable held a reference to an object that got closed before the next macro run.
• Excel's COM server crashed or was force-closed — Task Manager kill, out-of-memory, or a hard crash — while automation was in progress.

Fix 1 — Re-Acquire Object References (Most Common Fix)

Stop caching object references across procedure calls. Look up the workbook and worksheet fresh each time you need them — it costs one extra line and prevents this error entirely.

Broken pattern (stale reference):

' Module-level variable — dangerous
Dim gSheet As Worksheet

Sub Init()
    Set gSheet = Workbooks("Data.xlsx").Worksheets("Report")
End Sub

Sub ProcessData()
    ' If Data.xlsx was closed since Init() ran, this crashes
    gSheet.Range("A1").Value = "Done"  ' Error -2147417848 here
End Sub

Fixed pattern (fresh reference each time):

Sub ProcessData()
    Dim wb As Workbook
    Dim ws As Worksheet

    ' Check workbook is open before accessing it
    On Error Resume Next
    Set wb = Workbooks("Data.xlsx")
    On Error GoTo 0

    If wb Is Nothing Then
        MsgBox "Data.xlsx is not open. Please open it and try again."
        Exit Sub
    End If

    Set ws = wb.Worksheets("Report")
    ws.Range("A1").Value = "Done"
End Sub

Fix 2 — Validate Objects in Long Loops

Long-running loops are a trap. Ten thousand rows into processing, the user closes Data.xlsx, and your macro cheerfully crashes on the next ws.Cells() call. Check whether the workbook is still alive every hundred iterations or so.

Function IsWorkbookOpen(wbName As String) As Boolean
    Dim wb As Workbook
    On Error Resume Next
    Set wb = Workbooks(wbName)
    On Error GoTo 0
    IsWorkbookOpen = Not (wb Is Nothing)
End Function

Sub ProcessRows()
    Dim i As Long
    Dim ws As Worksheet

    For i = 1 To 10000
        ' Re-check every 100 rows
        If i Mod 100 = 0 Then
            If Not IsWorkbookOpen("Data.xlsx") Then
                MsgBox "Workbook was closed. Stopping at row " & i
                Exit For
            End If
            ' Re-acquire reference after check
            Set ws = Workbooks("Data.xlsx").Worksheets("Sheet1")
        End If

        ws.Cells(i, 1).Value = i
    Next i
End Sub

Fix 3 — Cross-Application Automation (Access/Word → Excel)

Driving Excel from Access or Word adds a whole new failure mode. Excel might crash, get killed by the OS, or simply time out — leaving your xlApp variable pointing at a ghost. A real GoTo error handler, not inline On Error Resume Next, is the only way to clean this up reliably.

' Running from Access VBA or Word VBA
Sub ExportToExcel()
    Dim xlApp As Object
    Dim xlWb As Object
    Dim xlWs As Object

    On Error GoTo Cleanup

    ' Create a fresh Excel instance
    Set xlApp = CreateObject("Excel.Application")
    xlApp.Visible = True

    Set xlWb = xlApp.Workbooks.Add
    Set xlWs = xlWb.Worksheets(1)

    xlWs.Range("A1").Value = "Exported Data"

    xlWb.SaveAs "C:\Reports\output.xlsx"
    xlWb.Close False
    xlApp.Quit

    Set xlWs = Nothing
    Set xlWb = Nothing
    Set xlApp = Nothing
    Exit Sub

Cleanup:
    MsgBox "Excel automation failed: " & Err.Description
    ' Always clean up even on error
    If Not xlApp Is Nothing Then
        On Error Resume Next
        xlApp.Quit
        Set xlApp = Nothing
    End If
End Sub

Three rules to keep in mind:

• Always call xlApp.Quit in your cleanup — leaked Excel instances pile up in Task Manager and cause every subsequent automation run to fail.
• Set object variables to Nothing in reverse order: Worksheet → Workbook → Application.
• Use a GoTo error handler for the main body, not On Error Resume Next — silent errors hide exactly where things broke.

Fix 4 — Handle the Error and Retry

Unattended scripts can't pop a message box at 3 AM. Trap error -2147417848 specifically, pause two seconds, and retry before giving up:

Sub RobustWrite(targetCell As String, value As Variant)
    Const MAX_RETRIES As Integer = 3
    Dim attempt As Integer
    Dim ws As Worksheet

    For attempt = 1 To MAX_RETRIES
        On Error GoTo RetryHandler
        Set ws = ThisWorkbook.Worksheets("Output")
        ws.Range(targetCell).Value = value
        On Error GoTo 0
        Exit For  ' Success — exit loop

RetryHandler:
        If Err.Number = -2147417848 Then
            ' COM disconnected — wait and retry
            Application.Wait Now + TimeValue("00:00:02")
            Err.Clear
            Resume Next
        Else
            ' Different error — don't swallow it
            Err.Raise Err.Number, Err.Source, Err.Description
        End If
    Next attempt
End Sub

Fix 5 — Workbook-Level Events Causing the Error

Workbook and worksheet events can catch you off guard. By the time Workbook_BeforeClose or Worksheet_Deactivate fires, Excel is already winding down the object. Your range reference is technically still there — just not reliably so. Move any visual updates to an earlier, safer event.

' WRONG — sheet is deactivating, range reference may disconnect
Private Sub Worksheet_Deactivate()
    Me.Range("A1").Interior.Color = RGB(255, 0, 0)  ' Can throw 80010108
End Sub

' RIGHT — use a flag and handle in a safer event
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
    ' Do visual updates while the sheet is still fully active
    Me.Range("A1").Interior.Color = RGB(255, 0, 0)
End Sub

Verification — Confirm the Fix Worked

• Open the VBA Editor (Alt+F11) and set a breakpoint on the line that previously crashed.
• Run the macro with F5. When it pauses at the breakpoint, open the Immediate Window (Ctrl+G) and type ? ws Is Nothing (swap in your actual variable name). It should print False.
• Remove the breakpoint and run the full macro. No error dialog means the fix worked.
• For cross-app automation: open Task Manager → Details tab after the macro finishes. Zero orphaned EXCEL.EXE processes means your cleanup code is doing its job.

Summary

• Error -2147417848 (80010108) = your code is calling a COM object that already disconnected.
• Most fixes: re-acquire the object reference instead of caching it, and check with Is Nothing before use.
• For cross-app automation: always Quit + Set Nothing in a cleanup handler.
• For event handlers: avoid accessing sheet objects in Deactivate or BeforeClose events.