VeeamDCS (Veeam ONE Monitoring Service) crash loop on Windows Server 2025 — 0xC0000005 at "Initializing alarm cache" and

[dfidalgo]

Hi everyone,

I'm investigating an issue with Veeam ONE 13.0.2.6723 where the Veeam ONE Monitoring Service / Veeam Data Collector Service (VeeamDCS) is continuously flapping. The service starts, runs for a short time, then crashes and restarts again every few seconds/minutes.

The issue started after updating to Veeam ONE 13.0.2.6723. In Windows Services, the Veeam ONE services may appear as running, but the application is not healthy. The Veeam ONE Client cannot connect properly and shows a SQL/database-related configuration issue.

**Environment:**
- Veeam ONE 13.0.2.6723
- Windows Server 2025 Standard (Build 26100.32995 — fully patched as of June 11, 2026)
- SQL Server 2017 (local instance VEEAMSQL2017)
- PostgreSQL 17 (local)
- Standalone/workgroup server (not domain-joined)

**Problem:**
VeeamDCS crashes in two distinct patterns since initial installation on May 29, 2026:

**Crash 1 — Alarm cache (persistent since day 1):**
```
"Initializing alarm cache..."
→ Exception Report: Unhandled exception occurred with code 0xC0000005
```
Root cause identified: `monitor.AlarmState` and `monitor.AlarmStateHistory` tables were missing from the VeeamONE database after fresh installation. MSI repair created the tables with correct schema (`id, triggered_alarm_id, assign_alarm_id, entity_id, status, time, triggers_config xml NOT NULL, param xml NULL, remarks nvarchar NULL`) but crash persisted regardless. Resolved by creating a new database (`VeeamONE2`) — the original `VeeamONE` database had an unrecoverable schema corruption from a failed first-run initialization on May 29.

**Crash 2 — OneAgent pipe client (occurs after adding VEM data source):**
```
"New local client pipe_1, PID: XXXX"
"Pipe client started"
→ OneAgent: Exception Report: Unhandled exception occurred with code 0xC0000005
```
Occurs approximately 90 seconds after VeeamDCS starts, immediately after the Veeam Analytics Agent connects via named pipe to VeeamDCS. This crash is triggered by the Agent→DCS communication, not by database issues.

**Dump analysis (crash 1):**
- Exception code: `0xC0000005` (Access Violation — READ)
- Faulting address: `0xFFFFFFFFFFFFFFB4` (null pointer dereference at offset -76)
- Crashing module: Veeam native DLL (v2.6723.0.63, size 0x131000) at offset `+0xBF256`
- Call chain: `VeeamDCS.exe → Veeam.One.*.dll (+0xBF256) → SQL ODBC (mod+0x1291B) → ntdll syscall`
- RAX=0x0 at crash (null return from database query)

**What has been tried (all failed):**
- Fresh SQL Server + PostgreSQL databases
- Complete product uninstall + reinstall
- MSI repair (`VeeamONE.Monitor.Server.x64.msi /fecms`)
- OS fully patched (26100.1742 → 26100.32995)
- en-US locale change
- Windows Defender exclusions
- Multiple server reboots
- Different database names (VeeamONE2 fixed crash 1, but crash 2 persists)

**Current status:**
- Crash 1 (alarm cache): **Resolved** by using fresh database `VeeamONE2`
- Crash 2 (OneAgent pipe): **Active** — VeeamDCS crashes every time the Analytics Agent connects after adding VEM as data source
- Support case open: Contract ID 08121184

**Question for R&D:**
1. Is there a known issue with VeeamDCS 13.0.2.6723 crashing on Agent pipe connection on Windows Server 2025?
2. Is there a way to disable the OneAgent pipe communication temporarily while keeping backup monitoring data collection active?
3. What is the correct workaround for the `monitor.AlarmState`/`monitor.AlarmStateHistory` missing tables on fresh install — is this a known installer bug?

Regards,
Diego

[RomanK]

Hello Diego,

Thanks for the case number. I can see the case has already been escalated to R&D and is currently being worked on.

Answering your questions:
1. All known issues must be fixed or documented, so this is not something known so far.
2. I found no documentation stating this is allowed and tested.
3. There shouldn't be any missing tables on a fresh install for sure.

The forum isn't really the right place for detailed troubleshooting, the support case is where this is best handled, since the engineers can dig into logs and your specific environment. Please continue working with them. I'm confident they'll find the cause of this issue.

Thanks