You can diagnose failing or slow server-side actions by capturing exception details in the ViewModel, correlating server jobs in the log, and inspecting current and recent work in MDrivenServer administration pages.

Start with the server-side job

A server-side job is a ViewModel action that MDrivenServer executes without a logged-in user. Before investigating an error, verify that the job is eligible to run:

1. Check that the server-side selection expression finds the objects you expect.
2. Check the action's enable or disable expression.
3. Check access groups. A server-side ViewModel has no logged-in user, so its access setup must allow execution by the server.
4. Open /admin/AdminAppPeriodicActions.aspx to see executed actions.

For example, if the log says Skipped <actionsname> due to enable==false <Viewmodelname> touched 0 objects, first check whether the enable/disable expression evaluates as intended, then check the ViewModel access groups and default access group.

For setup details, including server-side access-group patterns, see Documentation:Serverside actions. For periodic-action selection and execution behavior, see Training:MDrivenServer periodic server-side actions.

Save exception information in your model

You can add named columns and an action to the root ViewModel class to capture information when a server-side ViewModel throws an exception. This error-handling support was added in the September 2019 release.

When an exception occurs, MDrivenServer performs the available steps in this order:

1. Sets an ErrorInfo-prefixed column.
2. Sets an ExceptionInfo-prefixed column.
3. Calls an OnException-prefixed action.

The names are not case-sensitive, but each name must start with the stated prefix. You may omit any of these members that you do not need.

Add to the root ViewModel class	Requirement	What MDrivenServer does
ErrorInfo...	A string column, normally less than 255 characters	Stores error information.
ExceptionInfo...	A string column intended for longer text	Stores exception information, typically including a call stack. The text is truncated if necessary to fit the target attribute.
OnException...	An action	Runs after the two information columns have been set. The action can receive ErrorInfo and ExceptionInfo as string variables and use them in its logic.

Example: persist an error summary

Add the following members to the root class of the server-side ViewModel:

• A string column whose name starts with ErrorInfo, such as ErrorInfo.
• A longer string column whose name starts with ExceptionInfo, such as ExceptionInfo.
• An action whose name starts with OnException, such as OnException.

Use the OnException action to process the supplied error strings in the way your model requires. If that action tries to send email, it must also have the columns required by the email action; otherwise, the email action fails.

Transaction behavior

Changes made by the server-side ViewModel before the exception are rolled back before the error-handling steps above are applied. Design OnException with this in mind: use the exception information for handling or recording the failure, rather than assuming earlier changes from the failed execution were saved.

Inspect activity in WorkInfo

Open /admin/WorkInfo.aspx to get an overview of MDrivenServer work over short and long time ranges.

Read the graph from right to left:

• Work enters at the far right. The far-right edge represents work happening now.
• Bright red shows currently running jobs at the fastest time scale. A short job appears as a dot; a job that runs longer appears as a line.
• Bright-red activity passes across the full timeline in about one minute.
• The other colors show the same work at slower time scales. Blue is the slowest scale and stays visible longer, but has lower time resolution.

Start with bright red when investigating a current problem. Then use the slower colors to determine whether the same job has been running repeatedly or for an extended period. A long duration, or work that remains ongoing, can indicate database locks, missing indexes, or poorly constructed server-side jobs.

Check WorkInfo through the API

The WorkInfo graph information is also partly available through an API endpoint:

https://your-host/api/ServiceAdmin_WebApi/CurrentWorkInfo

Authenticate with a Basic Authorization header for an MDrivenServer user. The response contains work entries with a name, start time, and duration. A duration of negative one second means that the work is still ongoing.

[
  {
    "Name": "Evolve",
    "Started": "2026-03-31T17:01:14.2785393+02:00",
    "Duration": "00:00:00.1238185"
  },
  {
    "Name": "Watch_MainTimerTick",
    "Started": "2026-03-31T17:01:24.1734076+02:00",
    "Duration": "00:00:00.0003750"
  }
]

