[BUG] screenshot capture/capture-sheet fails with COMException 0x800A03EC on a protected worksheet

[fugulab]

Bug Description

screenshot capture and capture-sheet fail with a bare COMException: 0x800A03EC when the target worksheet is protected. Unprotecting the sheet and repeating the same call succeeds — protection alone is the trigger, not the range, not the workbook, not whether Excel is visible.

v1.10.6 made this easy to reach by adding worksheet protection to the server. A caller can now protect a sheet and then be unable to capture it in the same session, with an error that doesn't explain itself. I'd expect the capture behaviour predates v1.10.6, but I only tested v1.10.7, so I can't call it a regression either way.

I searched existing issues for "screenshot", "protected worksheet" and "0x800A03EC" and didn't find a duplicate. #563 and #583 are the closest, and both are closed. #563 does list 0x800A03EC among its symptoms — there it was occasional, tied to particular ranges of a real .xlsm on v1.8.33, and mixed in with blank and junk images. This one is deterministic on a two-cell workbook and switches on and off with sheet protection alone.

Component

• CLI (Command-line interface)
• Core Library (Shared functionality)

Command/Usage

For CLI (verbatim, v1.10.7, <id> is the sessionId from the first command):

> excelcli session create C:\tmp\probe.xlsx
{"success":true,"sessionId":"<id>","filePath":"C:/tmp/probe.xlsx"}

> excelcli range set-values --session <id> --sheet Sheet1 --range A1:B1 --values [["hello","world"]]
{"action":"set-values","success":true}

> excelcli screenshot capture --session <id> --sheet Sheet1 --range A1:B1 --output C:\tmp\a.jpg
{"success":true,"outputPath":"C:/tmp/a.jpg","sizeBytes":2617,"width":134,"height":52,"mimeType":"image/jpeg","sheetName":"Sheet1","rangeAddress":"$A$1:$B$1"}

> excelcli worksheetstyle set-protection --session <id> --sheet Sheet1 --is-protected true
{"success":true}

> excelcli screenshot capture --session <id> --sheet Sheet1 --range A1:B1 --output C:\tmp\b.jpg
{"success":false,"error":"COMException: 0x800A03EC","hresult":"0x800A03EC"}

> excelcli worksheetstyle set-protection --session <id> --sheet Sheet1 --is-protected false
{"success":true}

> excelcli screenshot capture --session <id> --sheet Sheet1 --range A1:B1 --output C:\tmp\d.jpg
{"success":true,"outputPath":"C:/tmp/d.jpg","sizeBytes":2428,"width":134,"height":52,"mimeType":"image/jpeg"}

For MCP Server: tool screenshot, actions capture and capture-sheet, with worksheet_style set-protection to put the sheet in that state. Both entry points reach the same ScreenshotCommands path, but I reproduced this through the CLI: the desktop client on this machine still has the v1.10.5 server loaded in memory, so I have not re-run it over MCP on v1.10.7. Happy to do that after a restart if it matters.

Expected Behavior

Capturing a protected worksheet returns an image, the way it does when the sheet is unprotected. Protection restricts editing, and other read paths keep working while it is on: range get-values and conditionalformat list-worksheet-rules both returned normally on the same protected sheet.

If that isn't feasible, an error naming sheet protection would be enough. The current message gives the caller nothing to act on.

Actual Behavior

No image is returned. The session stays usable, and the next call after unprotecting succeeds.

Error Message

{
  "success": false,
  "error": "COMException: 0x800A03EC",
  "errorMessage": "COMException: 0x800A03EC",
  "errorCategory": "ComInterop",
  "command": "screenshot.capture",
  "sessionId": "<redacted>",
  "isError": true,
  "exceptionType": "COMException",
  "hresult": "0x800A03EC"
}

capture-sheet returns the same with "command": "screenshot.capture-sheet".

Boundary matrix

All on v1.10.7, same workbook, same range:

