SCDPM 2022 rollupU3 Secondary DPM

For an MSDPM 999 crash while the protection group wizard is finishing, use the DPM crash data to identify which DPM service is failing, then verify the common service and database conditions that cause console crashes.

1. Check Application Event Log at the crash time
   • Open Event Viewer → Windows Logs → Application.
   • Look for entries with Level = Error and Source = MSDPM or another DPM service at the exact time the console crashes.
   • Open the event and review the General tab. It should identify the service/process that crashed and may include an error code.
2. Check the DPM error logs and crash files
   • Review the DPM error logs in the default folder: C:\Program Files\Microsoft System Center\DPM\DPM\Temp\
   • Look for the current error log for the failing service, named like: <service>curr.errlog
   • If a service crashed, also review the generated .crash file. The crash details are recorded at the end of that file.
   • This is the primary place to confirm whether the failure is tied to a service account issue, database connectivity issue, or another service-specific failure.
3. Verify required DPM services are running If the console crashes during launch or while completing the wizard, confirm these services are running:
   • MSDPM
   • DPMRA
   • SQL Server Agent for the DPM instance
   • SQL Server for the DPM instance
   • Virtual Disk Service
   • Volume Shadow Copy Service
   • DPM Access Manager
   • DPM Writer
   On Windows Server 2016 or later, also make sure Hyper-V Virtual Machine Management is running.
4. Check SQL service accounts if any DPM-related service fails to start If a service shows Error 1069: logon failure, verify the Run As account and password.
   • Most DPM services should run as SYSTEM.
   • The SQL Server services may use another account only in specific configurations.
   • For SQL services, use SQL Server Configuration Manager to validate or change the account.
5. Check whether the DPM database is stuck in recovery mode A DPM database left in recovery mode can cause service connection failures and console issues. Run this query against DPMDB:

      select * from tbl_DLS_GlobalSetting
      where PropertyName like 'DbRecovery'
   

   • If PropertyValue is 1, the database is in recovery mode.
   To clear it:

      update tbl_DLS_GlobalSetting
      set PropertyValue = '0'
      where PropertyName like 'DbRecovery'
   

   Then restart the DPM service and test the wizard again.
6. If services are timing out during startup If the service accounts are correct but a service is timing out while starting, a timeout increase can help. Warning: editing the registry is a system-level change. Incorrect changes can affect service startup behavior. Check or create this registry value:
   • Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
   • DWORD: ServicesPipeTimeout
   • Value: 300000
   The value is in milliseconds. Restart the service after changing it.
7. If the crash is tied to protecting SQL data sources One documented DPM crash case is when multiple SQL VSS writers enumerate the same SQL 2005 data source. In that case, the MSDEVersionChecking registry value must be set to 1 so only MSDEWriter enumerates the SQL 2005 databases.
8. If this started after rebuilding and restoring DPM If the environment was rebuilt and the issue points to database compatibility, note that error 3700 means an incompatible DPM database version was detected, and the documented action is to restore a valid database.

Given the current symptoms, the most direct path is:

• capture the exact MSDPM 999 event details,
• inspect the matching curr.errlog and .crash file in DPM\Temp,
• verify all required services and SQL service accounts,
• check DbRecovery in DPMDB.

• Troubleshoot Data Protection Manager console crashes
• Troubleshoot Data Protection Manager console crashes
• Troubleshoot application protection in System Center Data Protection Manager
• System Center vNext Data Protection Manager error codes