Monitor entries with long durations and -00:00:01-style ongoing durations when diagnosing stalled work. Compare the entry name and timing with the server log and the WorkInfo graph.

Correlate entries in the server log

Open /admin/Log.aspx to inspect actions recorded by MDrivenServer. Several jobs can execute in parallel, so their log lines can be interleaved. Use the job number shown with a log entry to identify messages that belong to the same server job.

For example, when one action fails while other periodic actions continue, filter your investigation by that shared job number rather than reading adjacent log lines as one execution.

See Documentation:MDrivenServer log and Documentation:Turnkey and MDrivenServer logs for log access and related log troubleshooting.

Reproduce a server environment locally

If you have MDrivenServer source code and need to debug an environment locally, you can copy the server's compact settings database into your local development environment. This reproduces connection strings and other server settings that may be relevant to the failure.

The compact database is located at:

AppCompleteGeneric\AppCompleteGeneric.PServerIis\App_Data\DatabaseCompact.sdf

1. In the MDrivenDesigner Portal window, create a snapshot and download DatabaseCompact.sdf from the server. You can also obtain the file manually.
2. Preserve your local copy so that you can restore it later.
3. Replace the local development environment's DatabaseCompact.sdf with the downloaded server copy.
4. Reproduce and debug the issue locally.

Do not leave two MDrivenServers active against the same environment while investigating the issue. Two servers create two client-synchronization queues, which makes the behavior and diagnostic evidence harder to interpret. Stop the other server while you search for the error.

Debug related custom code

This page covers diagnosing server-side ViewModel execution. If the failure is in CodeDress or Turnkey generic code, use the dedicated debugging procedures instead:

• Documentation:Debug CodeDress
• HowTos:Debug Turnkey Generic Code
• Documentation:CodeDress

Catching Debug Info and Saving it to Your Model

You can add root ViewModel columns named:

• ErrorInfo (not case sensitive, must start with) - string typically less than 255 char
• ExceptionInfo (not case sensitive, must start with) - string typically long with a callstack - we will truncate to fit target attribute
• OnException (action, not case sensitive, must start with)

If an exception occurs in a serverside ViewModel, we will set ErrorInfo, ExceptionInfo and lastly call OnException action.

The email action above will fail since we have not provided the needed columns for sending an email.

Logging and Information on What the Server Does

You can also review scheduled actions in the administrative interface: To see what actions have been executed, look them up in admin/AdminAppPeriodicActions.aspx

You can also get an overview of what runs when by looking at /admin/WorkInfo.aspx

The workinfo page is really good at giving an oversight of what the server does, both in the short and long term. Do not get intimidated by all the colors! Start by ignoring all the colors except bright red. The bright red refers to the running jobs - they come in from the right - far-right are the jobs happening NOW. As time passes, they move to the left. A job that starts and stops directly shows up as a dot - but as it is running for some time, a line will form. The problem with the bright red speed is that it will pass the whole timeline in one minute. This is why we have the other colors! These are the same job on another scale. The blue is the slowest - and what was a red line might show up as a blue dot due to the much lower resolution than the red, but the good thing is that it stays on the screen for a longer time. The colors between red and blue are other resolutions in between the two described.

x

Check logs in UI

Then you will always see actions in the log at admin/Log.aspx:

x

Generic Tip on How to Debug the MDrivenServer if You Have Source Code

The MDrivenDesigner Portal provides a way to download the server database: In the MDrivenDesigner Portal window, you have the option to snapshot and download the DatabaseCompact from the server - even if this can be done manually as well:

Consider stopping the server while searching for the error since 2 MDrivenServers mean 2 Client Synchronization queues - and that will confuse everyone.

See also

• Documentation:Serverside jobs
• Documentation:Serverside actions
• Training:MDrivenServer periodic server-side actions
• Documentation:MDrivenServer log
• Documentation:Turnkey and MDrivenServer logs