Call	Result
capture, sheet unprotected	✅ image returned
capture, sheet protected	❌ COMException: 0x800A03EC
capture-sheet, sheet protected	❌ same
capture, after unprotecting	✅ image returned
capture, protected, Excel window shown via window show	❌ same
capture, unprotected, Excel window hidden	✅ image returned

The last two rows are there because I first assumed this was the known "CopyPicture needs a visible Excel" behavior. Visibility makes no difference in either direction, which matches the code: ExportRangeAsImage forces app.Visible = true before capturing and restores the previous state in its finally block, so session-level visibility cannot reach this failure.

Root cause

The export path creates a temporary ChartObject on the target worksheet:

mcp-server-excel/src/ExcelMcp.Core/Commands/Screenshot/ScreenshotCommands.cs

Lines 196 to 217 in d526b22

	// Copy range as picture (with retry — CopyPicture is clipboard-dependent
	// and intermittently fails when Excel is still rendering after chart/table operations)
	try { app.CutCopyMode = false; } catch (COMException) { }
	CopyPictureWithRetry(app, sheet, range);
	Thread.Sleep(250);
	// Create a temporary ChartObject to paste into and export
	chartObjects = sheet.ChartObjects();
	chartObject = chartObjects.Add(0, 0, width, height);
	chart = chartObject.Chart;
	// Paste the copied picture into the chart
	PastePictureWithRetry(app, sheet, range, chart);
	// Clear clipboard immediately after paste — releases clipboard for subsequent screenshot calls
	// (otherwise marching ants remain and next CopyPicture may fail with clipboard contention)
	try { app.CutCopyMode = false; } catch (COMException) { }
	// Export to temp file in the appropriate format
	tempFile = Path.Combine(Path.GetTempPath(), $"excelmcp-screenshot-{Guid.NewGuid():N}.{fileExt}");
	chart.Export(tempFile, exportFormat);

ChartObjects.Add is what Excel refuses on a protected sheet. Probing the calls directly through COM on this machine, with the sheet protected by Worksheet.Protect() with no arguments, which is what SetProtection calls:

Direct COM call on the protected sheet	Result
Worksheet.ChartObjects().Add(0, 0, 150, 60)	0x800A03EC
Worksheet.Shapes.AddShape(...)	0x800A03EC
Range.CopyPicture(1, -4147) (xlScreen/xlPicture, the first mode the retry ladder tries)	returns
Range.Copy() (the final fallback)	returns

The DrawingObjects argument of Protect does not govern this. With Protect(DrawingObjects:=False), where ProtectDrawingObjects reads back False, Shapes.AddShape succeeds on the protected sheet while ChartObjects.Add still raises 0x800A03EC. Protect(UserInterfaceOnly:=True) is not an escape hatch either. ProtectContents looks like the whole trigger — convenient, since that is the property GetProtection already reads:

mcp-server-excel/src/ExcelMcp.Core/Commands/Sheet/SheetCommands.Protection.cs

Lines 27 to 37 in d526b22

	if (isProtected)
	{
	if (string.IsNullOrWhiteSpace(password))
	{
	sheet.Protect();
	}
	else
	{
	sheet.Protect(password);
	}
	}

Two things point away from CopyPicture being the throw site, independently of that probing:

