Let's break down your problem step by step, since you're dealing with a tricky combination of Office Interop quirks and server-side limitations:

Core Observations Recap #

• Your WriteTIByEmp method populates an Excel worksheet successfully (logs confirm data is written to cells, and "WriteTIByEmp 4" is logged)
• The process hangs/crashes at wb.Save() — "WriteTIByEmp 5" never appears
• No exceptions are caught by your catch block, even though the operation clearly fails
• Excel processes linger in Task Manager, and excel.Visible = true does nothing (expected for server environments)
• Other Interop Excel methods work fine in the same service

1. Why Isn't the catch Block Catching the Exception? #

Office Interop relies on COM, which behaves differently from managed .NET code in server contexts:

• COM Exception Swallowing: Many Interop failures don't surface as standard .NET exceptions — instead, the COM runtime may silently hang or terminate operations without propagating an error to your catch block.
• Unprocessed UI Prompts: If Excel tries to show a dialog (like "Do you want to overwrite this file?" or "Update external links?"), your server environment has no desktop session to display it. The operation will hang indefinitely instead of throwing an exception, making it look like wb.Save() just "stops working".
• Apartment State Mismatch: Interop Excel requires a Single-Threaded Apartment (STA) thread. If your service runs on a Multi-Threaded Apartment (MTA) thread, COM operations can fail silently.

2. Fixing the wb.Save() Failure #

First, eliminate the most common server-side Interop pitfalls:

Disable Excel UI Prompts

Add these lines right after initializing your Application object to prevent hanging from unshown dialogs:

Application excel = new Application();
excel.Visible = false; // Critical: Visible=true is useless on servers and causes issues
excel.DisplayAlerts = false; // Disable save/overwrite prompts
excel.AskToUpdateLinks = false; // Disable external link update prompts

Ensure Proper Resource Cleanup

Your current code doesn't properly release COM objects, which leads to lingering Excel processes and file locks. Add a finally block to clean up:

finally
{
    // Clean up workbook
    if (wb != null)
    {
        wb.Close(false); // Close without saving if Save failed
        System.Runtime.InteropServices.Marshal.ReleaseComObject(wb);
        wb = null;
    }
    // Clean up Excel application
    if (excel != null)
    {
        excel.Quit();
        System.Runtime.InteropServices.Marshal.ReleaseComObject(excel);
        excel = null;
    }
    // Force garbage collection to clean up residual COM references
    GC.Collect();
    GC.WaitForPendingFinalizers();
}

Verify File Permissions & Locks

• Check that your service's running account has read/write permissions to the file path TIEMPPath (especially if it's a network share or restricted folder).
• Ensure no other process (like a lingering Excel instance from a previous failed run) is locking the file. Restart your service and test again to rule this out.

3. The Long-Term Fix: Ditch Office Interop for Server-Friendly Libraries #

Microsoft explicitly does not support using Office Interop in server environments — it's designed for desktop interactive use. The instability you're seeing is a direct result of this mismatch.

Replace Interop with one of these reliable, server-safe libraries:

• EPPlus: A popular library for .xlsx files (note: v5+ requires a commercial license for commercial use)
• NPOI: Open-source, supports both .xls and .xlsx formats
• ClosedXML: Open-source, focused on .xlsx with a user-friendly API

Here's a quick rewrite of your core logic using EPPlus (simpler and more stable):

using OfficeOpenXml;
using System.IO;

public void WriteTIByEmp(CI.WriteReport Log)
{
    try
    {
        System.Data.DataTable Emps = Pinpoint.TICardsByEmpStatsDaily.GetTICardsByEmployer();
        Log.WriteLine("WriteTIByEmp 1");
        
        // Set license context (adjust for commercial use)
        ExcelPackage.LicenseContext = LicenseContext.NonCommercial;
        
        using (var package = new ExcelPackage(new FileInfo(TIEMPPath)))
        {
            var ws = package.Workbook.Worksheets[1];
            ws.Cells["A:G"].Clear();
            Log.WriteLine("WriteTIByEmp 2");
            
            // Load DataTable directly into the worksheet (no manual loops!)
            ws.Cells[1, 1].LoadFromDataTable(Emps, printHeaders: false);
            Log.WriteLine("WriteTIByEmp 4");
            
            package.Save();
            Log.WriteLine("WriteTIByEmp 5");
        }
        Log.WriteLine("WriteTIByEmp 7");
    }
    catch (Exception ex)
    {
        Log.WriteLine("Catching Exception");
        var st = new System.Diagnostics.StackTrace(ex, true);
        var frame = st.GetFrame(0);
        var line = frame.GetFileLineNumber();
        string msg = $"Component Causing Error:{ex.Source}{System.Environment.NewLine}Error Message: {ex.Message}{System.Environment.NewLine}Line Number: {line}{System.Environment.NewLine}{System.Environment.NewLine}";
        Log.WriteLine(msg, true);
    }
}

Final Notes #

• The immediate fix should focus on disabling UI prompts and cleaning up COM objects to resolve the wb.Save() hang.
• For long-term stability, migrating to a server-friendly Excel library is non-negotiable — Interop will continue to cause unpredictable issues in your service environment.

内容的提问来源于stack exchange，提问作者Patrick Foy