Share via

MARS Files & Folder backup failing

P.M 20 Reputation points
2026-04-14T17:56:33.79+00:00

I have an issue with the Files & Folder backup through MARS agent, for which Claude points me to a deterministic error with cbengine.exe 2.0.9506.0, which is the latest agent version as downloaded from Azure Porta. By any chance, is there a new version available with a fix for this? Or any other recommendations for fixing this?

System State backup running fine btw.

herewith details as investigated by Claude;

Current status

ItemStateOBEngine serviceRunningcbenginePID 16676 alive since 11:56:44 today — idle, emitting ETW "Buffer Filled" telemetry (no active job)Last C:\ backup attempt****CRASHED at 11:56:40 (4 min in) — cbengine.exe 0xc0000409 @ ucrtbase.dll+0x6d288, faulting PID 0x4de4. Third identical crash in 3 consecutive attempts post-cleanup.Last successful jobSystem State, 4/13 01:00–02:11 UTCVSS shadow storage on C:64 GB (27%) — intact; Used 0 at crash (never reached transfer phase)Auto-retry cadenceDaily @ 00:50 (was hourly/indefinite)Auto-updaterOKBlocker****Deterministic bug in cbengine 2.0.9506.0 — reproduces on clean scratch state. No self-service fix.Next action****Open Azure Support ticket; suspend weekly schedule until hotfix delivered---

What happened — summary

Before the cleanup (00:57–11:00), cbengine was crash-looping immediately on startup (0xc0000409 in ucrtbase.dll) triggered by stale VHDs and corrupted crash-job state left over from failed backups dating back to April 5.

After the cleanup at 10:55, cbengine started cleanly, connected to Azure, and entered the backup preparation phase (dscontext state 18 — VHD extension). It has been running without crashing since. The "same pattern" of log rotation and ETW flood is noise from the VHD extension activity, not a crash indicator.

Root cause of prior crash loop: stale scratch state + cbengine bug (0xc0000409)

Every backup attempt causes cbengine.exe to crash immediately with:

  • Exception: 0xc0000409 — STATUS_STACK_BUFFER_OVERRUN
  • Faulting module: ucrtbase.dll, always at offset 0x000000000006d288
  • Version: cbengine.exe 2.0.9506.0

The same fault offset every time indicates a deterministic bug in this version — the C runtime security cookie check (_report_gsfailure) detects stack corruption on a specific code path every backup run. The backup never progresses past start-up.

Crash history (from Windows Application event log)

DateTimeNote2026-04-0503:10, 04:00, 04:52, 05:52First crashes — backup job attempted2026-04-0603:00CrashJobs.txt written (4 job GUIDs)2026-04-1203:05, 05:56Two more crashes2026-04-1300:57–03:00Crash loop — 20 log files rolled in ~3 minutes

ETW Log flood example;

CTraceProvider::GetTraceBuffer TraceBufferIndex: 0,Current TraceBufferSize:0, NumEvents:0
4E98	0328	04/14	14:15:12.073	69	PrepProxy.cs(3351)				WARNING	Error listening on Trace Buffer filled Event. 
4E98	0328	04/14	14:15:12.074	69	PrepProxy.cs(3492)				NORMAL	Uploading to Telemetry upon:Buffer Filled 

CTraceProvider::GetTraceBuffer TraceBufferIndex: 0,Current TraceBufferSize:0, NumEvents:0
4E98	0328	04/14	14:15:12.074	69	PrepProxy.cs(3351)				WARNING	Error listening on Trace Buffer filled Event. 
4E98	0328	04/14	14:15:12.074	69	PrepProxy.cs(3492)				NORMAL	Uploading to Telemetry upon:Buffer Filled
Windows for business | Windows Client for IT Pros | Performance | Application technologies and compatibility
0 comments

Answer accepted by question author

VPHAN 35,285 Reputation points Independent Advisor
2026-04-14T18:44:33.97+00:00

Hi P.M,