• CopyPictureWithRetry cannot emit a bare COMException. It swallows every one across four appearance/format modes and ten attempts, then across ten more Range.Copy() attempts, and finally throws an InvalidOperationException with a descriptive message. A raw HRESULT reaching the caller means the failure happened outside that method.

  mcp-server-excel/src/ExcelMcp.Core/Commands/Screenshot/ScreenshotCommands.cs

  Lines 275 to 333 in d526b22

  	private static void CopyPictureWithRetry(dynamic app, dynamic sheet, dynamic range)
  	{
  	COMException? lastException = null;
  	(int Appearance, int Format)[] modes =
  	[
  	(XlScreen, XlPicture),
  	(XlPrinter, XlPicture),
  	(XlScreen, XlBitmap),
  	(XlPrinter, XlBitmap)
  	];
  	for (int attempt = 0; attempt < CopyPictureMaxRetries; attempt++)
  	{
  	foreach (var mode in modes)
  	{
  	try
  	{
  	try { app.CutCopyMode = false; } catch (COMException) { }
  	range.CopyPicture(mode.Appearance, mode.Format);
  	return;
  	}
  	catch (COMException ex)
  	{
  	lastException = ex;
  	}
  	}
  	if (attempt < CopyPictureMaxRetries - 1)
  	{
  	Thread.Sleep(CopyPictureRetryDelayMs * (attempt + 1));
  	PrepareRangeForCapture(app, sheet, range);
  	}
  	}
  	for (int attempt = 0; attempt < CopyPictureMaxRetries; attempt++)
  	{
  	try
  	{
  	try { app.CutCopyMode = false; } catch (COMException) { }
  	range.Copy();
  	return;
  	}
  	catch (COMException ex)
  	{
  	lastException = ex;
  	if (attempt < CopyPictureMaxRetries - 1)
  	{
  	Thread.Sleep(CopyPictureRetryDelayMs * (attempt + 1));
  	PrepareRangeForCapture(app, sheet, range);
  	}
  	}
  	}
  	throw new InvalidOperationException(
  	$"Excel could not capture the range after {CopyPictureMaxRetries} attempts because CopyPicture and the range copy fallback kept failing. " +
  	"Excel may still be rendering, busy, minimized, or unable to access the clipboard. " +
  	"Retry the screenshot after the workbook finishes refreshing, or capture a smaller range.",
  	lastException);
  	}

• The timing agrees. Failing calls returned in 3.7 s against 4.6 s for successful captures — exhausting the CopyPicture ladder would take over 30 s in sleeps alone before its InvalidOperationException.

Directions, smallest change first:

1. Catch it and return a message naming sheet protection, in the same spirit as the Python in Excel availability errors from [MCP] pythoninexcel: return a clear "Python in Excel unavailable" error instead of raw #NAME? #753.
2. Host the temporary chart off the target sheet, on a scratch worksheet or a temporary chart sheet. I have not verified whether the paste and the export survive that move, so this is a direction rather than a tested one.
3. Unprotect and restore around the export. A password-protected sheet can't be restored the same way, so this one would need a guard.

Which of these fits depends on how you want protection treated elsewhere in the server.

Environment

• Windows Version: Windows 11 Pro (10.0.26200)
• Excel Version: Microsoft 365 (Click-to-Run)
• ExcelMcp Version: v1.10.7
• .NET Version: standalone executables, no separate .NET runtime installed on this machine
• Installation Method: Binary download, standalone excelcli.exe and mcp-excel.exe from the GitHub Release zips
• File Format: .xlsx
• AI Assistant (if using MCP Server): Claude Desktop

Sample File

Reproduced on a workbook created by session create with two cells set and nothing else — nothing useful to attach, but I can put one together if it helps.

The v1.10.6 drawing, page setup and PDF export actions let me drop a win32com detour I had been carrying for a while. Happy to retest after a fix.

[sbroenne]

Thanks a lot for this report, @fugulab — it was a genuinely useful one. The 0x800A03EC you hit was Excel's generic "no" and gave almost nothing away, but your detail that it only happened on a protected worksheet was exactly the clue that pointed at the real cause.

What was actually wrong

screenshot capture / capture-sheet never took a screenshot. It rendered one inside Excel: copy the range as a picture, insert a temporary chart object into the target worksheet, paste into it, then export the chart. That insert is a drawing-object insert, which Excel refuses outright on a protected sheet — hence the bare COM error. There is no protection flag that allows it either; unprotecting DrawingObjects does not help, so there was no workaround short of unprotecting the sheet.

What we changed

Rather than patch around the restriction, the whole approach was replaced: capture now takes a real screenshot of the live Excel window (PrintWindow). Excel is never asked to modify your workbook in order to produce the image.

Alongside fixing your bug, that removes two side effects the old path had:

• your clipboard is no longer overwritten when you take a screenshot
• the workbook is never modified or dirtied — no temporary object is created in it, so a saved file is no longer touched just because you captured an image

Ranges bigger than the Excel window are now zoomed to fit and, if still too large, captured in several passes and stitched together, so wide sheets come out complete rather than clipped.

One trade-off worth flagging up front: because it is a real screenshot, capture needs an interactive desktop session. It will fail with a clear message on a locked desktop or a disconnected Remote Desktop session. If that affects your setup, please say so — it is useful to know.

Regression tests now cover capture and capture-sheet on a protected sheet, and assert the protection is still intact afterwards, so this specific break cannot come back silently.

Could you re-test?

The fix is merged to main and will go out in the next release. Once it ships, could you try your original protected-worksheet scenario again and let us know how it goes? If anything still misbehaves — or the image looks different from what you expected — please reopen this issue or file a new one with the details. Thanks again for taking the time to report it clearly.

[sbroenne]

Reopening deliberately: the fix is merged to main, but this stays open until @fugulab has been able to confirm it on a real protected workbook in a shipped release. It will be closed once that confirmation comes in (or if there is no response for a while).

[sbroenne]

The fix is now shipped in v1.10.8 (NuGet, VS Code Marketplace, and the standalone/MCPB downloads on the release page).

@fugulab whenever you get a chance, could you update and re-run your original screenshot capture / capture-sheet call against the protected worksheet? Capture no longer inserts anything into the workbook, so protection is no longer in the way.

One thing to be aware of when you test: capture now photographs the real Excel window, so it needs an interactive desktop session. It will not work over a headless/service context or a disconnected RDP session.

I'll leave this issue open until you confirm. Thanks again for the clear report.

[fugulab]

Confirmed fixed in v1.10.8.

Environment: Windows 11 Pro (10.0.26200), Microsoft 365 Click-to-Run 16.0.20228.20190 x64, ExcelMcp v1.10.8 (standalone exe), local interactive desktop session. Re-run through the CLI, the same entry point as the original report.

Original repro, same two-cell workbook and range:

Call	v1.10.7	v1.10.8
capture, unprotected	image	image, 132x22
capture, protected	COMException: 0x800A03EC	image, 132x22
capture-sheet, protected	same error	image, 132x22
capture, after unprotecting	image	image, 132x22

The images carry the actual cell contents, so nothing is coming back blank.

The two side effects you mentioned are gone here as well: worksheetstyle get-protection still returns isProtected: true after both captures on the protected sheet, and a sentinel string placed on the clipboard before capture was still on it afterwards.

The interactive-desktop requirement doesn't affect me. Excel runs on a local desktop session here, not over RDP. I have not re-run this over MCP yet, since the server process in memory is still the previous build; I'll follow up here only if the MCP path behaves differently after the next restart.

One observation on the new capture path. It isn't tied to protection (it reproduces with the sheet unprotected), so I kept it out of the matrix above: captures that use the full window height come out with a ~4 px dark horizontal strip that looks like the bottom chrome of the Excel window. On ranges tall enough to be captured in several passes, that strip lands inside the stitched image at every seam.

Range	Output	Dark rows (row average below 160 of 255)
A1:N30	924x675	none
A1:A45	62x952	y=939-951, the bottom edge
A1:AZ120	1372x1080	y=950-953
A1:A200	26x1800	y=950-953
A1:A400	26x3600	y=950-953, 1904-1907, 2858-2861, one per seam, period ~954
A1:A200 --quality High	35x2400	y=1267-1271