The crash loop you are encountering is a deterministic code defect in MARS agent version 2.0.9506.0. The 0xc0000409 exception code translates to a STATUS_STACK_BUFFER_OVERRUN, meaning the Universal C Runtime's security checks intercepted a stack corruption attempt and intentionally killed cbengine.exe to protect the system. Because your System State backups succeed and the analysis confirms the crash persists even after purging the local scratch folder, the agent is failing during a highly specific operational phase. The mention of dscontext state 18 indicates the engine is struggling with VHD extension, meaning it is likely choking on a specific underlying storage quirk or an edge-case file path during the initial metadata compilation before the actual data transfer begins.

Before modifying your backup policies, verify that the drive hosting your scratch folder, typically defined in the registry at HKLM\SOFTWARE\Microsoft\Windows Azure Backup\Config\ScratchLocation, is formatted as standard NTFS, has at least ten percent free space, and is not heavily fragmented. Sometimes, storage API timeouts during VHD allocation can trigger unhandled exceptions in the backup engine. If the storage environment is perfectly healthy, isolating the problematic directory through trial and error remains your only self-service mitigation until a new binary is released.

To actually get this resolved, you must escalate the issue to Azure Support to request a private hotfix, but you need to provide them with actionable engineering data. The ETW telemetry flood showing buffer filled events is just benign diagnostic noise and will not help their developers. Instead, you need to force Windows to capture a full user-mode memory dump. You can do this by navigating to HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps in the Registry Editor, creating a new key named cbengine.exe, and creating a DWORD value inside it named DumpType set to 2. Run the backup manually to reproduce the crash, and Windows will automatically generate a .dmp file. Provide that dump file along with the exact faulting offset at 0x6d288 to the support team so they can pinpoint the unhandled variable and patch the executable.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-14T17:56:53.65+00:00

    The latest documented guidance is to move to a MARS agent version that is at least 2.0.9250.0 (to use the newer Azure Data Box / Import-Export APIs) and, more generally, to stay on the current MARS release from the Microsoft Download Center or via the Azure portal. The context provided does not list a version newer than 2.0.9506.0 or any hotfix specifically for a cbengine.exe 0xc0000409 crash.

    From the available information, the only supported actions are:

    1. Ensure the MARS agent is fully up to date
      • Download and install the latest MARS agent from the Microsoft Download Center or via the Recovery Services vault (the context shows 2.0.9251.0 and earlier mandatory updates, but not beyond 2.0.9506.0).
      • If already on 2.0.9506.0 from the Azure portal, there is no documented newer build or hotfix in the provided material.
    2. Validate cache (scratch) configuration and VSS prerequisites Even though the crash looks deterministic, Microsoft’s troubleshooting guidance still requires verifying cache and VSS:
      • Confirm the scratch folder volume has at least 5–10% free space.
      • Ensure the scratch folder path is valid, accessible, and its file attributes are supported.
      • Make sure no antivirus or other process is blocking <InstallPath>\Scratch\*, <InstallPath>\Bin\*, or cbengine.exe.
      • Verify shadow copy storage on the protected volume is sufficient and, if needed, increase it with vssadmin Resize ShadowStorage.
    3. Check for known conflicting components
      • For other MARS crashes, Microsoft documents conflicts with Azure File Sync (StorageSync.sys) and recommends disabling that driver when it causes OBEngine/cbengine failures. If Azure File Sync is present, test with StorageSync.sys disabled.
    4. Open a Microsoft Support case
      • The context does not provide any public fix or newer version that addresses a ucrtbase.dll stack buffer overrun in cbengine.exe.
      • Given the deterministic nature of the crash and that System State backups succeed, the next step is to open an Azure Support ticket against Azure Backup/MARS, provide the crash details (event logs, dump if available, and MARS logs), and request a product-side fix or private hotfix.

    There is no documented self-service fix or newer public MARS version in the supplied material that resolves this specific cbengine 2.0.9506.0 crash.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.