If that strip is the bottom edge of each captured pass, trimming it before stitching would cover both the seams and the single-pass case. Happy to open it as its own issue with the images attached if that tracks better than a note here.

Thanks for the quick turnaround, and for replacing the capture path rather than catching the error at the chart insert. The clipboard and dirty-workbook behaviour went with it, and neither was something I had reported.

[sbroenne]

@fugulab — thank you, that was an unusually useful bug report. The pixel measurements and especially the ~954 px period were what made this a five-minute diagnosis instead of a fishing expedition, and you were right that it had nothing to do with protection.

You found a real defect that I introduced with the window-capture rewrite. Fix is up in #793.

Root cause. I sized each capture tile from Window.UsableHeight. That property describes the whole workspace, which includes the horizontal scroll bar and sheet tab strip below the grid — it is not the grid. Measured here at 192 dpi:

UsableHeight	558 px
trailing edge of last visible row	532 px
leading edge of last visible row	494 px

So every tile reached 26–64 px past the last painted row, and the tiler dutifully stitched that chrome in at each seam. Your period of ~954 px is exactly one viewport height on your display.

Fix, three parts:

1. The grid area is now measured from Window.VisibleRange rather than taken from UsableHeight, stopping at the leading edge of the trailing partially-visible row and column, with a one-row safety margin (Excel can report a trailing row whose leading edge is already past the painted grid — I measured 5 px of overshoot at 38 % zoom).
2. The tile layout is rebuilt after the capture zoom is applied. Row and column headers scale with zoom, so a layout planned before the zoom disagreed with the post-zoom pane by a pixel and left a hairline gap at each seam.
3. Canvas offsets and tile sizes now come from a single number, so the space reserved on the canvas is exactly what the tile can supply.

Regression tests. Two integration tests fill the captured range solid black, which makes leaked chrome trivially detectable — every pixel row of a correct capture is the fill, so any row that is not is chrome. Confirmed failing against the shipped v1.10.8 code first, reporting exactly your bands:

Capture of A1:A200 contains 32 pixel row(s) that are not the solid fill:
  y=542..546, y=1089..1093, ...

Both pass now, and the full screenshot suite is 21/21.

One thing that will remain, and I want to be upfront about it rather than have you re-report it: a real screenshot includes the active-cell outline. If the selected cell sits inside the range you capture, its border renders into the image. That is inherent to capturing the actual window and is not something I plan to paper over — but if it is a problem for your use case, say so and I will look at parking the selection outside the captured range during capture.

I will ship this in the next patch release and ping you here when it is on NuGet and the Marketplace. If you would rather verify sooner, the branch in #793 builds standalone.

Thanks again — two precise reports in a row on this one.

[sbroenne]

@fugulab — the chrome-strip fix is shipped in v1.10.9 (#793 merged): NuGet, VS Code Marketplace, and the GitHub release are all live.

Recap of what changed since your report:

• The capture now measures the real worksheet grid instead of trusting Window.UsableHeight, which includes the scroll bar and tab strip. That is what was leaking into every tile.
• The tile layout is rebuilt after the capture zoom is applied, so the canvas and the tiles agree to the pixel. Without that there was still a hairline gap at each seam.
• The fallback path used when Excel exposes no measurable visible range was trimmed the same way, so it cannot reintroduce the strip either.

Two regression tests fill the captured range solid black and fail on any pixel row that is not the fill, so a future change that reaches into the chrome breaks the build. They were confirmed failing against v1.10.8 first, reporting exactly your bands.

When you get a chance, could you re-run your matrix on v1.10.9 — particularly a full-height capture and a stitched multi-tile one, since the seams were the worst case? I am leaving this issue open until you confirm.

One expected leftover, so you do not have to re-report it: the active-cell outline renders into the image if the selected cell is inside the captured range. That is inherent to capturing the real window. Tell me if it gets in your way and I will look at parking the selection during capture.

Thanks again for the measurements — the ~954 px period was the whole diagnosis.